我並不是嗜好災難片電影或者紀錄片的。但是偶然的機會看了一兩集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深入人心，訓練真的能達到效果嗎？
看來，軟件項目也一樣，我們還會在暴風中降落。