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