前言

书接上回，前面已经对“做好，而不是做完”的问题，进行分析和提供解决方案了，就是这一篇文章，现在就要对“项目月末统计及时完成率，出现人人达标的情况”的问题，进行分析和总结，希望能梳理出有价值的东西。

任务及时达成率数据不够客观

我设计的项目管理系统，存在任务及时达成率、及时验收率，都人人达标的情况。

这个是什么原因的呢？

实际上，是因为我们对任务变更没有做管控导致的，而为什么不对这个做管控呢？

原因是插入需求的频率过高。

为什么过高呢？

因为项目业务肯定是要根据客户反馈的情况，去做调整的。要第一时间去响应客户的需求。

所以，很多时候，虽然我们制定了项目计划，但在执行过程中，经常出现任务变更的情况，而这个时候，没有去深究到底要不要、应不应该变更，而是默认允许变更了，只要有产品、后端、前端、运维等一方出现需求上面、或者任务执行未及时达成，影响后续关联的任务，那么上面的任务就会出现变更的需求，而这个时候，身为项目负责人，是应该综合考虑和判断，是否允许变更的，但是没有去抓这个环节，只是都是默认变更了。

这个本身就是一个漏洞了。

因为对于研发而言，如果你不允许插入需求，那么就太僵硬、死板了，但如果总是允许这样插入需求，那么项目计划就很容易失控，久而久之，项目成员就容易出现一种心态，反正最后都是要变更计划的，那么今天做完，还是明天做完，有什么区别吗？

反正制定的里程碑时间，制定的版本发布时间都是要改的，每次好像都没有及时达成过，那么早一点做完，迟一点做完，又有什么区别呢？

这种思想一旦萌生，就很难消除了，要从根源上，从制度上去解决才行。

实际上，还是回到项目计划的目的、里程碑的目的来说的，这个在之前很多篇的文章中叶提到过了，就是项目计划的目的是，有一个方向和时间节点，就好像大海中有一个灯塔一样，大家都朝那个方向前进，而不是，张三往东走，李四往西走，王五往南走，那还怎么做事情？这是其一，其二就是要求项目负责和项目成员，在面对任务变更，各种突发事件时，应该怎么充分发挥自己的智慧，通过有效的策略，就好像打仗摆兵布阵一样，先做哪些，再做哪些，怎么去争取资源，怎么去和其他成员、上级领导协调沟通，以致能够在时间要求内，及时达成里程碑，就像打胜仗一样。

单个项目管理，直接是项目负责人，对项目的把控，其实更为具体和实际，其实，还是很简单的，但是多个项目管理，还是有点难度的。实际上也不能说是难度吧，只是那种要靠他人来成事的情况，会更明显。自己没办法直接介入，要知道引导，辅助，以第三方视角，去掌控全部的事情。

不是单点突破，而是回到源头

所以最终还是要回到项目的完整的生命周期，对每一个环节，都要深入分析和研究，确保自己是真的做到位了。

下一篇，就说明一下完整的项目生命周期有哪些。