IT项目启示录——来自泰坦尼克号的教训（第六篇）（转）

泰坦尼克的设计者有许多设计选择并遵循一项战略就是要集所有最新的和超前安全技术提供最高等级的安全性。然而，由于他们迫于要为最终乘客（头等舱）创造一流体验的商业压力，泰坦尼克的设计者开始在安全装置上做出妥协。

我们还回顾了泰坦尼克的同型船奥林匹克号以及她在泰坦尼克号事故中所扮演的角色。值得注意地是，白星公司认为奥林匹克号的航行记录适用于完全相同的同型船，完全可以使泰坦尼克号不经过多方海上试航就可以直接投入使用。然而，由于发生了让船长和高级船员始终不安的几件事故，奥林匹克号的航行记录根本不能称之为完美。（见第4部分）。公司董事Bruce Ismay还决定把打破奥林匹克横渡大西洋的最快记录作为宣传噱头以证明泰坦尼克使用的技术是世界上最好的（见第５部分）。在泰坦尼克的处女航在4月10号开始的时候，人们和媒体全都认为泰坦尼克是不可战胜的。

为了使IT解决方案变成产品，必须做到的通过工具、过程和人的结合，创造一个能对该解决方案监测、运行和控制的支持环境。目的就是要达到项目初期给出的服务水平目标 (SLOs)。典型的做法包括围绕恢复时钟的平均时间创建了一个多级结构，其中恢复速度是最基本的因素。如果该解决方案面向客户或者紧急任务，这是非常重要的。

船的支持环境并没有许多不同，而且泰坦尼克兼备一线的和辅助的支持。包括位于操作台上的值班官员和船员可以在了望台中进行了望。无线电报房的报务员（与帮助台相似），他与外界保持联系，控制船与外部通讯的信息流动、并为游客发送和接收消息。辅助的保证人员包括安全员（负责绘制冰山的位置、气流和气象系统），领航员（负责绘制船的位置并保持路线）和专业技术职务（像那木匠、船的医生）。第三级的保证由大副、二副以及船长提供。

同样地，IT项目需要类似的三重保障组织，因为引入的IT解决方案一般来说是由操作／帮助指南、技术的和专业的保证、实施的领导者和项目经理组成。
泰坦尼克4月11日从爱尔兰的皇后镇港出发时，船长和高级船员是完全地知道前面冰山带来的危险。1912年的冬天已经特别的暖和，许多冰山都产生了断裂和松动。白星公司也采取了一些预防措施，比如提前启航时间，把船的航线向南移了一英里。然而，对安排泰坦尼克号这次横渡大西洋计时赛的Bruce Ismay来说，并没启到帮助作用。他不仅对船的安全设备而且对船的运转以及适当的预警报系统都充满信心。泰坦尼克有固定的反馈机制来提醒船员们周围环境的变化。这个包括操作台和了望台的肉眼监控，附近其他船的冰情警报。就Ismay而言，这些制度为采取规避行动将提供足够的警告。

同样地、今天的IT项目环境杠杆的支点在反馈机制上，这个反馈机制是对即将发生事故的预先警告操作保证机制的一部分。这个体系采集数据，为判断"事故"或对触发基于规则的软件和报警操作的"事故信号"制定计划。

在以后的两天中，泰坦尼克收到了8次关于冰冻、冰山和冰崩的报告.可是，由于指挥台太全神贯注于商品广播电台发出的大量信息，使得无线电报务员转播的冰冻警报反而显得很零星。操作员被发电报的人占用。电台被付了钱，要为富有的头等舱的乘客传递商业电报，还要给他们远在纽约的朋友们传口信。
这对于今天的IT项目来讲获得了一个重要的教训，就是对于所有的保障人员、尤其是操作人员，要把他们的注意力集中在完成服务级协定的重点上，特别是在当第三方或者外部代工介入时，更应如此。

船长和船员此刻已经得知法国游船Niagara号已经在4月11日在冰山的重围中撞冰。但是对于横渡的时间，付了钱的乘客和公众期待这船长接受和满足已经发布的行程，这与今天的航空公司及其相似。航行中，船长Smith推迟了在大西洋中部的转向30分钟，为了在航行中等到更多的南风。

一个名叫Ryerson夫人的乘客担心要早一天到达纽约，并还要另找旅馆房间。她请求Bruce Isma经过冰原的时候是否可以降慢速度。据说船长这样答复的：噢，不,我们打算启动更多蒸汽机来躲避它."他后来在美国的调查中否认这种说法。但是消防队员Frederick揭发说在4月14日，三台额外的蒸汽机被点燃，这比整个旅程中任何时候都要多。轮船当时在全速前进。Ismay迫使轮船在冰山的危险通路中高速前进，这是在拿船只的安全冒险。

今天的IT项目得到的教训是商业的执行者在没有工作介入或同意时不应该做出操作上的决定。

在下一期的连载中、我们继续关注发生在实施阶段的一些更多的常见错误。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/68472/viewspace-955597/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/68472/viewspace-955597/