关于需求评审，网易团队是这么“玩”的.docVIP

关于需求评审，网易团队是这么“玩”的 　　原本觉得需求评审也就那么回事儿，大家应该都差不多这么做的，没啥好说的。不过，前不久有一位同学问起来我们是怎么做需求评审的，然后发现有一些团队的做法可能还不大一样，他们也还踩着我们之前踩过的坑，他们还在探索更好的方式，于是决定将我们的“玩法”写下来，也许能给困境中的小伙伴一些启发。 　　 　　首先，我这里提到的需求包含了：需求，交互，视觉。 　　当然，在调整到当前状态之前我们的需求评审也存在很多问题，之前我们也有探讨过需求管理的方法。所以，我这次先来介绍一下比较原始的需求评审的方式以及存在的问题。 　　以前我们的做法是： 　　需求评审：各角色的负责人（包含策划，交互，视觉，开发，测试，运营等角色负责人）来参与，没问题的需求全部进入交互阶段进行交互设计 　　交互评审：所有成员（含所有策划，交互，视觉，开发和QA）参加，所有交互稿均会交付给视觉同学进行设计 　　视觉评审：基本无 　　以上这样的状态，给我们带来了几个困扰： 　　首先是所有需求都会进入交互设计和视觉设计阶段，但是最终有可能因为开发评估之后做不完而被搁置，形成了设计资源的浪费 　　交互评审全员参与，由于人数众多，而且分工还未确认，开发并不知道自己负责哪部分，所以参与度很低，一般就是交互在讲，开发就在下面听，也不一定能提出问题，到了后半程，有些同学就开始玩手机，效率很低 　　视觉评审的缺