需求评审这么“玩”更高效

编者按：本文来自微信公众号“网易杭研项目管理”（ID：NeteasePM），文/何燕华；36氪经授权发布。

原本觉得需求评审也就那么回事儿，大家应该都差不多这么做的，没啥好说的。不过前不久有一位同学问起来我们是怎么做需求评审的，然后发现有一些团队的做法可能还不大一样，他们也还踩着我们之前踩过的坑，他们还在探索更好的方式，于是决定将我们的“玩法”写下来，也许能给困境中的小伙伴一些启发。

首先，我这里提到的需求包含了：需求，交互，视觉。

当然在调整到当前状态之前我们的需求评审也存在很多问题，所以我先来介绍一下比较原始的需求评审的方式以及存在的问题。

基于以上问题，我们逐步对相关的评审机制做了一些调整，调整后的情况如下：

参与人员：团队核心成员（交互评审），相关功能的各角色成员（交互说明）

评审目标：评审交互的合理性，以及交互的可行性评估

评审形式：分为交互评审和交互说明。

整体交互稿的交互评审，在交互评审后一天内，参与评审的核心开发针对交互做一个基本的评估。反馈：哪些需求肯定做不完，这些需求就不需要全部进入视觉设计了。

在交互和视觉稿基本确认之后，在当前迭代的后期，再分批跟相关功能的开发和测试进行交互说明。此时，开发的基本分工已经确认，大家会更细致来听，并且能够提出比较细节的问题，当然此时交互稿需要修改的问题会比较少，基本不影响整体的安排。

调整思路：

1. 与需求评审一样，交互评审之后，基本上就能确认工作量，但是只需要核心的开发在交互评审之后的一天内大致评估工作量，定义是否有一些需求已无需进入视觉阶段，减少了浪费。

2. 缩小参与交互评审的人员范围，让在场的人能够充分参与；节约未来参加评审的同学的时间。

3. 缩小参与交互评审人员的范围，可能牺牲了一部分其他人的意见，为了补充这部分人的意见，所以在新迭代即将开始的时候再组织一次交互说明，不仅引入了这部分人的意见，同时也可以将交互做更细致的沟通。

4. 最后的交互说明，不需要所有人同时过来，而是分批进行说明，这样既能让具体的执行人员能够了解交互细节，又不会浪费大家时间。

评审目标：评审视觉稿是否满足需求，以及从策划和交互的角度提出建议

评审形式：当面沟通。视觉设计师会将设计稿邮件发给相应的策划交互，抄送开发，并且邀请策划和交互当面沟通意见。

调整思路：

1. 视觉稿没有评审，经常出现在后期策划交互走查时发现问题。但是视觉稿的评审又不适合做的太重，本身视觉设计是一种无法明确定义好坏的问题，不是越多人参与就越好，所以只定义策划和交互参与，开发只需看实现上是否有困难即可（一般比较少）。

2. 形式必须定义清楚，否则就会容易执行不到位。

结语

当然调整之后的模型也有一些限制条件：

本文讲的更多还是术的层面，关于评审道层面的讲解在《网易一千零一夜》一书有详细解读，大家可以按需进行阅读。

网易杭研项目管理部（ID：NeteasePM），为网易杭州研究院项目、产品提供项目管理服务，提升整体项目管理氛围和水平，从而提高项目成功率和增强团队成熟度，也对公司内外部输出培训，并出版了《网易一千零一夜》分享项目管理实战经验。