项目管理综合管理：被劫持的项目

申请免费试用、咨询电话：400-8352-114

为什么一本讲项目管理的小说要以主人公被绑架开始？汤普金斯先生，这位爱打瞌睡的资深项目经理，公司近期裁员的牺牲品，被绑架到一个完全陌生的国度，委以 一项近乎不可能的任务，开始一次奇异的、难以测度的冒险......这听起来完全像一部卡夫卡式的荒诞小说，但其实却是IT名著《最后期限》的开头。
你会说，这只是制造悬念、吸引读者的套路而已。可是“悬念”，原本只该发生在那些存在风险、需要胆魄和运气的领域：间谍或是反间谍，高空救险，买彩票等 等，哪里有悬念，哪里就有危险，就有失败甚至丧命的可能。为什么软件开发项目会卷入一场悬念、一次历险之中？“最后期限”，英文本来是 “deadline”，直译就是“死线”，据说原本指的是监狱里的最后一道界限，犯人一旦越过就格杀勿论——难道作者是以此象征开发者们头上悬着的剑？难 道作者在暗示，软件项目就很可能挣扎在这样的生死界限上，很可能陷入“被劫持”的危险中？
　　从软件行业之外的角度看，“项目”往往意味着规范的运作，甚至是“成功”的同义语。请设想一个建筑项目。不考虑款项拖欠和成本回收，单纯从设计、施工的角 度来说，“失败”的可能性相当小。如果让外行想当然地推测，软件项目很少与有形的“物质材料”打交道，成功的概率应该较建筑业更高。但是，任何略有经验的 软件开发者都会明白我说的“风险”对于软件项目意味着的比例。让我们援引业界公认的“硬数据”：作为软件开发管理的权威、软件项目研究专家，本书作者迪马 可在他的另一部名著《人件》中谈到，他们“跟踪研究的所有项目中，大约有15%的项目彻底失败。它们或者是被取消、或者夭折、或者延期、或者提交的产品从 来就没有投入使用。对大项目来说成功的可能性更低。在持续了25 个工作年或者更长时间的项目中，足足有25%的项目没能完成。”事实上，《人件》第一章的标题就是“此时此刻，在世界的某处有一个项目正在失败”。无怪乎 有一本项目管理指南叫《软件项目生存手册》——暗示着项目经理需要皇家空军飞行员般的逆境求生技巧，另一本则干脆叫《死亡之旅》，那意思是说，如果一个项 目经理像那些兴致勃勃的探险家一样天真莽撞地走入这片未知的领地，那么等待他的命运不问可知。
　　那么，或许可以说，软件项目从本质上来讲，首先并且总是处于危险之中。面对如此高的风险，不少深谋远虑的项目规划者甚至会像书中的汤普金斯一样，让多个项 目组同时开发同一模块，取最优的结果（据我所知，这种实践在日本软件业相当普遍）。但是，还是有很多不走运的软件项目，要么对此没有足够意识，要么无法负 担大量人力，只有前仆后继地被无名的力量所劫持，像卡夫卡小说中的K或是捐躯南极的斯各特船长那样，在不归路上“继续向前走，向前越迷越深”。
　　一段航程的展望
　　我立刻意识到了自己过度悲观的语调。虽然每次探险都肯定是“死亡之旅”，但显然不是每支探险队都有去无还。以著名的失败者斯各特为例，与他们几乎同时出发 的挪威人阿德蒙森探险队就获得了成功。回到软件行业，根据上面的数字，25%的失败率虽然不能容忍，但是毕竟多数软件项目确实还算得上走运。那么，成功的 秘诀和失败的主因各是什么？如果我们把多年以来软件项目成功、失败的道理都总结出来，不就能在以后的航程中智珠在握，一帆风顺了吗？
　　在纯技术领域，确实已有不少论著致力于这样的工作。很多专家发现大家总在重复相同的错误，进而总结出了软件设计中的一些典型错误思路，并把它们称为“反模 式”。对于一些具体的开发领域，比如Java，我们陆续地看到了名为“Java Pitfalls”、“Bitter Java”、“Bitter EJB”的专著出现，从书名就能读出陷阱之危险、教训之苦涩。
　　而在软件项目管理方面，如果也有这样一部记录成功的航线和沉船的位置的书该多好，我们不就也能据此把握航向、避开那些臭名昭著的礁石了吗？我最初就是怀着 这样的念头开始读《最后期限》。这本书也确实能起到这样的作用。伴随着我们的朋友汤普金斯在虚构的“摩罗维亚国”的历险，我也从一个个机智美妙的故事中学 到了不少Dos & DoNots——每章之后，都有一段以“汤普金斯日记”形式出现的总结，如果时间实在紧张，单单浏览一遍这些日记，你就能在工作划分、人员配备、项目时间 计划、测试、发布等等问题上收割很多真知灼见。
　　但是这样足够吗？如果单凭熟记若干原则就能塑造一位项目经理，那么何以项目管理人才还是眼下最稀缺的资源之一呢？事实上，读完全书后，我感到自己最大的收 获并非任何特定的管理秘诀，而恰恰是这样一个认识：没有任何单一的实践或原则能够确保一个软件开发项目的成功，同样，任何单一的缺陷也未必会将项目导向失 败。就像汤普金斯的成功并非完全依靠本人经验，或者凭借哪个全能智者的指引，而应归功于多种因素的综合作用和他麾下的众多天才的建议，如果我们单纯乞灵于 一个新方法，比如“测试先行”或“持续集成”，甚至，如果我们完全复制书中的所有提示，在下一个项目中取得成功的概率未必会有多少提高。同样，书中的故事 也表明，即使你身旁总有一位“邪恶的贝洛克部长”似的超级决策者，你的项目也不一定就单单因此而满盘皆输。
　　这似乎是对Brooks提出的“没有银弹”定理的一次简单扩充。不过我个人更愿意称此为“软件行业的多元决定论”。多元决定，意味着特定情景下的多种因素 处于一种复杂、动态而又相互交错的关系之中，强调其中哪一个的优先地位都只能是对实情的简化甚至歪曲。以我目前的辨识能力所见，我认为软件开发航线上的最 大阻碍是“商业、技术和管理”这三重因素的互动：软件开发首先并且最终是商业活动，商业利益要求开发周期越短越好、人力物力成本越少越好、后期能容忍的需 求变更越多越好；技术对于软件企业具有核心意义的重要性，尤其是，如何处理商业因素固有的保守性和软件持续的技术革命之间的冲突，成为每一个项目都会遇到 的问题；而软件项目的管理者更存在如何协调技术与非技术因素，如何对看似纯属理智产物、其实充满未知因素的开发过程进行监控的难题。
　　软件项目的一叶之舟，就航行在这三种因素共同作用而形成的湍流和漩涡之中。当我们将目光停留在任何单一的方面时，某个促狭的魔鬼就会从另两个领域悄然潜 入，引发令人懊悔的后果。克服这些阻碍，需要耐心、对所有问题领域的尊重、甚至还要一点点运气。想要只靠使用某个“项目管理软件”、掌握某种技巧或某种“ 境界的提升”，一劳永逸地解决所有问题，目前在我看来是不现实的：我们面临的困难，在Brooks的意义上是“本质”而非“偶然”的。即使某个特定的项目 中解决了某个困难，也无法保证从此我们就对它有了免疫力。来自考试大项目管理站。
　　但在硬币的另一面，正如德国人的名句所言“哪里有危险，哪里就有救渡”。软件项目的这种内在的复杂性，也许同样是其“奇异的魅力”之所在。如果软件开发的 艺术完全可以通过抽象的原则“线性地”掌握，那么我们甚至可以自问，会不会有一天软件项目只由计算机自行开发，人类开发者完全被取代呢？在严格的科学意义 上解决这个问题，也许需要更明晰的“可开发性”定义（就像上世纪中人们对“可计算性”的澄清一样）。细致的考察留给有志于图灵奖的各位完成。不过直观地考 虑，依据上面的讨论我们就可以相信，软件开发的困难所在，正是机器无法通过形式化的方式克服，而人类开发者最为擅长的部分。我想这是真正倾心于这项事业的 人乐于看到的论证：要感谢这些困难，广大软件开发人员不会在某天早晨醒来发现自己已被一台能干的计算机取代。