如何参加需求评审？

前言

这么多年参加了无数的需求评审，也见过很多同学参加需求评审。有的同学很抗拒需求评审，觉得产品经理一堆废话，自己也听不懂；有的同学觉得需求评审就是浪费时间，一次需求评审会议十几个人动辄1个小时，都没时间写代码；也有同学在需求评审上和产品经理 battle，探讨需求的合理性（🔪需求）；也有同学提前带着问题讨论需求实现的可能性...

以我个人经历举例，刚工作时参加需求评审比较怂，战战兢兢听着产品经理过需求，自己插不上一句话。现在参加需求评审，经常可以基于经验判断需求的可行性和重要性。这样其实就是一个比较舒适的状态，不会陷入一个“疯狂加班但是活永远干不完并且还不知道自己到底干了啥”的状态。

那，到底该如何参加需求评审呢？

一、需求评审前

个人认为需求评审最重要的阶段就是在于需求评审前。

每次需求评审都是一次比较费时费力的事情，所以在产品经理和你说要需求评审时，你可以先找他要一份需求文档，简单地先了解一下这次的需求内容。

1. 判断需求上线后是否能够解决存在的问题

首先，先大致判断一下这次需求的内容上线后是否能够解决问题，比如一个 UI 改版的需求，先了解改版是需要解决什么问题，是用户体验会更好还是能够减少用户的关键路径，如果 UI 改版不能解决这些问题，那这个需求就要画上一个问号。

2. 判断需求的技术实现可行性

其次，可以通过技术视角给到产品经理一点反馈，这次需求中的内容哪些是现有的技术能力就可以支持的，哪些是通过开发排期可以支持的，哪些是无法实现的，让产品经理在需求评审前就了解自己这次需求的技术方案是否可行，评审时也不用天马行空地发散讨论。甚至有没有可能通过一些更简单的方案就可以达成目标。

3. 判断需求内容优先级

最后，可以思考一下，针对这次需求的目标，需求的内容是否都是必要的，排出优先级，有的需求可能和目标根本没关系或者 ROI 特别低，这种需求就完全可以提前拒绝掉。有的产品经理喜欢加戏，也有的产品经理会夹带私货，提一些需求等你砍（上了他会更开心，砍了也无所谓）

这样的准备工作是必须的，不要一脸懵逼地就去参加需求评审，大家在聊需求的时候，至少得能接得上话吧。

对需求的理解程度有的时候能决定你在这次需求里的角色，你如果什么都不懂也没任何意见和建议，大家可能就会忽略你这一环而导致你在需求中比较被动。

题外话：在项目中占据主动的地位，可以按照你觉得最合理的方式设计技术方案，也可以在项目中落地一些你想推动的技术方案，有业务结果的同时也能有技术产出。

二、需求评审中

需求评审的时候，产品经理会先介绍需求的背景以及需求的目标，然后就是正式评审需求内容，我们在参与需求评审时需要仔细听，并且做到：

1. 敢于提出问题

在需求评审前你应该已经对需求有了充分地了解，方案不合理的地方以及和目标不匹配的地方都可以在需求评审时提出来，并且如果有不了解的地方，也可以在需求评审的时候问。其实会发现在需求评审中，大家都会提出很多问题，大家的目的其实很简单，就是尽可能清楚地看清这个需求。

2. 评审的内容，需求文档里必须体现

在需求评审会上提到的任何改动，都需要在需求文档里体现，因为需求文档会关系到后续技术方案设计以及具体的技术逻辑实现，特别是一些边界情况。并且更重要的是，清晰的需求文档也方便后面回溯和复盘，防止因为需求评审和具体功能实现之间存在差异导致误会发生（扯皮）。

3. 记录需求评审中讨论不确定的问题

在需求评审中，一般会出现需求内容中考虑不全的地方，或者需要不在场的人员会后确认的细节，这些都需要通过文档记录下来，并且确认这些事项的 action，跟进人和 deadline。如果不确定的点很多，甚至有重新进行需求评审的必要。

三、需求评审后

需求评审之后，按照需求内容设计技术方案并且进行排期，这里不展开。我们可以先按照自己的理解还原一下需求，复杂的需求可以通过思维导图的形式简单画一下需求流程，然后找产品经理确认一遍，看自己的理解是否正确。

总结

总结就是一句话，严谨对待每一个需求，站在产品和业务的角度考虑目标和价值，站在技术的角度考虑可行性和 ROI，争取做的每一个需求都不是白忙活。