非常常見的例子

我們經常能聽到項目經理和開發人員之間類似于這樣的對話：

PM：“你能不能給我一個開發某某功能所需要的預估時間？”

程序員：“一個月”

PM：“一個月時間太長了，我們只有一周時間！”

程序員：“***三周”

PM：“我只能最多給你兩周時間”

程序員：“好吧，成交！”

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

結論截然不同的簡圖

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

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

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

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

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

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

預估后項目出現異常的原因之一

軟件項目中的混亂源于精確的預估。

你知道是什么原因造成一個軟件項目出現混亂的嗎？原因就是項目進度落后于計劃！我們將這種現象稱之為正反饋效應（不要望文生義，正的反饋并不都是好的）。

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

下面是高估的例子：

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

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

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

大多數軟件開發，項目總是落后于原定計劃。這樣團隊中的人就沒有時間偷懶。

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

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

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