【IT168 技术文章】

    适用于：专用软件开发的项目管理，与通用软件不同，与大众消费软件不同。涉及甲方、承建方。

    观察项目的三个指标：时间、预算、质量及功能完整性。

    失败的项目一般体现为：超时、预算超支、牺牲了部分功能或质量。彻底失败的项目，就是一个最后压根没有完成的项目，比如烂尾楼。

    首先，我们讨论其中的一个指标，时间。

    每个人对时间的理解不同，同样在项目里面的每个人对项目的时间理解也是不同的。

    1、 公司，希望项目在最短的时间内完成，这样时间和预算都是最小的。当然能做到的项目少之又少，业内有数据的。

    2、 项目经理（为行文方便，暂称为PM，下同），希望项目的计划时间尽可能地长，这样才有机会应付各种突发事件和不可抗的影响，毕竟很多原因是客观存在的。墨菲定律。

    3、 功能模块小组长(如.....等，暂称为小组长)，一方面承受着项目经理的压力，一方面又承受着来自基层开发人员的压力。PM会要求小组长以最短时间完成所负责的部分；开发人员则很反感长期加班、高度的压力感。

    从过去的一年多来看，在时间要求方面，我们公司的意愿并不强烈。当然并不是强烈就可以解决的，后面会讲到，这是本文的重点。

    在我们公司，最后决定项目时间长短的关键，是开发人员。在人数不变、人员不更换的前提下，每个开发人员的产出是固定的，至少目前来说是固定的。加班，也不会有更好的改善，原因已经在我以前的邮件中说明过了。

    那么，从上至下形成一种新的强制性时间要求，会不会有效呢？事实上，不是没人试过，结果估计并不理想。程序开发是一种脑力劳动，决定一件任务完成所需时间是由程序员的脑袋决定的，甚至任务完成到什么程度，如果不花费大力气的检查也是不会轻易能发现的。这点有过中层管理经验的人，应该都清楚。例如，管理人员要求用三天完成某个新功能，开发人员说至少要一周时间，即使最后管理人员令开发人员妥协了，他得到的也很可能是一个半成品——能用，但有缺陷；或者表面功能完成了，主线功能有部分没有完成。

    换人吧，中国程序员遍地都是，这不是问题的关键，所以换人作用不大。新人很快会被同化。那全换吧？全换是什么概念，换到哪个级别，这是个Big Question。而且还有另外一个问题——知识传承。弄不好，伤筋累骨，结果还不一定就能如愿。

    那么，问题是不是无解了呢？ 不知道，我也没有经验，这里只能提供一点看法，周末不想逛街，就写点东西，分析一下身边的问题，说得不对，就按一下DEL，不会太费事。就当是闲聊吧。

    接着……其实还有一类人的时间，或许他们的时间要求才是最值得研究的。

    4、 甲方(客户)　一般地，政府作为甲方，内部意见并不完全统一。我们作为承建方，可能要配合那些支持我们的某些甲方代表（暂称友好方，下同），另一方面也要考虑到对我们不太支持的另一些人（暂称反对方）。很可能看起来无关紧要的一个小员的一句话，就会对项目产生不可挽回的影响。

    甲方内部的友好方和反对方，他们的时间要求是不一样。反对方，在具体开发的过程中会有一些不配合，另一方面对项目完成的时间要求又会格外的严格。所以，我们的时间表，以达到甲方内部的反对方的时间要求为最优，以达到甲方内部友好方的时间要求为及格。如果我们在开发中，处处以友好方的时间表作为自己的时间表，完全不预留安全时间，那么到最后我们会非常被动。