项目管理-从产品人员的世界出发看该如何管理项目

        至于在互联网公司工作多年，经历过很多产品的开发过程。不可否认的是开发项目发生进度落后，直到deadline前几天加班赶工的情况非常常见，且由于后期开发、测试、上线的各个环节甚至出现有不同程度的仓促应付，产品的上线质量可谓是心悬一线，上线之后也忐忑不安。一旦发生产品有致命缺陷，又着急忙慌回滚版本，重新投入开发意味着前期的努力以及人力、物力、财力投入价值所剩无几，甚至付诸东流，这是对资源的严重浪费，任何事情一次做成的成本才是最低的。所以成熟的项目管理对于产品开发、迭代、升级等都意义非常。

        针对项目采取更适合自己项目特征的管理方法就能够缩短进度、降低成本、提高质量，有时候这种能力的提高是非常明显的，尤其是当项目管理规范化的时候，向管理要效益并不是喊口号，而切切实实、无时无刻不在滋养着这个项目。

        在前公司工作中，我与产品部门、技术部门、测试部门、设计部门等经常聊项目当中出现的管理问题，到底是什么原因造成的，但我们通常都会说到具体是哪一个问题卡住了，延期了，比如在详情页增加的某个功能不太好实现，造成了当前进度落后的结果。其实再往深层次的思考大家都认同是管理不规范，发生风险时也没有及时能够识别，更没有处理的方式和方法。

        也因此，由我们的前项目产品总监提出了一套对于产品管理的经验探索——IPDO规范，并对我们后来的项目提供了积极的指导。现在分享给大家。

---------------------------以下正文--------------------------

概述

什么是IPDO

        IPDO是根据过往研发经验和科学管理理论结合后，制定的一套符合公司客观研发情况的产品管理规范。其名称取自所覆盖的产品管理四大环节，分别为I（Idea），P（Product），D（Development），O（Operation）。

IPDO在执行上，分为环节和角色两大层面。从环节上，具有步骤明确，界限清晰，管理有序，跟踪有方的特点。从角色上，明确了权责关系，参与阶段等内容

制定目的

        IPDO规范用于解决现有常规产品研发秩序与权责较多缺陷与不足的问题。通过规范各方行为和权责，可以有效的控制整个产品周期，从而提升效率、减少内耗、降低成本。为公司战略的实现提供支持。

        但请注意，IPDO为整个产品管理的框架规范，而并非整个产品研发运营规范的全貌，部分细节仍然需要附加的规范进行配合。

环节与角色

        IPDO规范依照一项产品功能（Function）的演进状态，将流程分为四大环节：

1. I（Idea）指提出创意构思（Brain-Storming）和需求粗画（Sketchy）的阶段。在Idea阶段，应产出需求卡，但不对需求点进行细化，仅讨论需求方向和需求的可能的方案。

2. P（Product）指需求卡通过需求分析、分解成具体需求，进入版本规划（Version Planning）和产品详细设计（Product Design）阶段。在Product阶段，应该产出确定的版本计划和产品文档，不能对需求方向和方案进行颠覆，只沿方向和方案细化需求产生设计文档。

3. D（Development）指确认开发版本（Version）进入研发阶段，包括UI出图（D1），编码（D2），测试（D3）等内容。在Development阶段，不能无故增加需求，不能无故修改需求。

4. O（Operation）指研发完毕的版本进入验收（Acceptance）、准备（Preparing）和线上运营（Operating）阶段。此阶段各方应保证版本运转正常，并产生经营结果报告。

        此四大环节，仅能在环节内进行循环。环节与环节之间界限不能被打破，流向不可逆。

I，P环节内的状态管理

        其中I，P阶段的固有特性客观上致使一定量的内容无法进入D，O阶段。因此针对I，P两个阶段项目的管理引入如下两种状态：

1. Active：活跃状态，指纳入可下一环节的项目

2. Inactive：非活跃状态，指暂不纳入下一环节的项目，对于非活跃状态的单项，将执行刷新回收流程

框架流程图

角色（Role）

        执行者

1. 需求方（BO）：需求意图所有者。主要需求方有：CEO，CTO，产品部，运营部。

2. 产品经理（PM）: 需求创造者，产品形态设计者，产品管理者和项目组织协调者。每个需求都有自己的责任PM，责任PM对自己所有的需求，从Idea阶段负责到整个流程结束。

3. 设计师（UI）：负责产品界面、元素等设计。

4. 开发工程师（RD）：负责主要技术架构、研发、详细设计和编码，配合运维发布

5. 测试工程师（QA）：负责随测及版本测试，验证产品的符合性一致性

6. IT运维工程师：负责开发、测试、线上环境的产品部署与状态维护。

审批者

1. CEO：需审核大版本规划。如有重大决定，需CEO签字确认。

2. CTO：需审核常规版本规划。如有重大决定，需CTO签字确认。

流程规范说明

Idea阶段 

简述

        Idea阶段是IPDO的第一个阶段，分为两大步骤：头脑风暴（Brain-storming）和粗画（Sketchy）。

        Brain-storming头脑风暴主要由需求方（包括产品部自身），对所提出的构想和意图进行头脑风暴。头脑风暴后必须产生确定的需求轮廓，按照SMART原则撰写需求卡才可进入粗画阶段，此处SMART原则至少应涵盖：覆盖的客群数量，影响的经营数据，如PV，UV，注册数，订阅数等的增量。

        Sketchy粗画由PM根据需求卡内容，转化为规范，合理的产品方案，由需求方确认后结束Idea阶段。

主要责任方及工作内容

需求方

1. 需求来源方需明确传达所提需求的目的和目标，指出什么样的新产品、方案和服务为什么可以在市场上取得成功，以及取得怎样的成功。

2. 需求方需提供需求卡，并有义务在产品部的要求下配合完善需求内容。

产品部

1. 接收到需求卡后，产品部会将此需求卡列入Idea库中，并针对需求提出的目的、合理性、价值和收益进行分析和判断，与需求方进行探讨、确认；

2. 如需求卡内容不明确、不合理时，产品部有权提出需求的改善建议或否定需求；

输出

1. 对于合理的需求方案，产品部需要将之分解成一条或多条需求录入需求池。

2. 对于不合理的或者超时未定细节的需求方案，产品部需要将其状态变成Inactive，留待将来处理。

Idea项生命周期管理

1. 在Idea库中的未开发各项会依照时间机制从Active转为Inactive。产品部会定期对Inactive项进行清理，联系需求方，进行刷新为Active或者丢弃。

执行界限及注意事项

1. Idea阶段产出的产品方案，只为粗略产品设计，不应精细撰写PRD、原型设计、以及UI设计。

2. 需求方与产品部双方进行解决方案讨论时，请注意控制讨论范围，讨论时间等。

3. 需求方在Idea阶段应该事先讨论需求和解决需求冲突。（需求前置讨论）

Product阶段

 简述

        Product阶段是IPDO的第二个阶段，主要是在产品部牵头的多方决策会议上，根据公司经营意图和产品发展方向，在需求池（REQPOOL）内确定需求实现范围并制定相应的版本，将确定需要实现的需求进行细化，设计原型，撰写PRD，并交付研发的过程。

Version Planning版本规划

       版本的规划与审批

1. 公司决策会议应提前给定版本策划指引

2. 版本分为重大版本和常规版本

3. 产品部组织会议，与需求方、运营、技术等相关方确定需求开发范围，并在给定时间内（不得超过两天）得出结论，形成开发版本（Version）

4. 技术部应对开发版本给定粗略估计工时

5. 开发版本应审批

6. 审批通过的版本，产品部为其分配版本号

Product Design产品设计

版本内框架设计

1. 产品部需要根据版本规划结果，详细设计版本内框架细节。

2. 框架设计初步完成后，应与需求方确认形态。需求方不应提出超出粗画范围外的要求。

3. 需求冲突需要在本阶段解决。

版本内详细设计

1. 产品应按照开发版本进行产品详细设计。产出结果包括描述清楚的PRD，UE等。

2. 责任PM在产品设计环节必须紧密和需求方和技术部门沟通。

3. 责任PM在设计环节必须遵守其他部门内规范。

4. 技术方应该编写确定的技术方案框架。

输出

1. 产品部给出各方认可的PRD以及相关文档。

2. 技术部给出关键功能的技术方案。

3. 上线时间确定。

Development 阶段

Development细分

        整个阶段分为D1-D3阶段，分别是：

        D1：UI设计阶段，配合整个Development安排执行。

        D2：研发阶段，包括架构设计，编码，集成，自测等内容。

        D3：测试阶段，按照功能测试，性能测试等执行。

        阶段间按流水线执行，在时间上可部分重叠，D1为产品部负责，D2-D3环节需按照技术部规范执行。

要求和权责

产品部需要：

1. 跟踪研发进度并负责确认功能实现情况；

2. 解决产品疑问问题；

技术部需要：

1. 在约定的结束时间前完成开发、测试工作。

2. 在进度发生变化时，主动告知各方状态。

3. 研发结束后，提供与线上环境高度兼容的试用环境，包括但不限于前后台环境，试用APP等。

输出

1. 测试通过的发布包以及相应的环境。

2. 相关上线准备物料、文档。

Operation 阶段

        Operation阶段覆盖产品研发阶段后到运行的全部内容，包括：

Acceptance验收阶段

1. 责任PM应组织关系人对要上线版本按照需求详情验证功能结果，包括功能点，视觉，交互体验，结果有效性等。关系人至少应包括：责任PM，需求方代表

2. 对于无法通过测试的可拒绝上线，并向关系方出具验收不通过的通知。

Preparing准备阶段

1. 上线前责任PM协调各方针协商上线前需准备的工作，并监督实施。

2. 技术部应按照需求的要求结合技术实际进行上线工作。

3. 上线结束后，技术部应组织线上回归测试。并通知责任PM。

4. 责任PM确认无误后，应向公司领导和需求方发布Release Note。

Operating投产阶段

1. 需求方应按照其提出的需求验收标准提供需求运行报告供产品部和公司领导审阅

输出

1. 线上发布；

2. Release note；

3. 线上运行数据、问题反馈；

以上阶段必须明确的提出时间目标。

---------------------------以上正文--------------------------

        这个规范，产品总监处于这样一个位置，对与项目整体的全貌把握还不够丰富，但对于我们当时来说已经非常优秀，并且重强调了需求的管理，并引入了需求池的概念，这是非常了不起的。也因此推动了产品需求卡在项目中的应用，并取得了非常好的效果，对于需求管理起到了非常大的规范作用。

        通常来说需求不清，范围不明，是导致项目失败的最重要原因。我在本篇的资源中上传了需求卡的模板和示例，如果你也对我们的需求卡感兴趣，可以查看资源，并下载研究。欢迎评论交流。