从泰坦尼克号看IT项目管理.docVIP

PAGE PAGE 1 从泰坦尼克号看IT项目管理 之前看过泰坦尼克号的电影，就是觉得这艘客轮极尽奢华，像是一个小世界，有贵族、有平民。看了从老师那下载的泰坦尼克号的有关资料。了解了背后有关这艘船的设计实施，从而了解了沉船的真正原因。 分析 项目的设计和计划阶段 在这个项目的最开始，这艘船的建造者—白星海运公司因为彼时的竞争优势不复存在，于是就启用投资新兴技术并用这些技术来建造豪华客轮这个战略。但是，打从一开始，新兴技术上总的投资额就没有包括诸如安全系统这种非功能需求的支出。重点放在功能需求上，建造宽大舞厅使得防水壁舱无法延伸到顶部的甲板，严重破坏了轮船容纳海水的能力，这也是沉船的原因。 项目设计阶段临近收尾时，大多数安全性能都没有得到重视。 在项目结束的时候，该项目小组认为船的安全性能仍然维持在最初设想的较高水平，还认为这艘船依旧具有最初设计所具有的功能，并没有进一步进行检测。以至于人们认为这艘船无比安全。 设计时，通过测试，项目无比完美，但是仍然会在实际操作中惨遭失败，这是因为，自然环境是难以模拟的，在测试时，我们只能大概分析环境影响。因此，要做足安全防范。 白星业务的资金回收期相对短，因此非功能需求的妥协不可能是成本削减造成的。白星没有充分评估出反弹值，并把它包含在业务情况中。项目重点有偏差。 白星海运公司急于向人们证明他们的优势，以至于在设计上，盲目的考虑游客的舒适程度，而不是船的航行最优化、安全化。 由于行政业务的压力，泰坦尼克号的建造者们在保险性能上做了让步，导致后来沉船的时候没有足够的救生艇、沉船速度异常快。 到泰坦尼克号的建造阶段，泰坦尼克号的建造者们都坚信泰坦尼克号是永不沉没的。正是这种氛围让建造者们将救生艇数目限制在16组内。 过度依赖于以前类似的项目，并且没有完全评估业务的风险。白星公司认为奥林匹克号的航行经历足以证明与之几乎一样的姐妹号即泰坦尼克号是不用经过多少海上试验就可以直接航行的。这个观念迫使该客轮所有者也认为泰坦尼克号已经是一艘天生就肩负着航行使命的轮船 项目测试阶段 因为有着姐妹号奥林匹克的参照，泰坦尼克号经历的测试既不多而且也不被重视。 测试的时候，高管们没有花多少时间去适应轮船的操作。 过分依赖以前与之类似的项目，从而减少了测试的次数。测试阶段应该重视非功能需求，因为它们详细说明了一个系统的操作特征并且决定了运作的实用性、安全性以及系统管理；还有非运作的可量测性、轻便性、可维护性、环境因素及进化能力。非功能需求确保了系统实现它应有的基本功能。 泰坦尼克号背负着让白星公司东山再起的重大责任，以至于白星公司高管过分着急，对各种非功能性需求妥协。 伊斯梅在没有得到船长及其员工的核实前提下给泰坦尼克号列出了一个新的服务级别目标(SLO)。这一点是致命的，将泰坦尼克号推向了它的操作极限。服务级别目标(SLO)通常不是由业务所控制的，而是由那些被委托运行系统的运作团体来控制的。伊斯梅的做法也犯了致命的错误。 项目的执行及实施阶段 在快接近冰山时，完全意识到会有危险，但是伊斯梅对轮船的操作和预警系统充满信息，以至于对危险无动于衷。为了向游客证实这艘船的能力，强行使轮船在充满危机的冰山巷中以峰速前进，这无疑是拿轮船的安全性开玩笑。 遭遇冰山时，为了扭转乾坤，泰坦尼克号采用了最早的警报系统，但由于没有适当利用关键反馈机制来汇报问题最终还是功亏一篑。 泰坦尼克号项目本身就存在严重的缺陷，留给测试的时间太少，官员在试航时没有经受任何S形转弯演习，也没有模拟在遇到可怕情况时如何驾驶轮船。 泰坦尼克号的技术支持团队并没有花多少时间来熟悉此轮船。他们未能识别出异常情况的规模，并且也没有将各自的想法集中起来。 伊斯梅急于挽回颜面，他害怕白星公司的名声受损，这使得周边的环境很容易出错。 在撞上冰山后，伊斯梅过于乐观，没有看到隐藏在平静背后的致命风险。 碰撞中，海水漫进了5号锅炉房，用抽水泵抽吸海水，但是形势没有得到缓和。这时候船已经进了很多水，船的其他部分在海水的压力下，也出现了裂变。 伊斯梅强行控制了轮船，即根本就不考虑MTTR或修复就让轮船继续前进。 在泰坦尼克号轮船上，正式的灾难修复计划没有在合适的时机进行。 轮船上的通讯工具太有限，以至于重要的通知往往让船员去一个一个船舱及公共休息室敲门口头通知。时间花销大。 船上的救生艇不够，救生艇的总装载容量仅为此人数的一半，船长害怕穿上恐慌蔓延。 总结 在没有经过一些风险评估时，关键的操作程序不能因业务上的压力而有所让步。 测试目标是为了揭发在需求、设计及建造阶段主要存在的漏洞问题。 一个业务主管在没有得到操作人员的同意下，没有权力下任何操作决策。 在监视一个刚实施的解决方案时，操作人员需要对它非常熟悉。他们必须积极主动地去预防在一线出现的错误，并且确保一线能符合它的