專案報警機制

如何判斷一個專案正在向這個方向發展（但尚未陷入災難之中）呢？如何在拯救措施的成本變高之前判斷出需要對軟體專案採取一定的措施？這些問題的答案在於EWS系統的報警機制。

出於討論的目的，我們將問題劃分為專案管理相關（例如行政、管理、過程、環境等問題）和產品相關（例如軟體的bug）兩類。專案和產品問題根據其所處的嚴重程度，分為下面幾類：

1．危急類

危急類產品問題：造成產品不可用或者接近不可用的產品缺陷。

危急類專案問題：若不將之克服專案就無法取得成功的、與專案有關的問題。

2．嚴重類

嚴重類產品問題：致使一個主要的產品功能不可用但整個產品尚可使用的產品缺陷。

嚴重類專案問題：如果不及時改正，將導致下面與專案有關的問題：

極大影響使用者的滿意度。有證據顯示預期會使用或購買產品的使用者中有20%或者更多將不會使用或購買該產品。

導致專案的經費預算超支20%。

導致專案的時間預算超出20%。

3．輕微類

輕微類產品問題：導致產品難用的缺陷，但產品的其他主要功能仍然能有效執行。該類別中還包括其他不危急也不嚴重的產品缺陷。

輕微類專案問題：指那些既不危急也不嚴重的與專案有關的問題。

危急類和嚴重類問題能夠觸發警報，具體來說，依據危急類和嚴重類問題的數量、清空問題列表所需要的時間以及解決問題的進展情況等屬性，判斷是否觸發警報。例如，在一個戰略軟體系統或生命支援軟體系統中，只要有一個危急類問題在專案中存在的時間超過了一個評審週期，就可能會響起警報。在針對非緊急事務的軟體系統專案中（如一個考勤管理系統），報警機制可能會較為複雜。

報警機制中經常會考慮到時效因素，也就是說，如果不對危急類和嚴重類問題加以解決，那麼隨著時間的流逝，它們的嚴重性會不斷增加。下面是一個報警機制示例（括號中是引數值樣例）：

1．對於一個新出現的危急類問題，賦予它X點值（例如，5）；

2．對於一個停留在問題列表裡的危急類問題，每過去一個彙報週期（例如，1周為一個彙報週期），為其增加Y點值（例如，2）；

3．對於一個新出現的嚴重類問題，賦予它Z點值（例如，1）；

4．對於一個停留在問題列表裡的嚴重類問題，每過去一個彙報週期（例如，1周為一個彙報週期），為其增加U點值（例如，1）；

5．將問題列表中所有危急類和嚴重類問題的值相加，計算出總和；

6．如果總和大於報警臨界值V（例如，20）那麼，就拉響警報。

X、Y、Z、U、V的值取決於專案、開發中的產品、開發機構、產品客戶和使用者、開發機構的歷史（以前的專案中問題解決情況如何）等方面的特徵。有兩條約束X、Y、Z、U、V值的規則：

1．必須在專案重啟前預先設定這些值；

2．在專案開發過程中，對這些值的更改應受到限制，不應頻繁改動。

這兩條規則確保了報警機制不會被輕率地改動。

大體來說，好的專案報警方法會以對專案的較全面審視（而不是僅以一個問題）為報警依據。不過，當一個問題具有壓倒性的影響（即由於該問題，專案失敗的可能性很明顯）時，警報也可能會被拉響。

我們在前面提到過，如果開發機構已經有一個有效的EWS，那麼在被拯救的專案重啟時，應使用那個EWS。對於其他機構來說，可以以前面例子中示例的X、Y、Z、U、V值開始，然後在專案推進過程中對這些值進行改進，透過這樣建立起一種簡單但有效的報警機制。不過，需要注意的一點是，不應頻繁地對這些值進行改動（X、Y、Z、U、V規則已對這一點做了規定）。

本文節選自《災難拯救——讓軟體專案重回軌道》一書

[美]Bennatan（本拿塔）著

侯豔飛，侯玉芳，李萌譯

圖書詳細資訊:http://space.itpub.net/?uid-13164110-action-viewspace-itemid-734730

專案報警機制