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