專案計劃與日程表的悖論

筆者問過不少做軟體專案管理的人，問他們感覺最困惑的事情是什麼，大部分人的回答是“如何制定一個真正有意義的專案計劃”。

專案開始不久，客戶和老闆就會來要專案的計劃；而此時專案組還不清楚專案的規模等細節，自然也定不出具體的工期與日程表；被逼無奈之下，專案經理只好先編造一個計劃來應付了事。

這裡出現了一個悖論：專案初期是否需要制定一個計劃來指導專案後續工作的開展；如果需要，那麼在專案細節不清楚的情況下，是否可能制定出一個足夠準確的日程計劃；如果計劃本身不正確，那麼又如何指導專案的工作。

打破悖論的關鍵在於我們如何理解“計劃”本身。人們常常將計劃plan等同於詳細的日程表schedule，這是對計劃的一種狹隘理解。所謂計劃，指的是人們事先對未來要做什麼、以及如何做的一種約定，它並不一定要具體落實到日程表上。

工程專案的最初計劃，描述的是專案組選擇怎樣的工程方法來解決專案問題。具體到軟體專案計劃，其內容應當包括：專案組選定了什麼樣的開發生命週期模型（比如迭代模型），設定了幾個里程碑階段；準備採用什麼樣的軟體過程（比如UP統一軟體過程）來組織專案的開發活動；以及按照什麼順序來從事相關活動（比如是否在需求開發前先做業務建模）。總之，專案計劃實質上可以看作是標準的工程方法與過程在當前專案中的一次例項化。

專案組明確專案的性質並不需要太多時間，專案經理很快就能夠在計劃中，記錄下如何應用適合本專案性質的方法的決定，並定下較近時間（比如一週）內的日程安排；之後專案組遵照計劃中的方法來執行各項活動；當專案組對專案的瞭解程度足以支援精確估算專案規模、工作量時，才正式制定詳細的日程表，它規定了較長時間內（例如幾個月）的日程安排。也就是說，先決定怎麼做，然後才確定做的具體時間。

作為客戶和老闆，總是有一開始就想知道專案的工期和成本的衝動。這種心理雖然可以理解，但卻違背了自然規律。專案初期問專案組要專案計劃的真實目的，不是瞭解專案何時能夠結束，而是用來監督專案組是否選擇了正確的方法，專案是否在朝著正確的方向推進。我們必須清楚一件事情——時間搞錯了會使專案延期，但方法搞錯了卻可能使專案失敗。