原文: 11 Laws of Software Estimation for Complex Work
作者: Maarten Dalmijn
我孤伶伶地坐在會議室，等著經理進來，心裡七上八下。我被首席產品官（ CPO ）臨時叫去開會。他說會議很緊急、很重要，要我立刻放下手邊工作。
我做產品負責人五個月了，七個月的合約快到期，我不禁擔心起自己的去留。
終於，門開了，他笑咪咪地走進來，我的緊張感瞬間消失。我還記得他說：「咱們公司剛接到史上最大咖的案子！有個刺激的新專案需要你來負責。」
聽到「刺激」和「新」這兩個字，我警鈴大作，心想：「代誌絕對不單純！」
他說：「為了成交，我們跟客戶掛保證，會在 SaaS 產品裡做一些客製化開發。我相信你一定可以準時完成這個關鍵功能，順利簽約。」
啊！陷阱果然在這，我想。
最後，他丟下一句經典名言：「安啦！他們要的功能很簡單啦！」
原來咱們的 CTO 和 CPO 覺得客戶的要求很簡單、很好做，對其他客戶也有幫助。我收到合約裡列出的七個重點，要在 12 週內完成。我沒參與估算，團隊也沒參與。除了這七點，我根本不知道要做什麼。
我馬上開始工作。跟一位資深工程師聊了幾分鐘後，我感到大難臨頭：這鐵定做不完！我很驚訝公司竟然承諾做不到的事。只要隨便問一個工程師就知道根本不可能。高層根本沒問過團隊，就自己用水晶球算時間，然後把這個不可能的任務丟給我們。
現在，要在這麼短的時間內完成，變成我們的問題了。我跟經理說這根本是天方夜譚，他卻回我：「你想得太複雜了啦！簡單一點就好。」
The fortune-telling approach used by management to come up with estimates illustrated by the fantastic Francisco Carle for this article
荒謬的估算從一開始就註定失敗
這七個重點需要十個團隊跨部門合作開發新功能，根本不可能在期限內完成。
光第一個重點就要花兩個月。之後雖然比較好掌握進度，但我敢保證，絕對不可能在 12 週內完成。工作量太大，團隊也太多。更扯的是，估算錯誤不是我的問題，但現在變成我的責任了。
那些搞出這齣爛戲的人只叫我「自己想辦法」、「給我弄出來」。我對合約裡的七個重點有很多疑問，得到的答案卻是：「我沒空理你，你自己看著辦。」
真是的，事情已經夠難了！
我跟客戶第一次開會就老實說做不完。我提議，會提早完成第一個重點，並且積極和他們合作，把他們的回饋納入後續開發，其他部分可能會比較晚完成，等第一個重點完成後，我才能比較精確地評估時間。
還好客戶答應了，雖然他們完全可以照合約走。最後，整個專案花了一年多才完成。還好我們跟客戶保持密切合作，也把他們的期待管理好，所以客戶還算滿意。
我們要怎麼避免這種痛苦的狀況？為什麼估算常常不準？我們要怎麼提高估算的準確度？我們要怎麼把這個必要之惡的傷害降到最低？
開發軟體產品十幾年來，我把我的經驗整理成 11 條軟體估算法則，可以幫助你面對複雜工作，以及軟體估算的複雜現實。
1. 不管估算多準，實際工作時間都一樣
我問你：「這罐子裡有幾個一塊錢？」
你大概猜不準。你甚至不知道罐子有多高。但你猜的數字不會影響罐子裡實際的硬幣數量。現實不會因為你的猜測而改變。
估算專案時程也是一樣的道理。功能開發需要多少時間就是多少時間，跟你的估算無關。是因為我們對時程的期待，才會覺得專案延遲。
2. 估算永遠不可能完全可靠
估算只是猜測。資訊不足的情況下做的預測。處理複雜工作時，我們都知道資訊不足。我們的資訊和理解有限，估得準只是運氣好，就像你光看照片就能猜中罐子裡的硬幣數量一樣。
期望估算很準，就像看茶葉算命一樣。沒有任何資訊，你根本沒辦法預測未來。
所以，不要相信估算。估算是根據你當下掌握的資訊做的，而這些資訊通常不足以讓你對複雜工作做出明確的結論。
不要相信估算，要知道它反映的是你當下的理解，通常是不準確的。但至少是個開始，總比沒有好。
3. 把估算強加在別人身上是自找麻煩
沒有什麼比逼團隊照不準的估算做事更讓人賭爛。估算常常不準，團隊會把氣出在做估算的人身上。
如果你想要團隊配合、做出比較準的估算，就讓實際做事的人自己估。這樣就算估不準，團隊也只能怪自己。
把估算丟給別人，只會造成災難，大家互相指責。
4. 專案快結束時，估算比較準，但也最沒用
專案初期，你掌握的資訊最少，估算也最不準。但這時候你最想知道專案需要多少心力，因為你還可以及時停損。
隨著專案進行，你會更了解狀況，估算也會越來越準。但專案快結束時，估算的準確度已經不重要了。而且因為已經投入這麼多時間和資源，公司不太可能喊停。
但不要被騙了。即使快做完了，還是有可能會冒出一些問題，毀掉整個專案。在軟體開發中，小問題也可能造成很大的影響。
5. 你越擔心估算，就表示你有更重要的事要擔心
估算只是個幌子。很容易讓人分心，以為準確的估算和準時交件最重要。但實際工作時間就是那麼長，跟你的估算無關。
當團隊努力趕上水晶球算出來的不切實際的時程時，就會開始產生隧道效應。就像沙漠中的海市蜃樓，大家只看到眼前的期限。所有討論都圍繞著「怎麼在期限內完成？」，而「品質夠好嗎？」被擺一邊，「怎麼加快速度？」變成最重要的事。
一直執著於「什麼時候可以完成？」只會讓你忽略真正重要的價值交付。
6. 你越不會寫程式，估算就越不準。你越會寫程式，估算頂多普普通通
不管你怎麼做，估算都不可能很準。能不能準確估算跟能不能做出好軟體沒什麼關係。比較厲害的團隊通常估得比較準，但再怎麼準，也不可能完全準確。
就像氣象預報一樣，超過一個禮拜就不準了。軟體開發團隊的估算能力也有極限。
不管你怎麼做，都不可能保證估算很準，也不可能保證準時交件。
7. 估算最大的價值不是估算本身，而是確認大家的理解有沒有共識
估算結果不一樣，通常表示大家對要做的事情理解不同。
透過討論，才能找出彼此認知上的差異。估算最大的價值是建立共識，而不是估算的結果，因為結果常常不準。
8. 保持簡單是提高估算準確度的最佳方法
減少複雜性和不確定性，不管是做事之前或過程中，都是提高估算準確度的最佳方法。保持簡單，才能避免估算失控。但要注意，如果事情過於簡化，也會產生問題。
9. 做比說更能提高估算的準確度
開始做事之前，大家喜歡討論、分析、設計、辯論、做一堆研究，想要消除所有不確定性和風險。但不管你怎麼做，你還是受限於你事先知道的資訊。一直根據不完整的資訊做推論，效果會越來越差。
實際去做，才能更快發現真正重要的問題。
用你已知的去發現你不知道的。
光有理論不夠，還要有實務經驗。
10. 把所有工作拆解到最細，只是讓你更晚交件
為了讓估算更準，我們常常開一堆會，把所有工作拆解到最細。但這樣反而浪費了寶貴的時間，這些時間本來可以拿來做事，找出真正重要的問題。而且這些精密的計畫脫離現實，只會越做越慢。
計畫趕不上變化，硬要照著計畫走是很危險的。最好一開始就做簡單一點的計畫，比較容易調整。你把所有工作拆解到最細，只是讓你更清楚專案會延遲多久而已。
11. 懲罰估算不準，就像處罰小孩不懂的事
有些公司覺得，團隊越成熟、越厲害，估算就會越準。所以估不準的團隊就是爛團隊。
懲罰團隊估不準，是在懲罰他們無法控制的事情。就像處罰小孩不懂的事情一樣。這是一種霸凌，只會造成恐慌和焦慮，沒有任何好處。
別再幻想你可以做出準確的估算
總之，以下是「複雜工作軟體估算的 11 條法則」：
不管估算多準，實際工作時間都一樣。
估算永遠不可能完全可靠。
把估算強加在別人身上是自找麻煩。
專案快結束時，估算比較準，但也最沒用。
你越擔心估算，就表示你有更重要的事要擔心。
你越不會寫程式，估算就越不準。你越會寫程式，估算頂多普普通通。
估算最大的價值不是估算本身，而是確認大家的理解有沒有共識。
保持簡單是提高估算準確度的最佳方法。
做比說更能提高估算的準確度。
把所有工作拆解到最細，只是讓你更晚交件。
懲罰估算不準，就像處罰小孩不懂的事。
過去的表現不能保證未來的結果，尤其在軟體估算方面。 1943 年，美國一家賭場，紅色連贏 32 次。你很容易就會覺得有什麼規律，但這是典型的「賭徒謬誤」：
「沒辦法理解機率事件的獨立性，誤以為可以根據過去的結果預測未來的結果。」 — APA 字典定義
很多軟體團隊都犯了同樣的錯誤，我稱之為「複雜工作估算謬誤」：
「誤以為只要常常估算、大家一起討論很久，就可以做出準確的估算。」— Maarten Dalmijn 提出的複雜工作估算謬誤
不管你怎麼做，估算都不可能很準。不要再自欺欺人了。
問問自己：你真的需要精確預測事情何時完成嗎？如果你確定自己正盡全力做出有價值的東西，就算比預期慢一點又怎樣？那個預期本來就不準。
調整你的方向，應對突發狀況和不確定性，而不是抱怨你永遠無法預測和控制的風向。
