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

軟體規劃的例子
一個專案團隊該如何規劃專案，以在一定預算內完成軟體？底下是一些專案規劃的具體工作專案：

◆一個軟體開發的規劃反映專案進行的方式。把規劃方式記錄下來可以讓專案的資助者透過這份規劃來了解專案。

◆專案評估提供了專案規劃的基礎。一份仔細的評估可以確切地定出專案的規模，從而確切地定出預算上限、人員需求與時間需要。差勁的評估會低估專案在各方面的需要成本，使專案難以順利而有效地完成。

◆在每個主要階段末尾作個修正評估，可以中途修正專案成本，並讓專案的進行以穩健的步伐前進。

◆一份包含技術審查與測試的質量保證規劃，可確保專案不會被代價高昂而找不出錯誤的測試、除錯和修正週期壓垮。

◆一份詳細規劃出軟體構建的方式，可確保軟體解決方案有效地在各階段以提高對客戶價值和降低風險的方式進行。

除了以上這些明確的規劃方式，軟體專案的幾個主要活動也可以被規劃處理。

◆詳細訂出專案團隊試著要解決的問題，確定正確解決問題的方式。

◆構架設計出解決問題方式的大體規格，建立正確的解決方案。

◆細節設計是關於如何建立專案軟體的綜合規劃，以正確的方式建立正確的解決方案。

規劃審查

規劃方式對專案的成功是如此的重要，一些專家說專案的成敗完全決定於專案初期10%的時間內。不管確實比例是10%還是多少，在專案的最早期，專案團隊應該已經訂出使用者介面雛形、細部要求跟包含成本與時間預估的細部專案規劃，而這些資訊可以用來決定要不要讓專案進行下去。

兩階段出資方式

一些組織中對軟體專案經費的問題在於專案主管在完成一些探索性的工作前就得要求上頭支出必要經費。這樣的請款要求必然失準，因為對軟體瞭解不足。軟體業界的經驗是，在專案初始階段的估計或多或少，可能會跟實際的要求差距達四倍。

一個較好的辦法是讓專案主管把經費要求分作兩個階段。專案主管先在專案完成初期10%到20%的探索階段要求第一次經費。到了階段結尾，專案團隊進行一次規劃審查，同時資深管理階層或是客戶決定要不要繼續推動專案，然後再撥專案剩下的部分經費。這時專案成本仍有可能變動，不過先前已經完成的部分會讓整個成本變動範圍從四倍縮小到50%左右。

準備規劃審查

在進行規劃審查之前，得先要有下面的準備：

◆決定好專案關鍵決策者
◆前景敘述
◆該軟體的業務狀況
◆初步努力與時程目標
◆初步努力與時程目標估計
◆十大風險列表
◆使用者介面風格簡介
◆使用者介面細部雛形
◆使用手冊/使用需求規格
◆軟體質量保證計劃
◆軟體開發細節規劃

上述每一項準備在本書其他部分會更詳盡的解說。

如果這些專案都沒準備好，表示還沒有足夠資訊來決定專案的質量如何，就不用進行
規劃審查了。如果專案團隊一直都沒能夠做好這些規劃審查的準備，失敗的風險很大。

做好這些準備所需要的時間依據軟體所需要的工作量而定。當一般使用者知道他們要的軟體是怎樣的情形下，這個準備時間可能只需要軟體總開發時間的10%。一般情況下，這段準備時間會佔總開發時間的10%～20%。在一些專案中，這項工作最困難的部分是幫助一般使用者理清他們要的是什麼，所以偶爾這部分的工作會佔用總開發時間的25%以上。對規劃審查的經費要求與計劃應該將這項工作的變動考慮進去。

規劃審查的一般專案

規劃審查應該集中在下列各專案上：
◆本來的產品概念仍然可行嗎？
◆發展一個滿足專案前景敘述的產品可能嗎？
◆該軟體的業務狀態在更新、更精確的成本與時間估計出爐後依然差距不大嗎？
◆專案的主要風險可被克服嗎？
◆使用者與開發人員都能夠同意使用者介面的細節雛形佈置嗎？
◆使用說明/使用需求規格是否完整而穩定，足以支援更進一步的開發工作？
◆軟體開發計劃是否完整，並適合進行更進一步的開發工作？
◆完成專案所需的預估成本為多少？
◆完成專案所需的時間安排如何？

在專案開頭10%～20%的完成部分應該足以解答這些問題，而且這些問題的答案應該足

以讓客戶或上層主管決定是否要繼續撥款進行專案的後面階段。
[@more@]