本文字數(shù)約2500字,閱讀時長5~10分鐘
首先要明確的是,無論在什么情況下,項目風險都是不可避免的,只能盡可能地進行管理。在一些特殊類型的項目中(如軟件工程),項目風險基本可以分為兩類,一類是技術風險,另一類則是項目風險。技術風險是項目完成后因涉及不當而可能出現(xiàn)的問題,而項目風險則是項目生命周期中可能遇到的任何風險。區(qū)分這兩種風險是_軟件設計良好和__后軟件功能正常的必要條件之一。
航線自主優(yōu)化系統(tǒng) (ERAM) 軟件故障
2014年4月,由于洛克希德·馬丁公司設計的En Route Automation Modernization(ERAM)軟件發(fā)生故障,直接導致了巨量的航班延誤和取消。一般來說,ERAM軟件會限制每個飛機的數(shù)據(jù)量。所以在大多數(shù)情況下,每架飛機傳輸?shù)臄?shù)據(jù)都很少,總數(shù)據(jù)量不大。
2014年4月,由于洛克希德·馬丁公司設計的En Route Automation Modernization(ERAM)軟件發(fā)生故障,直接導致了巨量的航班延誤和取消。一般來說,ERAM軟件會限制每個飛機的數(shù)據(jù)量。所以在大多數(shù)情況下,每架飛機傳輸?shù)臄?shù)據(jù)都很少,總數(shù)據(jù)量不大。
但是偏巧了,這天剛好有一架飛行計劃設計得特別復雜的U-2準備起飛,直接就讓ERAM系統(tǒng)承載能力超出了極限。造成這一現(xiàn)象的一個主要原因是這架U-2飛機的所需的飛行高度不能用于ERAM,因此系統(tǒng)開始輸入每個可能的選項,這導致它循環(huán)多次重啟并顯示錯誤消息,_后ERAM系統(tǒng)因內存溢出而崩潰。
由于內存過載,系統(tǒng)無法處理其他功能,因此在美國西南部至少數(shù)百個航班被取消或延遲。這就是一個無法容忍的技術風險的例子,無疑在洛克希德·馬丁公司的風險管理規(guī)劃中都沒有考慮到這一點。
次年8月,經(jīng)過軟件升級的ERAM還是沒有逃過類似的命運。這次軟件升級旨在為控制器提供自定義界面,以便于訪問和控制,允許使用者查看需要經(jīng)常引用的數(shù)據(jù)。如果控制器調整了設置,系統(tǒng)將保留信息,而不是按預期從系統(tǒng)中刪除已刪除的信息。
慢慢的,存儲的數(shù)據(jù)量越來越大,直到超過限制。內存再一次過載。后來雖然美國聯(lián)邦航空管理局(FAA)與洛克希德馬丁公司合作,確定為什么在測試過程中沒有發(fā)現(xiàn)這個漏洞,但這個漏洞已經(jīng)造成了美國東海岸的1,000多個航班被迫取消或延誤。
ERAM和技術風險
ERAM軟件問題發(fā)生在項目完成和升級推出之后,這些問題在風險管理規(guī)劃期間可能被識別為技術風險。如果提前知道這兩次故障的后果包括降低收益和客戶滿意度降低的話,這些問題肯定在風險管理規(guī)劃期間就被評估為風險規(guī)劃期間無法容忍的技術風險。
然而洛克希德·馬丁公司和美國聯(lián)邦航空局在進行軟件升級測試時并沒有特別清楚地認識到這些影響系統(tǒng)內存的數(shù)據(jù)問題的存在,特別是因為這是原始軟件故障的原因。
ERAM軟件項目是一個特別復雜而昂貴的項目,估計耗資24億美元。在這種規(guī)模的項目中,必須實施一個用于解決項目和技術風險的風險管理計劃。風險可能被歸類為可能的未來失敗或來自當前決策或行動的不良后果
軟件項目的風險因素包括威脅成功完成或實施軟件項目的任何風險,如果不識別和理解這些風險,可能會導致項目很快失敗。為了降低風險,必須精心制定詳細相關計劃和處理流程。該過程應首先確定并評估風險,然后制定詳細的優(yōu)先行動計劃,以應對可能出現(xiàn)的風險。
雖然一般來說對軟件項目風險管理的系統(tǒng)化過程的回顧是有限的,但鑒于軟件項目的復雜性,這仍然是一個具有巨大改進潛力的領域
管理軟件項目的風險
在_次ERAM軟件故障后,F(xiàn)AA調整了系統(tǒng),確保所有飛行計劃都在可用高度內,并且他們還為系統(tǒng)增加了更多內存。在第二次失敗后,他們暫停了自定義界面功能,并調查了為什么洛克希德·馬丁在測試階段沒有發(fā)現(xiàn)這個故障。
雖然我們沒有深入了解洛克希德馬丁公司和美國聯(lián)邦航空局可能創(chuàng)建的風險管理計劃,但我們可以假設一項用于一個價值24億美元項目的風險管理計劃該怎么做。當涉及新技術或復雜技術時,項目復雜性風險是不可避免的。在這種情況下可用于解決技術風險的行動包括徹底的研究,嚴格的質量_流程,_初有限的部署或分階段實施,以及應急計劃。
管理軟件項目風險有三種比較常用的方法:
1._種方法是清單法,可能會包括技術,組織和項目風險。檢查表也可能基于以前的項目風險。這些風險類型通常不會被單獨分離出來,而是按概率劃分優(yōu)先級。
2.第二種方法是分類法,通常用于通過某種框架對檢查表進行分類。由于清單是通用且詳細的,因此分類可以按類別幫助確定風險的優(yōu)先級。
3.第三種方法是流程建模,通過正式流程管理指定風險管理活動,該流程提供上下文,識別,分析和評估風險,并緩解,溝通和解決問題。
盡管將項目風險與技術風險分開足以確保技術風險不會被忽視,但所有這三種方法的組合對ERAM軟件項目都是有益且必須的。ERAM軟件的技術風險應該在項目啟動和設計時考慮,并且應該在整個項目生命周期內對其進行監(jiān)控,特別是在軟件框架開始成型的時候。
對于洛克希德馬丁公司來說,考慮項目管理協(xié)會概述的軟件項目特有的技術風險清單也會有所幫助,其中一些包括缺陷,容量規(guī)模問題,性能要求,軟件使用的簡易性,變更方案, 和更多。項目經(jīng)理應該使用專家判斷,并盡可能利用業(yè)務分析師的洞察力,集體討論潛在風險并確定每種風險發(fā)生的可能性,以便他們可以優(yōu)先考慮這些風險并實施緩解計劃。
當洛克希德·馬丁公司開始建立ERAM軟件時,幾乎可以肯定他們已經(jīng)確定了所涉及的風險。那么,他們是否忽視了不完整或大量數(shù)據(jù)輸入時會出現(xiàn)相關的內存短缺問題的可能性?
一般來說項目經(jīng)理應該遵守以下流程,以確保全面的風險管理:
1.識別不可容忍的風險
2.確定可容忍的風險
3.制定不可容忍風險的治療計劃
4.進行成本效益分析以降低可容忍的風險
5.制定風險登記冊
6.定期更新風險登記冊,并在每個項目階段結束時更新
如果能夠在項目中做到這些,上面發(fā)生的數(shù)據(jù)和內存問題就有可能提前定位為不可容忍的技術風險,并且通過更新設計要求而變成可容忍的風險。
還有其他更詳細的分析方法,例如統(tǒng)計模型和數(shù)據(jù)挖掘模型,它們也可以用于這種規(guī)模的軟件項目。無論選擇哪種方法,基本前提都是一樣的,那就是定期評估和重新評估風險,因為它允許項目經(jīng)理和其他利益相關者評估不斷變化的條件和需求。
總之,項目風險是不可避免的,特別是對于復雜的軟件項目。但是使用適合的方法可以盡可能減少風險引起的損失。