项目中"说到做不到"的个人分析

1. 最近有空，回首思考一下自己曾经做过的项目，发现普遍存在几个现象（1）前面给客户承诺的里程碑，一开始还可以达到，从第二个里程碑开始就明显感觉吃力（2）吃力意味着进度有delay，那么加班也随之而来（3）面对客户，只能不停地道歉，然后继续拼命加班（4）当客户有需求变更的时候，我报的时间是“把自己预估的时间*2”，客户听完马上觉得时间太久，给你砍掉1/3。最终，公司觉得派经验丰富的我进度上肯定没问题，客户觉得你经历过这么多项目，难道都是这么一直延期的吗？
2. 首先，我是一个有着4年开发经验的技术人员，遇到两三个人就能完成的小项目时，就像模像样的成为了项目经理。可能是作为技术人员太久了，当第一个项目出现上述现象时，我认为“应该是某个模块的设计上，没有给客户讲清楚，使得客户认为它很简单”，或者当时应该时候某种框架提高测试效率，等诸如此类，永远围绕技术开发相关在寻找问题。现在，我认识到这种反思方式是狭隘的，因为我发现有更多非技术原因。从这个角度上来说，我认为这是对自己的一个突破，超越技术情结，考虑问题会更完整一些。
3. 接下来，我想分析一下这些现象。这些现象用一句话描述就是"到点完不成任务"，就是不靠谱。因为，客户认为我们没有比客户更加了解这个项目。但凡是个客户，都希望遇到一个对项目特别懂的人。这样一方面项目可以做好，另一方面还可以跟你学习，一举两得。反过来，客户要教我怎么做项目，客户要盯着我的进度，某种程度上客户投入的时间更多。从“是否如期完成任务”这个结果可以说明我是不靠谱的。后面加班也好，加人也好，目标都是要如期完成任务，以证明自己是靠谱的。
4. 如何如期完成任务？任务的内容是客户的需求，任务的时间点是我们自己评估的。但是，为什么没有如期完成呢？因为在实际执行的过程中，发现问题比预期的复杂，或者工作量比较多，而且这个似乎是普遍现象。所以，一开始仅有一个里程碑时delay1天，后面的里程碑delay越来越多，因为这个delay是累计的。所以，问题是任务的时间点没有估算好。当然，暂时不考虑团队小伙伴中间的变更等情况。
5. 如何科学的估算时间呢？通常，我们会把整个系统拆分为多个模块，针对每个模块再评估时间，然后累计起来就是项目工期。多次的实际情况，我发现几个现象（1）技术人员评估时间总是会比较乐观（2）评估时间都是拍脑袋的（3）小事情叫雷厉风行，大事情拍脑袋叫不靠谱。之前我计算时间的粒度是模块。一个模块的开发时间，可能是3天也可能是1周，甚至是2周，这种不确定性还是比较大的。想要科学估算，就应该把模块进行再次分解，直到模块中的每个任务最小单元的任务都明确为止，工时控制在1天以内。这样把所有的任务工时累计起来，就是任务的工期。甚至根据模块（功能）的优先级等可以排出项目的里程碑。
6. 正确估算时间的意义。（1）工期谈判中作为支持。但凡客户从心底会认为供应商会给自己留余量，工期是有压缩空间的。所以一开始报工期，客户一定会砍掉一些。这时候，明确的工作分解和时间安排就是我们的支持。一方面，客户会发现我们做事情非常细致，给出的时间是科学的；另一方面，客户面对这个科学的时间，也会调低自己的预期，做出正确的决策（到底是延长工期，还是取消部分功能）（2）项目变更中作为支持。但凡是个项目，都会多少有些变更，这个变更也是有工期谈判的。最终结果，要就变更跟客户达成一致。这种情况下，里程碑延期是正常的。如果不能延期，至少是可以给公司正确利益的。曾经的我，作为项目整理，面对变更是这样的。首先，由于前期的delay，我不得不拼命加班和拼命道歉。当出现变更时，我通常不经意间欣然接受了，因为有变更那么延期就有些理所当然（在心理上，给自己的延期找到了一个合理的理由）。但是要知道我没有给客户一个合理的预期，而且变更只会让项目延期更多。客户虽然眼下买账，但是延期带来的焦虑感会慢慢蔓延，客户的预期是"拜托后面的里程碑不要delay"。但是这显然不可能，项目后期，客户越来越焦虑无形之中会加大对项目的干预。据我观察，他们干预的越多，对项目的预期就会越高，我们延期越多。最后，客户只能用“不靠谱”来评价我这个项目经理。对公司而言，为什么一开始不能合理评估呢？后面可能还有其他的项目会被影响，又是一轮恶性循环。时间是最贵的资产，作为项目经理要尤其敏感。
7. 总结一下，我的问题在于没能正确估算时间。在每个要求报时间的地方都需要做的细致一些，而且要详细的记录下来。不断的实践之后，相信我能做到"说到做到"，变得靠谱一些。