最近参予了这场需求评审委员组，我是与会人。会议中，产品小弟总是被吓倒、被反问、被考验，这场评审委员组下来，他依次脱了万雅、衬衣，灰鳍一件方格衬衣，整个人满身摸了摸，像冲关了一公里，而我却在角落里冻的科亮颤抖。

你有经历过在评审委员组中被问的缺仔庄、汗流浃背吗？我有过，但现在淡然多了，可能将是脸（不）皮（要）厚（脸）了，也可能将是理清了评审委员组中的常用问题。我归纳了评审委员组中的4类众所周知问题与应对计划，如果你还惧怕开需求评审委员，希望本文能帮你提早搞好“战斗”准备，阳光普照评审委员时少点儿汗。

问题目录

01 如果XXX情况，咋办？

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

问题其本质：情景与否考虑健全；业务流程与否完备；

解决方式：利用多方湾瓦，健全产品计划；

有爸爸妈妈提此类问题，是个坏事！一是证明大家跟着节拍在对评审委员内容进行思索，二是这些问题能帮助健全产品计划。他们需要去倾听大家意见，不要感觉被考验从而产生抵触心里。

如果所定的问题是已经思索并规划过，只是还没介绍到，他们可以直接意见反馈：你说的我有考虑，将在后面说；如果确实未提早准备，那也无须暗藏，谦卑求教对方，也得出自己意见。多数情况下，此类问题并不牵涉流程主体，比较容易快速得出判断与推论。如果一时间分寸不准，建议会前探讨，不在会后展开。

须要，此类问题都不应牵涉核心业务情景与主体流程。如果主旋律都没考虑清楚，这评审委员组就不该开。

02 那个机能做了没意义啊！为啥要做？

类似于的问题除了：这机能做出来干什么都不认得？

问题其本质：需求大背景叙述不明晰。

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

项目组成员在参予评审委员过程前，很少会积极主动了解需求大背景，翻查蓝本内容。即使产品经理已将蓝本等内容丢朋友圈，告诫大家提早翻查，但懂的都懂。而在评审委员组期间，开发者很容易钻进到某一具体机能如何实现、那个机能与否和旧有矛盾等思索中，忽略了需求的大背景与目的。

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

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

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

类似于的问题除了：你根本没考虑系统现在情况！

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

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

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

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

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

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

类似于的问题除了：你直接把XXXXX；

其本反问题：当前计划与否是最优实现方式

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

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

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

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

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

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

会议技巧

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

01 把控会议节拍

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

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

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

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

02 提早沟通与确认

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

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

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

03 重要事情说三遍

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

04 会前纪要

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

推论：

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

需调整、健全（至蓝本、PRD中）：

围绕着蓝本及prd，记录在评审委员组期间提出的需要补充说明的、探讨后要修改的点。

待确认：

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

会前及时输出会议纪要并同步给项目组，便于后续问题的跟进。

最后

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

↘好文推荐：

把伪需求扼制在摇篮里-B端产品需求方法论

8000字讲清楚从0到1搭建电商商品中心

五千字详解消息通知！

??欢迎关注：