来自中国培训门户网站“我爱培训网” | 我爱培训网“财务与项目管理专栏文章” 免费章节

(书评)《最后期限》：被绑架的项目

　　为什么一本讲项目管理的小说要以主人公被绑架开始？汤普金斯先生，这位爱打瞌睡的资深项目经理，公司近期裁员的牺牲品，被绑架到一个完全陌生的国度，委以一项近乎不可能的任务，开始一次奇异的、难以测度的冒险......这听起来完全像一部卡夫卡式的荒诞小说，但其实却是IT名著《最后期限》的开头。

　　你会说，这只是制造悬念、吸引读者的套路而已。可是“悬念”，原本只该发生在那些存在风险、需要胆魄和运气的领域：间谍或是反间谍，高空救险，买彩票等等，哪里有悬念，哪里就有危险，就有失败甚至丧命的可能。为什么软件开发项目会卷入一场悬念、一次历险之中？“最后期限”，英文本来是“deadline”，直译就是“死线”，据说原本指的是监狱里的最后一道界限，犯人一旦越过就格杀勿论——难道作者是以此象征开发者们头上悬着的剑？难道作者在暗示，软件项目就很可能挣扎在这样的生死界限上，很可能陷入“被劫持”的危险中？

　　在软件行业之外，“项目”往往意味着规范的运作，甚至是“成功”的同义语。请设想一个建筑项目。不考虑款项拖欠和成本回收，单纯从设计、施工角度来说，“失败”的可能性微乎其微。按此推测，软件项目很少与有形的“物质材料”打交道，成功的概率似乎会较建筑业更高。但是，任何略有经验的开发者都会明白我说的“风险”在软件项目中意味着的比例。让我们援引业界公认的“硬数据”：作为软件项目管理权威，本书作者迪马可在他的另一部名著《人件》中谈到，他们“跟踪研究的所有项目中，大约有15%的项目彻底失败。在持续了25 个工作年或者更长时间的项目中，足足有25%的项目没能完成。”事实上，《人件》第一章的标题就是“此时此刻，在世界的某处有一个项目正在失败”。无怪乎有一本项目管理指南叫《软件项目生存手册》——暗示着项目经理需要皇家空军飞行员般的逆境求生技巧，另一本则干脆叫《死亡之旅》，那意思是说，如果一个项目经理像那些兴致勃勃的探险家一样天真莽撞地走入这片未知的领地，那么等待他的命运不问可知。

　　那么或许可以说，软件项目从本质上来讲，首先并且总是处于“被劫”的状态中。面对如此高的风险，不少深谋远虑的项目规划者甚至会像书中的汤普金斯一样，让多个项目组同时开发同一模块，取最优的结果。但仍有很多不走运的软件项目，要么对此没有充分意识，要么无法负担大量人力，只有前仆后继地被无名的力量所劫持，像卡夫卡小说中的K或是捐躯南极的斯各特船长那样，在不归路上“继续向前走，向前越陷越深”。
　　 一段航程的展望
　　 我立刻意识到了自己过度悲观的语调。虽然每次探险都肯定是“死亡之旅”，但显然不是每支探险队都有去无还。以著名的失败者斯各特为例，与他们几乎同时出发的挪威人阿德蒙森探险队就获得了成功。回到软件行业，根据上面的数字，25%的失败率虽然不能容忍，但是毕竟多数软件项目确实还算得上走运。那么，成功的秘诀和失败的主因各是什么？如果我们把多年以来软件项目成功、失败的道理都总结出来，不就能在以后的航程中智珠在握，一帆风顺了吗？

　　在纯技术领域，确实已有不少论著致力于这样的工作。很多专家发现大家总在重复相同的错误，进而总结出了软件设计中的一些典型错误思路，并把它们称为“反模式（anti-patterns）”。而在软件项目管理方面，如果也有这样一部记录成功的航线和沉船的位置的书该多好，我们不就也能据此把握航向、避开那些臭名昭著的礁石了吗？我最初就是怀着这样的念头开始读《最后期限》。这本书也确实能起到这样的作用。伴随着我们的朋友汤普金斯在虚构的“摩罗维亚国”的历险，我从一个个机智美妙的故事中学到了不少Dos & DoNots——每章之后，都有一段以“汤普金斯日记”形式出现的总结，如果时间实在紧张，单单浏览一遍这些日记，你就能在工作划分、人员配备、项目时间计划、测试、发布等等问题上收获很多真知灼见。

　　但是这足够吗？如果单凭熟记若干原则就能塑造一位项目经理，那么何以项目管理人才还是眼下最稀缺的资源之一呢？事实上，读完全书后，我感到自己最大的收获并非任何特定的管理秘诀，而恰恰是这样一个认识：没有任何单一的实践或原则能够确保一个软件开发项目的成功，任何单一的缺陷也未必会将项目导向失败。主人公汤普金斯的成功几乎是不可复制的，因为决胜的因素缥缈而暧昧，并不能归结于某一点儿魔术药水式的“方法论”或某个天降神兵式的个人；同样，我们也能看出，即使你身旁总有一位“邪恶的贝洛克部长”似的超级决策者，你的项目也不一定就单单因此而满盘皆输。

　　这似乎是对《人月神话》作者Brooks提出的“没有银弹”原则的一次简单扩充。不过我个人更愿意称此为“软件行业的多元决定论”。多元决定，意味着特定情景下的多种因素处于一种动态、细微而又相互指涉的关系中，其中任何单个因素都不具有优先性。软件项目的一叶之舟，总是航行在“商业、技术和管理”这三股湍流形成的险恶航程里；当我们将目光停留在任何单一的方面时，某个促狭的魔鬼就会从另两个领域悄然潜入，引发令人懊悔的后果。克服这些阻碍，需要耐心、对所有问题领域的尊重、甚至还要一点点运气。想要只靠使用某个“项目管理软件”、掌握某种技巧或某种“境界的提升”，一劳永逸地解决所有问题，目前在我看来是不现实的：我们面临的困难，在Brooks的意义上是“本质”而非“偶然”的。即使某个特定的项目中解决了某个困难，也无法保证从此我们就对它有了免疫力。

　　但在硬币的另一面，正如德国人的名句所言“哪里有危险，哪里就有救渡”。软件项目的这种内在的复杂性，也许同样是其“奇异的魅力”之所在。如果软件开发的艺术完全可以通过抽象的原则“线性地”掌握，那么我们甚至可以自问，会不会有一天软件项目只由计算机自行开发，人类开发者完全被取代呢？而依据上面的讨论，我们或许可以相信，软件开发的困难所在，正是机器无法通过形式化的方式克服、而人类开发者最为擅长的部分。我想这是真正倾心于这项事业的人乐于看到的论证：要感谢这些困难，广大软件开发人员不会在某天早晨醒来发现，自己的职位已被一台能干的计算机顶替了。
　　 人怎样对软件工程说话
　　 但是如果仅满足于指认困难的内在性，本书的建设性意义究竟何在呢？一组命题如果不能按照可重复、可检验的方式把握，那不就等于“废话”吗？推广来说，作为学科的软件工程究竟意义何在？人能够像掌握，比如说，数学知识那样，掌握软件工程学吗？这门学科还是否能像“电子工程”、“生物工程”一样，被当作自然科学对待呢？

　　在我看来，软件工程学中的“纯技术部分”，尤其是系统构架设计，往往是容易确定，并能够通过教学、培训加以掌握的（当然这里和其他自然科学一样，仍需要悟性、实践和创新意识）；而对于其他的内容，特别是与开发的“商业”和“管理”环节对应的领域，虽然也包含高度的内在严格性，但很难直截了当的说明，更不容易通过简单的教学而传授。这些领域更多地与纯粹技术之外的人类普遍经验相关，对它们的学习、培育，也许只能经过实践，经过德国人所说的“教化（Bildung）”而缓慢、耐心地进行。

　　如果采用维特根斯坦的划分，上述前者属于我们能说清楚的“科学”，后者就只配叫“形而上学”了。他的名言是：对于能说的，我们一定能说清楚；对于不可说的，我们必须沉默。那么，人们难道就无法对此言说了吗？那么人们又怎样保持所获得的经验，如何才能在这些领域，比如项目管理方面，作出创新、进步呢？维特根斯坦的另一格言是：不可说的，我们可以“显示”出来。我想，从这个角度解释为什么作者要把对项目管理的思考写成小说，应是“虽不中、亦不远矣”。一部小说，除了“科普作用”和“可读性”之外，更重要的是它更类似于身体力行的“显示”而不是抽象的教条、重要的废话。简言之，它能说出不可说的，能重新塑造读者的思想方式和感受力。我相信，较之单纯的科学/技术学习，这是人类更持久、更普遍的学习模式。

　　当然抛开学习这层意思，只从享乐角度来看，本书故事诡谲紧凑，译笔准确流畅，是IT人士难得的好读物。我时常想，在人类的文学宝库中，各种各样的职业，比如骑士、政治家、艺术家、侦探甚至流浪汉，都存在文学门类加以写照，将来也肯定会有专门的小说类型，描绘日渐庞大的程序员族群。《最后期限》作为尝试，在这个方向上迈出了可喜的一步。