第六章：需求评审如何进行

Posted 2020-10-15

前言
今天我们讲的需求评审包括两个部分，需求过滤和需求评审。

需求过滤

1.需求分析
不是所有需求都要做进产品，我们要根据公司和产品的定位，进行合适地分析和过滤。

我们需要分析出用户需求所对应的本质，将其转化为产品能够提供的解决方案，即“将用户需求转化为“产品需求”。

苏杰在《人人都是产品经理》中就将这个过程归纳为“需求的DNA检测”。
（1）确定需求基本属性：负责该需求的PM、需求属于产品哪个模块、需求描述等。
（2）需求的商业价值。
（3）需求的实现难度（工作量）。
（4）需求的性价比（价值/工作量）。

同时需求决不能马虎，简单的记录需求是对自己产品不负责任的一种行为。下面给一个需求记录的借鉴格式：

需求DNA检测表格

2.需求过滤
需求分析之后需要进行需求过滤，一方面过滤性价比低、不符战略的“伪需求”，另一方面要排列需求的优先级，便于产品开发计划的制定。

这一环节非常关键，如果过滤不够合理的话，就会发生被砍的事件......

3.概念过滤
对于创业团队或是企业新项目，则需要对产品的整体概念进行过滤。这里我们直接引用《结网》里对概念过滤的6个问题：
（1）这个概念的原始出处在哪里，全球最佳实践在哪里？

（2）这个概念能为它的目标用户带来什么？

（3）进入的壁垒是否过高或更低？

（4）哪些用户会从中受益，他们是男是女，年龄多大，有多少人？

（5）这个概念是否有商业模式？

（6）它是否能够成为平台或现金牛，在公司的战略布局中将处于什么位置？

这里强烈建议大家阅读《结网》原文中这一部分，对于产品人来说，这本书部分提供了产品知识很好的广度和深度。

需求评审
需求评审是在产品进入正式开发前，由产品经理、设计人员、研发人员等针对将要开展的工作内容，进行检查并提出问题的过程。

通常由产品经理组织召开需求评审会。

1.目的
（1）方案评审：评估方案的技术难度、实现周期、投入产出状况，互联网产品迭代速度快。

（2）产品介绍：让与会者清晰地了解产品、需求来源、预期收益等，明确个人在整个方案中的所处的位置、职责等，对各自负责部分的实现难易有一定心理准备。

（3）细节沟通：让技术与测试人员深刻了解产品方案，关注方案细节，便于后期高效开发，避免了后续反复低效的沟通行为。

2.评审准备
（1）提前与开发、测试、设计等团队沟通协调时间，确保关键角色都有时间可以参加，确定需求评审会的时间安排，订好会议室，通过邮件发出会议邀请，并确保所有人知道。

（2）提前准备好产品交互原型、产品需求文档，通过邮件等形式发送给与会成员，并要求与会成员抽时间查阅相关文档，并提出自己的问题。

（3）提前收集大家对于本次评审内容的问题，汇总好问题后逐一解答，以邮件的形式统一回复给大家。

3.评审会议
评审会议需要产品经理整体把握好，牢记评审的目的和任务，这里注意以下几点：
（1）把握方案框架，切勿死抠细节
（2）掌控节奏，切勿争吵
（3）认真倾听，做好记录

4.评审总结
需求评审之后要形成会议记录或评审报告，对参与人员、评审方式、评审地点、评审时间、评审内容、问题记录及处理意见、评审结论进行详细的记录。

产品经理要参考评审中各部门提出的意见完善方案，更新产品文档，制定后续工作计划，明确责任人及反馈排期。

再评审完成之后，意味着你即将进入广义的产品开发流程。