人人都是产品经理|如何让PM完成需求评审而不被打？( 二 )
而不是说那句表面上让大家无法拒绝 ， 但是实际会非常掉底子的一句话：这是老板的需求 。
一般的需求价值包括：需求符合公司的战略目标吗？需求能带来直接的收益吗？需求能提升用户体验吗？需求能提高效率或节省成本吗？
和团队成员达成共识的目的 ， 是为了防止大家出工不出力 。 和大家就这些需求的价值达成一致 ， 有助于更好的完成需求开发 。
毕竟一个人从内心认可一件事的动力 ， 和因为外力强迫不得不做的动力 ， 那是天壤之别 。
讲解需求要从整体到局部 。 不要一开始就扎到细节里 ， 否则大家也会跟着你去抠细节 。
而需求评审并不是抠细节的 ， 需求评审的主要目的是：传递需求的价值 ， 让大家认可这个需求可以做 ， 而不是被强迫传递功能的场景 ， 让大家理解功能所覆盖的用户和使用的场景明确需求实现的方式 ， 划分大致的任务和排期
我们要先从整体对需求的流程做一个梳理 。 一般都是从用户的角度 ， 对用户使用这个功能的流程进行一个整体的梳理 。
就像你在看一本书时 ， 当读到一半的时候 ， 就忘记之前是讲什么的了 。
我们会发现很难将书中的知识串起来 ， 这个时候往往都会选择打开目录 ， 通过看目录来帮我们回忆起之前的章节内容 ， 从而将这些内容都串联起来 。
需求评审如何从整体开始？我们以优惠券需求为例 。
评审优惠券相关的需求 ， 就可以从优惠券的创建、优惠券发布、优惠券领取、优惠券消费 。
这四个大的步骤进行整体的概况说明 。 以此为需求评审的主线 ， 这样大家在听你讲解具体需求的时候 ， 不至于迷失在细节之中 。
本文插图
接下来 ， 描述该功能的使用场景 。 我认为产品经理 ， 最强大的软实力 ， 就是讲故事的能力 。
如何用一个故事把自己的想法表达清晰 ， 让大家易懂 ， 并且得到大家的一致认可 ， 是产品经理最难能可贵的能力 。
在讲解具体功能逻辑之前 ， 可以先描述下具体的功能使用场景 。
这样有利于大家理解这个功能：功能的用户是谁？用户通常在什么场景下使用这个功能？用户当前在这个场景下遇到了什么困难？我们的功能是怎样帮助用户解决问题的？
以场景的角度来描述功能 ， 同时也是进一步让大家理解做这个功能的价值所在 。
而且产品经理在思考功能的使用场景时 ， 也是进一步思考是否有必要做这个功能？怎么做这个功能才更好的机会？
而且 ， 让大家明确该功能的场景 ， 有时候会有惊喜 。 有时候对于一些你认为比较复杂的功能 ， 大家在明确背景的情况下 ， 有可能可以想到更简单的方案 。
详略得当 ， 不要毫无重点地长篇大论 。 哪些该讲？哪些不该讲？
这个要看团队之间的默契 。 如果是初期合作 ， 大家都不太了解彼此的时候 ， 建议要尽量详细 。
不要自以为某些功能很常见 ， 例如输入框的一些交互 ， 就省略不讲 ， 到最后开发没做 ， 就只能自己背锅 。
对于配合默契的团队 ， 可以根据团队的习惯 ， 忽略掉一些以前做过的东西 ， 或者一些常见的东西 ， 比如输入框的校验规则等 。
回答并记录问题 。 需求评审大家肯定会提出很多问题 ， 有的是质疑需求的必要性 ， 有的是指出需求的不完整 ， 或逻辑的缺失 ， 有的是讨论需求的实现方式等 。
有的问题可以直接回答 ， 例如需求的逻辑问题 ， 实现问题 ， 必要性问题等 。
而有的问题则可以不回答 ， 例如自己没有想清楚的问题 ， 一些比较细节的问题 ， 而且这些细节不涉及其他同学 ， 会后单独私聊就可以解决的 。
自己没有想清楚的问题 ， 千万不要因为要面子强答 ， 那只会让自己更丢脸 。
如果是简单的问题 ， 可以直接想一下然后回答 。
推荐阅读
- 互联网|中台产品经理实战(14)：中台与SaaS、微服务关系
- |产品入行3年，我总结了这些“情怀”
- 内部|容易被忽视的「内部营销」：你的产品感动你的员工了吗？
- 产品|全国唯一户外15米远距离AI测温系统深兰猫头鹰获工信部嘉奖
- 5G手机,vivo手机|7月最值得入手的三款vivo，都是内行人的最爱，用三五年不过时
- |框架思维，可能是产品经理的核心能力
- |想用触摸板但妙控键盘太贵？那考虑下罗技的产品吧
- 融资并购|心玮医疗获投数千万美元 专注脑卒中预防和微创治疗 已完成多个产品塑造
- |万胜智能产品售价显著高于同业，人力成本标准却偏低
- 行业互联网|原创 寡头西门子推高中高端洗碗机表现，国产品牌逆袭机会不仅是拼价格