需求评审是需求分析过程中的最后一个阶段，可以分为组内需求评审、技术需求评审、客户需求评审等。本文作者根据自己的工作经验，对需求评审的过程进行了拆解，希望能给你带来一些帮助。

需求评审是需求分析过程中的最后一个阶段，本文结合自己的经验对评审过程进行拆解，希望能让我们的评审更顺利，同时及时发现自己在评审前工作的不足之处，持续精进。

之前的文章中写过需求洞察（从收到需求到明确需求——需求洞察）、需求变更（频繁的需求变更让你痛苦过吗？）、需求蔓延（需求蔓延的复盘与思考）、需求讲解（如何做好一场需求讲解），再加上今天的需求评审，和需求相关的几大重要节点就整理完了，后续我会继续补充其他和需求相关的内容，欢迎持续关注~

言归正传，需求评审基于参与的人员不同、评审的目标不同、所处的阶段不同，也可以再细分为组内需求评审、技术需求评审、客户需求评审等，当然有些关键需求可能还会涉及与公司领导层进行评审。不同的情景下，我们评审的侧重点和注意事项也会有很多差异。

虽然有很多差异，我还是尽量以标准化的形式进行拆解，再针对部分差异单独说明。

全文概览：

1. 评审是评什么
2. 评审的目标
3. 评审前的准备
4. 评审中的讲解
5. 评审中的讨论
6. 评审后的结论
7. 评审后的完善

01 评审是评什么？

1）评审业务方案是否满足原始需求

最基础的目标，就是确认本次解决方案和原始需求是否贴切，通过我们深入的需求洞察和方案整理后，是否能够满足业务提出方的要求。

2）评审工作量是否可控

尤其对于有技术团队参与的需求评审，他们需要对本方案的开发工作量进行预估，可能一句很简单的方案但在执行时却很复杂。

同时如果涉及到关联方的改造，对方是否愿意配合，对方对我们的进度计划是否接受，也是需要在评审过程中最终确认的（当然有些情况不需要在需求评审会确认，这里不再单独罗列）。

3）评审方案是否满足业务规划

本次方案除了满足原始需求之外，可能需要领导或者业务相关的其他负责人评估本次的方案是否支持后续的场景拓展，是否支持系统的中远期规划。我们也会遇到即便方案满足原始需求，但有些业务规则的制定存在局限性的情况，这时为了后续业务的拓展，本次规则也需要同步修改。

不知道你是否听到过客户或者领导这样的话：“这块后续打算XXXX做，还要和XX系统对接上，你们要留个口子”。

这里与技术侧的设计评审有相通之处，即便本次只是做MVP流程，但为了满足后续的版本迭代，在设计时功能结构上也要对应满足拓展性。

4）评审可行性是否合理

同样的场景，会存在多种实现方式，需求人员在制定方案时可能只站在业务角度或个人经验角度进行分析，但其他角色可能会有更优的、更贴合现状的解决方案。

所以对于方案细节的合理性评估，也是本次评审的重点内容。

5）评审逻辑结构是否严谨

最后，对于很多评审而言，针对关键业务的逻辑规则严谨性也需要详细确认。此时可能需要技术负责人、测试负责人发表自己的意见，对关键细节提出质疑并形成多方认可的解决方案。

以上提到的评审内容，不同团队、不同业务模式，都会存在差异，每个参与评审的人员出发点不同，关注点不同。

虽然不能一概而论，但既然做评审，我们就是要圈定一个范畴，让多方角色对这件事达成共识。

02 评审的目标

虽然说评审都是为了让大家达成共识，但不同的参与人，不同的背景下，评审的目标也是不一样的。而且不同的目标也会影响我们在具体评审过程中的流程和侧重点。

1. 内部评审

属于产品组内部的评审，会涉及其他产品同事、产品总监，当然也可能会邀请一些其他组的相关成员提前参与。

这一步的目标更偏向于整体方案的合理性、完整性以及和版本的规划、市场反馈的优先级等综合商讨，具体功能的实现方法是否满足当下诉求。

其中方案撰写人可能在某个问题上有多个方案，或者无法权衡具体优劣，都可以在内部评审时先由产品团队内部讨论进行初步抉择。同时要向组内的伙伴们讲解关键功能的设计思路、背景原因等。

因为产品组内同事，都是你“最亲密”的战友，我们面对相同的合作环境，工作方法论也是相互贴近的，他们也是最能理解你的。所以在内部评审时，只要时间允许，我更倾向于【细致】。

对于产品组内评审，我认为的关键词是：尽量完整。

2. 技术评审

技术评审是和开发团队进行评审，更侧重于方案的落地性分析、工作量初步评估，疑难杂症的解决方案商讨，同时需要技术团队帮我们查漏补缺。

尤其是涉及功能迭代的需求，可能我们认为一个很简单的功能，在实现时需要伤筋动骨。

技术评审则需要我们把需求讲明白，不要遗漏，同时结合开发人员提出的工作量、工期等问题进行权衡、补充或删减。

同时我们可以通过他们的关注点更加理解技术思维，在后续的版本迭代过程中，合理的融入一部分技术思维来制定方案（当然这里面也有一个“尺度”问题，具体可查看历史文章：辩证难题 | 产品经理要不要懂技术？）

对于和技术团队进行的需求评审，我认为的关键词是：工作量。

3. 客户评审

对于外包类项目等需要客户方参与的需求评审，很多情况下评审会变成一个不可裁剪的流程节点。虽然有些可能是走个过场，但我们要认识到这次评审的重要性。

在评审时尽量解决之前因为协调困难等原因而遗留的需求问题，需要趁着领导在场时“拍板”或者“授权”或者“推进”。

客户评审时除了我们的需求人员、项目经理，客户方的领导，还可能有其他关联方的配合人、其他业务部门的协作人等等。因为涉及成员比较复杂多变，所以通用的方法论也不像另外两个评审标准，但更能体现需求人员的真实水平。

评审已经是最后一个阶段了，如果前期工作到位，评审过程会很顺利。一旦在评审时状况百出，困难重重，那一定要回顾自己之前的阶段是否有不到位的工作。

对于和客户进行需求评审，我认为的关键词是：签字。

4. 领导评审

其实和公司领导进行需求评审，会掺杂更多“汇报”的意味。如果前期汇报及时，最终的评审也会比较简单顺利。

如果前期领导比较忙，或者你们沟通的不及时，那也可能会在评审时对方案产生战略性转变。

而且对于领导的评审，可能更需要的是言简意赅，挑重点，毕竟领导的时间也不会很多（这里和客户评审在时间上的要求也比较类似）。

对于和领导进行需求评审，我认为的关键词是：支持、授权。

虽说每种评审形式有各自的侧重点，但我认为最基础的目标依然是为了形成多方之间的“执行对齐”。

03 评审前的准备

组织起一场正式的需求评审不太容易，所以为了让评审的目标更容易达到，让评审的价值更好的体现，我们在评审之前一定要做一些准备。

首先，主讲人要对本次评审的需求和方案很熟悉，对一些具体的实现步骤产生的原因很了解（因为可能涉及工作交接、人员变动等情况，有些功能不一定出自自己的思考。延伸阅读：工作交接中的“交”与“接”）。

这样既能保证讲解过程的连贯和全面，也能确保在提问、讨论环节的“稳定性”（包含情绪的稳定、思路的稳定、沟通表达的稳定）。

其次，我们要尽量让参与人在会前对整个文档，或涉及到自己工作的内容进行提前阅读。虽然我们无法保障阅读的质量，但是这一步的要求不能省去。因为届时我们无法保证临时性的理解能否真正到位，能否对此功能有全面考量。同时预防一些“漫无边际”的想法影响评审的正常进行。

而且，对于客户评审来说，我们在评审之前，绝大多数问题都应该已经提前沟通完成，该确认的问题也确认清楚，需要关联方配合的内容也已经私下确认，此时不应该遗留太多的问题准备在评审会上讨论（特殊情况除外），从而提前保证评审的连续性和目标感。

最后，我们需要协调好时间，发会议通知（形式不限），并且准备好讲解过程中需要用到的文档、物料等。还要单独准备一个文件或记事本，将讨论过程中的遗留问题记录下来，把待确认的问题列清楚，免得遗漏关键内容。

04 评审中的讲解

这里又涉及到需求讲解的很多方法和细节，我在之前的文章中虽然总结了需求讲解的注意事项，但是针对需求评审中的讲解还有一些特殊的情况。

1. 针对评审内容和参与者，适当调整讲解的细致程度

• 我们以客户评审为例，如果有大领导参加，而且需求的内容很多，那我们需要挑重点的功能来讲解，并且不需要讲解具体的规则；
• 如果有很多关联方参与，则侧重点在这些关联方如何配合，关联方在整个平台中扮演怎样的角色；
• 或者某些功能属于产品的标准化流程，则也可以加快进度，重点讲解特色化功能的逻辑关系。

总之一句话，同样的内容根据不同的听众一定有不同的讲解套路，我们要知道对方更关心什么，同时时刻提醒自己本次评审的目的是什么。

我们所有的讲解、讨论，都要基于目标而来。

2. 针对评审参与者与背景，适当调整宏观场景的描述

• 比如功能的迭代评审，宏观场景描述更多侧重于本次为什么要迭代这些新功能；
• 如果是0-1的新系统评审，则要把需求的背景，整体的参与角色、场景通过流程图或其他形式表达清楚；
• 如果内部评审或技术评审大家对这部分内容很了解，则可以更快的直奔主题。

3. 搭配更易懂的表现形式

文字的表现力一定不如图形、动画。为了让听众能够更快的理解，或者避免对方和自己思路不同频，我们可以搭配流程图、原型图、UI图等物料来辅助自己的讲解。尤其是相对复杂的处理逻辑，基于流程图的讲解能让结果事半功倍。

如果条件允许，在讲的过程中在白板上写写画画，不仅能更抓住听众的注意力，让对方更好的理解，还能对讲解人的水平有充足的认可，后续讨论过程也会更信服你给出的方案。

去年有一个新系统的建设，客户评审一共进行了两个半小时，我针对系统的核心流程图的讲解、讨论就占了一个多小时。而这些关键内容真正梳理清楚并让大家理解后，后续的细节其实就没有那么重要了。

而且通过这次评审，让几位关联方负责人很认可我们的方案，后续推进执行过程也很顺利。

05 评审中的讨论

这一步其实是最不可控的，也是最容易产生风险的。因为我们无法预估对方的思维会对整个方案提出怎样的影响。

但换个角度来考量，这个过程又是一个学习进步的时机，我们通过不断的吸收对方的意见，并快速甄别筛选，想出应对策略，本质对自己的能力也是一个很高的要求。

同时还可以以同理心站在对方的角度深入考虑，他为什么如此关注这个问题？他为什么会想在这里加这个功能？他为什么对我的方案产生质疑？

这一系列的过程，最终都能够让我们通过本次评审“成指数型”成长。

具体问题和应对策略不再深入分析，这里总结几点小建议供大家参考：

1. 关注核心目标，不要让发散性问题影响整体的评审进展；
2. 关注问题根源，不要让临时性的方案为后续埋雷；
3. 合理控制讨论时间，不要让评审变得“又臭又长”；
4. 关注领导关注的内容，优先解决领导的问题；
5. 及时甄别问题，不要因为小问题引申出大问题；
6. 客户评审时，讨论的过程很容易引起需求变更和需求蔓延，要提前和自己团队的人，或者关联方的人提前沟通好，届时一起“打打配合”；
7. 讨论的内容无论结果与否，都记下来，用于会后自己的复盘总结。

06 评审后的结论

评审即将结束时，一定要进行现场的总结。

总结依然要与本次评审会的目标相结合，并将遗留问题、或会中讨论的结论进行复述，一是为了再次强调这些内容以免遗漏，二是避免大家仍然对这些讨论结果没达成共识，后续推进时又要重新掰扯。

同时对于遗留问题要列好推进周期、关联人，并且对下一步的工作进行初步确认。

比如客户需求评审完成后，遗留了5个问题，两个需要完善方案，两个需要找关联方协调确认，一个属于遗留问题，要等到某个阶段再来决定。

• 这时我们需要向参会者表达新的方案什么时间能够完成，届时会再更新一版供大家查阅；
• 确认两个关联方的协调时间和人员，由谁负责主导，什么时间能够确认下来；
• 还要把遗留问题的风险提出来，而且等到可以做决定时不要遗忘，并且不能对项目的整体进展，上线验收等产生影响。如果存在类似的风险，则要提前确认折中方案或置换方案。

最后确认本次评审是否需要二评。

07 评审后的完善

评审结束不是终点，也可能是新阶段的起点，也可能是终点前的最后一步。

我没有见过评审后不需要完善方案的评审会，所以无论是否需要二次评审，本次的待修改点一定是必做的。

同时像上文提及的复盘、同理心思考对方的问题，并从中引申出自己业务的新思路，或者拓展自己的认知盲区，从盲区中寻找业务风险点，这些都是在评审之后，或者说方案完善后，需要持续思考的内容。

这些思考要趁热打铁，尽量不要搁置，因为当下的感受是最真实的，自己的思路也是更全面、更发散的。即便有些优先级低的遗留问题，也千万不要不了了之。

即便某个功能搁置不做，作为业务人员，我们也不能不想，否则怎么更进一步呢？

当然，复盘时我们依然要把握核心目标，不仅在本次需求评审会上提到的问题需要复盘，很多问题背后反映的前期工作问题，更要能意识到。

• 比如张三当时为什么提了这样一个驴唇不对马嘴的问题？——很有可能是因为你开始的讲解没有让他听明白；
• 比如李四为什么把上周确认的方案又拿出来讨论？——可能当时的方案没有得到他的认可，或者他原本就没有明白这个方案的内容；
• 比如王五为什么昨天说好帮我推进这个方案，结果今天“反水”了？——可能是因为他发现领导并不支持这个方法，或者他突然发现了此方案的逻辑漏洞；
• 比如赵六今天提的这个问题为什么我之前没有想过呢？——可能是之前工作交接时没有把此功能当做重点，也可能自己本身对业务的理解还不全面，也可能……

所以，评审虽然结束了，但我们的工作没有结束，个人的成长也远没有结束。

08 写在最后

不同的目标，不同的环境，不同的对接人，不同的业务场景，需求评审过程中需要注意的内容都会有很多差异，篇幅有限，不能把更多的例子逐一拆解，但上述所整理的关键节点和方法论，希望能够给有缘读到这里的你，带来一些帮助。

上述的内容并不绝对，比如评审时间的控制，对于客户评审尽量不要搞的太久。但是我也遇到有些客户会和我们一条一条过规则，战线拉的很长。总之我们要“因人而异”合理适当的调整我们的评审节奏、内容。

更不能因为客户问的细而不耐烦，也不能因为客户什么都不问而沾沾自喜。毕竟最终这些没有确认的细节，都可能是后期需求变更、系统缺陷、生产事故的一个个“伏笔”。

需求是系统的源头，在需求阶段每多确认一个细节，每多达成一个共识，每多识别一个风险，都能为后续的开发、测试、投产、运维等各个阶段节省很多时间。

虽然需求的好与坏很难客观评估，但作为一个负责任的需求分析、作为一个有职业素养的产品经理，让需求更完整，更合理，更切合实际，应是我们持久的追求。