專案總是延誤？因為你用錯排程方法了！ - Joel on Software系列

Joel在軟體開發上，總是有獨到的見解。本麵認為基本上他的概念，有下列幾個基石：

• 以人為本：找到對的人，好好照顧他們，通常一切就會對了 。
• 不自欺欺人：不訂定做不到事，包括功能、時程等。

這次要介紹的是：Evidence Based Scheduling，本麵翻為實際排程法，因為基於實際資料、作法實際、做出來的時程也實際（這也是最重要的一點）。

開頭Joel就說明，工程師都不喜歡定時程：第一、很難預估，第二、沒有人認為時程是真的。針對這兩個問題，Joel的公司發明了Evidence Based Scheduling (EBS)來解決這個問題。EBS的步驟如下（細節有興趣的朋友可以去看原文）：

1. 做出Work Breakdown Structure (WBS)：以小時為單位，把工作分成細項。每個工作最長不能超過16小時。時間太長的工作，代表你根本沒有去想到底這個工作要做多久。在你把工作分為細項的同時，你也在確定設計細節。
2. 追蹤花費時間：追蹤之前每個工作所花的時間，算出工程師預估的時間與實際花費時間的比例，當作未來預估的基礎。
3. 模擬未來：使用蒙特·卡羅方法，找出可能的專案完成時間範圍（重要觀念是，比較正常的預估得到的結果，應該是範圍，不是一個固定值）。
4. 管理專案活動：找出Critical Path啦，等等，依照實際狀態，調整你的時程。如果專案預估時程隨著時間愈來愈晚，You are in trouble。

另外有一些要注意的重點：

1. 由做事情的工程師預估時程。
2. 隨時解bug，把花的時間加到該工作花費時間裡。
3. 不要讓管理者跟工程師「橋」出更短的時程：菜鳥經理會任為短的時程可以激勵工程師加快腳步。根本是白痴。落後時程對士氣勢打擊，而非激勵，這道理很多台灣企業永遠都不懂。（或者他們裝不懂）。整天加班長期而言生產力並不會提昇，懂嗎？
4. 時程就像一箱木塊：如果箱子裝不下，你有兩種選擇：找個更大的箱子（時間拉長），或拿出一些木塊（減少功能）。你不可能把木塊變小（你可以欺騙自己那些木塊很小，但那終究沒有用）。時間不夠，就砍功能吧！天底下沒有非要不可的功能。Joel的一個經驗是：在Excel 5認為絕對必要，但被延後到Excel 6的功能，後來一個都沒做-因為都是些根本沒價值的功能。你的產品有比Excel好嗎？

Joel保證用EBS你可以準時下班。

本麵讀完之後的感想是：信任是台灣企業目前最缺乏的（還是說台灣社會？）。Joel提的這些方式，都是基於企業信任員工的基礎上。台灣企業看到這些方式，反應不外乎：

• 「要是工程師騙我，把時程估的很長怎辦？」：你怎麼會請到這種員工？或者說，為何你的員工要用這種方式保護自己？一定是他受過傷（被擠壓時程、加班加到天昏地暗）。歸咎起來，就是大家都不信任彼此。要改變這種文化，請從管理者做起。
• 「現在擠壓時程估計要做五個月，這種方式不是要做十個月？」：所以這功能應該哪時候有最好？今天嗎？如果一個功能應該今天就有，為何規劃者（經理、PM）不能在之前就規劃出來？所以其他人的無能要由工程師用加班來承擔摟？那你薪水要不要工程師幫你領呀？

無怪乎台灣人加班加的要死，員工效率在全世界排倒數（日本也是）。很多時候都在做虛工（好聽一點叫做調整策略方向，讚啦！）。天佑台灣！