讓里程碑評審避開誤區見成效
對於軟體專案管理來說,建立專案里程碑監督里程碑的完成,召開里程碑評審是一項基本要求。雖然每個軟體專案都會進行以上這些活動,可是專案里程碑評審常常會流於形式,沒有發揮作用,專案交付節點該延期還是延期,交付後的問題也是不斷出現。
所以如此是因為我們對里程碑評審的理解存在一些誤區。
誤區一,里程碑評審只能設定在階段末。
在《軟體工程最佳實踐》一書中,羅列出了13個典型的專案里程碑,分別是:
-
需求審查。
-
專案規劃審查。
-
成本及質量評估審查。
-
外部設計審查。
-
資料庫設計審查。
-
內部設計審查。
-
質量規劃及測試計劃審查。
-
文件規劃審查。
-
部署規劃審查。
-
培訓規劃審查。
-
程式碼審查。
-
每個開發測試階段。
-
顧客認可度測試。
從這個典型的里程碑列表來看,里程碑不僅可以設定在每個開發測試階段,還可以設定在你想關注的可交付成果的檢查點上。因為通常情況下,里程碑的結束是對可交付成果審查的直接結果。
誤區二,把里程碑評審當做技術評審。
里程碑評審不是技術評審,而是管理評審。里程碑評審要確認的是可交付成果的審查結果,而不是可交付成果本身。可交付成果的問題,應當在之前的同行評審中去發現,應當在已經提交里程碑評審的審查結果中體現。里程碑評審要確認專案是否存在問題,問題應當如何解決,而不影響專案進度;要確認專案是否存在重大風險風險,風險應當採取什麼緩解措施……而這些內容的確認,是依據專案已經完成的工作成果來進行,其中就包括了可交付成果的審查結果。
誤區三,里程碑評審只關注進度。
雖然專案進度是里程碑評審關注的內容之一,但它並不是唯一要關注的內容。里程碑要評審專案的承諾、計劃、狀態和風險,進度計劃只是其中之一。這四項評審內容中,最不容易確認的是專案的狀態。專案的狀態正常與否,不是通過專案報告中所有任務都完成,所有問題都解決,所有風險未發生這種結論就能做出判斷的。如果僅僅是這樣,里程碑評審就如走馬觀花一樣,發現不了專案潛在的問題。里程碑評審也會流於形式。
正如前文所說,里程碑評審應由授權人員對專案的工作成果進行確認,評審人員應當符合專案的交付成果及其審查報告,從中判斷專案是否有潛在的問題。這樣的里程碑評審才會發揮效用。
以上是里程碑評審常見的一些誤區。
里程碑評審是有效的專案管理手段,很多失敗的專案都是由於沒有進行里程碑評審,或者里程碑評審無效造成的。避開里程碑評審誤區,加深里程碑評審的理解,讓里程碑評審這一手段真正發揮作用是軟體專案管理追求的目標。