身為軟體工程師，肯定聽過上司或客戶問過不下數千遍這樣的問題：「請問軟體工程要花多久的時間？」如果很誠實的回覆他們：「該花多少時間就花多少時間。」，還會招來對方不放棄的逼問：「所以是多少時間！？至少給一個估計時間！」
說到這，你心中是不是一把火已經升起來了呢？但在怎麼怒火中燒，也別讓老板或客戶不開心，所以只好丟個隨意的數字好安撫老板或客戶的情緒，表面上好像給了個交代，老板和客戶也很滿意的離去，但軟體工程真的有這麼容易可以在預估的時間點內完成嗎？
- 軟體工程師為什麼無法估算時間？
為什麼軟體工程師無法估算時間？拿美國團結電影製片基金會會長 Michael Wolfe 舉的例子來解釋最貼切不過了，「假設我們要從舊金山徒步，從海岸線走到洛杉磯去拜訪位在紐波特海灘的朋友，首先先攤開地圖，沿海岸線畫出路徑，距離大約是 400 英哩這麼長，預估如果每天以 10 小時為單位，每小時走 4 英哩，一天下來就走了 40 英哩，只要 10 天就可以到達目的地了！
我們興高采烈的打電話給朋友，還預約禮拜六的晚餐，當天晚上 6 點我們包準能出現在門口。路線規劃好了，餐廳也訂了，雙方都已經迫不及待能順利會合！我們起了個大早，開始迎接這未知但充滿冒險的旅程，但…事情沒想像中簡單呀！這道海岸線拐彎足足就有一百萬條，也就是說原先預估的 400 英哩僅能勉強走過半月灣，還有多出來將近 100 英哩等著我們…。」
- 客戶以為我們故意打混，但我們其實是忙著在解決「所有」未知變數
此例子是否讓你稍為理解軟體工程師的處境呢？即便軟體工程師給出一個五天、兩個禮拜或一個月的估算時間，但誰也說不準是否會發生任何不在預期內的狀況，例如某個套件突然無法使用，或跳出讓人摸不著頭緒的 bug，久而久之軟體工程師只好選擇在時間內灌水，預先替「突發狀況」保留緩衝空間。
之所有會有此現象的發生，首先就要了解軟體工程最核心的本質是在「創造新知識」，此工作並沒有任何模組或現成程式可套用，而是需重頭思考如何利用手邊可用的工具來設計出新的東西，當然也有例外的狀況，如果軟體工程師曾經有足夠經驗涉足多項未知領域，而且跟之前做過的案子不謀而合，那麼軟體公程師也許有辦法能從經驗中推測完成的時間，但創造新知識並不如想像中這麼容易。
非開發工程師常誤認軟體工程師只要看一下架構，然後思考「應用 A、B 和 C，然後做 X、Y 和 Z，大約需要 N 個小時，或加減幾個鐘頭。」基本上的確是如此，但實際運作下來幾乎不可能，因為創造新知識的過程充滿未知的變數，當然也就更難以預測時間。
真要知道軟體工程師接到任務後腦袋瓜裡想什麼，絕對不會是 ABC 或 XYZ 這麼明確規劃出來，更典型的想法大概會是如此：
「如果我從草圖開始從頭設計整個控制器，我大概知道要怎麼做，但這需要花些時間…，有沒有比較委婉的駭客方式，讓我可以不用重寫 code 的情況下把這功能的輸入做更動？或者我是否可以來個猴子補丁 (monkey patch)（註：意指在不修改既有原始碼情況下，修改程式運作行為）？ 等等，也許有個 API 調用已經幾乎做到我想要的結果，喔！要是我透過非同步呼叫的方式外包給外部開放原始碼 (OS) 呢？」
但往往這樣的過程，軟體工程師也許可以很有自信的預估確切的時間，但重點是，光是要創造什麼樣的新知識恐怕就得先花上一小時到不知多久的時間。
不過通常上司或客戶一心想要透過預估時間來控管開發時間，然而預估軟體工程需要多少時間本身就是個錯誤，因為軟體工程所需的時間基本上是一個全新且未知的領域，但上司或客戶卻習慣性犯下以下兩種預估方式的錯誤：
九個工程師去生一個產品就能達成績效
有些上司或客戶認為，只要讓越多工程師進來投入越多時間，就能加快完成整個軟體工程和成效，這方法根本不可行，大家都聽過「九個女人去生一個小孩」的比喻吧，即便你在一個時程落後的軟體工程專案增加更多工程師，團隊同樣還要再花時間開會、確認 API、或找出到底 bug 是在哪個 code 裡，到最後還是要花九個月的時間生出一個小孩，更嚴重的是還有可能讓生產延後，甚至難產。
將大專案細分成小專案來預估時間
上司或客戶另一種想法則是他們設法透過專案的縝密度來提升估算的精確度，也就是說，只要把大型專案細分成 100 個或更多的小專案或小功能來執行，然後再要求每個專案都給出一個預估時間，但這根本可說是場災難，透過縝密度提升精確度並不會讓預估時間更準確，反而會反其道而行。
當預估軟體工程時，不應該期望預估值可以達到 100% 準確，因為這根本是天方夜譚，期望值應該是超估跟低估之間相互彌補，預估值才會有可能達到準確，然而若是越明確和縝密，越容易減少超估時間，對整體預估值反而造成傷害，更重要的是還有可能會造成預估疲勞。
- 軟體工程師並非以單一功能來預估時間，應該是以整個技術基礎去衡量
軟體工程師並非以單一功能來預估時間，工程師預估的點在於能讓這單一功能順利運作的技術基礎範圍，這是非常抽象的說法，舉一個比較實際能理解的例子，假設你正在架設一款需要登入 Web 服務 (Web Service) 的應用程式，你沒有一個獨立的服務端可以預估「用戶可以新增帳戶」、「帳戶信箱地址確認」、「用戶可以登入」、「用戶可以登出」，或「用戶可以重設密碼」等單一功能，那就以有一整個「用戶驗證」任務來進行預估，也許需要幾個小時？
也許不需要這麼多，如果以衣服尺寸來做比喻的話，S 號代表 1~3 小時、M 號代表 1~2 天和 L 號代表 1~ 幾周以上，根據使用的工具、技術負債（註：指漫無計劃的軟體架構或匆忙的軟體開發所引起的後果）、執行的工程師等種種原因，一週或幾周之後你應該就可以開始得知你大概需要多少時間，需要幾號的衣服尺寸，而不是假裝預估個大概的數字。
如果發現你的預估時間大多是 L 的衣服或是 XL 的衣服，你可能需要更進一步解構你的專案，如果你發現大部份都是 S 的衣服，意味你的專案太過分散，需要建構一下你的專案，如果你大部份都很平均有 S、M 和 L 的衣服，代表你已經有完整的架構了，你至少能夠得出最好的時間預估。
說來說去，軟體工程師口中常說的「該花多少時間就花多少時間」的背後，唯有實際去做才能得出個答案，但問題就是上司或客戶討厭這種模擬兩可的說法 ，因為他們已經根深蒂固的認為預估就是一切，因而迫使軟體工程師不得不隨易捏出個數字好給個交代，此反而無行中讓進度遠比預估的還要落後。
總歸而言，接受預估範圍根本是錯誤的，但也別期望上司或客戶從此不再繼續問這類的問題，身為軟體工程師，第一，就是確保上司或客戶不要再犯預估方式的錯誤，第二，不要用單一功能去衡量時間，而是以功能的整個技術基礎為單位，第三、切記永遠不要把估計時間當作承諾，你可以把它視為是對自己的任務所下的戰書，並找到能讓自己提升生產力的方式，設法處在一個高效率的環境下工作，如此一來也就能有效控制開發的時間，老闆開心，自己也能樂自其中。
（本文來源：TechCrunch；首圖來源：kennymatic, CC Licensed，未經授權請勿轉載，合作夥伴不在此限）
- 延伸閱讀
工程師寫 Code 的聰明省力法：Google 一次我可以寫 10 行程式碼
【超勵志】因為 Java，一位酒店少爺考上大學、變身工程師
給受委屈的 PM 們：不會程式也不代表你很蠢，直接和 RD 開口討論你的目的吧
誰說人人都能當 PM？缺乏邏輯關鍵能力拜託趁早轉行