虚假的项目进度该缓行了

发布日期:
2017-04-14

浏览次数:

作为汉捷咨询顾问,我在研发咨询工作中遇到一些企业,有的会说:“在我们公司,软件项目的进度不是问题,比如要求两个月交付,开发人员全力以赴,最后总是准时交付。”这是真的吗?我当然不会幼稚地信以为真。再进一步交流会发现,虽然项目准时交付了软件,然而需求文档、设计文档一概没有,并且交付后,因为质量问题,用户无法使用,还需要四个月的时间不停地修补,之后用户才真正地使用上。那么项目实际进度到底是四个月,还是六个月呢?

我们再来看一下被普遍接受的软件的定义: 软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分,它包括程序(program)、相关数据(data)及其说明文档(document)。

很多人都有体会,在大学实验室写出的代码和在企业做出的软件绝对是两回事:在实验室的代码根本无法称为软件产品,没有文档,没有大量的用户,代码的非功能特性也很少考虑,如可靠性,开发过程也不会按照软件工程方法进行的。与《人件》齐名的另一本软件工程经典之作《人月神话》这样描述什么是真正有用的软件产品:

报纸上经常会出现这样的新闻,讲述两个程序员如何在经改造的简陋车库中,编出了超过大型团队工作量的重要程序。接着,每个编程人员准备相信这样的神话,因为他知道自能以超过产业化团队的1000代码行/年的生产率来开发任何程序。

为什么不是所有的产业化队伍都会被这种专注的二人组合所替代?我们必须看一下产出的是什么。

虚假的项目进度该缓行了

图1.1:编程系统产品的演进

在图1.1的左上部分是程序(Program)。它本身是完整的,可以由作者在所开发的系统平台上运行。它通常是车库中产出的产品,以及作为单个程序员生产率的评估标准。

有两种途径可以使程序转变成更有用的,但是成本更高的东西,它们表现为图中的边界。

水平边界以下,程序变成编程产品(Programming Product)。这是可以被任何人运行、测试、修复和扩展的程序。它可以运行在多种操作系统平台上,供多套数据使用。要成为通用的编程产品,程序必须按照普遍认可的风格来编写,特别是输入的范围和形式必须扩展,以适用于所有可以合理使用的基本算法。接着,对程序进行彻底测试,确保它的稳定性和可靠性,使其值得信赖。这就意味着必须准备、运行和记录详尽的测试用例库,用来检查输入的边界和范围。此外,要将程序提升为程序产品,还需要有完备的文档,每个人都可以加以使用、修复和扩展。经验数据表明,相同功能的编程产品的成本,至少是已经过测试的程序的三倍。 

回到图中,垂直边界的右边,程序变成编程系统(Programming System)中的一个构件单元。它是在功能上能相互协作的程序集合,具有规范的格式,可以进行交互,并可以用来组装和搭建整个系统。要成为系统构件,程序必须按照一定的要求编制,使输入和输出在语法和语义上与精确定义的接口一致。同时程序还要符合预先定义的资源限制——内存空间、输入输出设备、计算机时间。最后,程序必须同其它系统构件单元一道,以任何能想象到的组合进行测试。由于测试用例会随着组合不断增加,所以测试的范围非常广。因为一些意想不到的交互会产生许多不易察觉的bug,测试工作将会非常耗时,因此相同功能的编程系统构件的成本至少是独立程序的三倍。如果系统有大量的组成单元,成本还会更高。

图1.1的右下部分代表编程系统产品(Programming Systems Product)。和以上的所有的情况都不同的是,它的成本高达九倍。然而,只有它才是真正有用的产品,是大多数系统开发的目标。

因此,在很多企业,号称以多高的效率完成了某软件产品开发,其实,完成的是更像上面所描述的程序(program),或者类似于大学实验室开发出产品,如果把程序再变成有用的变成系统产品,则要花费数倍的时间。如果以生产出“程序”作为项目结束的标志,那么这样这个看起来很让人满意项目进度只不过是个虚假的进度,它与项目真正的完成所需要的时间还有非常大差距。

虚假的进度,在很多情况是因为倒排进度计划导致,客户或者管理层要求四个月完成项目,那么项目要做出一个四月完成的进度计划;如果客户或者管理层要求两个月完成项目,那么项目就要做出一个两月完成的进度计划。接下来,项目会想方设法按时“结束”这样项目。当然这些项目“结束”的标志是代码已经写完了,至于代码是否满足客户的需求以及并要的文档工作都是被挪到项目范围之外去考虑了。

虚假的项目进度掩藏了项目的开发问题,特别是项目开发效率问题。被虚假的进度所迷惑,大家看不清项目的实际进度和实际成本。我遇到一个企业,有个五万元的小项目,他们宣称两个人两个月完成了,但实质上后续投入了至少一人年的工作量在不断地完善那两个月完成的那个半成品。如果以总的实际的工作量来算,这个项目不知倒贴了多少钱!

虚假的项目进度最大的危害是它变成了混乱的借口,如果要进行研发管理变革,进行规范化开发,一些常常会说:“有流程是好,可是流程会降低我们的开发效率,而我们项目进度要求又非常高!”只有揭穿在混乱中开发的项目进度的虚假性,研发变革才成为可能。

最后,在到处充斥着虚假项目进度的企业,不会孕育出“第一次把事情做好”的文化,质量和效率都不会在这样的企业中生根发芽;相反,会滋生隐瞒、欺骗、浮夸,蒙蔽了管理层的双眼,让团队斗志,让优秀员工心灰意冷。

虚假的项目进度该缓行了!

相关推荐