评审制度是互联网产品管理的重要手段，评审制度贯穿于产品管理的战略规划、产品设计、技术实现、产品运营、产品营销等各个环节。可以说高效的评审制度是一个公司产品管理能力的重要度量标准。简单列举一下评审制度的一些价值所在：

• 通过评审制度可以帮助利益相关方达成对产品建设目标的一致理解；
• 通过评审制度可以对产品规划方案、产品需求方案、技术方案、运营方案、营销方案等的质量进行把关，提升产品品质；
• 通过评审制度可以对产品规划建设过程中的关键点、风险点等进行把关，降低项目实施的风险
• 通过评审制度可以有效提升参评人员的能力；
• 通过评审制度来对方案进行把关，保证系统产品架构、架构设计的精神始终如一地贯彻下去

     尽管产品评审如此重要，但似乎没有哪家公司的评审制度是高效的，大家都在抱怨评审制度的万千罪恶，评审会议或是演变成了过形式，或是演变成了各大阵营的PK大会。关于评审制度，在各种软件工程的图书及方法论都有所涉及，这里的重点不是讨论评审制度的通用准则（例如产品评审那点事 ），这里主要讨论一下一个平台型的产品在运营过程中怎样通过评审制度来把关。

1、建设期项目 VS. 运营期项目

   对于诸如支付平台、开放平台这类采用了产品平台理念的互联网产品（产品平台），其处于建设期的产品的项目管理与处于运营期的产品的项目管理所面对的挑战不尽相同。

   之所以强调这些产品平台，主要在于对于很多互联网产品而言，主要逻辑就是网站前端，因此这些网站的评审相对容易，只需要采用原型驱动的方式。但对于这些平台化产品，不单纯只是一个简单的网站页面开发工作，这些系统最复杂的逻辑一般在于后端的业务规则、业务逻辑，而这些并不是一个原型就能够说明清楚的。

  1）、建设期项目特征

• 项目周期相对长，例如1个月以上
• 项目资源相对于充裕，可以以单独项目组形式运作
• 项目管理可采用传统项目管理方式或者敏捷项目管理方式
• 项目前期准备工作相对充裕，例如产品文档相对完整、完整的原型、完整的项目计划、项目立项讨论会/需求讨论会等、市场调研/竞争对手产品分析等等
• 项目相对独立，受到其他项目的约束较小

  2）、运营期项目特征

• 周期较短，大部分为2周以下
• 资源有限，项目组成员可能还要并发维护其他产品

      由于随着公司业务的扩张，熟悉产品及技术架构的人员始终稀缺，这些人一般都去负责一些重点新项目，必须在工作中帮助新人熟悉系统

• 项目管理一般采用诸如Scrum、XP这样的敏捷项目管理方式，甚至是裁减过的敏捷开发
• 项目准备并不是很充裕，也不可能准备充足后再做
• 项目需要在现有产品基础上进行优化、重构，不能影响现有系统。对于运营型产品，产品架构、系统架构的就是在一点一滴的修改中失控、变形的，必须有机制来控制这些因素

   这里重点讨论运营期的产品评审、技术评审的方法。

2、运营期产品评审的原则

• 不管再紧急的项目都必须做产品评审、技术评审
• 评审必须保持敏捷性
• 评审的形式不重要，评审！=开会，评审的形式可以正式评审、也可以为非正式评审。评审最核心的是需要有熟悉系统、有能力的人对方案进行把关
• 评审的目的不是找到最优的方案，而是在现有资源约束下最合理的方案
• 没有完美的评审制度，关键在实践中持续优化评审制度，建立适合自己公司情况的评审制度及跟进措施

3、运营期产品评审的方法

      对于运营期的产品评审而言，并没有最佳的实践方案可供参考，每一家公司都有自己现实的业务状况，不同的业务模式有不同的评审方式。可以说对运营期的产品进行高效评审是门平衡的艺术，必须均衡管理规范性、敏捷性、业务现实的要求。只不过整体而言，运营期产品评审的方法核心都是相同的：基于团队协作前提下的持续完善。

• 运营期的评审制度需要运营期的产品研发流程支撑。应当制定针对运营期产品研发的简化流程（相对于建设期的产品研发流程而言），以便从其他流程环节的收集暴露评审制度的问题，来保证产品评审制度的持续优化。例如通过质量测试、运营、销售、营销等环节的反馈，发现评审制度失效的项目，纳入到案例库，持续优化研发流程、评审制度
• 建立必须进行评审的硬性标准，细化成可量化的checklist形式（简单为第一准则）

       例如开发时间1周以上或少于1周但涉及重点业务模块的都必须过评审。之所以要采用工期及影响1刀切的方法而非采用接口人来评估是否需要评审，主要是避免太多的人为因素导致评审制度流于形式。

       对少于1周且不涉及重点业务模式改动的，由负责人来自行判断。

• 评审必须有利益相关者参与，不能单纯让产品人员、技术人员自己评。例如：产品方案必须有技术人员、运营人员、财务人员等；技术方案必须有产品人员、架构师、业务专家等。参与评审的利益相关者有权将方案打回重做。当然这有涉及到另外一个更大话题：团队协作问题，如果一个团队无法建立信任关系，那再完美的制度都会变成PK会。
• 评审人不需要做全面评审，只对需求关键点、关键业务规则、风险点的方案做评审，以保证评审的高效性。评审结果需要记录相关的流程表单中。
• 建立评审案例库，定期（每月）过评审案例库，持续优化评审制度。评审案例的总结对事而非对人，不要让评审人有必须对结果全面负责的负担。

   一个制度的执行不在于制度最初定义得多么的完美，关键在于制度能否持续不断地优化。持续优化/持续改进/持续完善 是各种管理方法众所周知且行之有效的核心秘密之一，但也是最难贯彻执行的，尤其是相对于那些管理时尚流行语，提持续改进太没新意、太没高度了，于是乎我们都指望有“银弹”来解决面临的各种问题。

打印  |  类别：设计思想  |  源地址