从泰坦尼克中汲取的IT项目教训（4）（AMT研究院 王艳 编译）

很多人对电影泰坦尼克号，或是对历史频道中有关这方面的记录片几乎耳熟能详。它们都重点展现了此次航行的最后两天行程以及灾难出现后最后几小时船上的情况。但是有关这艘船四年的建造工程细节、项目过程以及其与灾难的关系却鲜为人知。

让我们回顾1909年，重新审视白星公司用新兴技术建造三艘豪华客轮的项目。这三艘客轮分别将于1911、1912、1913年启用，而且可能要用上至少20年。但是实际上，投资并没有考虑到所有的风险。

泰坦尼克号的建造者们有很多设计，但最后选择了一套战略使用了所有最新的和先进的安全技术来提供最高级别的安全性。然而，由于行政业务的压力，尤其是白星总管布鲁斯.伊斯梅，他想打造一流的乘客（一等舱）体验值，泰坦尼克号的建造者们开始在这些安全性能上作出了让步。例如，四个防水舱壁没有达到顶端甲板，并且只高出吃水线10英尺，给200英尺的舞厅留出许多空间。

在测试阶段开始前的计划编制时，白星公司已经普遍形成了一个观念，即泰坦尼克号是所向无敌的。事实上，这被积极地用在泰坦尼克的行销上。在泰坦尼克建造临近尾声时，由Harland和Wolff（造船专家机构）提出了测试的计划。这两个机构必须保证泰坦尼克号满足合同中所陈列的条件和需求。测试赋予这两个机构一次能进行任何必要调整并避免财政金融风险或最糟的形式即不批准该船航行的机会。

同样地，IT解决方案应该总是符合合同中的提出的要求，这些要求必须与项目早期制定的服务水平目标相一致。根据机构能承受的无效率的多少，业务情况决定了方案成本和所需的服务水平。测试应该评估IT解决方案能否满足服务水平并识别出差距。

一般来说，计划制定包括了列出一个测试大纲。例如，必须测试泰坦尼克号是否适合航行、检查其稳定性，并仔细评估重量及装载细节。一个测试是“倾斜测试”，它通过一个简单的倾斜实验来检查轮船的重量及重心。它也详细地检查了计算。其它测试包括了码头邻接区测试，它是主要机械及辅助机械的初步测试。通常，对履行合同而言，正式的速度测试是必不可少的。这要求在某一具体条件下轮船能达到某个速度。

同样地，IT项目需要列出测试IT解决方案的大纲，并且要为功能需求和非功能需求都列测试大纲。然而，重点应该放在后者，因为非功能需求定义了一个系统的运作特征，非常重要。该测试必须是“动态”的，并且建立在早期的“静态”测试上。

许多IT项目测试单元所具备的功能很有效果，但是无法在宏观上进行测试。部分原因来自于模拟一个服务交付环境的可观察的成本，因此项目小组仅仅是不断地完成局部测试，这导致小组成员对方案能否成功启动缺乏信心。更甚至，一些公司之所以启动IT解决方案竟然是以为任何问题都可以被用户或客户在短期内解决掉。这是一个相当危险的想法，可能使业务陷入困境万劫不复。

在泰坦尼号的故事里，它的姐妹号奥林匹克在项目中扮演了一个重要角色，因为它在计划编制和测试阶段都做出了让步。泰坦尼克号是奥林匹克号的一个翻版，后者是在1911年开始航行的。白星公司认为奥林匹克号的航行经历足以证明与之几乎一样的姐妹号即泰坦尼克号是不用经过多少海上试验就可以直接航行的。这个观念迫使该客轮所有者也认为泰坦尼克号已经是一艘天生就肩负着航行使命的轮船。然而，这仅仅是比较了这两艘轮船的物理结构，并没有分析程序的完整性及全体工作人员工作准备的程度。

IT项目可能也会犯相似的错误，过于依赖以前类似的项目，并且没有完全评估业务的风险。一次评估决定了所需的测试，为什么要进行测试，以及测试的目的及全部的战略。

根据常规，要执行的广泛测试应该包括压力、绩效、衰退度、安全性及运作测试。这要求每一个测试目的都有其计划编制：要测试的是什么、怎么测试、用什么数据、预期的结果和效果。更重要的是，这些能测试该解决方案的实用性。此外，计划编制应该制定好测试是怎样被执行的，在什么环境下，以及由谁来确保客观性。例如，开发小组永不应该测试他们自己的工作；而应由别的小组来测试。

奥林匹克的记录并不完美，也出过几次严重的事件。第一次发生在北河上，奥林匹克出故障开不动了，有12只拖船拖着它要把它移到第59号码头停泊。有一只名为Hallenbeck的拖船当时位于奥林匹克的尾部，奥林匹克的右舷推进器一个突然的倒转将Hallenbeck拉近并将它的船尾构架、方向舵以及轮轴切断了。

第二次事件发生在她驶出索伦特海峡的第六次航行开始时。她与皇家海军巡洋舰Hawke号在一个狭窄的海峡中相距200码并以15哩/小时的速度并驾齐驱，这时Hawke号突然用力扭转与奥林匹克正面发生了撞击并刺穿了她的外壳。这次损伤相当大：一个裂开的三角形洞，大约有15英尺高，10英尺宽以及10英尺深。最大的两个密封舱迅速灌满了水，因此所有的水密门被关上了。还好任意两个间隔间都是朝向大海的，轮船没有沉没。二等舱被切开了，难以置信地是没有人受伤，因为当时乘客都在餐厅用餐。而Hawke号装备了一套撞击装置，它缓冲了这次冲击，减轻了自己的损伤。

IT项目必须仔细研究以前的项目记录，以及以前的项目是如何成功地汲取教训、理解风险的。就奥林匹克来说，很明显船上的工作人员面临的挑战是庞大的船体以及导致这些事件的技术问题。

在与Hawke号发生碰撞后，奥林匹克让她的1,300名乘客下了船，并且由于更换外壳而在贝尔法斯特干船坞赋闲了六周。在该事件的调查中，皇家海军专家指责原因出自奥林匹克功率过大的抽气机，根据柏努利原理，它是Hawke号抽气机功率的7倍。这次事件非常重要，因为泰坦尼克号在1912年离开南安普敦的时候也发生了一次碰撞。更为重要的是船长史密斯，大副麦多克，以及二副赖托乐赖托乐，他们当时都是这两艘船上的工作人员。事实上，白星公司提拔船长史密斯指挥这艘旗舰船也是表明对其的信赖。Hawke号碰撞事件深深困扰着船长史密斯，然而，他继续声明他是无辜的，提出Hawke号撞了奥林匹克，因此这次碰撞是Hawke号船长的错。

IT项目应该根据相关的程序和涉及到的机构来密切分析以前的解决方案是如何运作的。任何失败或不规则都需要通过一次事后研究来仔细分析，并把分析结果放入测试里。

结论

今天许多IT项目都没有制定充分的测试计划，并且在将解决方案转化成产品时，没有制止非功能需求上的严重让步。这就好比白星公司拿奥林匹克当试验，就认为泰坦尼克号的首次航行是低风险的。毕竟，这两艘船几乎是一样的，而且船主以及工作人员都对泰坦尼克号比较信任。然而，没有哪两艘船有完全一样的操纵性能。白星公司在不制定测试计划上豪赌了一把，并且还令横穿大西洋的泰坦尼克人手不足。当泰坦尼克号项目进入下一阶段，人们关于它不会沉没的观念仍然没有改变。

下一节我们来看IT项目的测试阶段。