作/转载者：项目管理者联盟

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

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

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

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

　　在纯技术领域，确实已有不少论著致力于这样的工作。很多专家发现大家总在重复相同的错误，进而总结出了软件设计中的一些典型错误思路，并把它们称为“反模式”。对于一些具体的开发领域，比如Java，我们陆续地看到了名为“Java Pitfalls”、“Bitter Java”、“Bitter EJB”的专著出现，从书名就能读出陷阱之危险、教训之苦涩。

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

　　但是这样足够吗？如果单凭熟记若干原则就能塑造一位项目经理，那么何以项目管理人才还是眼下最稀缺的资源之一呢？事实上，读完全书后，我感到自己最大的收获并非任何特定的管理秘诀，而恰恰是这样一个认识：没有任何单一的实践或原则能够确保一个软件开发项目的成功，同样，任何单一的缺陷也未必会将项目导向失败。就像汤普金斯的成功并非完全依靠本人经验，或者凭借哪个全能智者的指引，而应归功于多种因素的综合作用和他麾下的众多天才的建议，如果我们单纯乞灵于一个新方法，比如“测试先行”或“持续集成”，甚至，如果我们完全复制书中的所有提示，在下一个项目中取得成功的概率未必会有多少提高。同样，书中的故事也表明，即使你身旁总有一位“邪恶的贝洛克部长”似的超级决策者，你的项目也不一定就单单因此而满盘皆输。

　　这似乎是对Brooks提出的“没有银弹”定理的一次简单扩充。不过我个人更愿意称此为“软件行业的多元决定论”。多元决定，意味着特定情景下的多种因素处于一种复杂、动态而又相互交错的关系之中，强调其中哪一个的优先地位都只能是对实情的简化甚至歪曲。以我目前的辨识能力所见，我认为软件开发航线上的最大阻碍是“商业、技术和管理”这三重因素的互动：软件开发首先并且最终是商业活动，商业利益要求开发周期越短越好、人力物力成本越少越好、后期能容忍的需求变更越多越好；技术对于软件企业具有核心意义的重要性，尤其是，如何处理商业因素固有的保守性和软件持续的技术革命之间的冲突，成为每一个项目都会遇到的问题；而软件项目的管理者更存在如何协调技术与非技术因素，如何对看似纯属理智产物、其实充满未知因素的开发过程进行监控的难题。

　　软件项目的一叶之舟，就航行在这三种因素共同作用而形成的湍流和漩涡之中。当我们将目光停留在任何单一的方面时，某个促狭的魔鬼就会从另两个领域悄然潜入，引发令人懊悔的后果。克服这些阻碍，需要耐心、对所有问题领域的尊重、甚至还要一点点运气。想要只靠使用某个“项目管理软件”、掌握某种技巧或某种“境界的提升”，一劳永逸地解决所有问题，目前在我看来是不现实的：我们面临的困难，在Brooks的意义上是“本质”而非“偶然”的。即使某个特定的项目中解决了某个困难，也无法保证从此我们就对它有了免疫力。

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

　　在我看来，和软件项目一样，软件工程学也包括了无法归结为纯粹的科学/技术的内容。因此，与其说软件工程学像纯粹的自然科学，不如说它更接近于经济学，其学科内部又可以分为性质不同的多个领域，其中有一些领域就像经济学的具体计量、建模分析或是统计部分，具有很强的可操作性，另一些领域则是难以形式化的和微妙的。要对这些不同的领域有所言说，也许需要不同的语调和态度。

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

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