需求评审不只是讲解，还需要把握要点

产品小思考 2023-07-30 07:32:13

需求评审是产品经理工作的重要环节，是团队成员间衔接需求的重要桥梁，产品经理的方案能准确落地的重要保障。几乎每个产品经理，工作中都经历并主持过需求评审。无疑，产品经理是需求评审的主角，主导整个过程。

需求评审的主要内容，其实就是讲解需求。很多次刚入行的产品经理会疑惑，为什么有了PRD和原型，还要进行需求评审？因为，有很多信息是图和文字不能完全表达清楚的。需要大家进行沟通，打破信息的孤单岛。

当然，需求评审也不完全是讲解，还要与干细人员一起审验需求的方案和业务细节。因此，需求评审在需求落地的过程中的也有很积极的作用。同时，还能够促进需求方案的完善，探索方案的合理性。在这基础上，优秀的需求评审，甚至能影响团队的凝聚力，达成方向与目标的一致性。

需求评审的参与人员，几乎涵盖团队的所有人员。最直接的人员，就是技术人员和UI设计师。他们是负责产需求落地为产品功能的第一把手。他们在业务的可行性上，会提供最具参考价值的意见和反馈。当然，也需要运营和市场的人员参与。他们能为方案和细节提供一些参考和建议，同时也为了减少后续的重复沟通。特别是B端产品，运营和市场人员可能会直接对接客户。那么他们的很多意见就代表着客户的反馈。

可能很多产品经理会觉得需求评审，是一件很简单的事情，只是讲一讲需求，与大家一起探讨一下需求的正确性。但要做好需求评审，却是一件非常困难的事情。特别是要在保证效率和质量的情况下。这其中有很多的细节和方法，能够帮助产品经理改善需求评审。这些方法大都是对细节的把控和经验的总结。

一次失败的需求评审会，在技术及其他团队成员之间，容易造成对需求理解的歧义，进而导致更大的项目风险。失败的需求评审，极端情况下可能导致团队的裂痕，项目的开发进度延误，甚至于项目的失败。

如果在需求评审的过程中，与会人员对于业务的设计上存在较大的歧义，对方案有较多的负面反馈。那就需要反思产品经理的需求设计，是不是准备的不够充分。

一、准备工作

在正式开始需求评审之前，我们需要先做好的相关的准备工作。毕竟，需求评审涉及到的内容通常都是比较多的。而且，需要我们及时流畅的进行讲解。产品经理不能打没有准备的仗，一定要准备足够充分。

既然要进行需求评审，第一步必须完成原型设计、UML图和PRD文档的准备。这是需求评审的前提。需求评审评的就是这些东西所承载的内容。

在需求评审前，产品经理还需要先进行方案和技术的可行性评审。

第二步产品经理需要梳理一下评审的流程，并进行粗略的预演。

第三步则是需要准备好相关的资料。比如，相关的背景资料、技术人员研发过程中用到的对接文档等。如果在评审的过程中，我们需要进行演示，那还要准备好演示的相关资料和环境。如果有争议的需求，我们可以提前准备好数据等内容，以提升我们方案设计的说服力。

最后，做好以上准备后，我们就可以准备会议室并通知相关的参会人员。通知参会人员时，我们需要将准备好的资料提前发放给他们，并告知他会议的日期和注意事项。如果有远程参会的人员，需要进行特别提醒，并设置好提前通知他们参会的备忘事项。

在进行准备工作时，一定一定要提醒相关人员在参会前预习发放的资料和相关的PRD、原型、UML图等。如果参会人员不提前了解需求的相关方案，在会上再来思考的话，一方面会降低会议整体的效率，另一方面也不能充分的吸收和理解需求评审的内容。

二、正式会议

在正式开始需求评审会之前1~2个小时内，产品经理一定要对会议的流程和评审的需求进行回顾和熟悉。

需求评审的进行过程，我个人比较喜欢采用，经典的总分总的模式来开展。整体的总分总，在细化到每个功能点和细节的总分总。第一个「总」代表着整体性的介绍和说明；「分」代表着分点说明；第二个「总」代表讨论提问和总结环节。在这基础上，我将我的需求评审过程，分为五个步骤。第一步是背景介绍；第二步整体介绍；第三步功能细节评审；第四步提问讨论环节；第五步总结环节。下面，我们就来讲讲，每一步是怎么做和对应的一些方法。

正式开始需求评审之前，我们还需要确认一下人员的到场情况。如果，有一些关键人员没有到场的话，我们可能要确定一下是否需要延迟需求评审或者改期。

正式开始需求评审之后，第一步是背景介绍。首先我们要介绍需求的背景以及相关的行业背景。通常可以穿插着介绍一下用户的情况或者说客户的情况。在背景介绍的环节，通常我还会进行一些暖场。简单介绍一下我们这个需求解决的问题，以及完成这个需求之后，我们产品可能达到的目标或带来的增长。

第二步则是，需求方案的整体介绍。包括我们设计方案的整体结构，整体的业务流程，涵盖了哪些功能，涉及那些系统，以及系统间如何进行交付。还有整个业务的角色构成，甚至于我们给到的文档的构成情况。

第三步是正式进行功能的评审。功能评审，可以按照功能的关联性，串起来按模块进行评审。这样会使整个条理清晰。对于业务有关联性的，也可以按照业务流程来进行评审。对于单个功能的评审，也可以按照总分总的原则来展开。

在实际进行评审时，通常是根据原型图来进行讲解。一边以原型的交互来演示，一面配合逻辑上的讲解。在讲解的过程中，如果有UML图的话，可以穿插UML图到讲解的过程中。比如，在讲解某个功能的业务流程时，先讲解流程图。在讲解的过程中，应该按照用户的交互过程来进行展开。

在讲解原型的过程中，需要对细节进行补充。主要涉及到的内容，包含限制条件异常处理；UI需求的一些要点；可动态修改数据；某些业务包含的明细规则。明细规则，应该一条一条的给大家捋清楚，并且详细说明这些规则的说明在文档的那个部分。

在功能的讲解过程中，应该包含系统性的要求。比如说安全性、稳定性、响应时长、数据需求等。

在进行业务和功能讲解时，如果一场需求评审会，有多个产品经理参与，那么就需要在产品经理间穿插进行需求评审。通常以我需求评审的经验，进行产品经理间的穿插评审，我会保证业务的流程的完整性和顺序。同时，要求产品经理保持评审的风格一致。

当完成功能评审后，就进入到提问和讨论环节。提问和讨论环节，可以分为两个部分。一部分是在现场完成的。现场进行提问，并解答和讨论。另一部分则是在会后，相关人员进行更细致的消化之后的提问和讨论。在提问和讨论环节，尽量避免长时间的争议。以提高会议的效率。尽量把存在争议的环节，放在会后仔细研讨后再做定夺。对于提问和讨论，产品经理需要及时的记录相关的要点，以便会后对相关的文档和方案进行更新。

提问和讨论环节，并不是严格的放在所有功能评审完成之后再进行的。应该在功能评审的适当环节进行。比如，完成一个功能板块的评审之后，就可以乘热乎，对于这个功能板块的内容提问和讨论。特别是，当评审的内容较为庞大时，最后进入提问和讨论环节，可能并不效率并不高。因为相互人员想到的问题，已经被他们忘记了。但是，也并不建议在评审环节中随时提问。因为评审整个过程是存在关联性的，可能现在提出的问题，是后面的评审内容。再者，随时的打断不仅会打断产品经理的思维，还会降低整体的评审效率。

最后是总结环节。总结环节，主要是将大家提出的疑问和讨论的结果，进行总结提炼。最后还要和参会人员确定一下反馈的内容。比如，相关的研发人员给出节点的时间的时间，某些待明确问题的确认时间等。以及，讨论一下具体的后续计划安排。

以上，就完成了一场需求评审会。虽然会议完成了，但不代表着需求评审的工作完结，还有一些后续的环节。评审会完之后，产品经理需要对设计的需求方案和收到的一些意见反馈进行优化，会上待明确的内容进行明确，并且确定相关的时间节点。如果评审完之后，还要进行二次评审，那需要尽快确定二次评审的时间，尽快进行二次评审。需求评审也只是需求落地的万里长征的第三步。

已经没有待确认项并需求评审通过后，产品经理需要和相关人员，尽快确定好后续节点的时间。比如，UI的评审时间，研发的时间节点，上线节点等。最后，将时间节点整理成计划表。

三、要求和方法

在评审会时，产品经理要保证会议良好的氛围。尽可能，调动与会人员参与讨论。但是，尽量不要陷入到无穷的争议当中，避免抬杠。我有一个诀窍，就是当大家产生争议，如果能给出佐证争议的相关证据，那我们就继续深入讨论。如果，没有给出有说服力的证据，那我们就留待会后，再深入研究和小范围讨论。

在需求评审会上，建议大家多使用白板。不仅是自己用，也督促参会人员使用。特别是在讨论一些较为复杂的内容时，白板上勾画的内容比单纯的言语更令人易于理解。

前文已经提到过，这里再强调一下。要提高需求评审会的效率，一定一定是相关参会人员要提前阅读需求相关的文档和资料。

要开好需求评审会，不是一个快速的过程，而是一个逐渐形成标准化的流程的过程。对于每个产品经理都是这样，即使是很多年工作经验的产品经理，换了一个工作环境和团队，也需要重新形成需求评审的标准化流程。因为不同的团队，环境和文化氛围不同，需求评审会议最优的方式也不一定相同。

有些产品经理在评审时，特别是提问和讨论环节，喜欢全程录音，来会后进行回顾。我个人并不建议这样做，因为一般评审会的信息密度都达不到录音来保存信息的底部。对核心要点，记笔记，就足以应付大多数问题。除非你记性实在是太差了。

要开好一场需求评审会，虽然对于大家来说方法可能各有不同，但是有一些要求。一些要求是相同的，只有达到这些要求，基本上才能做一场良好的需求评审会。

产品经理一定要成为需求评审会的主导者，一定要带领大家去参与需求评审。而不能被其它牵着鼻子走。特别是在，有上级领导参与的过程中。

既然需求评审会，要求产品经理进行讲解，那么产品经理最基础应该保证自己发言的简洁明了通俗易懂。但是，切记不要去追求语言上的技巧。直白的语言，是最容易传递信息的。另一方面，在沟通和讲解的技巧上，产品经理还是要花点心思学习的。怎么与人沟通，怎么把一个东西简单明了的讲清楚，还是有一定技巧的。多练，也能熟能生巧。

需求评审会，产品经理要精确的控制好节奏和时间。计划多久完成需求评审，尽可能按时完成。多人会议通常拖的时间越久效率就越低。控制会议的节奏，也是产品经理的基础需求功力的体现。说白了就是自己对自己业务的熟悉程度。

在需求评审会上，尽量不要陷入到UI和交互的主观讨论甚至于扯皮上。产品经理一定要明确需求和产品的核心价值是什么。UI和交互是个人倾向很重的内容。这部分能容应该是群体的认同占主题，而不是陷入到个人执拗当中。

需求评审会上，尽可能的保证某个人都不被打断完整的发言。会议室不是菜市场，严禁多人产生哄抢式的争论。会议上的争论并不可怕，可怕的是走偏了方向，去讨论无关紧要的内容。菜市场式已经是被证实最容易带偏方向的。如果讨论的方向走偏了，作为评审会的掌舵人，产品经理要及时把大家带回正轨。

需求评审会不是挑刺大会。尽可能控制，任何人不要以为别人找出问题为目的来讨论问题。大家的核心目的一定要专注在理解到整个需求，讨论问题并找到最优的解决方案上。

四、小思考

在某些情况下，需求评审会可能要远程进行。远程评审的难度比在会议室高了很多很多。远程评审的硬件环境，要更复杂一些，需求投屏、语音之类的设备。而且，语音沟通肯定不如现场沟通来的直接。所以，我个人觉得能够现场评审，尽量不要做远程评审。如果一定要远程评审，那么尽可能的准备充分的文档，并且让与会人员详细详细再详细的阅读。

需求需不需要评审，其实主要由两点决定的。一是文档能不能详细的阐明清楚需求的设计方案。另一点是有没有容易导致大家产生歧义的点。也与团队的协作模式有关系。如果团队协调的已经很高效，而且非常乐于用文档传递信息，并且已经在高效的通过文档来传递信息，那么可以考虑不进行需求评审。有时候一个过于简单的需要，其实也是没有必要进行评审的。

需求评审是不是一种高效的传递信息的方式？显然不是的。因为一群人聚在一起通过讲解和讨论的形式，短时间内吸收大量的信息，并不高效。通过文档来传递信息是最高效的。但是，对于同一个内容，不同的人可能会产生截然不同的理解。因此，需求评审是需求文档的有效补充。需求评审能够「更准确」的传递信息。

我个人觉得一场会议，无论是什么类型的会议，尽可能的都要简短。超过两个小时的会议，会议的效率会非常非常低。我个人参加一个会议，超过半小时，待在一个密闭空间里，就有些受不了。更别说专心的吸取庞大的信息。

需求评审会上还需要注意，谁有决策权。是与会的领导有决策权？还是民主的方式来进行决策？这决定了需求评审会的进行过程和讨论氛围。强势的上级领导，在需求会上做决策，通常是一场需求评审会的灾难的开始。所以我通常在需求评审会前和后，与上级领导和后进行沟通，而不是其直接参与需求评审会议。「前」是确认，「后」是反馈。

最后，不同的产品经理有各自习惯的评审方法，不同的团队有不同的工作方式，不同的公司有不同的企业文化，不同的需求有恰当的评审方式，产品经理应该因地制宜。