軟體專案本來就複雜，而複雜的軟體專案若無細心的規劃就不可能成功。一個良好策劃過的專案會被有效控制著，其進度操控自如，且會照顧到參與專案進行者的福利。軟體專案本質上也是危險的，缺乏風險管理就不可能獲得成效。從頭保持跟專案的使用者聯絡，努力將產品維持在滿足客戶的要求之上，並盡全力把焦點放在找出專案關鍵問題的解決方法上。

小專案可以只靠著毅力與運氣而完成，中型和大型專案則需要更多系統化的做法。本文將概述一些讓中型專案達到成效的技巧。

規劃

許多技術工作者寧可直接做自己的工作而不想花時間規劃一下工作方向。許多技術主管缺乏足夠的技術訓練並且不相信自己可以規劃出改善專案的方式。由於兩邊都沒人對專案好好規劃，結果就是專案常常窘況百出。

沒有一套規劃方式是專案中最嚴重的錯誤之一。由於上一篇中描述的上下游效應，想在修正成本較低的上下游階段將問題解決掉，一套有效的規劃方式是必要的。一般專案約80%的時間花費在未經規劃的重複工作上。

軟體開發的成功歸功於讓所有錯誤變成一堆細心規劃過後的小錯誤，避免出現未經規劃的大錯誤。研究四種設計方式後，放棄其中三種，最多也不過是造成三個小錯誤而已。可是沒做好設計工作而必須把程式重寫三遍的結果，卻嚴重到可能造成三個大錯誤。由於在下游階段修正上游造成的錯誤比在上游階段就修正好問題要多花費50～200倍的代價，細心協調過的專案就有機會以1/200～1/50的代價將許多錯誤修正好。

專案中哪裡找得出時間來進行規劃？很簡單，把大部分專案花在未經規劃的重複動作上的時間中的一小段拿來用在專案初期的規劃上，避免之後將時間花費在高代價的重複動作上。儘管並非所有上游階段用去的時間都會確實省去下游階段該處理的麻煩，但是省下的麻煩還是很多。在上游階段質量保證的經驗法則是：用在進行技術檢閱等早期規劃工作上的一小時可以省下下游階段3～10小時的工作時數。從不同的觀點來看，一名開發人員每天花在專案要求規格或架構上檢查的時間一般會省下後一階段中3～10天的工作時數。[@more@]

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

相關文章