开需求评审会，你会出汗吗？

最近参与了一场需求评审会，我是参会人。会议中，产品小兄弟总是被打断、被质问、被挑战，一场评审会下来，他依次脱了羽绒衣、毛衣，只剩一件格子衬衫，整个人满面通红，像是冲刺了一公里，而我却在角落冻的瑟瑟发抖。

你有经历过在评审会中被问的面红耳赤、大汗淋漓吗？我有过，但现在淡定多了，可能是脸（不）皮（要）厚（脸）了，也可能是摸清了评审会中的常见问题。我总结了评审会中的4类典型问题与应对方案，如果你还害怕开需求评审，希望本文能帮你提前做好“战斗”准备，让你在评审时少出点汗。

问题清单

1如果XXX情况，怎么办？

类似的问题还有：你有没有考虑过这种情况？你这流程有问题啊？

问题本质：场景是否考虑完善；业务流程是否完整；

解决方式：利用各方意见反馈，完善产品方案；

有小伙伴提这类问题，是个好事！一是证明大家跟着节奏在对评审内容进行思考，二是这些问题能帮助完善产品方案。我们需要去倾听大家意见，不要感觉被挑战进而产生抵触心里。

如果所提的问题是已经思考并规划过，只是还没介绍到，我们可以直接反馈：你说的我有考虑，将在后面说；如果确实未提前准备，那也无需隐藏，虚心请教对方，也给出自己意见。多数情况下，这类问题并不涉及流程主体，比较容易快速给出判断与结论。如果一时间拿捏不准，建议会后讨论，不在会上展开。

需注意，这类问题都不应涉及核心业务场景与主体流程。如果主线都没考虑清楚，这评审会就不该开。

2这个功能做了没意义啊！为啥要做？

类似的问题还有：这功能做出来干什么都不晓得？

问题本质：需求背景描述不清晰。

解决方式：描述需求背景、用户故事

团队成员在参与评审过程前，很少会主动了解需求背景，查阅原型内容。即便产品经理已将原型等内容丢群里，提醒大家提前查阅，但懂的都懂。而在评审会期间，开发人员很容易钻入到某一具体功能如何实现、这个功能是否和原有矛盾等思考中，忽略了需求的背景与目的。

因此，产品经理务必在评审会刚开始时，明确需求场景，描述版本包含哪些功能、解决哪类用户的什么问题；在具体功能点评审前，强调该功能点的业务场景，说明用户故事。

产品经理给团队描述需求背景与用户故事的同时，也给团队“画了一张大饼”，让大伙知道了需求的重要性与意义。我们需要重视在“画饼”过程团队提出的意见，这时候的反馈很可能暴露了大方向的问题。建议在大家意见一致、目标一致后，再进行后续细节的评审。

03 这么搞我们又要重构了。

类似的问题还有：你根本没考虑系统现在情况！

问题本质：产品思维与开发思维的差异。

解决方式：辨别“真假重构”

重构是大事，往往在需求评审会前就已决定，并以一个独立版本来进行管理，评审会中的“重构”，更多的是原有产品功能的调整，是需求的变更。我们所主张的“需求是不断变化”开发不认，当有需求要调整时，他们更相信“重构”。你回想下，在评全新功能时，是不是听不到“重构”一词？

当开发会中提出“需要重构”时，我们无须慌张，以一个低姿态，去了解“重构”涉及哪些范围，为什么说要“重构”。通常情况下，“重构”是因为需求的实现要去查阅并修改原有不熟悉的代码或者已经知道涉及到的代码有坑难维护，开发希望产品经理不要动轻易改动，用“重构”一词提出抗议。我们需要向团队阐明，是用户在不同的时期对平台有着不一样的诉求，导致了需求的变更，并不是产品经理想改就改。当然，我们也要去理解、安抚可爱的开发，尊重他们的反馈，体谅他们的不爽。

另外，“重构”这一词在公司里有一定的敏感性，当老板听到某某某产品要重构、又要重构时，第一反应是之前的投入打了水漂，这将对整个团队带来潜在的影响。如果可以，请不要把“重构”一词挂嘴边。

4你这么设计还不如这样。

类似的问题还有：你直接把XXXXX；

本质问题：当前方案是否是最优实现方式

解决方式：阐明采用当前产品方案原因，吸取各方意见进行优化

这类问题也意味着，大家认同这个功能的预期成效，只是在实现方式上仍有分歧。

对于一个需求，因切入的角度不同，对应的最优方案也将不同。例如开发会从实现难度给出最优解，项目经理会从实现成本给出最优解，而我们需要牢记，我们是产品经理，需从用户角度，围绕业务目标思考最佳方案。

当然在多数情况下，产品经理需根据系统现状、资源现状、交付要求等进行权衡，但我仍然建议能有个理想化的产品实现方式，哪怕只是一个模糊的轮廓。在需求评审会中，我们可以简要说明理想方案，让大家对产品最终形态有一定认识。有心的开发会在实现过程中预留一些设计，便于后续扩展，待日后时机成熟，快速丰富产品形态。

在具体介绍当前方案时，我们需阐述当前方案所做的权衡，说明方案优势。当大家提出不同意见，去引导他们说出“为什么”，进而去评估是否需要调整当前方案。调整后的产品方案可能仍然无法满足所有人，但产品经理需要拍板明确最终实现方式，并让大家向着共同目标努力。

我们组织需求评审，为的是让团队明确产品目标与实现方式，暴露潜在问题。我们唯有直面团队的提问，并且逐一击破，才能完善产品形态，提升自我能力。

会议技巧

上面我们讲了4类需求评审会中常见问题，现在我们再来扩展说下开需求评审会的技巧与套路。我们需要高效的会议，避免一场会议持续好几小时，结束后发现毫无重点毫无主题，团队怨声不断。

01把控会议节奏

关于一场评审会的时间，我建议不超过一小时。超过一小时，大家的精神开始涣散，会议效率直线下降。回忆下高中的数学课，你能多长时间紧跟老师思路？对于我，超过半节课已属于超水平发挥。

而在这一小时的时间里，前半小时效率最高，因此我建议率先阐明用户故事，让大家从宏观层面对需求内容有所认知；率先描述重点内容，避免因死抠细节而忽略的主线内容。至于那些细节，我们需要在原型及PRD中清晰标注，当研发人员在编码对应功能时，自然会看到这块内容（也有很多不看文档直接开发的，那至少我们在后续撕逼中有了证据~）。

关于会议中的讨论，我建议控制在10分钟。如果提前做好了产品方案的沟通与确认，评审会期间的讨论不太会涉及核心问题。若讨论超出10分钟且没有结果，我们可以先将问题记录，会后和专人讨论确定结果后，再同步给大家。

有小伙伴问，在评审一个功能的时，是让开发随时提问，还是汇总到一个功能评审完成后集中反馈。我更倾向前者，特别是你对会议节奏有很强的掌控力，并且对产品方案十分自信的情况下，开发的提问通常都能快速解答，不会破坏会议进度。此外，你游刃有余的解答还会在团队心中树立不错的“威望”。但如果你还处于新手上路阶段，建议采用统一提问的形式，这能更好避免因频繁打断而造成的紧张、过程失控。

2提前沟通与确认

有时候需求评审会更多是走个形式，“逢场作戏”。会议中需要同步的信息、需要讨论的点已经提前和团队成员，或者团队各板块负责人达成共识。与其说是需求“评审会”，不如用“宣讲会”来的确切。

在需求评审会前，我会组织两次“小会”。一场是在确定业务流程，明确实现方式后，与服务端负责人沟通整体思路，如果有可预见的前端难点，也可拉上相关人员。第一场沟通，为的是暴露当前实现方式中的不合理点，并让研发团队对技术难点预研；另一场是在完成原型页面（非PRD，不包含完整规则）后，拉上各端负责人及测试，结合业务流程图，以一个较为具象的形式，同步最新的产品方案，再次审视之前认为欠妥的点，反馈研发小伙伴预研意见。

这两次沟通，不用讲很细致，因此也太长时间，每次控制在30分钟内。

3重要事情说三遍

在评审中，一定要把你认为重点的内容“敲黑板、划重点”，确保大家均已知晓，且没有异议。重复阐述要点便是一个不错的方式。这种看似简单粗暴的唠叨确实能起到不错的效果。举个例子，大家恒源祥的广告还记得吗？广告内容简单粗暴，一个静态logo加上“恒源祥，羊羊羊”的MBG，重复三遍，十分洗脑，以至于我在小时候考试题目做不出时，脑子里都会放循环播放“恒源祥，羊羊羊”。

4会后纪要

需求评审会的纪要不必复杂，主要说明以下三块内容：

结论：

评审是否通过。有的团队还会在评审会中确定该版本具体做哪些内容，我通常在评审会中侧重需求本身，对于版本具体包含范围，会在后续工时预估后再进行判断。

需调整、完善（至原型、PRD中）：

围绕着原型及prd，记录在评审会期间提出的需要补充说明的、讨论后要修改的点。

待确认：

记录会议中未讨论出结果或者有其他人需继续配合完善的点，并明确负责人员及时间要求。这是团队目前的待办事项，是会议纪要的重点。

会后及时输出会议纪要并同步给团队，便于后续问题的跟进。

最后

简单的说了下评审会常见的问题，也分享了下开会的经验。说实话，能帮到多少，我心里并没有一个谱。每个公司的制度不同、每个团队的能力不同，我们需“因地制宜、因材施教”，最终形成一套自己的方法论。