空难与软件开发（一）

我并不是嗜好灾难片电影或者纪录片的。但是偶然的机会看了一两集Air Crash Investigation，便被其深深吸引了。因为这些事故，和我们日常进行的软件开发是如此的相似，有一些今天广泛提倡的Best Practice实际上早就提出几十年了。于是突发奇想，干脆总结总结。这是第一篇。

美航1420次班机空难

1996年6月1日，一架MD-82飞机从美国达拉斯飞往小石城。在接近小石城机场时，机组人员接到雷暴警告。飞机在恶劣天气下从4R跑道进行进近，着陆之后，飞机冲出跑道，以高速撞向跑道尽头的引进灯，断裂为3截并起火，飞机机长和10名乘客遇难。

在所有的飞机空难事件中，不论事故的起因如何，总能从最终调查结果中发现，事故是一连串（有时甚至非常巧合的）相关因素（天气因素，人为因素或者机械因素）交替出现的结果。此次事件也不例外。这件事故发生的前后的时间流水账如下：

背景：

（1）在现代航空运营中，航空公司和机组人员面临这空前压力。效率与准时称为航空公司力保的因素。基层的签派员，驾驶员等必须全力以赴才能够完成任务并获得盈利。航空公司尽量保证签派计划不变但是有一项因素无法控制：那就是天气。而航空公司为了保证计划，不惜和天气赛跑，赶在风暴来临之前进行飞行和降落。

流水账

（2）1996年6月1日。美国1420班机在达拉斯机场准备起飞，由于风暴来临，班机已经延误。

（3）航空人员压力越来越大，延误事件越久越不可能完成飞行计划。（飞行员的工作时间有严格的限制，如果起飞过了某一个时间点此次航班也许会被取消），因此副驾驶频繁和签派中心联络商讨，驾驶员也担心随着时间推移目的地天气恶化。

（4）驾驶员和签派员仔细研究天气信息认为他们可以在雷暴袭来之前通过航路到达小石城。在匆匆告知乘客登机后，飞机终于起飞。

（5）在飞机距小石城100哩的时候，驾驶员准备降落，同时其发现前方的风暴正在形成。在小石城之间形成保龄球道。飞行员决定穿过保龄球道，尽快飞往小石城。

（6）飞机两旁密布闪电，飞行员不知保龄球道正在快速收缩。在飞机降落时，塔台通知天气情况，机场跑道有44米的侧风，足以掀翻屋顶。驾驶员计算阵风方向和进场方向后，发现极限承受的侧风值是50米，决定继续降落。

（7）但是强烈的天气变化使得雷达难以跟踪，塔台随后发布了风切警告。驾驶员只得放弃原来进场方向，决定盘旋并反向降落。

（8）由于飞机方向变换的原因，机上的雷达在这一过程中无法扫描到机场附近风暴的信息。同时，在飞机盘旋的10分钟内，风暴分布已经发生了变化，愈发的猛烈。

（9）在降落过程中，他们发现无法目视机场，同时还要注意天气变化，飞行员需要衡量的因素过多，工作强度陡增。风暴太过强烈，驾驶员认为他们必须尽快进场。

（10）机场努力的找出机场位置，决定放弃目视进场，转而使用仪器进场，机场紧急协调。宝贵的事件继续流失。

（11）天气继续恶化，大雨已经使能见度降低到3000英尺。飞机进场时非常颠簸，机长不知道他们正一头扎向风暴中心，但机组成员继续降落。此时能见度已经降低至1600英尺，不符合降落要求。由于已经处于降落末端，但根本看不到跑道，机组成员惊慌，开始连续犯错。

（12）飞行员努力调整襟翼对准跑道。终于飞机起落架触地，飞快的滑行，机组忘记了打开扰流板（可以理解为空气刹车），而只是开启起落架的两组刹车。飞机开始侧滑……（机组最后通话记录：Oh no! On the breaks, we are sliding! Other one, other one, other one）飞机断裂，起火燃烧。

计划和赶工

我相信你会有一些熟悉的感觉：计划 and 赶工。

软件公司是要挣钱的，和航空公司一样。航空公司需要航空计划（抛开维护的时间飞机最好都在天上，当然现实是不可能的），软件工程需要项目计划。成本估算是非常重要的一环。大部分的软件项目的时间很难用“宽松”这个词来形容，但是项目执行过程中“需求”和“交付”又是非常飘渺不定的事情，一旦影响到了关键路径，计划的实现就变得困难起来。

在原定的计划变的困难的时候，项目经理面临着选择：

（1）调整工期

（2）调整交付内容

（3）调整交付质量

（4）上述两个或者多个混合上

（5）什么都不调整，给我上

可能还有其他的路子，我们这回先说（1）和（5）。

调整工期

调整工期意味着延期和成本的上升，这中选择对于实例不雄厚的企业可能不能接受，但是对于将质量放在首要位置的项目来说应该是可以考虑的。就像上述案例中，机长可以考虑转飞附近机场。

都给我上

那么机长为什么没有这么做呢？调查人员在对2000次恶劣天气下的起降进行统计后发现了一个惊人的事实，2/3的飞行员都会选择扎到风暴里，尝试降落。调查人员惊讶于这个事实，但是最后，他们明白了受过良好训练的飞行员为什么还会选择冒险：

首先，调查人员发现这些飞行员几乎无一例外全处于航班延误的状态，如果他们发现前方的飞机穿过风暴降落，他们也会做出相同的举动；

而最重要的一点，实际上在飞机起飞前就已经种下了。调查员在机场发现了一个要命的飞行规定：“务必到站”。飞行员可能已经快到了一天的工作上限——十四小时，此时飞行员在这种双重压力下，就会有这种决定，冒险试一次吧，看看能否完成任务。于是他们开始在暴风中降落。有些飞行员成功了，有些则深陷险境，无法回头。在巨大的压力下，飞行员更容易犯错误。

我没有能力统计软件项目中有多少人会选择（5）。但是讽刺的是实际项目中，采用（5）的确有人在。无偿加班则是实现（5）的必备手段。如果技术和设计人员按照自然工作强度进行工作好比飞机在晴朗的天气飞行的话，加班可以说就是在阴云密布中航行了。稍有不慎则造成相反的效果。尤其是临近项目尾声的时候，人员已经非常疲惫，更容易出现状况（虽然项目经理都是非常专业的，但往往项目到尾声的时候都会有状况出现，有些状况使人匪夷所思，例如：发现没有实现的功能，非功能性需求无法满足，出现观止级BUG等等）。此时，再想调整已经难有余地。

基层的人员会把这种情绪发泄在项目经理的身上，但是实际上项目经理为什么会做出“给我上”的决定呢？如果除去项目经理个人能力的问题，你往往也能找到上述问题：

首先，项目经理背负着有好多软件项目都遇到了问题，但是他们都完成了的压力。那么他用同样的方式也要完成。

其次，抛开项目经理个人能力的因素，你总能够找到有另一个人，在对项目经理下达“务必到站”的规定。对于这个人，你甚至没有办法影响他，于是项目经理在压力下，说，我们试一次吧，看看能不能完成任务。于是项目经理选择了（5），期望船到桥头自然直，车到山前必有路。有些项目经理成功了，他们的经历甚至写成了书，有些项目经理失败了，他们的经历也写成了书。

调查后的治理

在暴风之夜，1420班机的机组人员在完成当天最后的任务，但是在多重压力下，飞行员们犯了最最基本的错误：在着陆后忘记打开扰流板。11个生命就此断送。

最终的调查报告指出，飞机坠毁的原因有两个：

（1）飞机在风暴中降落；

（2）驾驶员没有启动扰流板。

美航修改了降落的Checklist，规定所有飞行员降落时都需要检查扰流板的启动。

但是：

（1）这并没有包含是否应该在风暴中降落；

（2）降落的时候，飞行员只有几秒做出判断，除非Checklist深入人心，训练真的能达到效果吗？

看来，软件项目也一样，我们还会在暴风中降落。