很多朋友都学过项目管理知识，但是在项目实践中却难以达到期望的效果。因为项目上的情况和理论知识存在偏差，在执行中更加考验项目负责人的灵活性，只有结合实际场景及时做出调整才有可能完成任务。

纸上得来终觉浅，绝知此事要躬行。本文以实际项目为例，根据项目的启动、计划、执行、收尾的4个阶段分别拆解。作为项目的参与者（非项目经理），复盘实施过程中的有哪些亮点、槽点、及对应解决措施是什么。希望能够在项目管理方面对大家有所帮助。

---

0 1

项目启动

先介绍下项目概况。公司和X省邮政的邮区中心局合作，承接了该省一级邮件分拨中心的快递包裹运营业务，即组织人员对各邮路的快递进行分拣和装卸任务。

为了降低运营中的人力成本支出，以及提高运营管理的作业效率和质量，公司成立了以“邮件运营管理业务升级”为目的的产品项目组。

虽然是公司内部的信息化系统建设，但涉及了全新业务，同时横跨多个部门和团队，项目整体相对复杂。

🐴 小亮点：明确的项目目标和需求范围

解决问题的第一步是要澄清问题。所以在启动阶段的首先要明确项目要做成什么样？代表了领导在当前业务状态下对项目（产品）的诉求。 在充分了解项目需求、项目目标以及项目范围后才能进入计划阶段。

公司是首次负责邮件运营型业务，所以针对运营场景下的各类业务流程及管理办法都处在不断探索和调整中。因此项目经理和产品经理在前期除了研究业务资料，还参与业务运行逻辑讨论，以及对关键业务负责人和一线人员进行多轮调研。充分了解了业务场景、业务痛点、项目诉求。

发现包含但不限于以下痛点：

1） 数据获取分散 ：现场通过纸质单据、微信、邮件等多种途径进行数据的交流，下游人员不能及时获取。

2） 数据流转繁琐 ：用工需求等业务通过纸质单据流转，需要员工在现场找各领导审批，造成长时间等待，影响业务进程。

3） 数据无法沉淀 ：由于数据分散且多形式存储的特点，无法有效沉淀业务历史数据，不利于成本优化等分析。

最终通过产品规划，拟定1阶段任务为：对运营管理中的现场人员用工（长期工、临时工）相关业务进行信息化改造，并通过系统优化部分业务流程。目的在于提高信息流转效率和准确性，同时满足管理者对业务执行过程及结果的监管诉求。

在多次需求澄清会议后，由产品人员输出《人资系统业务需求规格说明书》并由领导签字确认，确保双方在需求方面达成共识。

🐞吐槽点：较为薄弱的团队管控力度

关于项目团队组建这件事……公司先后指派了2个项目团队负责执行任务。先由A部门的项目组负责，包含项目经理1人、产品经理2人、研发测试6人。

因为A团队的项目结果达不到预期，后改由B部门的项目组负责，同时因为时间紧任务重，B部门研发资源不足，借调了A部门的部分人员。最终项目组包含项目经理1人、产品经理2人（含借调1人）、研发测试6人（含借调3人）。

我们就是B部门的项目组。可以看到项目组成员构成相对复杂，不仅是跨部门协作，更是涉及前团队人员。更加考验项目经理对团队的管理能力。

虽然做了部分预案和措施，执行中依然出现了各种问题，比如：

1）团队协作的习惯冲突：

不同团队的工作习惯不一样，组建新团队后各两方人员没有较好的磨合，导致交付物输出进度和质量受到影响。比如：多人拥有代码部署权限，导致线上系统代码冲突，出现bug等情况。

2）人员状态的管控薄弱：

团队成员分别在两地办公，部分在业务现场，部分在总部。项目经理对团队人员请假or在岗状态没有第一时间掌控，造成进度延期。

3）团队氛围持续性低迷：

A项目组成员经过数月高强度工作，成果却不被认可，又安排进入接手团队中。诚然更熟悉业务和代码，但也有疲惫和抵触心理。

🦉 改进点：管理制度的建立、维护和更新

对上述问题需要通过多个维度来解决。无规矩不成方圆，让随意松散的行为受到约束是提升团队管控粒度效率和质量的前提条件。比如从项目管理制度的建立、维护、更新3方面着手。

1）建立管理制度：

在工作链条上交集的团队成员提前约定好交付规范和时间节点等内容，避免后续因为习惯问题引发的冲突。确保所有人员遵循同一套流程规范。比如：需求管理流程，版本发布流程，内外沟通机制……

2）维护管理制度：

制度的执行不能只依靠一份文件，需要不断的宣贯。相应负责人需要及时识别偏离制度的行为并予以修正。

比如：沟通流程中的日会制度，目的在于持续的进度和问题反馈，主持人要注意把控内容，不要让会议变成走形式的流水账。

3）更新管理制度：

制度并不是一成不变的，会根据当下的特殊性进行制度的更新。比如：需求管理机制的更新。

最开始产品从0到1时是整个产品的方案输出，评审后只需要发布原型并告知开发测试即可。随着产品迭代，需求更加零散，新流程则需要将方案发布到禅道（项目协作工具）并在需求池中标注编号。

---

0 2

制定计划

在确定了项目目标、需求范围、可调用的资源等情况后，项目就过渡到了制定计划阶段。计划就是要把抽象的需求转换成可执行的具体事项。因此，本阶段任务围绕具体事项展开，包含任务分解、进度规划、风险控制等内容。

不要认为企业内部的项目对进度的管控会有所松弛。事实上项目用时每多一天，企业就需要支付数千元的成本，所以更加关注产品的快速价值变现。

🐴 小亮点：细致的任务分解和进度规划

任务的细化是多维度全面的细化，包含但不限于：与上一团队的项目交接、本项目团队的组建、产品任务细化、研发及部署任务细化等内容。同时充分考虑项目受到的约束条件，比如截止日期、可调用资源等要素，对任务做出合理的进度规划。

在产品细化方面，秉持着先满足主流程，后满足分支流程的原则。 决定先处理基础数据模块和业务主流程，对结果数据的统计报表等需求降低了优先级，后延至下一阶段处理。

考虑到业务处于不稳定的阶段，先处理相对固定的业务形态对应的需求，避免出现产品上线后不久就面临大范围修改的情况。

基于以上，对本阶段的产品功能模块进行了细颗粒度的拆解。拆解内容如下（已简化处理）：

1）系统基础设置：组织管理、部门管理、角色管理、用户管理等。

2）业务基础设置：临时工管理、长期工管理、黑名单管理、渠道商管理、长期工排班设置、长期工考勤设置等。

3）业务运营管理：用工需求管理、渠道人数分配、临时工考勤、临时工工资、长期工考勤等。

🐞 吐槽点：淡薄的风控意识和清单

虽然对常见的风险事项做了预案，比如项目任务进度规划、需求管理机制、沟通管理机制……但是从最终结果来看依然偏离了预期——产品发布延期。

导致延期的原因有很多，其中一个重要原因是风控反馈行为迟钝。事实上每个项目在执行时都会出现风控问题，重点在于及时识别和处理。

什么是风控反馈行为迟钝呢？对风险清单内的问题处理不够及时，对风险清单外的问题识别不够及时。最终导致问题的扩大，由小问题变成大问题。在本次项目中多次出现风控问题，因为未能及时处理导致影响范围扩散。如下：

1）研发外包采购无结果：

项目组的部分研发人员是通过其他部门借调加入的，但借调只是一时之计，所以项目之初就制定了招募研发外包人员的采购计划。截至一阶段项目结束时，依然没有人员入职。研发资源不足也是导致发布延期的诱因之一。

2）沟通机制执行不规范：

为防止项目实施中出现职责不清或沟通不畅，拟定了《项目阶段事项细化及干系人表》。但是项目相关会议上没有进行持续的宣贯和强调，致使产品研发等部分环节中需要咨询和告知的对象没有沟通到位。

🦉 改进点：风险清单增补机制

风险的存在不以主观意识而转移。 风险管控的重点就是对各类风险进行预测、识别、定级、应对 。事实上，在项目计划阶段已提供了风控清单，依然出现问题！原因是清单外的问题识别不及时、风险应对不及时。可以通过以下举措避免来规避问题。

1）补充风险清单内容：

风险清单是有序管控风险的依据，一方面需要完善风险上报内容，一方面要健全风险上报字段。

- 完善清单内容 ：通过过往项目的风险清单筛选出符合本项目情况的内容进行继承。同时结合项目情况进行新增。比如：采购外包研发人员的事项，在之前项目中没有遇到，所以在本次梳理清单时应予以补充。

- 精简清单字段 ：风险上报内容应简要精准，降低上报难度。字段包含但不限于以下：编号、风险类型、风险描述、风险等级、上报人、上报日期、应对措施、应对责任人、预计解决时间、状态、备注。

2）风险识别机制调整：

在原有的机制中更多的是对已知的风险清单内容进行识别，并且风险清单的巡查不及时，无法将问题遏制在萌芽阶段。应从3方面解决：

- 每日巡查清单 ：在每日的项目例会后，根据反馈的情况对照风险清单进行巡查，及时识别风险。

- 风险项目增补 ：项目执行中，出现的任何异常情况或代办事项，酌情转为潜在的风险清单内容。

- 问题持续追踪 ：很多问题已经发现并反馈了，但最终依然不了了之，直至问题爆发。所以对已发生的问题要标记跟进人和反馈时间，做好持续跟进和预警。

以上项目管理中启用和计划环节的复盘，下一篇继续复盘执行和收尾环节。敬请关注。