关于需求评审，网易内部是这么“玩”的

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

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

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

　　以前我们的做法是：

　　需求评审：各角色的负责人(包含策划，交互，视觉，开发，测试，运营等角色负责人)来参与，没问题的需求全部进入交互阶段进行交互设计。

　　交互评审：所有成员(含所有策划，交互，视觉，开发和QA)参加，所有交互稿均会交付给视觉同学进行设计。

　　视觉评审：基本无

　　以上这样的状态，给我们带来了几个困扰：

　　首先是所有需求都会进入交互设计和视觉设计阶段，但是最终有可能因为开发评估之后做不完而被搁置，形成了设计资源的浪费。

　　交互评审全员参与，由于人数众多，而且分工还未确认，开发并不知道自己负责哪部分，所以参与度很低，一般就是交互在讲，开发就在下面听，也不一定能提出问题，到了后半程，有些同学就开始玩手机，效率很低。

　　视觉评审的缺失，视觉评审由于没有约定明确的评审流程，所以有一些视觉没有经过评审就进入了开发阶段，直至需求走查的时候才发现有问题。

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

　　>>>>需求评审

　　参与人员：策划，交互，视觉，开发，测试，运营等角色负责人

　　评审目标：评审需求的优先级和价值，以及初步判断可实现性

　　评审形式：集中会议。需求评审完成后的一天内，开发对需求的大小进行初步评估。从估算和计划的角度来看，可以认为这是在需求细节还没那么

　　明确的情况下的评估，有可能存在50%±的偏差，但是他能将多余50%之外的需求砍掉，不必再进入交互阶段。