37 | 如何做好需求评审（上）：需求评审不只是一次会议

Feb 13, 2018

37 | 如何做好需求评审（上）：需求评审不只是一次会议-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

37 | 如何做好需求评审（上）：需求评审不只是一次会议

2018-02-13 邱岳来自北京

《邱岳的产品手记》

课程介绍



讲述：邱岳

时长10:33大小6.04M



“问渠哪得清如许， 为有源头活水来。”
——朱熹
几天前收到了一位专栏读者的留言：说自己在现实工作中发现，大家并没有把需求评审这件事情放在心上，有些同事对业务并不熟悉，或者没有建设性心态，觉得潦草交差即可，所以在评审阶段不重视需求方案，认为反正都是产品经理的责任。
他在留言中问我有没有什么办法能让大家转变心态，可以关注产品，而不是简单地交付项目。
这个问题我也遇到过，而且一直持续地遇到，即有我主持需求评审别人心不在焉的时候，也有别人的需求评审我走神儿的情况。
年轻的时候我想了不少歪门邪道让别人在评审阶段关注需求和方案，对需求评审用心，承担责任。
比如提前发出文档然后针对文档问问题，比如要求必须提出两个以上的反馈，或者让工程师来主持需求评审，甚至还干过把评审结论打印出来让业务部门代表在纸上签字的事情。
所有的这些方法和手段在刚提出来的时候都会有一定的效果，但随着大家逐渐习惯，它们就会形式化，然后我们又去寻找新的流程化手段，周而复始，流程越来越重，效率也越来越低。
那应该怎样优化需求评审呢？今天我就来谈谈自己的一点经验和思考，希望可以给你带来启发。
1. 当我们谈论需求评审的时候，我们在谈论什么当我们谈论需求评审时，第一反应会觉得它只是一个环节，可能包括一次会议，几封邮件。但我们不能局限在一个流程切片的角度去理解和讨论它，需求评审串起了前期的需求收集和分析，不同利益相关方的博弈，以及后续项目落地实施的计划管理等各个方面，评审会议本身只是露出水面的一角，想让评审更有效，事前和事后都要做不少工作。
正因为如此，需求评审也成了对产品经理综合能力的一次考验，我曾经有个同事把需求评审会称作是产品经理的 Show Time（表演时间），如果完成得出色，不但项目会顺利很多，也会为自己在团队中的影响力加分。但是，对于那些能力欠缺、准备不充分的产品经理来说，也可能会是一场噩梦。
2. 需求评审的受众、目的作为产品经理的下意识反应，任何事情都应该先去追问：“解决谁的什么问题”。对需求评审来说，就是要先弄明白需求评审的受众和目的。我们通常意义的需求评审，是产品经理完成需求收集和分析，确定解决方案之后，面向两个角色，做四件事情。
第一件事情是向需求方以及其他利益相关方详述自己对需求的理解和分析，明确我们的需求分析与他们的原始期望是一致的。通俗一点讲，就是需求方（包括用户）说了自己需要什么东西，你思考和挖掘他们背后的动机之后，用自己的理解复述给他们听，确定自己的理解是不是正确。比如用户说要一匹更快的马，你分析需求和场景之后，认为他的动机是希望更快地到达目的地，把你的分析过程讲给他听，并同他们达成一致。
第二件事情是向设计、研发和测试团队，也就是需要去实现产品的这一票人，讲清楚需求的背景和来龙去脉。这个在我们之前怎样与工程师相处的分享中也提到过，不能只交代做什么，还要交代为什么做。这个事情本质上跟刚才提到的，向需求方详述对需求的理解和分析很像，只不过受众不同，可能需要多交代一些背景。
第三件事情，是向需求方交代具体的产品解决方案，也就是他们将要得到一个什么东西，是一个按钮，还是一个表单，还是一段没有界面的逻辑。这个东西会如何出现在他们的工作场景中，以及会如何跟他们发生关系，让他们的工作发生什么变化。
第四件事情，则是向开发团队交代产品解决方案，设计师、工程师需要弄清楚自己将要制造一个什么东西，长成什么样子，怎样运转，有哪些特性。这也是我们提到需求评审之后可能想到的第一件事情。
3. 哪些人参加评审，怎样安排议程？有人曾经问我，需求评审会应该安排哪些人参加？需求方和工程师应该在一起完成评审吗，要不要分开开会，或者，怎样安排需求评审会的议程等等。其实如果把上面提到的四件事情拽出来，分别排列组合一下，就很容易得到答案。
需求方代表，如果有的话，通常是业务或者运营团队，To C 产品也可能没有一个具体的代表，通常有产品经理本身来充当。实现方则包括设计、研发、算法、测试甚至运维等等。
如果通过一次串讲，既能与需求方达成一致，也向实现方交代了背景；既能让需求方明白产品方案，也可以让实现方清楚特性列表，那就尽量一次性搞定。如果有实际情况或者流程障碍，比如你的开发团队是外包的，或者关于产品方案实现细节的讨论冗长而且专业，那再根据具体情况去拆分会议。当然，不论开几个会，评审几次，都要记住上面四个目标，手段是为目标服务的。
评审议程也应该结合目标来安排，一般是先讲业务，然后再讲方案，讲的过程中还是根据刚才说的四个目标来安排逻辑和内容，提高效率。
4.“预则立，不预则废”大部分人的思考都需要时间和过程，有的产品经理为了顺利通过评审，会想要打别人一个措手不及，毫无铺垫突然开评审会，趁着参会的同事还没反应过来，闪电完成串讲，需求评审顺利结束，结果后面一大堆问题，他还振振有词说谁让你们需求评审的时候没提出来呢。
还有一种情况是，没有提前准备，结果在会上发现有根本性的分歧，当场陷入到具体细节里，长时间的讨论，但依然没法达成一致，无果而终。
所以，大家一定要重视会前的沟通，提前做功课，要记住需求评审会应该是凯旋的钟声，而不是冲锋的号角。
会前沟通一般是小范围的，针对一些细节点深入、频繁地与具体的相关人交换信息，达成一致。这其中既包括与业务部门的沟通，也包括与工程师的沟通。通过这样的沟通，确保在需求评审之前，将整个流程中可能发生分歧的点都考虑到，并且进行过讨论，要做到最终在需求评审会上的内容不会让与会者感到“意外”。
另外很重要的就是一定要提前发出需求评审的材料，让大家可以提前熟悉一下评审内容。虽然有一些手段可以敦促大家提前预习，但说实话，大部分人还是不会读。你也不能怪别人，在没有引导的情况下读产品文档确实是件很低效的事情，寄希望于把文档发出去大家就都会仔细阅读然后给出反馈，其实也是一种推卸责任。
这时候，最好可以一对一跟进一下，也就是说，产品经理需要能够意识到不同的人关注的不同内容，然后非常具体地指出来，再让对方去提前读。
比如，文档发出去之后，跟业务部门代表说：“你看看功能图例里头那个流程图，是不是跟你们业务实际情况一致”，或者是，“你看看文档里的线框图，加了一个按钮可不可以”。只有这样具体地指出来，相关的同事才能有操作路径，才有预习的效果。
除了会前沟通之外，还有一件对于需求评审很重要的准备工作，就是准备材料和议程。材料至少要包括需求文档，议程至少有讲业务、讲实现、评审讨论三个部分，如果是大规模需求评审，可能还需要特别准备幻灯片，如果需求评审跟项目启动会一起开，或许还要加上项目计划等等。
会前发出来的材料和议程，一定要专业，要严谨，一方面是可以把事情交代清楚，另一方面，大家提前看到这样专业和严谨的东西，会收到影响，在潜意识里会对这次需求评审更严肃和重视一点。虽然听起来有点形式主义，但还是有必要传递这样的信息。如果你自己都吊儿郎当，别人凭什么郑重其事。
总结今天我们关于需求评审的分享就先到这里，我们说需求评审不仅仅是一个环节，它会贯穿整个产品需求分析和实施过程，然后聊到需求评审的两种受众和四个目的，以及基于这四个目的，如何去安排需求评审会议，最后说到如何为需求评审做准备，做好会前沟通和预习。
下次分享，我们会继续聊需求评审，关于需求评审你有没有值得分享的经历？不妨在留言中一起讨论交流，谢谢你，我们下次再见。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 7

提建议

36 | 产品案例分析：解读知识星球

38 | 如何做好需求评审（下）：在评审中控住全场

 写留言

精选留言(9)

听天由己
2018-02-13
感谢二爷的良苦用心。之前遇到这些困惑，的确是自己对于产品工作或是需求评审这件事的重视程度不够，在自己尚未准备充分或是考虑清楚的情况下寄希望别人来共同参与，这是不负责任的表现。作为产品经理，首先要认真做好自己的本职工作，从二爷提到的很多细节上，我还有很长的路要走。能够清晰、完整地将自己的业务流程和逻辑具象化表达，并且让大家统一思想，提前沟通，这本身就是对产品经理的综合考验。我真心认同二爷说的「需求评审应当是凯旋的钟声，而不是冲锋的号角」。两者的差异可见一斑。年前经历的那次需求评审并不完美，时间紧迫，只好提前用正式机会和大家沟通，这就造成很多不确定性，这是我体会最深的。希望年后回来能够认真做好每一件小事。感谢二爷的辛苦付出，提前祝大家新年快乐，万事如意~
展开
作者回复: 谢谢刘祯，每次读你的留言也很有收获，祝你新年快乐
8
CC
2018-02-13
今天的分享中关注到两个关键词： “冰山一角”，不能局限在一个流程切片的角度去理解需求评审。这让我想到足球比赛中的“临门一脚”。这一脚固然精彩，但更重要的是之前的传接配合。首先要在会议之外下功夫，会议才有达到预期的可能。记起在之前的分享中学到的，非正式沟通是会议之外很好的补充。 “意外”，生活中意外有可能是惊喜，而项目中的意外往往相反。面向两个角色，做四件事情，目标就是统一期望值，让产品在需求方和开发团队的脑海中的形态统一。第一步尤其重要，可以通过之前关于需求变更的分享中提到的“五问法”，挖掘背后真实的需求。我作为前端程序员，其实也可以从自己的角度出发去促成与产品经理的沟通。比如，可以主动一对一跟进，了解需求背后的缘由，以及需求文档上自己需要重点关注的地方。谢谢二爷分享，春节快到了，提前祝二爷和一起讨论的极友们新年快乐。
展开
5
周阿冰
2018-04-13
很想交流一下。我不是产品经理。最早是测试工程师，现在是项目经理。深深认同二爷的这两个观点：评审的四个目标和手段是为目标服务。评审会能不能开好，就看是否达成这四个目标。然而，现实情况是需求评审会很不容易开好，一旦有某一方掉链子，会议效率低下还是轻的，重则研发过程中天坑滚滚。在遇到各种问题之后，我们制定了评审会的几个重要原则：1.重在评审，不能开成培训会；2.产品经理必须在会前和需求方充分沟通，确保可以实现业务目标；3.大需求必须在产品框架方案构思阶段和技术负责人沟通，确认可行，并且实现成本尽可能小；4.大需求必须和业务负责人就方案达成共识。此外，我们还围绕会议效率和质量定了一些细则要求。最近几个月，我们遇到了一些糟糕的情况，因为需求方调整了策略或者当初没规划清楚功能的使用，花费大量资源开发出来的一些功能基本不使用，甚至搁置未用。这对团队造成了极大的伤害。我们因此做了一些调整，在需求评估阶段，产品经理要合理评估需求的价值，需求方要阐述清楚未来使用该功能的规划。如果产品经理或者产品团队不具备可以评估需求价值的能力，依然有可能会存在这种问题。
展开
5
雪甫
2018-02-26
会而不议可能是需求评审的最高境界了吧，所有问题都在事先沟通解决了，会上只是大家一起确认一遍，而不是讨论需求，更不是读需求
4
Marnie
2019-02-20
学到的最重要的一点是，完成需求搜集和分析后，产品经理要事先与相关人员沟通。再有，要提前发出需求评审的材料，让大家提前熟悉评审内容。但不能只是笼统发出去，要指出不同人需要关注的地方。
1
Dylan
2018-07-23
文档发出之后一对一进行指导和跟进，这是一个站在对方角度去高效处理问题的好方法，学习了。其实需求评审应该是个很高效的达成共识的会议，总结过往展望未来，很有必要。
1
王星
2020-04-16
需求评审，让大家知其然并知其所以然，建立相关方对产品的生产的参与感，这样大家做起来要有意义和成就感一点。
罗帅
2018-05-06
讲的很细，虽然我只是一个程序员，但是听过之后对产品经理工作更加理解了
林彦
2018-02-13
二爷，一个to B的小硬件公司(30人以下，也有软件和云服务)，只有需求方和开发团队，需求方是商务总监和销售，开发团队很少第一线与潜在和已有客户沟通（唯一直接接受客户反馈和投诉的工程师快自己蜕变和被定位成支持工程师了)。最近请了一个做过硬件行业品质和项目的资深经理担当项目经理的角色，他对软件开发了解得比较少。这种情况下除了空降外，什么样的人，或现有的团队和角色里，谁比较适合当或发掘成产品经理，原因是什么。如果外部空降是更好的解决办法，看重候选人的哪些特质，技能，过往经验，现有公司从哪些方面支持他更有助于他融入和为团队贡献价值。这个话题有些大，二爷能回答一两点我也很感激😀
展开
作者回复: 林彦你好，由于不了解行业和人，我的所有回答都仅供参考。可以考虑从资深工程师中选一个有商业意识的人来承担产品经理的职责，商务上的东西可以通过旁观和讲授来大致理解对话，而技术则通常需要一些时间和背景知识才容易对接。空降的话，最重要的还是人品吧我感觉。听你说感觉是toB的团队，那希望他尽快能理解toB的逻辑吧

