让评审效果最大化(评审需求方案都是技术)

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

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

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

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

全文概览：

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

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

2）评审工作量是否可控

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

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

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

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

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

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

4）评审可行性是否合理

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

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

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

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

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

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

02 评审的目标

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

1. 内部评审

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

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

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

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

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

2. 技术评审

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

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

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

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

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

3. 客户评审

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

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

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

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

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

4. 领导评审

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

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

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

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

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

03 评审前的准备

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