项目管理中常出现意料外的状况，一个处置不当就会导致项目的失败，产品上线延期、需求范围变更、消耗资源增加等问题比比皆是。上篇文章以实际项目为例，对项目管理中启用和计划环节做了复盘。书接上回，本文继续复盘项目执行和收尾环节。看看实施过程中的有哪些亮点、槽点、改进点。希望能够在项目管理方面对大家有所帮助。

一、执行任务

经过任务分解和进度规划，需要协调人员和各类资源来按照计划实施任务。执行任务阶段的难点主要体现在资源调配（配置情况、到位情况、发放情况、使用情况）和团队管理两个方面。在资源配置方面，“邮政邮区中心局”项目中首先面临的问题就是产品和研发人员不足、服务器资源不足；在团队管理方面，因为团队分别来自两个部门，加上两地办公，工作协调难度也比较大……总的来说，任重道远。

1. 小亮点：持有资源的充分使用

项目的研发实施时间只要2个月，实施范围基本覆盖用工管理中长期工和临时工两条业务线的主要流程，时间非常紧张。现有资源难以支撑满足项目需求时，从充分利用现有资源和寻求外部帮助两个方向来解决。

1）充分使用已有的资源

将已掌握的资源进行充分地利用，结合计划阶段拆解的任务进行人员安置。同时根据项目节点要求，酌情安排加班等措施来追赶进度。虽然交付物的输出进度上有所改善，但加班不是长久之计。持续加班会影响团队氛围，越往后交付质量也会越低。所以也要寻求外部支持……

2） 积极获取外部的支持

在现有资源不足的情况下，积极上级和兄弟部门协商，申请借调人力和采购硬件等资源。比如：面临产品设计资源不足，就借调同部门不同小组的产品经理支援；面对服务器容量不足和不稳定的情况，及时向公司申请服务器上云和购买容量等措施。虽然最终在人力方面依然没有得到很好的满足，但是一定程度缓解了压力。

2. 吐槽点：团队成员之间的“各自为政”

诚然团队成员都很努力，但由于大家对团队其他人的任务目标了解不够清晰，导致在工作协同方面表现的如同“各自为政”一样。

虽然负责的是同一个项目，但是具体负责的模块并不一样，同时模块之间相互影响，并不是孤立的。在工作协作中暴露了严重问题，在研发环节表现的尤为突出。

1）任务衔接不清晰

项目团队中的研发人员分别来自两个部门，工作习惯没有得到较为充分的磨合。虽然在计划阶段对不同研发人员负责的功能模块做了分工，但是各自功能模块的数据交互等部分没有衔接好，导致代码质量、功能输出进度等受到影响。

比如：A同学负责基础业务数据功能“区域组别岗位”（现场作业级别划分），B同学负责的“用工需求提报”业务流中需要调用该数据，因为沟通不够充分，导致取值出现偏差。

2）发版流程不规范

不同团队的代码发布流程不一样，但是在一个项目中出现了两套代码发布流程只会带来混乱，在项目中就是不规范的！技术负责人在发布前没有制定和统一拉通相关的规范，导致代码多人多次发布到同一代码环境，导致代码混乱，功能崩溃。

3. 改进点：从澄清目标到团结合作

合理的工作协调是快速推动项目进程的基础条件之一，所以为了避免“各自为政”的现象，可以从两方面着手，一方面需要加强团队成员之间工作习惯的磨合，建立合适的任务衔接模式。另一方面，需要就任务目标在团队内部达成共识，从而促进团队成员间的紧密合作。具体如下：

1）澄清目标意义

在团队内部澄清具体的目标要求和目标意义，只有真正了解和认同了目标才能有效的提升凝聚力。

目标要求：是指项目目标下拆解后的子任务目标，根据SMART原则设定和传达。

目标意义：来从过去的角度，阐述做这件事情的出发点是什么，需求解决什么样的问题；从未来的角度，阐述做的事情会达成什么效果。

2）互相知晓目标

为什么要知道他人的任务目标？因为一方面可以提供相关的资源和信息进行辅助，同时可以避免和别人目标冲突的事情；另一方面公开自己的目标，也有利于他人的监督。具体可通过项目日会、周会、板报等形式来展现。

二、项目收尾

磕磕绊绊终于到了项目收尾环节，本环节主要任务是对验收各项任务的输出物，并且向业务部门推广系统。如果验收出现纰漏，项目也将功亏一篑。

最终项目验收通过。但是延期了将近1周的时间，而且功能范围也和项目计划出现偏差。因为在产品研发过程中业务已经发生变化，原先的产品设计已不能适应新的业务场景，不得不进行调整，执行需求变更流程。

1. 小亮点：可接受范围的产品发布

因为需求变更、团队资源限制（外包研发人员没有到位）等原因，产品的验收的时间和范围跟原计划并不一致。好在项目执行过程中做了预警，变更结果获得了项目干系人的认可。同时项目团队为了系统上线后的使用推广做了很多工作。

1）组织产品验收

产品验收并不没有很高的操作难度，但是是过程相对繁琐。由研发、测试、产品等多个角色从各自的角度参与验收工作。

研发验收：根据需求文档在本地环境进行单元测试、集成测试，如有功能性的bug先在研发团队内部处理。

测试验收：根据测试用例在测试环境进行测试。发现、分析、跟踪bug，并提交测试报告。

产品验收：检查功能清单中的功能逻辑实现是否完整。因为本期资源不足，对交互反馈和UI方面没有严格的要求。

2）系统推广准备

面向企业的业务系统不像个人应用那么容易理解和操作，同时系统对现有业务流进行了改造，所以在前期需要产品人员辅助推广和使用。

基础数据配置：产品人员在系统中配置了初始化数据，包含系统基础信息和业务基础信息，如：组织部门、用户角色、班次、人力供应商、人力运营方案等内容。

系统使用培训：项目经理组织了《人资系统》的多场系统专项功能使用培训会议。

系统操作手册：产品人员提供了《人资系统操作手册》，以及面向不同业务角色的《系统操作任务：人事专员/人事经理/业务主管……》。

2. 吐槽点：推动系统使用较困难

研发系统的初衷是降低项目运营上的成本支出，同时提高运营管理的作业效率和质量。要达成此目的必然是离不开各业务人员的支持。虽然项目团队做了很多工作，但从结果上看依然不乐观，存在部分业务环节人员的配合意愿不高等情况。

经过分析，造成不愿使用的原因可能是：

1）增加了用户工作量

在系统试运行阶段，系统各功能和数据没有得到验证，所以业务人员要同时执行原业务流操作和人资系统功能的双流程操作，造成了工作量增加。

2）系统功能不够完善

人资系统V1.0版本的功能模块对业务场景的覆盖不够全面，在数据报表等结果数据呈现的缺失严重。同时系统在交互体验上也存在很大优化空间。

3）对用系统不够重视

因为没有管理层的强烈要求，在推进使用时出现过用户不会操作或遇到bug时就停下来了，并不主动反馈。只有项目经理或产品经理问起时才会提起说明情况。

3. 改进点：多维度的推进使用

在推动业务人员使用系统方面，除了上述常规的方法之外，也需要丰富其他的方式方法。不仅仅是团队人员的自身努力，也要适时借助第三方的力量共同推动事项的进程，比如：更上级的领导，寻求能够自上而下推动的力量。

具体的方法拓展，包含但不限于以下：

1）陪同系统使用

安排产品人员或客户服务人员在业务现场陪同生产，从业务流源头开始，系统功能使用逐一攻克。用户操作时提供必要的指导，减少用户的学习成本和抵触情绪，从而保障系统中业务流程的顺利流转。同时产品人员也可以借机近距离观察用户使用过程中遇到的障碍，记录后转为需求池的内容。

2）快速响应需求

系统的设计不可能完全贴合业务场景，所以用户在使用系统会提出的各种疑问和需求。面对疑问要及时解答，面对需求同样要快速响应。这里的“快速响应”并不是立刻设计方案进入研发，而是需求记录和进度告知，以此提升用户受重视的感觉。需求采集后进入常规的需求管理流程即可。

3）借助高层力量

在刚引入系统的新老流程并行阶段，必然会增加用户的工作量。所以在推动系统使用方面，除了来自团队人员努力，争取高层领导对系统的价值认可（立项阶段基本完成），由高层领导给予一定程度的支持也非常重要。需要根据引入系统后的新业务流程制定出配套的管理制度或作业规范等，自上而下的推行更加有力。以上项目管理中执行和复盘环节的复盘。文中有太多未尽之处，欢迎私信沟通。

本文由 @耳目不染 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议