编辑导语：对于产品经理来说，项目管理是一件既头疼又让人很有成就感的一件事。一个项目往往需要很长一段时间才能收尾，其中也有很多的风险存在。本文作者通过回顾自己刚刚完成的一个长达半年的项目，为大家总结了一些经验和教训，希望能够帮助到大家，让新人产品经理们少走弯路。

最近负责的两个长达半年多的项目终于阶段性闭环交付，心里的石头落下了一大半。

回顾这半年多，作为项目负责人的项目管理过程，心中五味杂陈。有因项目风险不确定性的焦虑感，也有因能掌控项目进度和质量的成就感，有为团队成员一起并肩战斗的感动，也有为自己在这个过程中看得见的成长和进步而欣慰。

在项目收尾阶段，总结下在经历项目实战后的项目管理经验和教训，算是个人一个小小的项目结项报告。

本文导图框架如下图，主要从经验篇和教训篇两个方面展开：

1. 经验篇：项目管理过程总结

我理解的项目管理的定义：在一定的范围、时间、成本约束条件下，交付满足质量要求的产物，以获得客户满意的过程。

所以这里涉及到的五个要素：范围、质量、成本、进度和客户满意度，这五大要素，也会贯穿项目管理过程的各个阶段。

项目管理一般分为五个阶段：启动、规划、执行、监控、收尾，下面将重点讲述这每个阶段的目标、要做什么、以及如何做。

1.1 启动阶段

启动阶段一般可分为四个过程，对外的商务谈判，以及内部的项目立项、识别相关方，并组织开工会。

目标是为了明确项目启动的背景、前因后果和来龙去脉，确定项目目标，完成项目愿景和目标的同步。

1.1.1 商务谈判

一部分一般由商务主导，内部配合协助评估合同范围等。

在这里值得注意的是：一定要充分评估项目范围、交付时间、交付指标等，具体明确到交付指标的定义，测试方法，避免后期由于模糊的定义而“填坑”。

1.1.2 识别相关方

识别相关方的目的是为了提前了解项目对各相关方的影响，以及相关方对项目的需求和期望。

相关方分为外部和内部，外部客户根据不同的利益方，对应进行不同程度的关注与沟通；内部相关方，一般就是项目组的成员，包括：商务、产品经理、项目经理、研发、测试等。

1.1.3 项目立项会

基于成本与风险考虑与管控，一般投入超过一定工作量的项目，必须要进行项目立项，说清楚项目的背景、价值与收益等，特别是对外交付的项目。需要撰写项目立项材料，进行立项评审。

立项的过程，需要思考以下五个维度：

1. Why：项目来源，价值意义，是否符合公司的战略目标；
2. What：项目目标需要做什么，项目范围，核心功能；
3. Who：那些人做，涉及到多少资源，成本；
4. How long：做多久，项目的起止时间，初步的里程碑计划；
5. 风险评估：是否存在技术风险、市场风险或其他风险，风险应对措施；

1.1.4 开工会

在项目立项通过后，组织项目相关方参与项目开工会，会议不需要过多讨论项目实现细节，主要与项目组成员同步项目来源和目标，哪些人做哪些事、怎么做等等，并达成共识（以后就是一条船上的蚂蚱啦~）

1.2 规划阶段

在项目启动后，并不是立即投入开发，而是由产品对项目进行规划，目标是梳理需求，确定项目的版本迭代计划、执行方案与排期。

所以这一阶段主要分为三个过程：工作任务分解、任务计划排期以及风险管理。

1.2.1 工作任务分解

工作任务分解：通常又称为WBS（Work Breakdown Structure），不论项目大或小，可以说都是由需求组成，也就是我们常说的需求池，将需求不断的分解，并明确执行路径时，项目的抗风险能力才能更强。

分解方式：一般可按照功能模块进行分解，比如针对于某个平台，按照功能细化开，可以分为会员模块，订单模块，商品模块等等.每个模块又可细分为更细的功能，例如会员模块又分为会员权益，会员信息等。

在需求分解后，确定需求优先级，根据优先级筛选需求形成版本迭代计划。

比如可分为三个版本计划：

1. 1.0版本的目标就是产品“可用”
2. 1.1版本的目标是产品“好用”
3. 1.2版本的目标是满足质量指标

WBS参考图

1.2.2 任务计划排期

1.2.2.1 里程碑计划

在确定需求池，工作任务分解后，根据优先级，确定版本迭代排期，形成里程碑计划.

如下图，比如在什么时间节点分别完成哪些版本需求设计、研发编码、测试验收。

里程碑计划参考图

1.2.2.2 详细进度计划

在完成初步的里程碑计划后，对当前阶段的工作任务进行进一步细化，明确到具体的工作任务、完成目标、责任人，开始时间，结束时间，成果产出等等.

如下图，比如各个功能的需求说明，需求评审、研发详细设计、研发编码、测试用例评审，测试验收等。

详细进度计划参考图

在完成任务计划排期后，建议先线下与各相关方或责任人确认，再开会与所有人同步确认，现场“签字画押”，也就是意味着大家都认同的计划，在执行阶段就严格按照计划执行，原则上不能delay。

1.2.2.3 风险管理

项目管理过程中风险管理贯穿始终，即各个阶段都需要进行风险识别，但尽量将风险前置，避免风险发生时，措手不及。

风险管理的方式，可借鉴PMP里到的风险登记册去管理，一般可分为外部风险和内部风险：

• 外部风险，比如项目范围和需求不明确，验收指标高，以及外部的依赖性等；
• 内部风险，比如一些比较难突破的技术风险，人力不足的资源风险等。

及时识别风险，风险应对措施管控，通过风险登记册记录，并以一定的频度比如每周去跟进风险情况，如下图：

风险登记册参考图

1.3 执行与监控阶段

执行与监控阶段的目标，即依据规划阶段的计划，将项目有条不紊执行下去，定期跟踪监控，对项目进行管控，保证项目进度和质量。

1.3.1 各细分过程跟踪

往往在项目管理过程中，是多个项目同时在并行，或者紧急任务的插入，一个人同时负责多个项目，或者遇到功能开发问题等等，各种因素都有可能导致项目的里程碑delay，所以过程跟踪也是项目管理中非常重要的事。

过程跟踪的方法，可通过每日站会、每周周会的方式，监控项目的执行情况，一般是周会并配合周报的方式。

1.3.1.1 周会

尽量控制在15~30分钟，产品经理可在周会前一天与各责任人check各任务事项的进展情况，做到开会前心中有数。

周会的主题：周任务的完成情况，遇到的问题或难题，以及下周计划，明确到工作任务、责任人、时间节点。在会议结束后，在工作群里同步会议结论。

1.3.1.2 周报

与周会配合，文字邮件的形式同步。但周报的内容，根据不同的汇报对象，有不同的侧重点，比如，向上汇报，建议更突出结论性的输出，里程碑完成情况，top风险管理情况等。

若汇报对象为项目组成员，可以更细粒度，本周周计划完成情况，下周计划，风险与问题情况。

周报模板参考图

1.3.2 阶段性产出文档评审

整个项目生命周期中，不同的阶段会产出不同的文档，对于文档输出和评审是非常关键的一环。

一方面文字输出能留存记录，避免口头传达信息的不准确和理解有误等问题；另一方面，文档评审环节，可以提前把关方案可能存在的问题或风险，避免做完之后与预期不符，造成返工，工作量的浪费。

一般的文档包括：

• 产品需求文档：由产品经理输出，包括功能架构、泳道图、流程图，以及相关的说明等；
• 研发详细设计文档：由研发输出，包括详细的方案设计、接口文档等；
• 测试方案、用例与报告：由测试输出，依据产品需求文档与研发设计文档，设计测试方案与用例，经相关人评审后，进行产品测试，并输出测试报告。

文档不是一成不变的，可能在项目执行过程中，会根据实际情况进行调整，所以一般在文档开头部分加上修订记录，即什么人，在什么时间点，修改了什么内容。

1.4 收尾阶段

收尾阶段的目标，即对可交付产品进行验收，包括内部验收与客户验收，并将项目过程中的相关文档进行归档，总结经验教训，撰写项目结项报告。

1.4.1 产品验收

1.4.1.1 内部验收

一般由产品验收，确定jira问题单是否全部关闭，是否有遗留问题，测试报告、测试结论是否满足交付指标等。

1.4.1.2 客户验收

交付件加密后交付，并在交付后，定期跟进客户集成测试情况，以及客户满意度如何等。

1.4.2 经验教训总结

经验教训总结，即项目复盘是对于每个项目都非常重要，对于一些比较成功的经历、方法等，通过复盘总结，形成经验和规律。一方面可以提高团队的项目管理效率，另一方面，也能形成组织过程资产，为公司减少培训成本。

在这个过程中暴露的问题，比较失败的部分，通过复盘知道如何改进，下次不再犯错，也是下一章要总结的部分。

2. 教训篇：踩过的那些坑

项目管理是整合多个部门的资源，协同并进，产出满足需求的产品的过程，这其中不仅仅是对各事项管理，也包括团队成员的协作、沟通等。

这里梳理我在项目管理过程中，暴露的那些问题，踩过的那些坑，以及对应的改进措施。

2.1 “管事”

给项目交付留buffer。

这一点是“血的教训”，在项目执行过程中，我对于研发出的产品质量过于乐观，并且风险识别不够及时，后面只留给测试两周的的时间，临近交付不断的发生各种问题，内部原定的里程碑交付时间不断的延期。

所以，对于交付物，一定要有“风险意识”，并且留一定的缓冲时间进行bug解决，问题修复。内部交付时间较实际交付时间，进行一定时间周期的提拉，给未知风险留应急处理时间。

每一个方案调整，必须及时分析其联动影响，并验证可行性。项目各个功能模块之间往往有很多依赖关系，牵一发而动全身。

在实际过程中，我没有充分全面的评估好某一个功能模块的改动，对其他功能的影响，并且进行验证，导致后期联调时，才发现很多本应该在前期方案调整时就应该验证发现的问题，导致返工。

其实这里产品一个人的认知具有局限性，应该先评估出可能影响的相关方，再组织相关方一起讨论细节，才能更全面的评估和验证。

2.2 “管人”

适度的强势。

前段时间刚被同事“吐槽”说，平时看着挺小女生的，一工作起来就很强势了。

其实在项目前期，在对自己的项目管理能力不太自信的时候，会比较“软弱”，以前研发跟我说，这个做不了或者比较困难，我可能就“妥协”了。

现在会有明确的项目目标和自己的原则，态度上会更强硬，遇到什么困难，程度有多大，有什么数据支撑。当然有问题也不会让项目组成员独自承担，一定是一起想办法，是否有其他方法解决。

修炼内功才更有说服力。在与同事的项目沟通、协作上，刚开始会觉得如果实力不够的话，就用“人格魅力”凑一凑，够一够，即与项目组成员相处愉快一些，“搞好关系”，这样在资源协调上应该会比较顺利一些。

后面到遇到非常有自己主见的同事，他也提出了我在项目过程中的一些问题，虽然是用非常质疑的口吻，但是我现在是很欣赏和感谢那个同学。

他让我内心变得更大强大，同时也意识到，专业能力、解决问题能力强，才能更有信服力，努力修炼内功才是王道。

写在最后：

对于产品经理来说，项目管理能力是非常重要的一个硬技能：

• 在过程管理上，不断的实战与复盘，内化成自己的能力；
• 在在心态上，项目管理一定不是一帆风顺的，中间一定有出现各种问题，发生各种风险，但一定要保持一个积极的心态，相信冲锋陷阵的团队成员能力，也相信领导作为军师的后盾力量，方法总比困难多，问题一定是可解的。

以上便是我基于PMP的一些理论知识，并结合两个项目实战后的项目管理经验与教训总结，可结合自己的实际项目加以灵活应用，希望能对你有所帮助。

作者：小谭同学；微信公众号：斜杠产品汪

本文由 @小谭同学 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议