关于需求评审，网易团队是这么“玩”的
原本觉得需求评审也就那么回事儿，大家应该都差不多这么做的，没啥好说的。不过，前不久有一位同学问起来我们是怎么做需求评审的，然后发现有一些团队的做法可能还不大一样，他们也还踩着我们之前踩过的坑，他们还在探索更好的方式，于是决定将我们的“玩法”写下来，也许能给困境中的小伙伴一些启发。
首先，我这里提到的需求包含了：需求，交互，视觉。
当然，在调整到当前状态之前我们的需求评审也存在很多问题，之前我们也有探讨过需求管理的方法。所以，我这次先来介绍一下比较原始的需求评审的方式以及存在的问题。
以前我们的做法是：
- 需求评审：各角色的负责人（包含策划，交互，视觉，开发，测试，运营等角色负责人）来参与，没问题的需求全部进入交互阶段进行交互设计
- 交互评审：所有成员（含所有策划，交互，视觉，开发和QA）参加，所有交互稿均会交付给视觉同学进行设计
- 视觉评审：基本无
以上这样的状态，给我们带来了几个困扰：
- 首先是所有需求都会进入交互设计和视觉设计阶段，但是最终有可能因为开发评估之后做不完而被搁置，形成了设计资源的浪费
- 交互评审全员参与，由于人数众多，而且分工还未确认，开发并不知道自己负责哪部分，所以参与度很低，一般就是交互在讲，开发就在下面听，也不一定能提出问题，到了后半程，有些同学就开始玩手机，效率很低
- 视觉评审的缺失，视觉评审由于没有约定明确的评审流程，所以有一些视觉没有经过评审就进入了开发阶段，直至需求走查的时候才发现有问题
基于以上问题，我们逐步对相关的评审机制做了一些调整，调整后的情况如下：
需求评审
参与人员：策划，交互，视觉，开发，测试，运营等角色负责人
评审目标：评审需求的优先级和价值，以及初步判断可实现性
评审形式：集中会议。需求评审完成后的一天内，开发对需求的大小进行初步评估。从估算和计划的角度来看，可以认为这是在需求细节还没那么明确的情况下的评估，有可能存在50%±的偏差，但是他能将多余50%之外的需求砍掉，不必再进入交互阶段。
调整思路：主要增加了开发的初步评估，将大大超出团队容量的需求提前砍掉，减少了交互的工作量，使得交互稿可以提前交付，同时也避免了不必要的交互浪费，因为当前版本未能开发的功能，在下一个版本可能优先级就又不一样了，或者早已不符合市场需求了。
交互评审
参与人员：团队核心成员（交互评审），相关功能的各角色成员（交互说明）
评审目标：评审交互的合理性，以及交互的可行性评估
评审形式：分为交互评审和交互说明。
整体交互稿的交互评审，在交互评审后一天内，参与评审的核心开发针对交互做一个基本的评估。反馈：哪些需求肯定做不完，这些需求就不需要全部进入视觉设计了。
在交互和视觉稿基本确认之后，在当前迭代的后期，再分批跟相关功能的开发和测试进行交互说明。此时，开发的基本分工已经确认，大家会更细致来听，并且能够提出比较细节的问题，当然此时交互稿需要修改的问题会比较少，基本不影响整体的安排。
调整思路：
视觉评审
参与人员：相应的策划，交互，视觉，以及视觉负责人
评审目标：评审视觉稿是否满足需求，以及从策划和交互的角度提出建议
评审形式：当面沟通。视觉设计师会将设计稿邮件发给相应的策划交互，抄送开发，并且邀请策划和交互当面沟通意见。
调整思路：
结语
当然，调整之后的模型也有一些限制条件：
- 交互评审的时候，能够找得到所谓的“核心开发”，他要对产品整体的业务逻辑都非常清晰，能够评估新提出的需求大致的工作量。如果团队中的开发都是独立负责一块，项目之间都不了解情况的，那就比较难采用这种方式。
- 这样的视觉评审形式其实也是比较依赖大家的主动性。否则就需要一个人，如视觉负责人来监督，是否所有视觉稿都经过评审。
作者：何燕华，网易资深项目经理，PMP，CSM。先后在网易私有云、网易用户中心、网易GACHA、网易LOFTER等项目担任项目管理工作，积累了丰富的项目管理实践经验，并始终致力于项目的成功交付和团队的健康发展。《网易一千零一夜》主要作者之一。
下一篇：没有了
相关文章：
相关推荐：