WHAT
1、需求评审是什么
需求评审不仅仅是流程中的一个环节。需求评审串起了前期的需求收集和分析，不同利益相关方的博弈，以及后续项目落地实施的计划管理等各个方面。
2、需求评审的受众与目的
（1）向需求方以及其他利益相关方详述自己对需求的理解和分析，明确自己的需求分析与他们的原始期望是一致的。
（2）向实现需求的团队（设计、研发、测试）说清楚需求的背景和来龙去脉，交代为什么要做。
（3）向需求方交代具体的产品解决方案。如何出现在用户场景中，产生什么关系，发生什么变化。
（4）向实现团队交代清楚产品解决方案。要做什么东西，怎样运转，有什么特性。
3、需求评审与会人员，安排议程
需求方：2B是业务或运营团队，2C通常由产品经理本身充当。
实现方：设计、研发、算法、测试、运维。
如果一次串讲，既能与需求方达成一致，也向实现方交代了背景；既能让需求方明白产品方案，也可以让实现方清楚特性列表，那就一次性搞定。
如果有实际情况（如开发团队外包）或者有流程障碍（如产品方案实现细节的讨论冗长且专业），那就根据具体情况去拆分会议。
结合目标来安排议程，通常先讲业务，再讲方案。
4、提前准备需求评审
需求评审应该是凯旋的钟声，而不是冲锋的号角。
会前沟通：一般是小范围的，针对一些细节点深入、频繁地与具体的相关人员交换信息，达成一致。包括业务部门和工程师。这样，评审流程中可能发生分歧的点都考虑到并且进行过讨论，不会让与会人员感到“意外”。
提前发出材料：提前让大家熟悉一下评审内容。产品经理需要一对一跟进，意识到不同的人关注不同的内容，然后非常具体地指出来，再让对方去提前读。材料一定要专业和严谨，让大家在潜意识里重视起来。
准备材料和议程：材料至少包括需求文档，议程至少包括讲业务、讲实现、评审讨论。大规模需求评审还需要准备幻灯片。和项目启动会一起开，还需要准备项目计划。
HOW
1、换位思考
知识的诅咒：当一个人拥有某种知识之后，就很难想象和模拟出不知道它时的状态。
做宣讲或者评审需求的时候，要像做产品设计的时候一样，把自己放到听众的上下文中去，把来龙去脉讲清楚。尽可能从所有人都了解的背景开始讲，逐渐向外延伸，像讲故事一样。（大部分人听到自己已经知道的事情时会有安全感，以此为基础延伸开来，才能让听众感到踏实和好奇，摆脱知识的诅咒。）
2、不要强迫，要用“具体”来吸引
与其对着文档照本宣科，不如从场景和故事出发（此处可以用一些技巧，例如动画），用具体的案例来跟通知沟通。先整体地介绍业务，大的逻辑和背景，然后用一个实际的业务案例把相关的功能和流程串讲一遍，最后回到文档本身，把需求文档从头到尾过一遍。
3、用态度感染
产品经理在评审时一定要有信心，并且在评审过程中传递这样的信心。自信者，人恒信之。除了日常建立的影响力和信任之外，在评审过程中表现出来的信念和气势也非常重要。没人愿意跟软蛋合作，尤其是产品经理。
4、不要为了赢而争吵
不要因为是在自己的舞台上，就为了捍卫自己而争吵。产品经理要对自己的情绪活动敏感，当意识到是因为自尊而开启战斗模式的时候，需要尽快刹车。
发生冲突时，及时摁住情绪，把态度描述忽略掉，用陈述句去复述提问人的意思。“所以我理解你的意思是...”“我理解一下，你是想说...”。用这样的风格不断复述的同时，可以引导他把问题背后的问题说出来。这个过程的目的是通过他的反对找到有建设性的建议，而不是赢得争论。另外还能让对方意识到自己的情绪，引导对方回到冷静讨论的范围，而不是继续抬杠。不要让情绪影响了判断，更不要让赢得争吵取代做好产品成为你的评审目标。
如果没能控制好情绪，或者发现陷入细节无法自拔了，一定要有礼貌地喊停，先搁置争议继续后面的内容，不要浪费其他人的时间。
PS：小公司、创业团队可以没有大型需求评审会议，但最好有需求评审的过程。可能是跟工程师小范围的需求串讲，也可能是产品经理自己在脑海中对自己的一次模拟评审。
这是黄西西的第3篇产品笔记。上课需要做笔记哦，learn from邱岳。
网友评论