如何保证项目流程畅通？

【导读】当一个IT解决方案在生产阶段进展不顺时，项目小组应根据项目自身所准备、计划并测试好的一个流程去采取一些措施。

　　为了挽回这艘轮船的名誉，泰坦尼克的高管们试图避免碰撞。然而， S型转弯方法虽好，但还是未能大大减慢轮船的行驶速度。泰坦尼克号后来终于慢慢停了下来，有成百个乘客是这样描述的:在持续几秒钟的震动及隆隆声中，轮船仿佛在一大堆大理石上翻转了一下。

　　船不是“突然停止的”，因此几乎没有受到什么损伤。侧面也没有什么大的摇晃，整条船也没有反复的摆动。当一艘轮船在采取了一定的措施来减轻侧撞时，一般都可以产生这种情况。摆放在餐厅的早餐餐具几乎没有晃动，放在一等舱吸烟室及休息室的饮料也没有洒出来。所有的迹象表明轮船被搁在了冰山的冰架上。麦多克阻止了船头直接与冰山相撞，如果那样相撞的话，前4个舱厢会撞坏，成百名乘客将遇难或致残。

　　同样的，当一个IT解决方案在生产阶段进展不顺时，项目小组应根据项目自身所准备、计划并测试好的一个流程去采取一些措施。此流程必须基于一个平均修复时间时钟，这是为了尽可能快地得到实时的IT解决方案以满足服务级别协议(SLAs)的首要目标。然后在后台可以修补解决方案，这个修补可以是暂时的也可以是永久的。

　　然而，在方案投入运行前，方案的完整性必须先建立好，这样问题才不会再发生。操作人员可以通过时钟来检查流程及监测、判定、方案及修复这四个“问题”象限。当平均修复时间(MTTR)时钟开始记时，就标志着服务(一次意外事件，参看第2节)失败的开始，必须为用户意外时间制定标准，这样可以评估有多少用户服务丢失以及丢失持续的时间。

　　这比通常用的以百分比(例如99.999%)来衡量服务的效用性要精确得多。泰坦尼克的问题监测信号是来自于守望员发出的长达37秒钟的警告。这对IT解决方案来说并没有多少相同之处，后者可能是在任何重要失败出现之前就消除错误并提出警告。这首先就让操作人员有时间去采用自动的或手动的操作行动来预防问题的出现。

　　泰坦尼克号的船长、主管以及高管聚集在桥楼决定采取什么措施。由于损伤的程度也是问题的一部分，因此船上分布了两个搜索救援组，一个在船头，一个在船中央。第一个小组在10分钟内返回并汇报没有大的损伤或进水。在主管布鲁斯.伊斯梅看来，问题监测及判定现在是完整的。使用求救呼号的决定对他来说是个问题，因为这样做会有损白星公司在业界的地位，并且会破坏泰坦尼克号的广告效应，摧毁一度辉煌的行销(参看第2 节和第5节)，这种行销曾吸引了世界上不少富人踏上这艘号称最安全的轮船。

　　另一个较好的解决方案是让轮船返回哈利法克斯，远离纽约和世界新闻中心。然后他可以制造出更好的新闻故事，将事故忽视为一次小意外。他能够将乘客转送上火车，再对轮船进行修补，或者把轮船送回贝尔法斯特修补。事实上，他可以大胆地宣布泰坦尼克号自身采用了新兴技术，是一艘救生船，能够把自己从一次巨大的灾难中救回，因而能为白星公司作一次更好的安全性宣传。

　　对今天的IT解决方案来说，问题的结论考虑了该方案给用户造成的影响。结论必须与有效迹象相一致。对反馈机制及日志的再调查对于判断问题是否扩大了以及扩大的原因是什么至关重要。

　　在一个复杂的IT解决方案里，常常能看到多米诺效应，即诸如一个子系统这样小的有缺陷的因素会激发一系列问题。如果不分析出事情进展的精确信息，这可能会导致一次错误的判断――产生一次错误的修补并且问题重新发生。只有找到问题的最根本原因并得以证实才算完成了判断。

　　对一个IT解决方案来说，肯定手边的证据以及询问下面几个问题非常重要。是否意识到IT解决方案会失败?如果是的话，是否尝试了一些(自动化的)预防措施?它向人工或自动化的操作员发出了警报吗?反馈机制是否有问题并且提供了不可靠的数据?对问题的判断准确吗?

　　泰坦尼克号的情况是紧急的，但还不到灾难性这一步。伊斯梅急于挽回颜面，他害怕白星公司的名声受损，这使得周边的环境很容易出错。泰坦尼克号安静地靠在水下的冰架上，这使它看起来十分安稳。也许细心一些他们就能以最小的损伤全身而退。伊斯梅仓促行动做出了草率的决定。第二搜索救援组(里面有造船人员和木匠)还来不及返回并给予评估。

　　今天的IT项目从中所获取的经验是:在解决问题时，必须在搜集好所有数据信息的前提下，分析每个解决方案所带来的风险性，再考虑选择最合适的解决方案。要不然就得靠最后第四象限的修复阶段了。在这个阶段里，操作小组会根据服务级别协议(SLAs)即时撤回IT解决方案，并让服务再重新开始。

　　就泰坦尼克号来说，不是所有采取的措施都是完全依据问题的解决方案。伊斯梅做出了致命的决定，给轮机舱打电话让船向前开，想以最低速度来改变当时的情况。轮机员后来证实轮船以3哩/小时的速度前行时曾发出过碾碎的声音。

　　结论

　　今天，许多IT项目由于没有作好周密准备，导致流程不能很好地处理有关平均修复时间(MTTR)时钟的问题，因而项目在操作阶段受到了严重的损伤。一个流程对于操作小组来说意义重大，因为它能使小组快速恢复服务并维持服务水平。一个流程也应具有部门之间的相互制衡机制(通过审核)，以此来最小化在一个有压力的环境下出错的可能性。一个流程应该列出每个人承担的责任和扮演的角色，以此确保合适的人去制定合适的决策。

原文转自：http://www.ltesting.net