泰坦尼克号的项目管理及其与软件项目的对比

很少有哪个项目能像泰坦尼克号及其奥林匹克级姊妹舰——奥林匹克号和不列颠尼克号——所取得的那般声名远播、广为人知，这些船的设计始于一百一十年前的今年。当然，从奥林匹克级船只的命运中，我们可以在项目管理方面汲取许多教训，事实上，项目管理还有许多方面值得探讨。

（在整体提及这些船只时，我将简单地把它们称为奥林匹克级船只，因为这三艘船共同构成了 White Star Line 的奥林匹克级船只。泰坦尼克号个体性的、后来才有的名声在此无关紧要。此外，我在此假定，有关奥林匹克级船只及其历史与命运的一般信息对读者而言已是常识，故不再重复叙述。）

鉴于奥林匹克级船只的项目管理已被反复论及，我认为更明智的做法是审视几个现代的对应案例，借助一面宝贵的历史镜鉴来审视当今世界的项目管理实践。项目管理确实是一门延续了数千年的学科，其中许多挑战、技能和技法并没有发生太大变化，而过去的种种陷阱在今天对我们依然适用。那句老话很贴切：如果我们不从历史中汲取教训，就注定要重蹈覆辙。

因此，我在此的目标，是审视该项目的风险分析、风险认知及风险概况，并将其应用于现代项目管理。

首先，我们必须确定奥林匹克级项目中的各方利益相关者。White Star Lines 公司本身（出资公司及主要投资方）及其董事 Joseph Bruce Ismay，承建船厂 Harland-Wolff 及其首席设计师 Alexander Carlisle 和 Thomas Andrews，船上的全体船员（其中包括船长 Edward John Smith），英国政府（我们稍后会看到其作用），以及最重要的，乘客。

与任何一组利益相关者一样，其中存在着不同的角色。White Star 一方是出资方和投资方，在现代软件项目中可类比为出资的客户、经理或部门。Harland-Wolff 是设计者和建造者，与现代软件团队中的软件工程“团队成员”，也就是开发人员本身，最为相近。船上的船员负责项目完成之后的运营，可比作在软件完成之后接手运行最终软件的 IT 运维团队。乘客则很像今天的最终用户，他们希望从工程交付物（船只或软件）以及在该产品之上构建的服务（轮渡服务或 IT 托管服务）中受益。（“Olympic”）

对该项目进行分析的另一个维度，是“鸡”与“猪”式利益相关者之分——其中“鸡”是有所投入并承担风险者，而“猪”则是全身投入并承担终极风险者。在普通软件中，我们用这些比喻来谈论利益相关者的程度之分——参与其中者与全心投入者，但就奥林匹克级船只而言，这些术语却被赋予了新的、骇人的含义，因为在船只的运营阶段，船员和乘客实实在在地把自己的生命押了上去，而投资方和建造者则只承担财务上的风险。（Schwaber）

其次，我认为有必要区分奥林匹克级项目背景下所存在的不同项目。当然，其中有三艘船的实体设计与建造。这是一个单一的项目，包含两个清晰的组成部分——一是设计，一是建造。以及三个离散的交付物，即三艘奥林匹克级船只。在建造阶段结束时，存在一个极为清晰的分界点：参与船只组装的项目经理和团队会停止工作，而运营船只的船员则会接手。

在此，我们已经可以与现代技术世界画出一条重要的类比线：软件产品由软件工程师设计和开发，当它们完成后，便交接给 IT 运维人员，由其接管最终产品的实际预期使用。这两个团队可能同属一个组织框架之下，也可能来自两个甚至更多彼此独立的组织。但工程部门与运营部门之间的分隔，在今天大多数企业中所保持的清晰与分明，与一个多世纪以前的造船和轮渡服务别无二致。

我们还可以更进一步，把 White Star 的跨大西洋轮渡服务与许多现代的软件即服务（SaaS）供应商相比较，例如 Microsoft Office 365、Salesforce 或 G Suite。在这些案例中，相关公司拥有一个工程或产品开发团队来打造核心产品，然后由第二个团队接手这个内部产品并将其作为一项服务来运营。在软件开发领域，这种由创造软件的同一家公司最终成为其运营方、但面向外部客户的模式，正日益成为一种重要的商业模式。在许多方面，奥林匹克级船只对现代软件和 IT 的相关性，是在提升而非下降。

这就引出了一个重要的交接面理解，它在奥林匹克级船只上被忽视了，而在今天也经常被忽视：交接双方各自都认为对方才是安全的最终责任方。工程师们标榜自己设计上的安全性，但一旦被施压，便愿意作出妥协，假定运营程序会缓解风险，而自己的努力在很大程度上是冗余的。同样，当被催促保持进度、争取时间时，运营团队也愿意在程序上作出妥协，因为他们相信工程团队已经做到了让自己的努力变得基本多余的地步——船是如此安全，以致于运营上的防范措施根本没有必要。这种沟通失误，使得这一事业从拥有两类极度安全的体系，沦落到基本上一类都没有。倘若任何一方了解了对方将会或确实会如何运作，他们本可以将其纳入考量。最终，双方至少在某种程度上都假定安全是“另一个团队的事”。尽管这艘船在宣传中大力突出安全，但现实却是它延续了过去半个多世纪以来的总体趋势：每一年所建造和运营的船只都比前一年更不安全。（Brander 1995）

今天，我们在 IT 与软件工程之间看到了同样的问题——只不过焦点不再那么集中于稳定性（尽管那当然依旧成立），而是转向了安全（security），在奥林匹克级船只的语境中，安全（security）可以被类比地看作安全（safety）。在过去十年里，安全（security）已成为技术藩篱两侧最重要的话题之一，而行业所面临的挑战，正源于双方都需要彻底落实安全实践——任何一方都无法真正独自实现安全的系统。为安全所做的规划，根本无法替代在运营过程中以程序方式去强制执行安全。

今天一个绝佳的对比是英国航空（British Airways）以及他们如何对待其所监管的每一次跨越大西洋的航班。作为北大西洋空中交通的主要承运方——正是奥林匹克级船只原本意图横渡的那条航线——英国航空必须维护其在安全方面卓越的声誉。即便在 2017 年，飞越北大西洋仍是一段充满风险且复杂的旅程。

在任何一架英国航空的航班起飞之前，飞行员和机组人员都必须审阅一份长达三百页的任务手册，其中告知他们正在发生的一切，包括飞机、机组、天气等方面的细节。这一流程是如此严格，以致于英国航空甚至拒绝把它称作一次航班，而是正式地将每一次跨越大西洋的飞行称为一次“任务”；其用意正是为了向所有相关人员深刻强调这样一项事业所涉及的严峻性和风险。他们清楚地懂得，改变人们对这样一次旅程的看法至关重要，并且明白一旦人们开始假定其他每个人都会把自己的工作做好、从而可以在自己的工作上偷工减料，会发生什么后果。他们不希望任何人变得疏忽大意，或开始觉得这趟飞行——尽管每天要完成好几次——可以算是例行公事。（Winchester）

倘若泰坦尼克号采用了英国航空这样的做法，灾难很可能就不会在当时降临。单凭运营这一方，本就足以避免那场灾难。同样，倘若当年的船舶工程师们被要求遵守今天波音（Boeing）或空中客车（AirBus）那样的标准，他们很可能就不会在项目推进过程中如此轻易地被管理层施压去修改安全要求。

在许多方面，真正影响奥林匹克级船只的，是一种未受约束的范围蔓延（scope creep）。该项目最初采用的是传统的瀑布式方法，即“前期大设计”（big design up front），而最初的需求是良好的，安全在其中扮演着关键角色。倘若沿用原始的项目需求乃至大部分原始设计，这些船本会比实际安全得多。但对更大餐厅或更奢华陈设的新需求占了上风，项目的范围和参数被更改以迁就这些新的变更。与任何项目一样，没有哪个变更是在真空中发生的，而是会对成本、安全或交付日期等其他因素产生连锁影响。（Sadur）

具体到泰坦尼克号上的范围蔓延是戏剧性的，但在很大程度上是隐蔽的、并不一定显而易见。指出诸如餐厅大小变动之类的小改动很容易，但重要得多的是船只必须交付的时间框架发生了变化。真正改变了项目范围的，实际上是最初的截止期限和各项工程必须相对严格地得到维持。这之所以特别成问题，是因为在泰坦尼克号干船坞作业以及后来的系泊作业期间，年长的姊妹舰奥林匹克号曾多次被调来进行大规模维修，而这对原定计划中可供泰坦尼克号自身作业完成的时间量产生了极大的影响。这类范围变更非常容易被忽视或无视，尤其是事后回顾时，因为实体交付物和原定日期都没有发生任何戏剧性的变化。然而，无论从哪个角度看，泰坦尼克号都是被以远比原计划更快的速度赶工完成的。

在现代软件工程中，有一点已被广泛接受：没有谁能比将要亲自执行某项设计任务的工程师本人更准确地估算出该任务所需的时间。同样被普遍接受的是，没有任何办法能通过管理层施压来显著加快工程和设计工作。一旦项目以最快速度运转，它就不会再更快了。试图加快速度往往会导致错误、疏漏或遗漏。我们知道这在软件中是成立的，并且可以假定它对于船舶设计也必然成立，因为其中的原理是相同的。倘若泰坦尼克号在这一过程中被给予适当的时间，那么安全措施或许会得到更周全的考虑，或者至少在交接时被妥善地传达给运营团队。被赶工的团队被迫作出妥协，而由于时间是约束条件、无法调整，那么不得不偷工减料之处便只能落到别处，而几乎总是落在质量和周全性上。这或许表现为一处错误，或许表现为在更改设计的某一部分时未能充分审视其所涉及的全部因素。

这就把我们引向了整体性设计思维。在项目伊始，奥林匹克级船只是以安全为念而设计的：这种安全源于众多彼此独立的系统经过精心配合的相互协作，它们共同旨在打造一艘高度可靠的船只。我们无法孤立地看待如此规模船只的各个组成部分，那样它们将毫无意义——船体的设计、甲板的样式、货物的重量、所用的材料、舱壁的样式，全都相互关联，必须协同发挥作用。

当项目被推着更快完成或更改参数时，这种整体性思维以及对早先决策的清晰复盘要么没有进行，要么进行得不够充分。相反，个别组件被加以更改，而不顾这会如何影响它们在整艘船中的角色，也不顾由此对整体安全产生的影响。看似微小的变更却带来了意想不到的后果，而这些后果之所以未被预见，正是因为整体性的项目管理被抛弃了。（Kozak-Holland）

这种对工程方面的更改，当然也在运营层面如出一辙地上演。每一项变更——例如不使用双筒望远镜，或不进行冰桶测温——单独来看都多少有些微不足道，但合在一起却影响巨大。很可能（但我们无法确定）当时并未采用一套有凝聚力的项目管理体系，或者至少没有采用流程改进体系。是谁在监督双筒望远镜是否被使用、海水测试是否准确，等等？哪怕任何一项检查都本会揭示出，执行这些任务所需的工具根本就不存在。根本不可能对这些程序进行哪怕一次简单的试运行，更不用说定期检查和流程改进了。流程改进的缺失尤为突出地体现在：Smith 船长曾在 RMS 奥林匹克号上有过实践经验，在其第五次航行中造成了一次海上碰撞，随后又在泰坦尼克号的首次启航中几乎重蹈覆辙。本应成为奥林匹克级船只所有船长和领航员吸取的重要教训，结果却被无视，并几乎是立刻就被重演了一遍。（“Olympic”）

当然，造船和软件是截然不同的事物，但许多教训是可以共通的。其中最重要的教训之一，便是认清造船所面临的种种局限，并认识到在处理软件时，我们何时并不被迫保留这些同样的局限。奥林匹克号和泰坦尼克号几乎是在同一时间建造的，根本没有时间让从奥林匹克号的建造——更别提其运营——中所获取的工程知识得以应用到泰坦尼克号的建造上。在现代软件中，我们绝不会预期这样一种约束，并且能够在某个软件之上以真实代码乃至概念形式构建更多软件之前，至少在某种小的程度上先对其进行测试。今天的项目管理需要尽可能充分地利用既存在于更现代的时代、也存在于我们这一不同行业中的种种差异。某些软件项目至今仍然确实需要这样的流程，但随着时间推移，它们已变得越来越罕见，如今远比仅仅二十年前要少见得多。

非常值得评估的是 Harland-Wolff 在奥林匹克级船只上所做的工作，因为他们显然极力在当时其职权范围内尽可能地纳入各种可行的反馈回路。他们不仅试图利用早先船只的建造来为后续船只学习更多经验——尽管这一点非常有限，因为这些船大多是并行建造的，大多数经验教训根本来不及被应用——更重要得多的是，他们采取了一项非同寻常的举措，让一个“保证组”（guarantee group）随船航行。这个保证组由形形色色的学徒和资深造船工匠组成，来自各种各样的辅助工种。（“Guarantee Group”）

利用保证组来获取直接反馈，这在当时是、而且确实至今仍是前所未有之举，对船厂而言是在硬成本和时间上的一笔巨大投资，要牺牲如此之多宝贵的工人去乘坐豪华舱位往返横渡大西洋。这个小组得以亲眼检视自己的工作成果、目睹其实际运作、在运营中的船只这一语境下加深对其使用的理解、共同开展团队建设、知识传递等等。这远比来自船坞（那里的船只在建造上彼此重叠）的反馈更有价值，这是对其造船事业未来的一项有力投资：一项对产业教育的承诺，很可能在数十年间令他们获益。

现代的部署方式、工具和教育，已经使绝大多数软件从在一种与上个世纪之交造船业所用方法相差无几的瀑布式方法下创建，转向了大多采用某种程度的敏捷方法，从而允许快速测试、评估、变更和部署。范围蔓延也已从某种必须加以缓解或严加管理的东西，转变为某种在开发过程中可以被预期和假定其存在的东西，甚至到了几乎可以加以利用的地步。前期大设计的根本问题之一在于，它总是要求客户或承担客户角色的利益相关者“在前期作出重大决策”，而这些决策对他们来说往往远比设计对工程师而言更难作出。这些早期决策往往是范围蔓延或后期变更请求的一个主要诱因，而通过那些预期需求会持续变化、并将这种变化纳入流程之中的敏捷过程，往往可以减少或避免这些决策。

造船商 Harlan and Wolff 确实建造了一个十五英尺长的奥林匹克号模型用于测试，这在某种程度上是有用的，但当然未能模拟出全尺寸船只日后会产生的水动力作用，也未能预测出这艘新船在靠近其他船只时因其尺寸所引发的某些更危险的副作用，而正是这些副作用导致了该级船只的第一起事故，以及几乎发生的第二起事故。不过，造船商似乎确实在整个设计和建造过程中，于他们所能及的每一个阶段都竭尽全力去测试和学习。（Kozak-Holland）

与现代项目管理相比，这可类比为快速制作一个原型或线框图（wireframe），供开发人员甚至客户在投入进一步精力之前先亲身体验，以免走上一条可能因不可预见的原因而成为死胡同的道路。这在用户界面设计中尤为重要，因为若不给实际用户一个亲自动手操作系统、并由他们自己判断它是否提供了所追求体验的机会，往往就很难妥善预测可用性或满意度评分。（Esposito）

当然，我们必须在奥林匹克级船只所处历史时期的财务趋势与力量这一并置语境中，来审视它们所承担的风险。当时，从上个世纪中叶开始，盛行的财务思维认为最好倾向于冒险而非求稳——就生命、货物或船只的损失而言；并通过保险工具来弥补其中的差额。让船只以冒险的方式运营，相比于对人命过度谨慎，在财务上实在太占优势了。到奥林匹克级船只的时代，这一趋势已经稳固确立了近六十年，并且直到泰坦尼克号沉没所引发的大规模舆论之前都不会开始改变。直到那艘“永不沉没”的船连同船上如此众多的生灵以如此惊人的方式消逝，对公众的市场冲击才得以出现。

这种对风险及其财务权衡的态度，是今天的项目经理们必须像一百多年前的人们那样去理解的。人们很容易陷入这样一种认识：风险是如此重要，以至于值得不惜任何代价去消除它，但项目不能这样思考。在追求降低风险的过程中投入无限的资源是有可能的。在现实世界里，我们有必要在风险与风险缓解成本之间取得平衡。现代一个绝佳的例子——尽管不在软件开发这一具体领域之内——是美国对信用卡欺诈的处理方式。直到仅仅过去的这几年，美国信用卡业界普遍持有的观点都是：在信用卡上采取更强的安全措施以防盗用，其成本相比于不采取这些措施的风险而言过于高昂；从本质上说，花钱去为虚假交易做赔付，比去防范那些虚假交易更具成本效益。这种成本与风险之比有时可能违反直觉、甚至令人沮丧，但它正是必须以合乎逻辑、经过计算的方式来驱动项目决策的那种比值。

同样地，在 IT 领域，人们常常在设计系统时认为停机的代价本质上是无限的，并为缓解停机风险而投入远超过实际中断事件本身一旦发生其代价可能数额的资源。这显然是愚蠢的，但正因为此类成本分析极少被进行、或极少被正确地进行，人们便太容易落入这种心态的陷阱。在软件工程项目中，我们必须以类似的方式来对待风险。接受任何一种风险的存在，并确定其实际风险、该风险所带来影响的量级，再将其与各种缓解策略的成本相比较，对于就该风险作出恰当的项目管理决策而言至关重要。（Brander 1995）

另外，对于超大型项目——奥林匹克级船只无疑名列其中——还有一个额外的概念尤为值得关注，那就是“大到不能倒”（too big to fail）。当然，这是一个在过去十年金融危机期间才出现的现代说法，但这一概念及其现实却要古老得多，对于任何规模庞大到一旦彻底失败便会被记录为一场“国家级金融灾难”的项目而言，它都是一项宝贵的考量。就奥林匹克级船只而言，英国政府最终为投资者隔绝了彻底崩盘的风险，因为在当时，最大的客运航运公司之一的倒闭，对国家而言将是灾难性的。

White Star Lines 实在是“大到不能倒”，并在数年后被强制并入 Cunard 之前，可以说一直由政府托着、使其不致沉没。这一概念——即明白政府不会愿意承担该公司倒闭的风险——在当时是否被计算或考虑过，我们不得而知。然而我们确实知道，今天在面对超大型项目时，这一点是会被纳入考量的。一个正在发生的例子是洛克希德·马丁（Lockheed Martin）的 F-35 战斗机，它严重超出预算、远远逾期、甚至已不再被认为可能有用，却多年来一直被托着不放，而那些不同的政府出资方之所以这样做，是因为他们认为该项目过于重要，即便处于无法交付的状态，也不能任由其对国民经济而言彻底崩溃。随着这一现象越来越广为人知，我们很可能会看到更多项目在其风险分析阶段将其纳入考量。（Ellis）

转到这一等式的运营一侧，我们本可以审视导致泰坦尼克号沉没的诸多出错环节中的任何一个，但我相信，归根结底，最为明显的是整个过程中缺乏标准操作程序（standard operating procedures）。这在某种程度上是可以理解的，因为该船当时正处于其处女航，几乎没有时间进行流程文档化和改进。然而，这毕竟是一家历史悠久的航运公司的旗舰，它有声誉要维护，在这些事务上也有着大量经验。这种解释还忽略了一点：到泰坦尼克号尝试其首航之时，奥林匹克号早已服役，其时间之久足以绰绰有余地形成一套令人满意的标准操作程序。

即便是处女航，基线文档也本应是意料之中的；指望一艘如此规模的船在船员之间没有协调与沟通的情况下还能正常运转，是不合情理的。在第一艘船启航之前，本有充足的时间——事实上是数年——来创建和准备基本的船员运营程序，而且当然，对于所有这类船只都必须这样做，但显而易见的是，就泰坦尼克号而言，这样的操作程序是欠缺的、缺失的、且未经检验的。

负责制定操作程序的一方，很可能会被认定为来自项目等式中的运营一侧，但其中也需要工程和建造团队提供或与之协调一定程度的此类文档。在泰坦尼克号上崩溃的许多程序包括：在压力之下指挥链的失灵——公司董事接管了舰桥而船长予以默许；无线电报务员被指示把转发乘客电报作为优先于冰山警报的事项；任由无线电报务员告知其他试图警告他们的船只停止发报；关键讯息未被送达舰桥；执行关键工作所需的工具未被配备，等等。（Kuntz）

正如船只的工程和设计所需要的那样，船只的运营也需要强有力且整体性的指导，以确保船只及其船员作为一个整体协同运作，而不是把诸如 Marconi 无线电报务员之类的部门当作一个孤立的单元来看待。在那个例子里，他们在名义上并非船上的船员，而是 Marconi 公司的雇员，登船是为了处理付费乘客的电报通信，而只有在时间允许的情况下才处理船只的紧急通信。倘若他们被作为一套整体性运营管理体系的一部分来加以监管，哪怕是作为外部承包商，那么他们的程序很可能会更加以安全为重，或者至少，围绕把讯息送达舰桥所定的服务级别协议（service level agreement）会被清晰地界定，而非临时随性、全凭自行裁量。

在任何项目及项目组成部分中，良好的文档——无论是关于项目目标、交付物、程序等等——都至关重要，倘若良好的沟通与文档不处于我们所做一切的核心（既包括项目内部，也包括与外部利益相关者之间），项目管理就几乎没有成功的希望。

我们今天所发现的是，奥林匹克号、泰坦尼克号和不列颠尼克号的项目管理教训对我们今天依然宝贵，而那个时代的种种背景——无论是尽可能推动迭代式项目设计、投资于经验性知识（tribal knowledge）、计算风险、理解系统工程与系统运营各自的角色，还是保护性的外部力量对产品成本的影响——也依然切题。影响项目的各种因素是周期性地来来去去的，今天我们看到种种趋势倾向于更像奥林匹克级船只而非与之相异的模式。在未来，钟摆很可能会再度摆回来。其中根本性的教训非常切题，而且将会继续如此。无论是通过评估我们自己的项目与 White Star 的项目有何相似之处，还是有何不同之处，我们都能从中学到很多。

参考书目与引用来源：

Miller, Scott Alan. Project Management of the RMS Titanic and the Olympic Ships, 2008.

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry, February 2007.

Esposito, Dino. “Cutting Edge – Don’t Gamble with UX—Use Wireframes.” MSDN Magazine, January 2016.

Sadur, James E. Home page. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 13 February 2017.

Winchester, Simon. “Atlantic.” Harper Perennial, 2011.

Titanic-Titanic. “Olympic.” (Date Unknown): 15 February 2017.

Titanic-Titanic. “Guarantee Group.” (Date Unknown): 15 February 2017.

Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture”. (1998): 16 February 2017.

Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 16 February 2017.

Ellis, Sam. “This jet fighter is a disaster, but Congress keeps buying it.”. Vox, 30 January 2017.

补充说明：

Mark Kozak-Holland 最初于 2003 年将其著作作为一系列关于泰坦尼克号的 Gantthead 文章发表：

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers and later ProjectManagement.com (2003): 8 February 2017.

延伸阅读：

Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.

Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.

1912 年美国参议院及英国官方听证与调查记录，见 Titanic Inquiry Project。