可以計劃、策劃、分割、折疊、旋轉和扭曲一個項目無數個小時，但你仍然不知道在實際編寫代碼時會遇到的困難。

本篇文章，我將會表達一些略主觀的意見：

對于任何具有重要意義的軟件項目，準確預估是不可能的。

現在，你們中有很多人讀到這句話會認為我瘋了。也許我確實瘋了，但總得有人說出我們都知道卻不愿承認的事實。

關于如何更好地預估軟件項目，市面上已經有很多書討論過，在預估軟件項目時也一定舉行了很多會議，購買了不少時間的咨詢，寫了很多博客帖子。我明白，我們都在努力工作，盡最大努力，試圖安撫那些想知道新功能何時準備好的老板。我們總是根據會議日期而不是軟件實際準備好的時間來設定截止日期。

但實際情況是，我們根本做不到。好吧，我們相信我們可以做到——實際上，我們一直在這樣做——但我們做得并不好。換句話說，我們的預估總是有或多或少的偏差。

我的意思是，我們不斷地花錢參加研討會，閱讀博客和書籍。我們請來高薪的顧問，他們表現得好像自己知道自己在說什么。但這項工作從未變得更好。我們在這件事上很糟糕，卻總是認為我們可以改進，下一個流行趨勢真的會是靈丹妙藥。但我們不愿承認我們所知道的真相：我們根本無法對軟件項目進行非常有信心的估算。

我們都做過這樣的項目，我們認為需要一定的時間，但最終卻花了兩倍或三倍的時間。你可能參與過一個項目，它比預期提前了一半的時間完成。但很少有項目能在原始估算的緊密窗口內完成。然后，當我們應用霍夫斯塔特定律（“它總是比你預期的要長，即使你考慮到霍夫斯塔特定律”）并將估算時間加倍時，往往最后預估時間還是有偏差。

這種情況發(fā)生的原因有幾個。最突出的，我認為也是大多數人最難接受的，是每個軟件項目都是獨特的，它有自己長長的“未知的未知”清單。你可以計劃、策劃、分割、折疊、旋轉和扭曲一個項目無數個小時，但你仍然不知道在實際編寫代碼時會遇到的困難。一些你認為具有挑戰(zhàn)性的事情最終可能很容易解決。但大多數時候，你會嚴重低估項目某個特定方面所帶來的挑戰(zhàn)。

當然，這種情況發(fā)生的原因是，大部分的軟件經理總是相信所走的路徑將是一條平坦、筆直的高速公路，一路上天氣都很好。而事實永遠不是這樣，需求會不斷變化，這些變化的需求不會使項目所用時間變短。人們會意外地請假，會受到其他項目或優(yōu)先事項的干擾，銷售部門需要這個小調整來完成一筆大交易。從開始到結束，永遠不會一帆風順。

我有一個擁有計算機工程學位的朋友，當我這么說時，他會非常生氣，但真正的問題是，軟件開發(fā)不是一門工程學科。相反，它是一個和充滿了變化的人類欲望相互作用的狀態(tài)，以及不斷變化的客戶需求、不科學的解決方案相互斗爭的過程。軟件開發(fā)是一個創(chuàng)造性的過程，而不是一個按部就班程序化的過程，創(chuàng)造性的努力不能被簡化為可知的步驟和可重復的系統。

當然，我知道這很難聽。企業(yè)——我的意思是客戶——不想聽到“嗯，我們真的不確定什么時候能為你準備好?！彼麄儠x擇客戶更愿意接受的話來與客戶溝通或承諾，即使那完全是胡說八道。公司必須賺錢，為了做到這一點，他們需要盡快產生價值，新功能的演示實際上確實需要在那個特定的會議上發(fā)生。

我們需要找到方法接受和適應這一特征。我這么說是因為我認為，作為一個行業(yè)，我們一直在尋找軟件預估的圣杯，而且我們永遠都會這樣做，雖然我們永遠不會弄清楚。直到我們接受這一點，我們將繼續(xù)掙扎和掙扎，并繼續(xù)告訴自己一些我們知道根本不是真的的事情。

我沒有解決方案，我懷疑甚至根本就沒有解決方案。接受這一點是解決問題的第一步，這個問題永遠也不會消失。

原文標題：Why we suck at estimating software projects

原文作者： Nick Hodges