IT项目启示录——来自泰坦尼克号的教训(第五篇)(转)

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

我们还回顾了泰坦尼克的同型船奥林匹克号以及她在泰坦尼克事故中所扮演的角色。值得注意的是,白星公司认为奥林匹克的航行记录足以用于几乎相同的同型船,泰坦尼克可以不经过多方面的海上试航而直接开始服务。然而,由于发生了让船长和高级船员始终不安的几件事故,,这个记录远远没有那么理想。

到了测试阶段开始时,泰坦尼克不可克服的看法不仅存在于白色星工作人员中间而且也被公众所接受。再加上船的所有者对奥林匹克号的“完美”记录的认识,泰坦尼克号已经准备好了的错觉深深地印入所有人的头脑中。泰坦尼克在1912年4月进行了为期一天的海上试航。全体人员渴望新船的速度可以与奥林匹克号匹敌。与泰坦尼克号相比,奥林匹克号进行了包括实际发动机测试和调整罗盘在内的更广泛的海上试航。

但是泰坦尼克的试验究竟缺少那些东西呢?第一,不仅试航进行不广泛,而且被认为不是关键性的工作。结果,泰坦尼克根本没有进行任何一种组合控制操作如经常惯常在紧急状态故障发生时经常惯常的"S形转弯"。第二,高级船员只有非常短的时间熟悉船的操纵。对于泰坦尼克来说,奥林匹克被看成测试的基础或衡量尺度,而且人们对奥林匹克航行记录过于信任。特别是,人们对奥林匹克号的航行记录如此肯定,以至于都在争论怎样才能很好地把奥林匹克的经验用于泰坦尼克。

同样,IT项目由于太依赖以前类似的执行过程和减少测试内容和环节,可能会做出类似的错误。测试阶段应该多方面和严格地审查决定系统工作特性的无功能需求和确定运行时间内的可利用性,可靠性和系统管理;基于非运行时间特性的其他无功能需求包括可量测性、可携带性、维修性、环境因素和可升级性。无功能的需求确保了系统能够提供出所设计的功能。

由于泰坦尼克号四年的建设周期占用了大量的投资,泰坦尼克号寻求生存的商业压力是巨大而且是可以理解的。另外,由于与HMS Hawke号的碰撞,奥林匹克已经不能使用,要在旱船坞中持续修理一个月。但是泰坦尼克的使用被证实需要更进一步推迟,需要把初次航行时间从三月推迟到1912年四月。但是白星董事Bruce Ismay确信泰坦尼克已经就绪,强烈主张提前开航。
今天的IT项目由此获得的教训是,项目进行只能按照既定方案制订的日程表来进行,因此组织和尤其是操作团队要很好地筹划和准备。重要的是要确定任何商业变化都要通过变更管理过程进行,变更管理过程要对类似提前发布启动日期这样的风险进行仔细评估。当然,规范的变更管理和控制理论在1912年并没有建立,也无法避免这种情况发生。

为了确保产权的平稳转移,Ismay与Harland and Wolff公司的总建筑师和首席工程师一起登船共同见证泰坦尼克的处女航。在故事中,之后将会发生一次严重的碰撞。

今天的IT项目从中得到的教训是,无论ismay作为董事,在不在在船上。船长才是重要决策的制订人。由于公司董事在船上,这可能使得它可能暗中篡夺被他雇佣的船长和高级船员的报告等级。

同时,对分阶段建设交货的三艘船,Ismay知道有个非常好的打开市场机会,把不断进行改进的三艘船作为卖点依次推出。事实上,这是社会关注技术不断进步典型例子。用打破奥林匹克最快的横渡记录作为卖点,Ismay可以把泰坦尼克作为更高级的远洋客轮在市场上进行推销。泰坦尼克的初次航行之前,Ismay为了促销在纽约时报发表一项声明,声称泰坦尼克将比白星公司颁布的航程早到达一天。事实上,这是一个宣传噱头,但是他给出了泰坦尼克的新服务等级目标(SLO),这个目标并没有经过船长和高级船员们证实。事实证明这个决定是致命的,是把船推向它的运行极限。

IT项目由此获得的教训是,虽然服务等级目标(SLO)不能受到商业的控制,只能由被授权执行生产过程中整个系统的工作团队完成。商业的确有助于确定服务等级目标(SLO),但是要经过谨慎地谈判并且各方要达成一致。

事实上,泰坦尼克的功率输出不会有所提高了,泰坦尼克号的速度也不会超过奥林匹克号。除了在某些功能上有一些差别外,两艘船完全相同。Ismay将让泰坦尼克横越大西洋时全速疾弛以超过奥林匹克的最短记录,这也是11月移交工作的其中一项。

今天IT项目由此得到的教训是没有进行的风险评估计,商业压力会使项目操作超越极限。

从南安普敦出发时,泰坦尼克与蒸汽机船纽约号几乎相撞,当时纽约号下锚断裂,只差4英尺就要与泰坦尼克号相撞。这与奥林匹克号与Hawke号相撞事故非常类似,这也意味着要操纵好这艘巨轮,全体船员面临着一项艰巨的挑战(见第四部分)。

爱尔兰的皇后镇,是开始横渡大西洋主要路程经过的最后一个港口,在那里贸易部检查员对泰坦尼克作了检查。作为检查的一部分,高级船员测定了船的适航能力,检查了船体,锅炉和机械装置。他们还检查预防措施,水,燃料和救护器材。他们检查了三等舱的照明和通风,以及全体人员和三等舱旅客的健康情况。

还有一项重要的检查就是安全性的检查。使检查员确定全体船员已经准备好了,当着检查员的面进行救生船使用训练,用以判断船员们以做好准备。在训练时,只放下了两艘救生船,但是并没有到达水面,所以这次检查根本没有完成。这次训练的大致内容是挑选了8到10个训练有素的人进行训练,让他们降下救生船。这次测试没能显示全体人员做好充分的准备,应对同时需要放下16救生船的事故。事实上,在全体船上人员中仅有83水手。其余人分别服务于船上的豪华饭店或者操作船的机械装置。检查完了之后,皇后镇贸易部给出了泰坦尼克的报告:泰坦尼克适于航海,并已经为启航做好了准备。

今天的IT项目由此获得的教训是,测试目的是要发现与需求、设计、建设阶段不符的较大缺陷。泰坦尼克号的最后测试完全是粗制滥造,并明显暴露了由于自大驱使的"决不会有任何问题"的态度。

结论

今天,许多IT项目严重地放弃了本应非常充分进行的测试,屈服于商业压力把解决方案很快地变成产品。泰坦尼克的所有者迫于极大的经济压力,不得不把泰坦尼克投入运行。实际上,泰坦尼克的测试包括此次满载乘客横越大西洋的初次航行。这是可以理解的,因为在整个建设期间投入并占用了大量的资本。但就可以接受吗?

这里另外一艘船也是商业机会。白星的整体目标是拥有两艘豪华邮轮运营横渡大西洋航线,并使这条航线航行日程是每周一次。另外,奥林匹克出乎意料的要大约八左右星期无法运行,所以Ismay急于要把泰坦尼克尽可能快的投入使用。但这付出了多少成本了呢?Ismay为泰坦尼克号制订了一个新的服务等级目标(SLO),这被证明这对下一步事态发展起了决定性的作用。

下部分我们将关注IT项目的执行过程和操作阶段。[@more@]

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

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

你可能感兴趣的:(IT项目启示录——来自泰坦尼克号的教训(第五篇)(转))