从泰坦尼克中汲取IT项目教训

centralsundata

从泰坦尼克中汲取IT项目教训

冰海沉船的故事似与IT项目毫不相关，但若了解这艘船的建造工程及其对于最后灾难的关联，将对规避IT项目风险带来非常有价值的借鉴。


或许你还对电影《泰坦尼克号》那凄美的爱情故事念念不忘，或是对有关泰坦尼克的记录片几乎耳熟能详。但它们都重点展现了航行的最后两天行程以及灾难出现后最后几个小时船上的情况，关于其它我们则知之甚少。这艘船四年的造建工程有什么样的内幕？它重要吗？它与这次灾难有关吗？或者，我们能从中发现点什么，给我们今天的IT项目带来些许借鉴？
让我们一起再重温历史。

第1幕
决策：把泰坦尼克建成什么样
让我们回顾1909年白星海运公司面临的经济情况。当时它们的船队老化，完全不能与其它公司竞争。白星启用了一个战略，即投资新兴技术并利用这些技术来建造三艘豪华客轮。因此，在设计时，他们采用了豪华设计战略而不是船速战略，如此一来，这些客轮的二等舱相当于其它客轮的一等舱。但是这种业务战略正确吗，它考虑了所有的风险和成本吗？
与此类似，今天，在您动手做一个IT项目前，您需要可行性分析。例如，被提议的IT方案可以返还足够的价值，并且对公司的业务来说它不构成“风险”。
为了强调其可行性以及能否收回投入，大多数IT项目都经历过一次快速成本收益分析。一小部分IT项目甚至还进行了一次更为详细的业务检查，并计算出投资回报率以及预测项目存在的风险。
您需要提前1年用一个简单的公司（收入＞固定成本＋可变成本＋方案投资）来对项目运作进行分析。
但这还不够，竞争的加剧，迫使许多企业面临为客户、合伙人或厂商提供不间断的服务。然而，一旦发生故障就会造成无效率。为了给您的IT项目计算出一个精确的投资回报率，您需要在上面的公式中再加上无效率及其它的“真实”成本：收入＞固定成本＋可变成本＋方案投资＋总的无效率成本
但是您怎样评估总的无效率成本呢？出现故障时，项目并没有产生收入或节省成本。为此，您得评估一段时期（例如一年）内这种情况出现的次数以及损耗记录的数字。一个用户故障记录（UOM）可以作为量度标准及参考。一个UOM取决于一个用户在一次故障中受到影响的时间。UOMS取决于故障的总次数、一次故障的持续时间以及受影响的用户数量。
总无效率成本＝无效率成本★UOMS
对每个UOM来说，您必须计算：无效率成本＝（每分钟平均收入－故障损失价值）
然而，收入不是平均产生的。更多的收入是在“峰顶时期”产生。获悉这些峰顶时期每分钟的收入非常重要，因为它们很有价值。例如，在一次在线证券交易操作中，“日交易结束时期”最有价值。“故障损失值”是指如果在那个时刻操作消失，您的公司可能蒙受的损失值。
故障损失值＝（每峰顶时刻的平均收入＋反射值）
“反射值”是故障出现时刻的连锁反应。例如，对产生收入的在线操作来说，它包括了交易丢失的影响、调整和处理造成的成本、缺少服务保证的罚款、客户和信誉的丢失、股东信心的丢失、形象的破坏、品牌的贬低、以及诸如顶峰销售时期这样的不幸时机造成的诉讼及损失。
在白星公司案例中，反射值主要有罚款、客户和信誉的丢失、信心的丢失、形象受损、品牌名的贬低以及诉讼这些因素影响。一次旨在削减成本的IT项目包括了自动化进行文件处理、后端功能或工作流处理。它们各自带来了不同的影响，诸如损失的员工生产力、调整和解决、额外的支持和维护开销等。
白星业务的资金回收期相对短，因而在投资分析时不存在成本的压力。白星没有充分评估出反射值，并把它包含在方案中。如果做好了这点，那么公司就会把投资重点放在非功能需求和尽可能排除所有风险上。

第2幕
设计：一切为豪华让步
然而白星并没有这么做。在泰坦尼克号的设计阶段，设计师们把业务需求转换成了轮船的功能需求，即运输和提供服务。同样的由于功能是有形的且极易被业务主管和IT成员理解，大多数IT项目在这个业务需求转换阶段相对来说都很顺利。
按照一般规律，在实现外观的豪华或“功能需求”这个目标时，在“非功能需求”上的投资也不能少，即必须保证具备诸如性能、安全、容量这样的支持功能。不管功能需求的定义是什么，非功能需求确保了轮船具备应有的基本职能。对泰坦尼克号的设计师来说，这要求他们检查保险设置、性能、稳定性、安全、可维护能力以及环境。
但是打从一开始，在白星公司经营战略的要求下，设计师把重点主要放在功能需求上，非功能需求只能让步。新兴技术上总的投资额就没有包括诸如安全系统这种非功能需求的支出，诸如，建造一个宽大舞厅这样的功能需求导致4个防水壁舱无法延伸到顶部的甲板，严重破坏了轮船容纳海水的能力。不过，非功能需求看起来不太明显，不常被人注意。
同样，对IT项目来说，非功能需求确保系统具备应有的基本职能。在今天的IT项目里，非功能需求通常都超出了大多数业务主管的范围，因此这些需求上的任何让步，业务主管可能很难理解。因此，项目经理需要将这些造成的影响总结起来便于业务主管理解。
今天一些IT项目也在设计和建造阶段有过严重的妥协，一般倒也无伤大雅。但是这些妥协可能引发的问题当时看起来不明显，却可能在项目完工后以及方案投入生产后的若干天、若干月甚至几年后爆发出来。项目经理需要确保对功能需求和非功能需求投入同样程度的关注。

第3幕
测试：业务压力下一切从简
在泰坦尼号的故事里，它的姐妹号奥林匹克在项目中扮演了一个重要角色，泰坦尼克号是奥林匹克号的一个翻版，后者是在1911年开始航行的。白星公司认为奥林匹克号的航行经历足以证明与之几乎一样的姐妹号即泰坦尼克号是不用经过多少海上试验就可以直接航行的。然而，这仅仅是比较了这两艘轮船的物理结构，并没有分析程序的完整性及全体工作人员工作准备的程度。而且，奥林匹克的记录并不完美，也出过几次严重的事件。
泰坦尼克号在1912年3月经历了一天的海上测试。而在试航中缺了点什么呢？首先，它所经历的测试既不多而且也不被重视。结果，泰坦尼克号没有经受过任何复杂的操作动作，诸如S型转弯，过去被用来在紧急时候逃离危险的动作。其次，高管们没有花多少时间去适应轮船的操作。奥林匹克被用作泰坦尼克的试验品或是标准，人们太相信她的航海记录了。
根据常规，要执行的广泛测试应该包括压力、运转、衰退度、安全性及运作测试。测试目标是为了揭发在需求、设计及建造阶段主要存在的漏洞问题。这要求每一个测试都有其计划编制：要测试的是什么、怎么测试、用什么数据、预期的结果和效果。更重要的是，这些能测试该解决方案的实用性。计划制定包括了列出一个测试大纲。例如，必须测试泰坦尼克号是否适合航行、检查其稳定性，并仔细评估重量及装载细节。此外，计划编制应该制定好测试是怎样被执行的，在什么环境下，以及由谁来确保客观性。例如，开发小组不应该测试他们自己的工作；而应由别的小组来测试。
同样地，IT项目需要列出测试IT解决方案的大纲，并且要为功能需求和非功能需求都列测试大纲。然而，重点应该放在后者，因为非功能需求定义了一个系统的运行特征，非常重要。该测试必须是“动态”的，并且建立在早期的“静态”测试上。
另外，泰坦尼克号所遭到的业务压力是巨大的，但考虑到四年建造的庞大投资这又是可以理解的。此外，奥林匹克由于事故当时正处于一个月的维修期。这更加耽搁了泰坦尼克号的建造工作，使其首次出航出1912年的3月延尺到4月。因此白星主管布鲁斯·伊斯梅很着急泰坦尼克号的开航日期，他坚信万事俱备，只欠东风了。
IT项目可能也会犯相似的错误，过于依赖以前类似的项目，从而减少测试的内容和次数，并且没有完全评估业务的风险另外，不能仔细研究以前的项目记录，以及以前的项目是如何成功地汲取教训、理解风险的。
IT项目应该根据相关的程序来认真分析以前的解方案是如何运作的。任何失败或不规则都需要通过一次事后研究来仔细分析，并把分析结果放入测试里。
今天，许多IT项目在测试中做出了让步，没有把测试看得足够重要，并且在将解决方案迅速投入生产的业务压力下屈服了。许多IT项目也没有制定充分的测试计划，并且在将解决方案转化成产品时，没有制止非功能需求上的严重让步。这就好比白星公司拿奥林匹克当试验，就认为泰坦尼克号的首次航行是低风险的。

第4幕
首航：一去不复返
预警系统形同虚设
就这样，泰坦尼克伧促起航了。当泰坦尼克号于4月11日离开爱尔兰女王城－进入大西洋的最后一个海港时，船长和高管们意识到了前面会有冰山危险。1912年的冬天异常温和，许多冰山都开始融化。白星公司在航海之前采取了一些预防措施，并且还让轮船改道，向南方再前进了10英里。泰坦尼克号内置了反馈系统，一旦周围的环境有所变化，它就会提醒相关官员和全体工作人员。而反馈信息包括了来自守望员和船桥的目测情况，以及来自于附近轮船发出的冰山警号。
同样地，今天的IT环境也应当采用内置的反馈机制作为支持结构的一部分，这样可以预先警告即将出现的问题。这些系统收集数据，并且能感知到那些触发软件和警报操作的“事件”或“预兆”。
泰坦尼克把眺望台及船桥楼当成内置的监视系统。除了在眺望台上有两个看守，赖托勒长官自己也是桥楼上的一名望员。泰坦尼克号上安排了六个专业看守人员，并且每次换班是00∶00时刻。有一个问题是：为什么没有安排额外的值班看守来注意所有的警报信号。通常在船首都要安排额外的眺望人员，他与桥楼的望员可以通过电话传递信息。在商业周期中存在一些关键时期，诸如月末工序，它要求操作人员必须额外细心。越是特殊情况越不能掉以轻心。
此外，眺望人员缺少双眼望远镜，这真令人匪夷所思。今天的IT项目从中所汲取的教训是：在关键位置上的工作人员，诸如操作员，应该比同样等级的职员拥有更好更实用的工具。
接下来的两天里，泰坦尼克号接收到了八次冰山警报。然而，无线电话务员仅仅是偶尔把这些冰警播送到船上，因为他们的时间被大量流出的无线电商业咨文占据了。话务员是无线电报的雇佣人员，他们的酬劳主要来自于为那些有钱的一等舱乘客给其纽约的朋友发送无线电信息。对于今天的IT项目来说，这是一个重要的教训，所有工作人员尤其是操作人员，他们所重视的工作，他们的工作动机都是来源于服务级别协议（Service Level Agreements），因此项目应该重视到这一点，尤其是当项目牵涉到第三方或外来资源时。
4月14日的晚上，加利福尼亚号客轮位于泰坦尼克号的北边，正驶往波士顿。在与一堆冰架发生严重的碰撞后，决定当晚轮船不再前进，而是停下来。虽然加利福尼亚号周围都是冰，但却并不危险，无线电话务员接到了船长的指示，要将冰情警报发送给泰坦尼克号的无线电话务员。泰坦尼克号在收到冰情警报后，只是不耐烦地回复，“闭嘴，闭嘴，我正在忙呢。我正在加速前进，你少来管我。”今天的IT项目从中所汲取的教训是，任何外部警告，无论是来自于顾客还是供应商，都需要认真对待，并彻底调查。就泰坦尼克号来说，如果船上有人将所有的冰情警报信息收集到一起，就能推测出有一个巨大的冰原，大约有80英里宽，就在前方。
泰坦尼克号最早采用了警报系统，但由于没有适当利用关键反馈机制来汇报问题最终还是功亏一篑。另外，再加上该船对自身安全措施的过分自信，还有关于巨大冰原面积的不精确信息，这些导致了大家对整个事态一点都不重视。
泰坦尼克号朝着冰山前进着。事实上，这几乎是不可避免的。泰坦尼克以它最快的速度穿越表面漂有小冰山和片冰的海洋。寒风刺痛了那些没有双眼望远镜的守望员的双目，他们在这样的条件下也只能竭尽全力地透过薄雾对地平线进行大致的估量。当他们挣扎着辨认出前方有一个形似大黑块的物体时，他们未能及时把这个情况汇报给船上的桥楼。
可以看出，泰坦尼克号的技术支持团队并没有花多少时间来熟悉此轮船。他们未能识别出异常情况的规模，并且也没有将各自的想法集中起来。操作和技术支持之间的磨合虽然克服了没有双眼望远镜的缺失，但还是没有给当时的情况帮上忙，并且守望员的犹豫误了最重要的时间。当泰坦尼克号右转向后摆动时，操作未能使船与冰山完全平行，所有守望员只能眼巴巴地看着即将到来的碰撞。
今天，许多IT项目由于没有足够重视操作阶段从而使操作处于不利状态。提出操作的重要性是处一种事后做法。项目全体成员也不是在计划及试验阶段就熟练掌握了操作，他们是直到实施时才真正投入到项目中去的。
今天的IT项目从所汲取的教训是：在监视一个刚实施的解决案时，实施人员需要对它非常熟悉。他们必须积极主动地去预防在一线出现的错误，并且确保一线能符合它的服务级别。他们必须对方案及其周围的环境有很好的洞察力。他们也必须能快速地评估及分析他们面前的数据（这些数据是在项目的试验阶段中从反馈机制中收集来的）。当机制变得混乱时，他们必须能识别形势，关且判别出与预先所设置的标准有区别的任何潜在影响。他们需要断定操作是不是真的出了岔子还是只是让人有疑问。他们必须对有关是否进行下一步以及按什么顺序进行下一步做出正确的决定。
实施及技术支持人员需要一定的时间为方案的运转性制定关键场景，为预防意外事件制定策略并确定可行的相应措施。这些都必须在执行之前就被仔细做好。它包括考虑自动化的的操作人员，他们必须有优先权，否则他们可能来更多麻烦。毕竟，最终目标首先是为了预防随时出现的故障损耗，或者服务不佳现象。

风险发生后，糟糕的挽救
在发现了前面的风险后，泰坦尼克的高管们试图避免碰撞。然而，S型转弯方法虽好，但还是未能大大减慢轮船的行驶速度。泰坦尼克号后来终于慢慢停了下来，有成百个乘客是这样描述的：在持续几秒钟的震动及隆隆声中，轮船仿佛在一大堆大理石上翻转了一下。
同样的，当一个IT解决方案在生产阶段进展不顺时，项目小组应根据项目自身所准备、计划并测试好的一个流程去采取一些措施。然后在后台进行修复，这个修复可以是暂时的也可以是永久的。如果尽可能快地实施 IT解决方案是服务级别协议的首要目标，此流程必须基于平均修复时间，以利于把握好时间。
泰坦尼克号的高管聚集在桥楼决定采取什么措施。由于损伤的程度也是问题的一部分，因此船上分布了两个搜索救援组，一个在船头，一个在船中央。第一个小组在10分钟内返回并汇报没有大的损失或进水。在白星主管布鲁斯？伊斯梅看来，问题监测及判定现在是完整的。使用求救号的决定对他来说是个问题，因为这样做会有损白星公司在业界的地位，并且会破坏泰坦尼克号的广告效应，摧毁一度辉煌的行销，这种行销曾吸引了世界上不少富人踏上这艘号称最安全的轮船。
另一个较好的解决方案是让轮船返回哈利法克斯，远离纽约和世界新闻中心。然后他可以制造出更好的新闻故事，将事故忽视为一次小意外。他能够将乘客转送上火车，再对轮船进行修补。或者把轮船送回贝尔法斯特修补。事实上，他可以大胆地宣布泰坦尼克号自身采用了新兴技术，是一艘救生船，能够把自己从一次巨大的灾难中救回，因而能为白星公司做一次更好的安全性宣传。
对今天的IT解决方案来说，问题的解决方案要考虑到该方案给用户造成的影响。解决方案必须与现有的依据相一致。对反馈机制及日志的再研究对于判断问题是否已经出现了以及原因是什么至关重要。
在一个复杂的IT解决方案里，常常能看到多米诺效应，即诸如一个子系统这样小的有缺陷的因素会激发一系列问题。如果不分析出事情进展的精确信息，这可能会导致一次错误的判断——产生一次错误的修补并且使问题再度发生。只有找到问题的最根本原因并得以证实才算完成了判断。
对一个IT解决方案来说，肯定手边的依据以及询问下面几个问题非常重要。是否意识到IT解决方案会失败？如果是的话，是否尝试了一些自动化的预防措施？它向人工或自动化的操作员发出了警报吗？反馈机制是否有问题并且提供了不可靠的数据？对问题判断准确吗？
泰坦尼克号的情况是紧急的，但还不到灾难性这一步。伊斯梅急于挽回颜面，他害怕白星公司的名声受损。泰坦尼克号安静地靠在水下的冰架上，这使它看起来十分安稳。也许负责和细心一些，他们就能以最小的损伤全身而退。伊斯梅仓促行动做出了草率的决定。此时，第二搜索救援组（里面有造船人员和木匠）还来不及对问题给予评估。
今天的IT项目从中所获取的经验是：在解决问题时，必须在搜集好所有数据信息的前提下，分析每个解决方案所带来的风险性，再考虑选择最合适的解决方案。要不然就得是靠最后的修复阶段了。在这个阶段里，操作小组会根据服务级别协议即时撤回IT解决方案，并让服务再重新开始。
就泰坦尼克号来说，不是所有采取的措施都是完全依据问题的解决方案。伊斯梅做出了致命的决定，结轮机舱打电话让船向前开，想以最低速度来改变当时的情况。轮机员后来证实轮船以3哩／小时的速度前行时曾发出过碾碎的声音。
今天IT项目从中获取的经验是，一个业务主管在没有得到操作人员的同意下，没有权力下任何操作决策。而且，作为主管的伊斯梅是否有必要出现在船上也值得商榷。船长是关键的决策者，而把一个主管牵涉进来，船长及他手下的官员可能会遭遇主管的逾权。
今天，许多IT项目由于没有作好周密准备，导致流程不能很好地处理有关平均修复时间（MTTR）时钟的问题，因而项目在操作阶段受到了严重的损伤。一个流程对于操作小组来说意义重大，因为它能使小组快速恢复服务并维持服务水平。一个流程也应具有部门之间的相互制衡机制（通过审核），以此来最小化在一个有压力的环境下出错的可能性。一个流程应该列出每个人承担的责任和扮演的角色。以此确保合适的人去制定合适的决策。
在与冰山碰撞后，泰坦尼克外形看起来还不错。没有人受伤，并且从桥楼上看，该船完好无损。白星总管布鲁斯·伊斯梅一心想挽回颜面以及挽回公司的名誉。在晚上11∶50，即碰撞发生的10分钟后，伊斯梅下令重新启动轮船并且离开冰山。乘客们并没有意识到任何危险，也对碰撞及潜在的灾难性后果一点也不感到紧张，但事后证实了他们最初的幸免于难只不过是噩梦的开始。
第二搜索救援组返回时带来了对整个情况的更精确的评估和更详细的数据。第一搜索救援组并没有完全下到甲板上去观察所有的损伤。在几秒钟的碰撞中，海水漫进了煤仓和5号锅炉房中。一个消防员在事后证实他看到在煤仓的地板上有一个2英尺深的洞。抽水泵立即被拿来抽吸海水。安德鲁深知如果档案室被淹的话，这艘船将难逃噩运。
今天的IT项目从中所获取的经验是：为了查明错误，支持小组要充分了解整个处于运作中的解决方案，并且具备将这些了解的内容细分到各个逻辑层、并将其分解成一系列的产品和组件的能力。在项目的每一阶段要创建文件，并且要将此文件传达给支持小组留作后用，这两点非常关键。
在重新启动轮船后，6号锅炉房也开始进水了。约20分钟后，很明显最初的判断是非常不精确的，修复并没有了使形势得到缓和。档案室被淹没了。史密斯与官员协商后，决定将当时正以 8哩／小时速度行驶的轮船慢慢停下来。前进无疑于加速死亡。船已经进了很多水，这使灾难即将来临。船的其它部分，在刚开始还没有损坏，但是在海水的压力下也开始出现了裂变。
今天，如果一个IT解决方案在平均修复时间阶段出了问题，保持对周围数据（迹象）的评估和再评估以及监视环境上的任何变化非常重要。重初的修补通常是暂时的，因为这只是为了让解决方案能快些恢复正常并使服务重新启动。要想得到永久的修补通常要花上好几个小时或好几天。修补解决方案可能必须在不引人注意的地方进行。诸如，代码可能必须重写或者方案中出现了一个新的集成组件。然后这要经过计划及测试，之后才可以使用项目程序在生产中执行，因此我们需要一个强大的变动管理流程和一个测试/演示环境。
今天的IT项目从中所汲取的教训是：平均修复时间程序在一个有限的时限内是循环的，并且它酌留出了修复尝试的空间。然而，伊斯梅强行控制了轮船，即根本上就不考虑MTTR或修复就让轮船继续前进。
今天，由于在解决方案的运作及修复阶段没有遵循事先制定好的方法，许多IT项目在关键情况中遭受了不幸。专业化的平均修复时间程序可以帮助我们从不同的决策中选择出最好的一个，然后将其运用在泰坦尼克号上。因此支持人员应该对解决方案的细节了如指掌。
在所有事情中， 通过临时修补或永久性修补来及时恢复服务首当其冲。然而，在这样的情形下，对服务提供的环境是否进行了修补进行密切监控也非常重要。
在今天的IT项目中，针对修补无法解决问题以及情况超过了IT方案的平均修复时间范围这些意外事件，项目小组对其未雨绸缪显得至关重要。那些再也无法修补的服务对于最终客户来说，也是无法再获得的。在这种情况下，专业人员在项目进行时就必须建立、准备、计划及测试好灾难修复程序。
造船专家清楚地知道泰坦尼克号船上的情况已经超出了正常的问题修复范围，灾难即将来临。他断定问题无法修复，并强调船还有2.5到3个小时的时间完全沉没。许多船舱都破裂了，海水大量涌入，抽水机也抽不过来了。
泰坦尼克号的船长在船与冰山碰撞后较快地了解了情况的严重性，但是他没有把这个告诉下面的船员也没有通知船上的乘客。这使得情况越加复杂，尤其是船员们。诸如，轮机舱派了一些轮机员到救生艇甲板上，但是桥楼又把他们遣回轮机舱。关于泰坦尼克号缺乏交流的可能解释如下：
★轮船拥有非常有限的通讯工具，连有线广播也没有。
★船员并不真正了解船上的情形，因此最后乘客得到的信息也各不相同。
★船长意识到救生艇的数量不够。船上约有2,223人，而救生艇的总装载容量仅为此人数的一半。能做到的只有让大家镇静下来，在适当的时候有序上艇。
★船长害怕船上恐慌蔓延。
在今天的世界里，一个交流计划可能和一个灾难修复计划一样重要，主要有以下几个原因：
★与您的员工在内部进行交流将大大有利于控制灾难的影响程度。同时，交流的速度也是至关重要的。例如，先通知那些直接与客户打交道的员工，因此他们能通知客户。
★在外部与您的客户进行交流也很重要。并且此交流计划必须视问题严重程度来使用不同渠道与各个客户进行沟通。同时也必须提供一个保留客户的策略。
★与媒体的交流也很重要。这要取决于服务丢失的严重度。这点要求识别关键信息，交流的方式是什么，以及通过什么渠道。当记者借助技巧性问题来向缺心眼的员工套话时，许多公司在这时都会防不胜防。
故事进行到此刻，我们终于可以明白为什么在项目建造过程时非功能需求所做出的让步最后会令泰坦尼克号遭至如此大的灾难。