由于詹姆斯·卡梅隆执导的著名电影《泰坦尼克号》的原因，以及电视中很多的探索或历史频道中有过关于Titanic方面的记录片，许多人对泰坦尼克的故事几乎耳熟能详。这些故事都重点展现了此次航行的最后两天行程以及灾难出现后最后几个小时船上的情况。但是，这个为期4年的巨轮项目的建造细节究竟是怎样的？这个项目本身有什么样的重大意义？在项目中到底出现了哪些情况导致泰坦尼克号最终遭受了如此的劫难呢？审视我们今天的IT项目，我们能够从泰坦尼克号获得什么样的教训呢？ 

　　让我们追溯到1909年，审视白星公司White Star的业务经营情况。当时，白星公司White Star老化的客轮航线已经不足以与日益强大的竞争对手进行抗衡。针对这一情况，白星公司着手制订了一项战略，即投资新兴技术并用来制造三艘超级巨轮。这笔投资非常关键，因为这些客轮可能要用上至少20年。使用这些巨大投资来制造的客轮可能至少要服务20年。因此对于设计者，正确的设计至关重要。相对于速度而言，他们的设计战略更关注豪华。如此一来，所设计客轮的二等舱相当于其它客轮的一等舱，三等舱相当于其它客轮的二等舱。

　　为了与豪华或“功能需求”这个目标相匹配，在“非功能需求”上的投资也不能少，所有这样的支持功能包括诸如性能、安全、容量。但是从一开始，如同许多项目一样，白星公司的项目小组就该项目投资的支出重点引发了一次争论，最后经营战略战胜了其它的考虑因素。争论牺牲的结果就是，本来应该属于诸如安全系统这样的非功能需求的新兴技术的花费被省掉了。按照原来的设计，安全系统本应包括一个双层外壳（底部被划分成73个水密室），15个有着电动门的防水壁舱，48艘救生艇以及具备高级的抽水机技术。

　　现在既然重点主要放在功能需求上，非功能需求只能逐步妥协。不过，非功能需求看起来不太明显，因此这种“切角”现象不被人注意。诸如，建造一个宽大舞厅这样的功能需求导致有4个防水壁舱无法伸展到顶部的甲板，严重破坏了轮船容纳海水的能力。这不仅是业务执行官，特别是负责这个项目的主管布鲁斯.伊斯梅的责任，还有技术人员包括白星公司的造船专家以及Harland-Wolff的建造师对这一妥协负有不可推卸的责任。

　　项目建造阶段临近收尾时，大多出于安全性能的要求都由于这样或者那样的原因被“妥协“掉了。船上有些地方防水舱的高度仅仅高过吃水线10英尺。对这些白星的设计师做出了似乎合理的解释，即Titanic号的综合安全措施足以保护泰坦尼克抵御任何自然灾难。

　　在项目结束的时候，该项目团队认为船的安全性能仍然维持在最初设想的较高水平。如此，人们对处女航充满了信心。更为自大的观点是认为泰坦尼克本身就是一艘巨大的救生艇。直到最后，泰坦尼克的项目团队仍错误地沉浸在最初的设计假想中，并且没有进行足够地测试。在项目结束的时候，人们对这艘轮船如此信赖，以至于连灾难修复和业务持续计划都被认为是多此一举。

　　简而言之，那些本职工作未尽职的设计者们默许了安全上的隐患。当这艘船即将航行时，人们都认为即使有意外出现，该船也有足够的安全保护能力。正因为这样，船上全体工作人员及乘客们都逐渐形成一种共识：这艘船将永不沉没。难怪会有53 个百万富翁上了这条船！

　　不过，JP Morgan，这个当时世界上最富有的人在前一晚取消了他的行程。在经历了仓促的“试航”后该船出发了，前方布满了无数的风险。在到达冰原地带时船一直在持续的加速。安全方面的“妥协”在操作中一步步产生：由于“冰桶”测试进行得粗制滥造，无线电冰情警报未能及时传达到船桥，以及守望员人数太少并且没有双眼望远镜。该轮船的指挥人员由于未能计算出冰原的实际面积，因此没有意识到当反馈系统出错时所带来的巨大危险。

　　回到今天，对比我们的现代IT项目，整个IT项目从设计到运行等诸多方面与泰坦尼克号都有很多的可比性。它与现代IT项目有许多相似之处，例如，在IT项目完成及投入运行后的几天、几个月甚至几年内都会出现问题。

　　IT项目可能在展开时显得非常成功，并且还通过了一系列所谓的“标准”测试（系统、性能以及认知度），然而在实际运行时它仍然会惨遭失败。毕竟，只有25%的IT项目是成功的，这个数字已经是得到了多个调查结果证实的（根据Standish Group公司1994、1996和1998的调查报告，所有的IT 项目中仅有25%在预期时间内完工、没有超出预算并且所有特点和功能都符合最初的设想）。

　　看一个IT项目是不是成功，不能光看部署使用，而是应该在解决方案投入运行一段时间后再仔细衡量。衡量的标准要考虑所有业务可能遭遇到的所有影响因素。泰坦尼克号的故事有助于我们更好地理解功能和非功能需求之间的关系、项目各竞争要素之间的妥协关系、以及造成运行情况出错的原因。

下一篇：联想、华为、微软、天士力极客驾驭法则