在产品评审时是否有时候被一位高层打断，明确指出此产品与企业业务发展方向不符，不能实施？是否在讲解产品时，有些人员似懂非懂？是否产品评审太激烈时经常会忘记一些意见收集……
相信类似上面这些情况在你在过产品时也遇到过，产品评审做为产品把关的重要环节，产品评审的重要性不言而喻。那产品评审到底是怎么一回事呢？
评审，顾名思义就是关于审查和批准项目计划，产品变更和工作进展评价的一个步骤。
产品评审在产品过程中占着很重要的一个环节，是对产品成型，产品质量，产品进展等环节的检测和评估过程。

评审的重要性：
1.需求是开发最重要的一个输入，好的开始是成功的一半! 所以，产品需求的质量很大程度上决定了产品质量。
2.产品风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段带来的风险，就要把需求评审做好。
3.产品评审做不好的后果：
1）需求变更
2）产品目标不明确
3）产品周期不可规划
4）产品功能不可实现
导致后续工作难于开展或经常出现变更。
4、产品经理：“不识庐山真面目，只缘身在此山中”，需求是自己写的，容易受到固定思维的限制，所以，需要一双没有看过这个需求的眼睛来检查一下，有什么问题。
产品需求的不同层次：
目标性需求：定义了整个产品需要达到的目标；――高层关注
功能性需求：定义了整个产品必须完成的任务；――中层关注
操作性需求：定义了完成每个任务的具体的人机交互；――执行人员关注
在做产品评审的时候，应该根据不同的产品需求层次，进行不同的评审。

那么究竟如何做好产品评审呢？

建议一：分层次评审
我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：
目标性需求：定义了整个产品需要达到的目标；
功能性需求：定义了整个产品必须完成的任务；
操作性需求：定义了完成每个任务的具体的人机交互；
目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源浪费的情形。

建议二：正式评审与非正式评审结合
正式评审是指通过开评审会的形式，组织多个专家（可以是多个不同类型的产品经理，也可以为产品相关部门的负责人），将产品涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对产品进行正规的会议评审。而非正式的评审并没有这种严格的组织形式（也就是所谓的头脑风暴法），一般也不需要将人员集合在一起评审，而是通过电子邮件甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这2种方式。

建议三：分阶段评审
应该在产品形成的过程中进行分阶段的评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了产品返工的风险，提高了评审的质量。比如可以在形成目标性产品需求后进行一次评审，在形成系统的初次概要产品后进行一次评审，当对概要产品细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。这样做法对于评审人员的理解能力以及产品经理组织评审的连惯性要求较高。

建议四：精心挑选评审人员
产品评审可能涉及的人员包括：高层管理人员、中层管理人员、潜在用户、开发人员、测试人员、交互、UI视觉等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和产品的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证产品评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。

建议五：充分利用需求矩阵表
需求矩阵表是很好的评审工具，产品经理需将需求列出，通过个个功能需求进行讲解，以及涉及到人员及实现阶段、重要性等进行划分，让更多的人员了解产品需求是什么，以及涉及到的人员，了解各个需求对于产品影响，是否有独立性，产品需求之间的产品功能迭代。列出详细的产品需求，直观的表达给审评人员。

建议六：建立标准的评审流程
对正规的产品评审会需要建立正规的产品评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件，评审需要提交的资料，每次评审会议的人员职责分配，评审的具体步骤，评审通过的条件等等。通过评审流程执行可能会避免一些人员对产品问题争吵的场面出现，让所有的人员定位好自己的产品评审领域，发挥人员的专业性。

建议七：做好评审后的跟踪工作
在评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。

建议八：充分准备评审
评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。

产品评审需要面对的问题还很多，做好准备的评审会让你的产品评审过程事办功倍，做好评审意见收集，把好产品“质量”关。

这是下午与公司的相关人员进行淘宝项目评审后总结的，当然在产品Beta版上线后还会进行产品评审，到时更多的是让用户来进行产品评审。产品评审也就那么点事，反应的是产品经理对产品流程及产品走向的理解，同时更是给其他相关人员心理一个底，让更多的人明白你做的产品是干什么的，为什么要这么做，以及如何去做，什么人去做，如何更好的去做，给所有人一个成功的信号传递―产品一定会成功。

建议继续学习：

1. 使用线框图来简化你的产品设计流程    (阅读：2863)
2. 需求评审与讨论问题的基本方式    (阅读：2982)
3. 技术方案评审    (阅读：2416)
4. 产品UI设计流程    (阅读：2305)
5. 研发流程中与其他岗位协作效率的提升    (阅读：2149)
6. 产品UED流程及交付物    (阅读：1980)
7. 也谈前端开发流程    (阅读：1916)
8. 线下项目工作流程(归纳篇）    (阅读：1839)
9. 关注前端开发流程    (阅读：1755)
10. 线下项目工作流程（分析篇）    (阅读：1709)