微軟專案求生法則之求生技能3（轉）

規劃審查的主要好處
讓軟體組織將軟體專案經費分成兩階段處理至少有三種好處。首先，被取消的專案常被看成失敗的案子，可是一個進行了10%～20%就取消的專案反而應該視為徹底成功。完成80%～90%才被取消的專案所耗用的經費足以負擔許多在探索階段進行10%～20%就取消的專案。

再者，將龐大的經費延遲到專案完成10%～20%之後再撥款的話，可以對專案所需的龐大經費做出更可靠的要求。

最後，要求專案主管先完成專案的10%～20%才能要求撥款進行下面的部分，可以讓這些主管做好與對專案成功息息相關的上游工作。這些工作往往被省去或忽略掉，帶來的損失只有到專案下游階段必須花費昂貴的成本來修正許多錯誤時才會突顯出來。如果專案團隊被要求在下游工作之前完成最重要的上游工作，專案的整體風險就會大大地降低。

風險管理

風險管理是一種特殊的規劃方式。進行過大中型軟體專案的人都親身體驗到許多事情都可能出錯。最成功的專案就是採取積極步驟以免屈服在這些問題的困擾之下。你也許是完美主義者，可是對軟體專案而言，就如人們說的，你可以有最佳期望，但是應該要有最壞準備。

幾種最嚴重的軟體專案風險與規劃方式息息相關：

◆沒規劃好。
◆沒照著規劃方式做好。
◆沒在專案環境變化後修正好規劃方向。

在軟體專案中不採取積極的風險管理就是忽視軟體業界在過去幾十年中從幾千次教訓

中總結的一個經驗：軟體開發是高風險的活動。如果專案採取積極風險管理的方式，就可以避免或降低許多風險，而這些風險有許多如果沒處理好，就可能使專案陷入癱瘓中。

本文求生策略中包含（並在本書其他部分談到）的做法比起其他方式風險更低，並能夠增強對其他型別的專案風險的發現與控制，而被選錄。對軟體專案中要不要採取風險管理策略，你沒什麼選擇餘地。如Tom Gilb在《軟體工程管理原理》（Principles of Software Engineering Management）一書中所說的，如果你不積極面對軟體專案中的風險，你就會碰到這些問題。

專案控制

本文的一個主旨是，軟體專案可被控制，從而迎合時間、經費跟其他目標。對一些人來說，這種專案“控制”的點子簡直慘無人道，令人想象起一名專制的專案主管以皮鞭和銅鏈展現威權的樣子。

--------------------------------
專案“控制”的反面就是專案失控。
--------------------------------

人們也許，會認為專案即使沒人控制方向，也會順利地進行下去而不會失控。我的想法和經驗都告訴我那是不可能的，

有些人反對專案控制，因為他們認為這表示控制專案成員的行動。事情並不是這樣，專案控制所控制的是專案本身。下面是一些我所指的“控制”的意思：

◆選用一種軟體生命週期模型，如本文中使用的階段完成模型，給專案中技術性工作一個輪廓構架。
◆管理需求的改變，只接受必要的改變。
◆確立設計與程式寫作標準，使設計方式與原始碼以彼此一致的方式產生。
◆建立專案的細節規劃，使每一名開發人員的工作朝專案目標前進而不會防礙到其他人的工作。

控制並不是良好的技術性工作的附屬品。專案控制必須透過積極的專案管理與持續漸進的控制行動來落實。專案控制的具體行動將在本文其他部分談到。[@more@]