文档介绍：项目管理——某公司软件开发案例

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

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

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

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

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

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

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

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

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

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

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

那么,问题是不是无解了呢? 不知道,我也没有经验,这里只能提供一点看法,周末不想逛街,就写点东西,分析一下身边的问题,说得不对,就按一下DEL,不会太费事。就当是闲聊吧。接着……其实还有一类人的时间,或许他们的时间要求才是最值得研究的。

4、甲方(客户) 一般地,政府作为甲方,内部意见并不完全统一。我们作为承建方,可能要配合那些支持我们的某些甲方代表(暂称友好方,下同),另一方面也要考虑到对我们不太支持的另一些人(暂称反对方)。很可能看起来无关紧要的一个小员的一句话,就会对项目产生不可挽回的影响。
甲方内部的友好方和反对方,他们的时间要求是不一样。反对方,在具体开发的过程中会有一些不配合,另一方面对项目完成的时间要求又会格外的严格。所以,我们的时间表,以达到甲方内部的反对方的时间要求为最优,以达到甲方内部友好方的时间要求为及格。如果我们在开发中,处处以友好方的时间表作为自己的时间表,完全不预留安全时间,那么到最后我们会非常被动。

甲方的