需求评审不只是讲解还需要把握要点吗「需求评审不只是讲解还需要把握要点」

编辑导读：需求评审是产品经理的一项基础工作，和技术人员、UI设计师等人员一起探讨需求落地的可行性。在需求评审会议中，不单单只是讲解，还需要把握要点，让需求评审会议发挥出它最大的价值。本文作者对此进行了分析，与你分享。

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

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

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

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

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

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

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

一、准备工作

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

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

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

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

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

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

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

二、正式会议

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、要求和方法

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

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

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

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

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

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

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

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

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

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

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

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

四、小思考

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

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

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

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

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

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

#专栏作家#

产品小思考，微信公众号：产品小思考，人人都是产品经理专栏作家。擅长行业业务分析，设计行业方案，设计B端产品架构。主要关注医美、医疗行业，涉及HIS、CRM和各类业务系统产品。

本文由@产品小思考原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

如何有效地进行需求评审

需求评审是我们项目立项之前的一条必经之路，是项目经理，开发，测试，架构师等等的同学针对自己将要开展的工作内容，进行检查并提出问题；只有评审通过的需求才能立项，但是我们的评审总带有一定的盲目性；
在公司里面，需求评审的时候，我们常可以看到这样的一个情况，一堆人，在一间会议室里面，吵得脸红脖子粗；大家都在强调：“你没有明白我的意思，我的意思是。。。”上午吵不完，下午继续吵，今天吵不完，明天再吵。。。最后，一个旁观的人突然说：“你们争论的根本不是同一个东西。”
在此同时，至少有五个与这个功能完全没有关系的人在看着别人脸红脖子粗。。。哀哉。我们需要改进现有的评审方式。
1、评审要有目的
在需求评审的时候，与会的同学关注的需求功能点都是分散的，我们很难将偏离用户需求的功能点找出。
我的意见是在评审之前，发出会议邀请的时候，分清必须参与评审的人员和选择参与评审的人员。必须参与评审的人员必须在需求评审之前发出自己认为需求中存在的问题；选择与会人员，可以自主选择是否发出评审意见；
一期的评审就以大家发出的问题为范围，由相关问题引申出来的问题，可以在相关人员查找资料之后，再进行二期评审；直到大家问题都解决完了为止。
2、评审要控制时限
我们也常见到这样一种情况，PM和PD两个人就一个问题争执不下，其余的同学都在下面看着两个人争执不下。可能还有这样一种情况，我说服不了你，但是我就默默唧唧的不答应，你也别想说服得了我。或者我们也在评审的时候发现：我们从A问题引申到B问题，再到C问题，直到大家一起偏离主题讨论N久，原定的计划还没有完成，还浪费大家的时间。
所以，对于每次评审中的提出的问题，PD或者PM设定一个讨论的最大时长，比如十五分钟。如果对一个问题讨论的时间太长，那么，在一定的程度上，这个功能点的实际存在着问题，考虑还不周全、不完善，有必要大家回去再思考。
3、及时作出评审的界定
在PD轮岗期间，在制定搜的需求评审期间，和项目的UED同学对项目的流程争执不下，连带着各自的一帮人都在争论不休；我们当时有叫来需求方，各自对需求方讲诉我们各自的出发点，结果需求方被我们讲得头晕脑胀，不知所言。
即使是辩论赛，我们也会有一个主持人进行中间调停。此时，我们当需要公推一个能拍板的人来，为此时做个不偏不倚的公断！
拍板的结果，双方必须当场无条件信服。如果争执的一方还认定自己的观点，本次会议中不可以再次提出，但是可以在搜集证据之后，再次召集有关人员讨论这个问题。
4、跟踪评审中问题的结果
在需求评审的时候，肯定还存在一些，例如调用存储访问等留待沟通之后再议的问题，但是评审之后是烟云缭绕，不知下文。如果没有一个发起人催一下问题解决的结果，甚至可能项目上线了，都没有让所有相关的人员知道问题是否得到解决，以及问题具体的解决方法。
在我们项目中的一些主要角色中，需求方太遥远，PD太忙太没有时间，开发太飘忽太随意，当然，我们的测试可能因为影响力等原因，太没有力度。要建立自己的威信和对项目的责任感，我们需要从跟踪评审问题的结果开始，让大家都看到你对项目的关注程度，你对项目的责任感。
5、设定需求变更联系人
在淘宝，拥抱变化的思想深入人心；我遇到过这样一件事情，后台CRM需要跟流程平台打通，调用流程平台的审批系统；我们当时跟流程平台的同学一起讨论可行性，讨论接口的内容等。突然，有一天我询问项目进度的时候，开发同学说，我们决定不用流程平台的审批系统了。
我们也常听到测试的同学怒吼一声，你们需求又变了，我为什么不知道。这些是什么原因导致的呢？
一直以来，大家都很随意，没有一种明确的需求变更的机制；如果需求变化了，应该告诉谁，对谁可能有影响，这些我们都没有想；我们只想到，我们实现这个功能更加简单了。这种片面性的想法导致了以上的种种问题。
故而，上到一个项目，下到一个小日常，我们需要确定项目需求变更的通知人。一旦遇到变更情况，需要马上通知到相关的变更联系人。
6、评审的结果——基线
基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
而我们现在评审完毕之后，顶多发出一个会议的纪要出来，上面写明，今天的评审中提出了哪些问题，哪些问题是需要进一步跟踪的会议纪要，再也没用进一步的东东。所以，这个不是基线，至少不是完整的基线，不是正式的基线。
我觉得，基线还应该包含以下几个方面的内容：
1） 需求变更的联系人
2） 公开评审中问题的结果
3） 修改后，大家达成共识的PRD。现在我们评审的结果只有输入值，一个初始版本的PRD,但是没有基线版本的PRD。
评审是我们项目和日常的第一步，熟话说，好的开始是成功的一半。一个良好的，有序的评审方法，有利于我们发现更多的问题。

作为一个软件测试人员，需求评审应该做些什么？

需求评审对于软件测试人员来说就像是最初的“产品测试”，在理解的基础上发现产品设计上缺陷，其中包括逻辑错误，功能缺失，细节问题等等，这样就会有效的在前期规避很多后期开发中产生的bug，减少了很多后期返工的成本。可偏偏需求评审往往是最不重视的一环，甚至可以说是没有这个环节，追其原因无非因为项目时间紧迫或者觉得没有必要，其实这是本末倒置和得不偿失的。
产品需求作为程序的源头，只有控制好最开始部分，才不会到最后去亡羊补牢。我有过很多血的教训，所以才深深的体会到需求评审的重要性。
说了需求评审的重要性，接着就来谈谈如何进行需求评审，一般还是分为3步：
第一步就是要完全读懂产品需求，这个过程只需要理解而不是去挑刺，因为要明白这个需求的目的是什么，为什么这样做，怎么做等等，只有在理解的基础上才能去发现问题，而不是一知半解的去挑毛病，有些需求设计的是不合理，但也许有其特殊的用意，或者只是没有更好的方案，不能为了挑毛病而去挑。
第二步就是分析和找问题；这就有点类似写测试用例的时候设计测试方案了，把逻辑梳理出来，看看有没有不对或者遗漏的点，整理出来反馈给产品经理。除了考虑有问题的地方，没问题的地方也是需要分析的，比如有些设计非常合理，但会增加代码的复杂度或者不利于后续的扩展和修改，同时也可能会给测试带来成倍的工作量，这些也是需要指出的，因为测试要考虑的东西一定要比产品经理多，用户使用习惯，程序复杂度，与线上系统的兼容性等等，不然直接让产品经理做测试不就好了吗？
第三步就是细节问题的纠正，可以是界面，可以是文字，开发一般都是复制黏贴或者照着样子画葫芦，这些小问题后期其实也可以测试出来的，但其锅不在于开发，早点发现问题早点解决也是好事一件，至少不用提bug走一套bug处理流程了，也算给大家省点工作量，积少成多也是极好的。
当然需求评审能解决的问题也是有限的，一方面计划往往赶不上变化，中间会有部分需求的改动，另外一方面有些深层次的问题只有在测试之后才会发现。但无论如何对于测试来说还是非常有必要的，如果能重视起来不仅仅对项目的效率提高不少，而且也能让后期测试压力减小，何乐而不为呢？