程式設計師軟體專案預估的寶貴經驗

我最近參加了一個關於軟體預估的課程。對於這種本質上就是非精確的科學，我一向都非常謹慎，因為我深信預估可以創造價值。在這個歷時兩個小時的課程中，我發現瞭如何提醒大家進入預算而不必過度分析和思考的方法。

非常常見的例子

我們經常能聽到專案經理和開發人員之間類似於這樣的對話：

PM：“你能不能給我一個開發某某功能所需要的預估時間？”
程式設計師：“一個月”
PM：“一個月時間太長了，我們只有一週時間！”
程式設計師：“最好三週”
PM：“我只能最多給你兩週時間”
程式設計師：“好吧，成交！”

呵呵！猜猜接下來是什麼情況？如果你在下決定之前能快速考慮一下預算與目標之間的差距，那你就不至於這樣草率，也不至於在接下來的時間裡焦頭爛額。

結論截然不同的簡圖

在課程中有這麼一張圖片，它強調了精確預估的重要性。我粗略地照著原圖重新畫了一張：

圖片表達的中心思想為，我們需要將精確預估作為目標。對此我不置可否。事實上，我想說的是，我們的預估永遠達不到100%的精確。

為什麼呢？因為預估本身就是一種並不精確的科學。雖然有很多很多方法（可能甚至比我們需要都要多）可以讓我們擅長估計，但是總會有一些不確定性。沒錯，100％精確自然是最好的，但是在實踐過程中，這是不可能的。

不僅如此，低估時間的成本也是不可承受之重。先看看例子：

• 專案可能會失敗（最壞的情況）。
• 不斷地通宵達旦
• 高壓和焦慮
• 專案可能會延遲
• 質量會受影響
• 成本增加
• 使用者表示不滿

有時候預估時間結果是非常重要的。因為如果你估高了，功能依然可以完成，其代價為耗費的時間多。但是如果你估低了時間，那麼可能指定功能你甚至就完成不了。

預估後專案出現異常的原因之一

軟體專案中的混亂源於精確的預估。

你知道是什麼原因造成一個軟體專案出現混亂的嗎？原因就是專案進度落後於計劃！我們將這種現象稱之為正反饋效應（不要望文生義，正的反饋並不都是好的）。

還有一個預估方法是給出一個範圍。這麼做的效益/成本我們暫時不考慮，下面是使用範圍估計最後卻發現低估的例子：

下面是高估的例子：

曲線下面的陰影部分代表需要付出的努力、成本和計劃進度，看上去明顯比上圖高估所需要的少得多。

當然100%的預估精準度自然是最為理想的，但是在實際操作中，其錯誤成本太高。

你的團隊是否需要常常加班熬夜？下面這句話是我在一篇文章中看到的，印象非常深刻：

大多數軟體開發，專案總是落後於原定計劃。這樣團隊中的人就沒有時間偷懶。

這種思想在我們這個行業非常普遍。我真心是想舉雙手雙腳反對！這種想法顯然是不公平不公正的。

因為很多開發人員在預估時，大多會有20％-30％樂觀餘度，換言之就是，開發人員普遍性會低估實際完成專案所需要的時間。這一點我深信不疑。

由此看來，精確的預估精度很有必要。但是結合這些簡圖，更重要的是，寧可高估啊！