产品及研发需求评审的阶段【转】

从需求评审的外部来看，需求评审又分为哪几个阶段呢？

需求评审分为不同的阶段，一般分为内部评审、预评审、正式评审和终评审四个阶段。内部评审、预评审、正式评审和终评审的目的不同，参加的人员也有所不同。 同时，每一个阶段也并不一定每次都一次通过。

 

内部评审

主要目的是：产品出了低保真原型之后，先进行内部的评审。即产品经理同事之间的相互评审，尤其是同一产品线有关联的不同项目，如不同客户端或者产品逻辑上有联系。

产品经理同事坐在一起相互提建议、梳理逻辑、找坑，根据需求出发，发现产品逻辑问题。同时内部评审的又一个重要的目的是为了保证在更大范围的需求评审会议上，产品经理同事之间可以保持立场的一致性。

预评审阶段

主要目的是：产品出了低保真原型之后，先小范围的进行沟通，提前灭掉大问题，从需求开始审视，确保方向正确之后，才能够进入高保真设计阶段，减少后续需求推翻带来的人力资源浪费。

一般参加的人员有产品自己、产品线的同仁（包括产品总监）、UE和UI设计负责人、技术总监等。人员范围不宜过大，主要是产品的前半阶段的核心人员。

正式评审阶段

主要目的是：设计根据完善后的低保真设计出高保真页面，产品做好高保真交互原型，此时基本上可以还原产品90%的需求和交互场景，代表着产品的最终形态，除了基本的物料和数据交互之外。也就是说对高保真交互原型质量要求比较高，产品的核心人员会在一起看一下高保真的整体效果。

一般参加的人员有产品自己、产品线的同仁（包括产品总监）、UE和UI设计负责人、技术总监等。主要是在高保真环境下浏览产品的需求、功能、交互以及界面样式，强调高保真的整体感受。

终评审阶段

主要目的是：根据最终完善的高保真交互原型，产品提供产品说明文档，提交给研发，让研发理解需求、统一思想、确认实现方法和数据处理、评估研发周期，最终进入研发阶段。

一般参加的人员主要有产品自己、产品线的同仁、相关研发工程师、测试工程师、运营等。涉及的人员主要是产品的后半阶段的相关人员。

 

以上便是需求评审的4个不同阶段，依照评审的不同目的来划分。当然在实际的执行过程中，并不一定是4个阶段都需要分别走一遍，可以根据实际情况适当地改变策略。

套路是死的，人是活的，具体看所在公司工作方式。对于初级产品经理来说，尤其要注意不同的需求评审阶段的目的。