优质项目管理的四大要素是:选择正确的人、为他们分配正确的工作、保持他们的积极性和帮助团队凝聚起来并保持团队的凝聚力。安全和变化的辩证关系在于:除非感到安全,否则人们就不能去迎接变化;在所有成功的工程中,变化都是基本的要素之一;安全感的缺乏会让人们反对变化;人们可能会因为来自客观世界的直接的恐吓而觉得没有安全感,但是如果察觉到管理者可能滥用权力来惩罚自己,他们也会觉得没有安全感。风险控制方面,通过控制风险来管理项目;要为每个项目创建并维护风险统计表;跟踪根源性的风险,而不只是最后那讨厌的结果;建立简单的(可能是匿名的)通道,让坏消息能传递到高层。或者在早期,人员超编会迫使项目跨过关键的设计阶段,如果在设计完成之前,工作先被分给了许多人,那么人与人之间、工作组之间的接口就会很复杂……
如果只是把这些管理箴言一一罗列,另外再举几个诸如微软、宝洁、IBM等大公司的经营事迹,那么这本书顶多就是目前我们常见的管理学畅销书籍及励志图书,能成为畅销但很难成为常销。《最后期限》独辟蹊径,作为一本项目管理小说,它是以主人公被绑架开始的:汤普金斯先生,这位爱打瞌睡的资深项目经理,是公司近期裁员的牺牲品,被绑架到一个完全陌生的国度,委以一项近乎不可能的任务,于是开始了一次奇异的、难以测度的冒险……这听起来完全像一部卡夫卡式的荒诞小说。
这样的开篇,或许您会说,这只是制造悬念、吸引读者的套路而已。可是“悬念”原本只该发生在那些存在风险、需要胆魄和运气的领域:间谍或是反问谍、高空救险、买彩票等,哪里有悬念,哪里就有危险,就有失败甚至丧命的可能。为什么软件开发项目会卷入一场悬念、一次历险之中?“最后期限”,英文原词是“deadline”,直译就是“死线”,据说原本指的是监狱里的最后一道界限,犯人一旦越过就格杀勿论——难道作者是以此象征开发者们头上悬着的剑?难道作者在暗示,软件项目就很可能挣扎在这样的生死界限上,很可能陷入“被劫持”的危险中?
据说,在软件行业之外,“项目”往往意味着规范的运作,甚至是“成功”的同义语。请设想一个建筑项目。不考虑款项拖欠和成本回收,单纯从设计、施工角度来说,“失败”的可能性微乎其微。按此推测,软件项目很少与有形的“物质材料”打交道,成功的概率似乎会较建筑业更高。但是,任何略有经验的开发者都会明白我说的“风险”在软件项目中意味着的比例。让我们援引业界公认的“硬数据”:作为软件项目管理权威,本书作者汤姆·迪马克(Tom Demarco)在他的另一部名著《人件》中谈到,他们“跟踪研究的所有项目中,大约有15%的项目彻底失败。在持续了25个工作年或者更长时间的项目中,足足有25%的项目没能完成”。
由此,我们可以这么认为,软件项目从本质上来讲,首先并且总是处于“危机四伏”的状态中。面对如此高的风险,不少深谋远虑的项目规划者甚至会像书中的汤普金斯一样,让多个项目组同时开发同一模块,取最优的结果。但仍有很多不走运的软件项目,要么对此没有充分意识,要么无法负担大量人力,所以其命运大都前仆后继地被归为失败。回到软件行业,尽管有25%的失败率,但是毕竟多数软件项目确实还算得上走运。那么,成功的秘诀和失败的主因各是什么?
在纯技术领域,确实已有不少论著致力于这样的工作。很多专家发现大家总在重复相同的错误,进而总结出了软件设计中的一些典型错误思路,并把它们称为“反模式”。而在软件项目管理方面,如果也有这样一部记录成功的航线和沉船的位置的书该多好,我们不就也能据此把握航向、避开那些臭名昭著的礁石了吗?笔者最初就是怀着这样的念头开始读《最后期限》。这本书也确实能起到这样的作用。伴随着我们的朋友汤普金斯在虚构的“摩罗维亚国”的历险,我们从一个个机智美妙的故事中学到了不少“作为”与“不作为”——每章之后,都有一段以“汤普金斯日记”形式出现的总结,如果时间实在紧张,单单浏览一遍这些日记,就能在工作划分、人员配备、项目时间计划、测试、发布等问题上收获很多真知灼见。
事实上,读完全书后,笔者感到自己最大的收获并非任何特定的管理秘诀,而恰恰是这样一个认识:没有任何单一的实践或原则能够确保一个软件开发项目的成功,任何单一的缺陷也未必会将项目导向失败。主人公汤普金斯的成功几乎是不可复制的,因为决胜的因素缥缈而暖昧,并不能归结于某一点儿魔术药水式的“方法论”或某位天降神兵式的个人;同样,我们也能看出,即使您身旁总有一位“邪恶的贝洛克部长”似的超级决策者,您的项目也不一定就单单因此而满盘皆输。这似乎是对《人月神话》中“没有银弹”原则的一次简单扩充。这一个原则意味着特定情景下的多种因素处于一种动态、细微而又相互干涉的关系中,其中任何单个因素都不具有优先性。因此,即使某个特定的项目中解决了某个困难,也无法保证从此我们就对它有了免疫力。
软件项目的这种内在的复杂性,也许同样是其“奇异的魅力”之所在。如果软件开发的艺术完全可以通过抽象的原则“线性地”掌握,那么我们甚至可以自问,会不会有一天软件项目只由计算机自行开发,人类开发者完全被取代呢?而依据上面的讨论,我们或许可以相信,软件开发的困难所在,正是机器无法通过形式化的方式克服、而人类开发者最为擅长的部分。这是真正倾心于这项事业的人乐于看到的论证:要感谢这些困难,广大软件开发人员不会在某天早晨醒来发现,自己的职位已被一台能干的计算机顶替了。
但是如果仅满足于指认困难的内在性,本书的建设性意义究竟何在呢?在笔者看来,软件工程学中的“纯技术部分”,尤其是系统构架设计,往往是容易确定,并能够通过教学、培训加以掌握的(当然这里和其他自然科学一样,仍需要悟性、实践和创新意识);而对于其他的内容,特别是与开发的“商业”和“管理”环节对应的领域,虽然也包含高度的内在严格性,但很难直截了当地说明,更不容易通过简单的教学而传授。这些领域更多地与纯粹技术之外的人类普遍经验相关,对它们的学习、培育,也许只能经过实践,经过教化而缓慢、耐心地进行。于是,《最后期限》的意义在于它用有趣的故事情节、丰富的人物形象,告诉了我们许多深刻的管理智慧,以及能够帮助我们满足最后期限的实用建议。