文/Mark Kozak-Holland　译/杨磊

4月14日晚间，位于泰坦尼克号以北方位的加利福尼亚号正驶向波士顿。在遭到浮动冰架的一次几乎致命的撞击后，（加利福尼亚号的）史丹利-诺德船长决定不再前进，抛锚过夜。该船周围虽满是浮冰，但所幸并无什么危险，遵船长之命话务员伊文斯向泰坦尼克号上的同行---那位每天都得工作14小时、不停收发商务通信讯息的话务员---发出了浮冰警报。而泰坦尼克号则报以那句著名的回复，“住口，闭嘴！我很忙。我正与瑞斯角通信而你干扰了我。”

由于安排给话务员的讯息量过于超量，这最后的外来警报并没能被适当地上传给舰桥指挥部。工作章程中把相关讯息传回舰桥指挥部的程序，在此时已被最大程度地歪曲。加利福尼亚号的话务员伊文斯也没再继续尝试下去，关掉无线电后他就睡觉去了。

IT项目于此节上所能吸取的教训在于，任何外来警讯，不管来自客户还是供应商，都需严肃对待，予以彻底调查。从海量的噪音，冗余的信息中辨识和发掘出真正有意义的那部分，其重要性无出其右。在泰坦尼克号上，倘若有谁能把与冰雪有关的所有警讯都组合在一起研究一下，不难发现所有这一切都指明同一个事实：在本船正前方有一个宽度竟达80英里之大的巨型冰原。令人吃惊的是，当时确实没有做对周围航行环境的任何宏观评估。

（事实上）任何有经验的水手都应注意到当时那些预示着有巨大冰原存在的种种海况。（比如，）海面显得很平静，那正是由于大浮冰和积冰块平抑了水浪；而且，海水看起来象油状，也正是因为其已接近凝冰点。从船上往外的总体视距被认为好于正常水平，正是这一点使得船员们高度相信各种危险都能被发现。但是，虽说星空灿然、水波不兴，地平线处却已出现薄雾，它与天相接时将使得地平线再也难以分辨。

泰坦尼克号在其守望塔楼(the crow’s nest)和舰桥指挥部两处都装备有目视监视器。在守望塔楼的两个目视监视点之上，舰桥指挥部的赖特霍勒船长还有一个自己专用的监视点。船上配备了6名专业目视监视员，下一班应在0:00开始轮值。(其实，此时)往往都应该在船首部部署特别监视哨，并安装一条专线电话直接通到舰桥指挥部上。问题在于，为什么在诸多警讯迹象之下，仍然没有安排特别的目视监视员来当值。这一点再次说明指挥人员们的过分乐观和自信。

此节上IT项目所能吸取的教训是，在商业周期中，随情况之变会出现所谓关键时段，比如在月末的种种操作，往往需要特别的安排和处理，此时任何不寻常的状况都不得掉以轻心。

况且，泰坦尼克号的观察哨发现双筒望远镜找不着了，这太不寻常了。按惯例，在守望塔楼应至少常备一付。其实，观察哨兵们已经不止一次地汇报了这一异常：哨兵们自从离开南安普敦就一路抱怨，这些本来列入在工作合同中将帮助他们更好完成其义务的工具，却不见踪影。哨兵们得到的解释是，这些双筒望远镜被分配给指挥官们用了，也或是有人偷了、但鉴于船大人多，没法追查回来。

在此IT项目应吸取的教训是，对那些处于关键位置的某些员工，如一线运行操作人员，应尽可能把最好的工作设备配备给他们，而不是配给组织结构和阶层中的任何其他人。

在估计与海上浮冰相距多远时，水温是非常精确的指标。通常，当船进入冰原时，应从船体的一侧用帆布桶取海水，然后放入温度计进行测量。按照此法每两小时测一次，一系列的测试之后将能很精确地揭示出大冰川与船体的距离。然而，一个旅客（事后指出）当时曾看到一个船员往测量桶里灌的是船上自来水管里的水，原因是桶上的提绳不够长，放不到海里。

而今IT项目应吸取的教训是，当反馈机制不断返回着相互矛盾、相互不能关联的数据时，必须详查反馈机制本身。然而现实中，泰坦尼克号反馈机制不仅本身就不完善，而且即便是通过该机制汇报上来的问题，其相关数据也是伪造来敷衍了事的。这同时又强调了在项目正式实施前，检查测试所有反馈机制和操作步骤的重要性。

尽管有前述的种种警讯，也没人采取任何措施减慢航速。从事后的角度看，船长和指挥官们应针对报上来的种种异常情况做更多的澄清工作，更直接深入地调查，集思广智。然而，没人料想得到在这一航程上如此快地就将直面冰山，因为冰山通常并不会飘游到象泰坦尼克号的航线那么南的海域。指挥员们当时一定认为在那样“极好”的能见度下一切都能被及时发现。

如今许多IT项目在项目执行上打折扣，是源于不够严肃认真、或屈从商务压力，而过快地让初步方案最终产品化。当初泰坦尼克号的船主们就被让船尽快投入商业营业的经济压力所驱使。

结果，泰坦尼克号的（项目）测试，换变成了（直接）满载乘客横跨大西洋的处女航。考虑到已经投入和在泰坦尼克号建造中积压的大量资本，这一点是可以理解的，然而是否是可以接受的呢？商业机会对奥林匹亚号是同样存在的，而白星号的总体目标就是每周在大西洋上对开两班豪华航线。况且，奥林匹亚号已两次意外停运了近8个星期，所以Ismay急于让泰坦尼克号尽快投入正式营运。而代价呢？Ismay为泰坦尼克号写下了一个新的“服务水准目标”（Service Level Objectives），下一部分将证明它是对泰坦尼克号是命运攸关的东西。

下一部分将着眼于IT项目的运行阶段。

原文：

On the night of April 14, the ship California was north of Titanic, bound for Boston. After a near-fatal collision with an ice shelf, Captain Stanley Lord decided against proceeding forward and pulled up for the night. Surrounded by pack ice but in no danger, radio operator Evans, under orders from the captain, sent an ice warning to Titanic’s radio operators, who had been working a 14-hour day sending/receiving commercial traffic. Titanic responded with the infamous, “Shut up, shut up, I am busy. I am working Cape Race and you are jamming me.”

This last warning was not passed back to the bridge because of the message overload. The procedure for passing messages back to the bridge was confusing at best. Evans did not try again, turned off his wireless and went to bed.

The lesson from this for IT projects today is that any external warnings, from customer or supplier, need to be taken seriously, and thoroughly investigated. Finding the meaningful information in a sea of “noise,” or redundant information, is invaluable. With Titanic, if someone had pieced together all the ice-warning information, it would have indicated a giant ice field, around 80 miles wide, directly ahead. Effectively, there was no macro view of the environment.

Any experienced mariner would recognize sea conditions indicative of ice fields. The sea is calmer, as the ice floes and pack ice dampen water movement. The seawater also takes on an oily appearance as it approaches freezing point. The overall visible distance that objects could be seen from the ship was thought to be beyond the norm. This gave the crew a high level of confidence, in being able to spot all hazards. However, although stars brightly illuminated the sky, and the sea was incredibly calm, there was a haze on the horizon created by the cold weather. This made it difficult to outline the horizon as it merged with the sky.

Titanic had some built-in visual monitoring through the crow’s nest and the bridge. Beyond the two lookouts in the crow’s nest, officer Lightholler maintained a lookout himself from the bridge. Titanic carried six specialist lookouts, and the next shift change was due to start at 00:00. A question remains why no extra lookouts were on duty, considering all the warning signs. It was typical to post extra lookouts on the bow of the ship, to which a telephone link ran from the bridge. This is another example of the overconfidence of the officers.

The lesson for today’s IT projects is that there are critical periods in the business cycle were conditions change, like month end processing, and this requires extra diligence. Unusually quite conditions should not be taken lightly.

In addition, the lookouts were missing binoculars, which was very unusual. It was customary to always have at least one pair in the crow’s nest. The lookouts had repeatedly reported this, since leaving Southampton, resentful at not having these since they were the tools of the trade required to make them effective. Explanations include they were assigned to officers on the bridge, or that someone stowed them away and was unable to find them with the size of the ship.

The lesson for today’s IT projects is that certain staff in critical positions, like operations, should have the best equipment available, in preference to others in the hierarchy.

The temperature of water is a very accurate guide to the proximity of ice in the water. Normally, when entering ice fields, tests were taken by drawing seawater from over the side of the ship with a canvas bucket, and then placing a thermometer in the bucket. Repeated every two hours, these tests were an accurate indicator of the proximity of large ice floes. However, one of the passengers noticed a sailor filling the bucket with tap water because the rope was not long enough to reach the sea.

The lesson for today’s IT projects is to investigate feedback mechanisms that are reporting contrary data in isolation to other data collected. In Titanic’s story, the mechanism was faulty but rather than report the problem the data was falsified to cover it up. It also emphasizes the importance of testing all feedback mechanisms and operational procedures before implementation.

No attempt was made to slow the ship down, despite all the aforementioned warnings. In hindsight, the captain and officers should have done more to clarify the scope of anomalies brought to their attention, investigate them more closely, and piece together all the intelligence. However, no one expected icebergs to be directly in the path of the ship so soon in the voyage, as icebergs did not usually drift down as far south as Titanic’s course. The officers must have perceived that anything would be seen well in time with such “excellent” visibility.

Conclusions
Today, many IT projects severely compromise implementation by not taking it seriously enough and bowing to business pressures to get the solution into production quickly. Titanic’s owners were very much driven by the pressing economic need to move Titanic into service.

In reality, Titanic’s testing consisted of the maiden voyage across the Atlantic fully loaded with passengers. This is understandable, considering the huge amounts of capital that had been invested and sat tied up during construction. But was it acceptable? The business opportunity was there for another ship (Olympic) and White Star’s overall objective was to have two luxury liners crossing paths on the Atlantic on a scheduled weekly basis. In addition, Olympic had been twice unexpectedly out of service for about eight weeks, so Ismay was anxious to see Titanic move into service as quickly as possible. But at what cost? Ismay wrote out a new SLO for Titanic that proved to be crucial in the next part of the story.

The next installment will look at the operation stage of the IT project.

【 发表评论 0条 】