軟體開發有個長久以來令人詬病的問題：開發時間總是估不準。
不管怎麼估計，最後好像還是會發生意想不到的狀況，導致開發時程 Delay，PM 只能忍弄砍需求，跟老闆賠不是；或是為了趕上死線，逼工程師加班。
既然估時間一點都不可靠，那不如就不要估了吧？當然是不行呀，主管或客戶還是會需要一個數字，團隊也需要這個數字來互相配合。
所以到底為什麼，軟體開發的工時這麼難以估計？以下根據我自身的經驗，來聊聊三個可能的原因和對應的改善方式：
導致估時不準的幾個原因
一、缺乏評估，魔鬼藏在細節裡
PM 希望在這個按鈕上加上一個功能，請工程師評估時間。
「沒問題，這個簡單，一下子就搞定！」工程師信誓旦旦地回覆。
然而就像鬼打牆一樣，搞了三天還卡在一個不明所以的地方。
狀況說明
軟體開發有時候就是這樣，表面上看起來很單純，但內部卻暗藏玄機。
像是前人留下的 Legacy Code，用了不為人知的作法，並且沒有留下任何技術文件，導致沒人知道過去發生什麼事，光是看懂這些程式碼就花了大量時間了。
以為只是換個燈座就可以解決的問題，結果拆開燈座發現裡面的電線錯綜複雜，根本不知道怎麼接的。
又或者，這個需求其實很複雜，牽一髮動全身，並不是一開始以為的簡單改動，實際往下細看，發現有其他東西也要一起處理。
誇張的一點來說，大概就像是電燈不亮，結果是電線根本沒接，從換燈泡的問題，進階成拉線路、配電的問題。
這樣的情況尤其容易發生在大型系統，大型系統通常歷史悠久，歷經多位工程師以及不同時代的做法，每個看起來類似的功能，可能用的是不同的技術，所以相當容易誤判。
解決方法
要改善這種問題的方法其實很簡單，只需要讓工程師在提出預估時間前，花一些時間了解一下實際的狀況。要了解目前系統的狀況，目前是用什麼方式做的，預計用什麼方式處理。
雖然需要多花一點時間評估，但總比在會議上毫無根據的喊出的時間，還要更來的可靠吧！
二、需求不明、時常變動，無法收斂
狀況說明
解決方法
三、缺乏標準作業流程
狀況說明
解決方法
還是估不准怎麼辦？
加上剛剛好的 Buffer
PM 或工程師不可以為了讓專案永遠不會超時，而加上了過頭的 Buffer。
工程師估三天，那就是五天的意思；工程師估兩周，那可能至少要一個月。
但如果工程師估一天，PM 抓五天，那就有點過頭了。
那怎麼辦？有沒有一個準則可以依循？
坦白講，大部分時候還是要依照經驗來判斷要加上多少 Buffer，但有一個主要的原則可以依循：
狀況越不明朗的，Buffer 要抓越大。
什麼叫做狀況不明朗？
以 PM 角度來看，例如，你可能剛加入一個團隊，不了解團隊的狀況。例如你可能在製作新產品，這個新產品很顯然再過不久的將來，需求一定會變更。又例如，這個專案過於龐大，有太多團隊參與其中，很難控制所有人。
以工程師的角度來看，也是同樣的，不熟悉的系統，有可能發生預期外的狀況。不熟悉的團隊成員，溝通磨合可能會出問題。一個全新的專案，一開始規劃的時候可能會漏掉一些部分。
簡單來說，專案過程中，有越多沒辦法精準控制的部分，就是需要預留一點空間來處理的部分。