我們都有這樣的經驗：要開發一個東西，請工程師估算時間，大概要五天。結果過了一個禮拜，東西還沒出來。一問之下，碰到了原先完全沒有預期的情況，否則就是某個套件原來不能這樣用，必須要換一個，否則就是一個莫明的錯誤，找了一個下午還是不知道為什麼。久而久之，工程師開始習慣在回報的時間裡面灌水，預留空間給這些「未知數」，而我們也常常把他們給的時間乘以二，來得到最壞情況的數字。問題是這樣的方法之下，最後整個組織開始習慣用最龜的速度前進，因為估算精準、動作快，在這中間一點好處也沒有。更壞的情況，是叫九個女人去生一個小孩，那才是災難的開始。
為什麼軟體工程無法估算時間？
要了解這件事情發生的原因，你必須要先知道為什麼軟體工程是無法估算時間的。我以前常常喜歡用「常態分布」來解釋軟體工程時間的花費 — 上述的情況，讓大家慢慢從 Average 變成 (Average + 3 STD) 估算，最後平均浪費了 3 STD 的時間 — 不過這只是統計學上的解釋，並不是真正的「原因」。直到我前幾天看到這篇文章：「Why Can’t Developers Estimate Time?」，才給了我超大的一個領悟。(文章有點難，不過英文不錯的人，我鼓勵你們去讀讀。)
作者 Ashley Moran (愛許麗‧莫倫) 說：
我們無法預測軟體開發中每一個項目的時間，是因為這些工作的本質就是「創造新知識」。開發軟體的目的是創造「自動化的流程」，一但目標達到，自動化後的流程就可以重複的被執行，在可預測的時間裡面。所以一個軟體就像是「食譜」一樣，而電腦就是「廚師」，輸入的資料是「食材」，而輸出的資料是「晚餐」。
因此，我們在做的事情是讓未來從不可預測，變得可預測，讓大哥小弟、老爸老媽、只要想煮飯的，人人都可以當食神，給他三十分鐘，都可以弄出一鍋超級無敵海景佛跳牆。所以，「開發食譜」這件事情的本身，是一個創造新知識的過程，時間上當然很難預測。
如何管理
因此，軟體工程用硬體工程的模型去管理，從出發點就是錯誤。一個建築案是先有了「藍圖」，才去估算每個細項需要的時間。當我們在做的是藍圖本身，怎麼能夠沿用他們的模型？如果是這樣，一個創業團隊該如何「管理」開發的時間？
我的答案是你沒辦法 — 你怎麼能夠控制臭蟲什麼時候要出現？但是你可以管理「生產力」，也就是確認團隊總是在高效率的情況下工作，那最後你會得到的是 Average 的工作時間，比起前述 Average + 3STD 快上了 3 STD，這前後有可能就快了 2-3 倍。
而要管理「生產力」，一個現代化的軟體開發團隊，我認為有以下的幾個好工具可以用：
- Pair Programming (兩人小組) — 一個人寫程式常常會有盲點，兩個人一起則可以看到對方遺漏的地方。更重要的是兩個人都會從對方身上學到很多知識和技巧，彼此都會成長。而當兩個人都了解一組程式碼，日後的維護也有了兩個選擇，不會因為一個人請假、離職，這些 code 就變成孤兒。記得給他們兩個鍵盤，實務上這會比鍵盤移來移去有效率。
- Daily Stand-Up Meeting (每日早會) — 每天早上固定開一個快速早會，全部人都站著，每個人依序報告昨天的進度，碰到的問題，和溝通彼此程式間該如何傳遞資料。這讓團隊明確的知道彼此的進度，也省去很多溝通不良的麻煩。
- 高效率的工作環境 — 開放、明亮、舒適的工作環境，或許讓大家換上拖鞋，確認團隊成員們可以取得他們需要的飲料、食物，但是不會吃得過飽、或是喝下過多的咖啡因。當其中一個成員困惑時，確認有人可以幫助他。
- 隨時找得到使用者 — 代表「使用者」的那個人 (通常是 PM)，最好是使用者本身，必須要隨時在現場，幫團隊解釋開發上細節不明確的地方。
- 設定上線時間 — 雖然你沒辦法知道每一個子項目會花的時間，但是你可以設定一個上線的時間，然後所有的人通力合作在那個時間之前，盡可能做出一個可以推出的版本。當然，如果第一個版本推出時你不會覺得丟臉，那就是花了太多的時間。
以上，希望可以幫助你們重新思考軟體開發該如何做，也希望對你們正在做的網站、行動應用有幫助。(當然這不是完整的列表，歡迎大家提出你們喜歡用的工具。）
___
除了網誌，我每天都會在 Facebook 分享許多創業者應該關注的資訊，歡迎追蹤
(Image via purecaffeine@flickr under CC license)
