文章描述：互联网运营期产品评审杂思.

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

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

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

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

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

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

  1）、建设期项目特征

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

  2）、运营期项目特征

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

      由于随着公司业务的扩张，熟悉产品及技术架构的人员一直稀缺，这些人普通都去担任一些重点新项目，必须在任务中协助新人熟悉系统

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

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

2、运营期产品评审的准绳

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

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

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

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

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

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

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

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