有一则故事：在一个需求评审的现场，参加的人有产品线的产品总监、产品经理、设计负责人、技术总监以及老板，产品经理伴着低保真的交互演示，开始介绍产品的需求、功能和交互。
产品总监说，还有一种情况你没有考虑到。
技术总监说，这样做太麻烦了，开发成本很高。
设计负责人说，这个地方的交互你确定是这样的吗？
老板说，我们的用户是不是还有另一种需求，像我自己…
之后，他们又对此争论了一番，才说服老板突然的想法。这时候产品经理心理五味杂陈，一方面觉得他们有的地方说得确实有改进的空间，另一方面面对领导和上级，有些地方他又没有办法很好去公开表达自己的想法。
最后，产品经理只好乖乖地回去一通改，而忘记了最初的需求和思考。
这是大多数产品经理的真实写照，那么如何进行高效地需求评审？
首先，产品经理需要发问，需求评审就没有一次就过的时候吗？
答案是没有，为什么？
有一点观点需要明确，影响产品最终走向成功或者失败的原因有很多，包括真实的需求、良好的用户体验、美观的界面、可预期的开发成本等等。需求评审就是为了发现问题，保证产品能够一直走在正确的方向。从宏观上来讲，需求评审需要倾听。
那么从需求评审的外部来看，需求评审又分为哪几个阶段呢？
需求评审分为不同的阶段，一般分为内部评审、预评审、正式评审和终评审四个阶段。内部评审、预评审、正式评审和终评审的目的不同，参加的人员也有所不同。 同时，每一个阶段也并不一定每次都一次通过。
内部评审的主要目的是：产品出了低保真原型之后，先进行内部的评审。即产品经理同事之间的相互评审，尤其是同一产品线有关联的不同项目，如不同客户端或者产品逻辑上有联系。
产品经理同事坐在一起相互提建议、梳理逻辑、找坑，根据需求出发，发现产品逻辑问题。同时内部评审的又一个重要的目的是为了保证在更大范围的需求评审会议上，产品经理同事之间可以保持立场的一致性。
预评审阶段的主要目的是：产品出了低保真原型之后，先小范围的进行沟通，提前灭掉大问题，从需求开始审视，确保方向正确之后，才能够进入高保真设计阶段，减少后续需求推翻带来的人力资源浪费。
一般参加的人员有产品自己、产品线的同仁（包括产品总监）、UE和UI设计负责人、技术总监等。人员范围不宜过大，主要是产品的前半阶段的核心人员。
正式评审阶段的主要目的是：设计根据完善后的低保真设计出高保真页面，产品做好高保真交互原型，此时基本上可以还原产品90%的需求和交互场景，代表着产品的最终形态，除了基本的物料和数据交互之外。也就是说对高保真交互原型质量要求比较高，产品的核心人员会在一起看一下高保真的整体效果。
一般参加的人员有产品自己、产品线的同仁（包括产品总监）、UE和UI设计负责人、技术总监等。主要是在高保真环境下浏览产品的需求、功能、交互以及界面样式，强调高保真的整体感受。
终评审阶段的主要目的是：根据最终完善的高保真交互原型，产品提供产品说明文档，提交给研发，让研发理解需求、统一思想、确认实现方法和数据处理、评估研发周期，最终进入研发阶段。
一般参加的人员主要有产品自己、产品线的同仁、相关研发工程师、测试工程师、运营等。涉及的人员主要是产品的后半阶段的相关人员。
以上便是需求评审的4个不同阶段，依照评审的不同目的来划分。当然在实际的执行过程中，并不一定是4个阶段都需要分别走一遍，可以根据实际情况适当地改变策略。
套路是死的，人是活的，具体看所在公司工作方式。对于初级产品经理来说，尤其要注意不同的需求评审阶段的目的。
微信扫一扫 
