對於專案的時程預估，我常常碰到一個提問：
「Joe，我參與的專案因為過去從沒做過，所以很多工作的預估沒辦法精準。這樣排程不就沒意義了嗎？有什麼方法能提高工期的預估程度嗎？」

有做過工期預估的人，恐怕心裡都有想過類似問題吧？

但我得說，大家對於工期預估這檔事，常過度把重點放在「提升預估準確度」這部分了！但準確度其實沒有大家想像的這麼重要。

倒不是說準確不好，而是就真實狀況而言，我們對於「預估」能提升的信心程度其實是非常有限的。畢竟專案的特性就是獨特。你就算這次能提升預估，當下次的需求不同、客戶的類型不同、或是有任何新元素加入（如用新材料、或是用新的元件模組、用了過去沒合作過的供應商、有新人加入團隊、以及其他一千種原因），都會大幅地打亂你的預測能力。而且專案的工作很多，每一個工作的少量預估落差，累積起來最後整體的預估精準度「一定」是不佳的！

所以我一向的建議就是：「不要花太多心力想讓預估有很高的精準度。有50%的大致把握就夠了。因為既然我們都用『預估』這兩個中文字了，就代表其中有很高程度的部分是猜測。就算是找來專業技術人員來做 Educated Guess，別忘了那也還是Guess。」

有人看到這邊可能就會問：「如果預估就只是猜，那排程不就一定不準？我要一個不準的排程做甚麼呢？」

這倒是整個概念裏頭大家最該扭轉的地方：做時程預估的主要目的，是讓我們在專案面臨變動時，對於怎麼調整有一個比對的基礎。能精確當然很好，但不精確不表示就不能用。

不精準，是哪裡有用？

這概念是這樣的。假設你最近要去東京旅行，雖然過去從來沒去東京過，也對東京一無所知，但你還是可以做個簡單的旅行排程。

又假設你因為工作忙碌，能去玩的時間只有週末兩天。而這趟行程你又有好多地方想去。你可能最想去的是三個地方：淺草寺的雷門、皇居、還想去吃和牛燒肉。所以這計畫得「根據核心需求來安排時間」。

雖然你對於每個景點確切會逗留的時間毫無概念，但你還是可以做個簡單的排程：週六的中午到東京，下午去淺草寺、晚上去吃和牛燒肉，星期天早上去皇居、下午搭飛機回台北。

甚至要更妥當，你還可以拆解得更細。比方說週六12:30到東京，13:30希望搭上捷運，14:30到淺草寺，18:30去燒肉店排隊，21:30離開餐廳，22:00到旅館。

上面有幾個行程可以預估得很精準。比方說從機場搭捷運到淺草寺要多久，這透過Google Map以及交通行程的網站可以拉出明確時間；當然，也有些行程可能無法預估得很精確，比方說要去吃和牛燒肉的餐廳，是不能預約只能現場排隊。所以到底要排多久？這當然不可能事先知道。就算看了幾個別人的Blog，你發現平均排隊時間是一小時左右，可是真去了現場，當天或許來了比較多人、可能碰到下雨、可能剛好有團客，所以最後排了多久這必然是無法猜準的。唯一你能做的是，就是既然過去有人排過一小時，那你也預估（猜）可能要排一小時。排寬裕一些總是不會錯的。然後你又猜進去餐廳可能會吃兩小時，所以總共安排了1+2小時。至於淺草寺你壓根沒去過，你也完全不知道會待多久，但是離吃晚餐反正有四個小時，那就暫定四小時。
 
最後排程出來，可能類似下圖
 
（簡單的東京行程Day 1）

這樣的規劃確實很不精確。但不精確就沒用嗎？當然不會。

這個簡陋的計劃最少還能提供兩個價值。
1.提醒自己
2.應對變動

提醒自己不難理解。有這計劃在手，在旅行的過程中你將知道接下來會發生甚麼，並比對自己的狀況。比方說，出海關到底有沒有延遲？還是其實順利的提早了？轉車是否順利？後面的行程需不需要趕一下？

應對變動則是另一個更重要的目的。因為當你實際在現場 （專案執行時），你突然發現淺草寺比想像的好玩，你想多待半個小時。照原來的計畫來看（下圖），如果要待久一點，後面的行程必然就會受到影響。

（上圖看出淺草寺如果多待半小時對後面有甚麼影響）
 
也因此，若你手上有這麼一個計劃，你就可以評估：
1. 我若逗留久一點，後面的行程會受到怎麼樣的影響？哪個可以趕一下？或是哪個可以根本刪除？
2. 如果後面行程更重要（若和牛燒肉絕對不能放棄！），那最後可能的結論是：不如放棄變動，別待太久，還是繼續照原本計畫吧！至於淺草寺這次沒看到的，我們就下次再來看（下一個版本再來優化)。
 
換言之，你手上先有一個計劃，碰到變化要評估時，才有決策的依據。但如果你毫無計畫，人就會傾向樂觀（沒關係啦，就多待久一點，只多花半小時嘛，後面不會有影響的啦啦啦～）。但過度的樂觀，之後通常都會失望。很可能最後就是壓縮了一堆行程，或是結果根本沒吃到自己最想吃的和牛燒肉。如果還一群人去，那肯定是吵吵鬧鬧大家不開心。

事實上，專案也常常有吵吵鬧鬧的狀況不是嗎？常常就是因為我們彼此對於「變動可能造成的影響」有認知上的落差。以至於你犧牲了我的權利，或是我犧牲了你的權利。雖然當下「相忍為公司」，可是矛盾與不快，還是在這過程中逐漸累積。

而且，雖然這次淺草寺玩的不痛快，但最少我也學了個乖，下次如果還有去東京，而且還去淺草寺，那我得到的教訓是：下次可要安排更多的時間！日後計劃的可行性也會逐步提升。

最後，我把上面那個東京旅遊的排程改了幾個字，下面這張圖有沒有就很像一個專案了？

（實際專案中做的排程也是同樣概念，讓我們方便看到變化的影響）
 
雖然這個專案規劃看起來顯然很粗糙，只有少少的幾個工作。但最少你會在面對變動時，一樣能看到變動的影響、一樣可以協助你提早示警、可以思考怎麼因應變動、可以凝聚共識、可以視覺化的解釋，所以就算一個粗糙的計畫在手，還是可以大幅度的提升溝通效率！

此外，也可能有人看了這計劃會說：「Joe，我們專案也有個部份是要做研發。但研發的新技術從來沒做過，我哪裡知道研發要多久？」排程另一個價值在於，如果你們有一個明確的上線時間，那你可以把所有「過程中該有的工作」卡入這個時間段中。如此，你最少知道自己有多少研發時間。於是你可能得從最重要的功能開始進行。至於產品研發若在過程中發現需要的時間超過預期，那你一樣也能示警、也能討論我們是不是做範疇上的調整、也能討論是不是延後上市時間、也能討論是不是能增加人力等等各種做法。但要有方案前，你要知道影響；而排程，就能收到這樣的效果。

所以專案跟旅行一樣，就算是沒做過的事情，還是可以猜。猜了，當碰到需要取捨時，你知道怎麼取捨。當取捨讓你覺得遺憾或是不舒服了，那下一次做類似的事情時，你也知道更合理的時間會是甚麼。你對於規劃的能力會逐步提升、對於取捨的能力會逐步提升、對於解釋給別人聽的能力會提升、對於安排緩衝的能力會提升、對於面對變動的能力也會提升。雖然起點是個不怎麼準確的預估，但誰都是這樣開始的、所有事業（包含旅遊）的計畫也是這樣開始的。

Photo by Louis Hansel on Unsplash