項目負責人必讀：軟體項目估算永遠不準怎麼辦？

• 2019 年 10 月 8 日
• 筆記

「 軟體的估算是世界難題。完成一個任務實際花費的時間總會超過計劃花費的時間。但是作為客戶、用戶或業務，他們需要我們提供估算，以便確定一個項目的預算和交付時間。一方面我們面對一個項目，裡面充滿著巨大的不確定性，另一方面客戶、用戶或業務需要確定性，這對矛盾如何破解？如果這對矛盾無法破解，是否可以轉移矛盾？」

01

—

軟體項目估算不準確的原因

摘自李笑來的《把時間當朋友》第二版第 54 頁：

錯誤估算任務所需時間，是最常見，也是最致命的錯誤。在時間領域有一個與墨菲定律同源、貌似悖論的侯世達法則值得牢記： 完成一個任務實際花費的時間總會超過計劃花費的時間，就算指定計劃的時候考慮到本法則，也不能避免這種情況的發生。 大家是不是有似曾相識的感覺。 為什麼人們總是錯誤估計完成任務所需要的時間呢？因為大多數人在執行任務之前忽略了一個重要的步驟，那就是分辨任務的屬性——它是熟悉還是陌生的？

有些任務是你所熟悉的，即以前曾經做過的。在這種情況下，正確估算時間是很容易的。 然而，有些任務是你陌生的，那麼在執行過程中就必然會遭遇各種所謂的「意外」。其實它們根本不是意外，只不過是因為你對任務不熟悉，它們才成了「意外」。

很不幸，軟體項目每次都在實現不同的目標、完成不同的東西，每次都是陌生的，充滿「意外」，所以無法準確估算所需要的時間。

02

—

對用戶來說，估算就是承諾

前面說了，軟體項目由於每次不重樣，估算無法準確。

但客戶、用戶並不會理會這些。他們的要求很簡單，我提了需求，你告訴我要多少錢、花多少時間，我覺得 OK ，你就去做。

對用戶來說，估算就是承諾。

但這樣的後果也是顯然易見的。

大家可以想像一下，在充滿各種意外的項目執行過程中，原來的估算很快就會失效。但是由於估算被當成了承諾，項目經理習慣做的肯定就是粉飾太平。

而這種事情並非項目經理會這樣做，項目經理也會一直過問 BA 、開發、測試等人員的進度，各角色也做過自己任務的估算，同樣會被當成承諾，被問到的時候，也會粉飾。

但紙終究包不住火，這樣下去項目一定會在最後時刻翻車，導致無法挽留的後果，所有干係方全盤皆輸。

這不是項目經理和交付團隊的無能，而是一種保護自己的應激反應。

訓練有素的項目經理會試圖及時管理估算不準確的問題，一旦發現有超預算或超時的苗頭、原定的範圍有變更，或者發現範圍假設有誤、發現了自己原來不知道的事情，就會啟動變更流程。

但在傳統項目管理中，這個流程非常重，相當於重新立項，項目組也必須暫停交付支援，進行重新估算。這種費時費力的事情肯定是不到萬不得已不做的。

03

—

限制未必是壞事

既然估算永遠不準，又會被當作承諾。所產生的後果一定錢少時間緊，這個死結能破嗎？

答案是肯定的，但我們需要一點創新的思維。有句話說的好，所謂創新，就是改變主要矛盾。

舉個例子，需求與資源，永遠是一對矛盾。面對無限的需求，一個思路是增加資源，招更多的人。但這也會極大地增加管理成本和難度，也無法保證人員素質和交付品質。另外一個思路是，把現有資源當作限制，倒逼用戶對需求進行有效的價值和優先順序排序，實現價值驅動交付，精耕細作，確保品質。這就改變了主要矛盾。

對於前文提到的問題，我們的思路一定不僅是提高估算的準確性，提高估算準確性可以在一定程度上緩解問題，但並不能完全解決問題。

估算是否精確，不應該成為一個考核點，因為這既不公平，也沒有意義。

有一天和同事吃飯，我們聊到愚公移山。一個有趣的結論是，由於愚公移山這個「項目」並沒有期限，因此它無所謂成功與失敗。所以，無限時間、無限資源並不代表能帶來成功。很多成功恰恰因為有限制條件。

阿波羅登月計劃，一個很重要的成功因素就是有一個明確的目標和不可改變的期限。對於複雜項目而言，嚴格的期限意味著取捨。

當年，美國總統肯尼迪對於登月任務提出的目標是：「在60年代結束之前，要把人送上月球，然後再安全地返回地球。」

有了這個清晰的目標和期限，在項目推進過程中，管理者們思考的角度就變成了某個考量是會保證進度還是會拖延進度。一些更高級的技術、更複雜的實驗，就算再有價值，如果沒法保證那個期限，就會被擱置。

比方說，當時登月計劃採用的燃料就是煤油、液態氫和液體氧，而不是更先進但未成熟、研發周期長的固體燃料。

（引自《邵恆頭條》第46期）

明確的期限和有限的資源，為設置優先順序提供了有力的依據。

1991年，李安準備拍攝電影《推手》時，預算只有區區300萬人民幣，作為新手的他專門請了獨立製片人來幫他控制預算、嚴控進度。在這種嚴格管理下，《推手》順利地在18天內完工，投資方開心，也一舉樹立了李安在電影界的地位。這個獨立製片人的作用，就是限制李安必須在預算範圍內，對天馬行空的想法進行取捨，確保進度與完成。

反觀早年卓別林和其他幾個著名導演，因為要擺脫好萊塢的製片人制度，一起創辦了一家獨立製片公司，裡面都是導演這樣的藝術家，沒有專業製片人，不受預算約束，完全按照創作意願來拍電影。

在這種「無拘無束」下，公司被一部叫《天堂之門》的電影製作搞垮了。該電影原始預算是700多美金，最終花了4400萬美金，超支六倍多，票房卻只有400萬美金。

（引自《羅輯思維》第775期）

可見，限制並非壞事。利用好限制，反而可以把資源集中到核心目標上，實現最大價值。

04

—

把估算的結果作為限制

我們來看看軟體項目估算到底確定了什麼？它確定了預算（包括所需要的資源）和期限。

傳統項目管理是以資源、期限和範圍作為鐵三角。理想模式是，這三者都不能變。出現意外時，範圍不能變，然後通過增加人手或加班、延期和犧牲品質來彌補。

我們知道所謂敏捷模式，或者價值驅動交付模式是，資源和期限不變，範圍可調，圍繞著項目的核心目標，對範圍進行持續地合理裁剪，讓最有價值的部分先上線，產生效益並獲得回饋，後續進行持續交付。

今年我們部門在預算上，也從過去的需求驅動型預算變成供應驅動型預算。

過去，只要業務部門有充足的預算，我們就照單全收，然後據此制定招聘計劃。結果是如果某一年業務部門特別有錢，IT部門規模就需要快速擴張，招聘任務艱巨，培訓也跟不上，同時要兼顧好幾個大型項目，應接不暇，一地雞毛。

今年，我們以現有的人員加上合理的人員規模增長作為預算，倒逼業務部門基於這有限的資源對項目進行取捨，確保我們能在有限的、高價值的項目上深耕細作。

05

—

實例：讓MVP先跑起來

最近有一個項目，核心系統是一個定時發送報表的系統。系統需要配置定時發送時間、頻率以及生成報表所需要的複雜參數。

過去，這些配置需要IT來做，每次配置都是一次正式發布，需要走標準的交付流程，業務覺得這樣太慢，他們要求我們做一個UI，把這個功能開放給他們，讓他們自己來維護，省卻繁瑣和冗長的交付流程。

為此，業務部門利用了一個特別預算來立項，因為這個特別預算是千載難逢的機會，過了這村沒那店。在立項時，除了上面提出的核心需求外，也順帶提了十幾個針對這個系統的其他需求。

結果這個項目僅需求就談了一年多，沒有什麼實質進展。後來這個燙手山芋來到了我手上。

我和對接的業務人員明確說，這個項目剩餘的預算已經不多了，而且我們的人手也很緊張，我們不會像以前那樣再花幾個月談那十幾個需求的設計文檔，然後花幾個月開發所有的需求，這樣做到明年年底也未必能上線。

我們要先談哪些需求是MVP（最小可用產品），然後先做MVP的設計、開發、測試和上線，剩下的需求等MVP上線後再說。而且MVP應該只解決核心痛點，也就是允許用戶自行配置的需求，不涵蓋任何其他非核心痛點的需求。

由於MVP相對簡單，範圍可控，我們可以承諾在今年內把MVP交付上線。這既能保證交付能在預算內完成，又保證了今年內這個期限可以把對方的核心痛點給解決了。

業務答應了這個約定。

這個項目剩餘不多的預算和時間，反而成了我們和用戶談判的有利籌碼。這裡博弈的重點是，不管對方提出了多少需求，核心痛點，也就是更快地完成報表定時發送配置，才是對方最急迫要解決的問題。在預算、時間和資源都非常緊張時，對方必須放棄不現實的期望，做出選擇。

06

—

總結

軟體項目的估算永遠不會準確，完成一個項目實際花費的時間總會超過計劃花費的時間。

我們不應該緊盯如何提高估算的準確性這個偽命題，而是轉換主要矛盾，把估算確定下來的預算（資源）和期限作為限制條件，圍繞著項目目標，管理用戶持續調整範圍，實現價值驅動交付，並通過持續交付不斷滿足核心痛點和獲取真實回饋。