你想去拜訪一個十年沒見的朋友。 但你這幾年從沒去過他現在住的地方，只知道是在宜蘭山區的某個地方，且你們約了第二天中午十二點吃午飯。

接下來你會怎麼做？
A. 先安心的睡到第二天十一點，等出門再想怎麼去。
B. 自己找路真麻煩，也別多想就包計程車去好了…
C. 出門前先找出到達宜蘭的幾個方法。 評估可行性、花的時間、難度，然後決定去的方法以及合適的出發時間。

我猜，大部分人會選擇C吧？

想的更全面的人，可能還會思考「哪條路可能塞車？」、「火車會不會更快更方便？」、「當天會不會刮風下雨？」、「地址會不會抄錯」、「對方會不會忘記」。 可能還會先用Google Map或是數位地圖之類的工具，計算幾條不同道路會花多少時間。

生活中的大小事往往都有超過一種的解決方式。但到底哪種最好？ 往往是要全盤思考後才能決定的。 以上面的情境為例，查出去幾種可以到達目的的方式，評估每種方式的風險與到達時間，才會做出一個決定。 都決定好後，可能還會把這計畫(路線)問問對方可行性，並做最後的確認。

很常識，不是嗎？

但不知道為何，用在工作上，很多人就會跳脫常識性的工作模式。

比方說，專案的成案，其實就也如同上面提到的概念一樣，其中絲毫沒有甚麼更了不起之處。 如果你能把這日常生活的概念活用在工作上，很多事情自然會順利起來。 有人說，公司做了一堆規定很討厭。 但若大家認真去理解那些規定，規定本身的目的不過就是希望確保上面這種常識性的思維能落實在工作中罷了。

不能理解嗎？ 那我們隨便模擬個情境吧！

比方說，CEO把你召進辦公室，跟你說：「我們接下來要啟動一個案子，希望在十二月底辦一場產品發表會。」

這句話輕描淡寫的跟「明天十二點一起吃飯吧」其實沒什麼太大差異，都是一個模糊的目的。 要達到或許不難，但都需要一些規劃。 專案的規劃跟開車去某地也差不多：「你列出所有要經過的路並計算每處的時間」；知道沿途的路程，大致就能算出花的時間。 反推，就知道何時該出發，或是原來預想的出發時間是否能達成。
 
  
(透過Google Map計算出的路徑與時間)

這種畫地圖的工作，在專案管理上也有，專門的術語叫做「排程」，英文是Scheduling。 目的跟用地圖軟體算路徑的原理是一樣的，就是為了「了解整個專案路程到底要花多少時間」，以及了解「是否能滿足一開始的需求期待」。

如上圖，這是個「策展案」很簡化的工作規劃。 其中列出了此專中的工作、各工作銜接的順序、以及相關時間。 資料都列出來後，讓我們知道專案做完的「路程」及該路程需要的時間；就如同用地圖軟體規劃出遊行程一樣。 唯一的差異只是把「中正路」、「中山路」換成如「設計」、「程式」、「開挖」、或是「建模」等各式各樣實際專案的工作。 但就概念上而言，所謂排程，就是把專案的地圖畫出來。 然後我們再來分析，這樣的地圖到底合不合理、以及是否能在期待的時限內完成。 (也就是前面提到的十二月底的目標)

這部分的概念應不難理解，事實上之前的文章也屢屢提到這概念。

但很多人還是一直會有誤解的一件事情：認為排程的結果是一個敲死了不能變的嚴苛產物。 也因為這假設，自然而然的產生一種說法：「計畫趕不上變化，變化趕不上老闆的一通電話」。 於是排斥做這類事情，認為所有的計畫不過只是應付老闆做做樣子就好。 以至於私底下，自己另外又有一個別的東西來記錄甚至管理時程。

這在我來看，是有點本末倒置的做法，也總讓我覺得可惜。

實務上而言，確實計畫趕不上變化。 我自己也從來沒碰過任何專案能完全如一開始想像的順利進行。 不管討論的再久、計畫的再周詳，總難保證之後不會出現甚麼想像不到的問題。 就如同前面講到開車拜訪朋友的案例，我可以想到提早出門、可以想到車上要帶備胎、千斤頂、跟水壺，但是若路上突然發生重大車禍、或是山崩地震這類災害時，我還是很可能會被困在半路的某處。 就算不用出現這些重大災害，多碰上幾個紅燈、塞車久一些，我也可能比預期花更多時間才達到目的地。

但你會因此就不規劃路徑嗎？

不，當然不會，怎麼樣你都還是會做些計畫不是嗎？ 事實上，任何規畫的「真正」目的就是在此。 唯有你曾想過要怎麼走，一旦中間有意外，你腦中才會清楚知道自己現在被困在哪裡、你原本棄置不用的第二方案、或是第三方案，這時候就或許能派上用場。 你就可以想說「那我若要轉去替代道路，有哪些選擇？」 「這些選擇會花多少時間？」「 我現在這時間若要轉，是否還來得及趕上十二點的約會？」「 那邊會不會也塞車？」 甚至你有GPS在車上的話，當場就能分析替代方案，並轉過去繼續往目標移動。

是，專案管理上，你的排程系統就該類似車上的GPS → 它不是讓你填寫開始完成時間的；相反的，它是應該被當成一個「模擬器」來使用。

一開始，你會分析專案需求，排出一個想像起來應該可行的Schedule。 再來你排程計算Schedule，然後分析這樣的做法、工作內容、以及工作時間是否真的能讓你如期完成。 如果不行，你嘗試著調整工法、調整資源投入量、調整工期、或是減少範疇，來看看是否能滿足時間以及成本的要求。

這就如出遊前上網找資料，選出最好的路線、然後模擬這樣開去要花多少時間，並看看是否能及時趕到一樣。 一切都準備好時，你可能會把路線畫在地圖上，之後開車時可以對照。 專案上也是一樣，當你排程且覺得應該可行時，你會把你的規畫定義成是所謂的「基線」(Baseline)，也就是如你GPS上預定要走的路線。

專案有時候甚至比開車出遊更複雜。 擬定好的Schedule，自己看起來好像完美無缺，可是專案不是一個人做，你需要團隊甚至外包一起協力完成。 所以定好的東西常常還需要跟「支援單位」來討論。 這時候才真正是模擬器發揮作用的時間。

舉例而言，你找了工程單位的主管來討論Schedule：

『你看，根據Schedule我九月時需要你們一個班的工程師支援場地的裝潢喔』

「下個月？ 下個月嗎！？ 欸… 這不行耶，下個月我們工程師都已經講好要支援老王的案子了。 我看看，這… 你有沒有可能延遲到十月才開始裝潢？」

『延遲一個月嗎？ 我模擬看看…』

當下你就能模擬此情境，模擬完成後你發現完成時間被往後推…

 

『這樣我就不行了啦！ 老闆跟我講是要十二月底好，要是你們十月才進場的話，這樣我會做到一月初。』(請看上圖最後一個工作的完成日期是1月7日)

對方或許因此回應：「不然這樣呢？ 我一樣十月初給你人，但是我讓你用兩個班的工程師。 這樣30天的工作我評估20天應該可以搞定。」

『唔，我再試試看…』，你當下又可以模擬一下…

排程出來後，你會發現：『唔.. 這樣看來會提早到12月23號完成。』

「這樣能符合你案子的需要，我人力調配也容易些。 應該是雙贏的方案吧？」

但這時你可能又想到：『還有辦法更快些嗎？ 七天的緩衝對我來說還是危險些…』

對方或許想想後又說：「唔，趕一些的話，兩個Team十八天應該有機會做完，但穩當的時間而言可能真的要20天。 不然你可以考慮找過去合作過的ABC公司，他們若是九月初有人力的話，或許就能提早完成？」

結果如何不知道，但上面大概就是一個正常Schedule談判的過程。 最後終究會有個結論，但Schedule會是專案各層面人物彼此協商下的某種妥協。 排程工具就在這過程中扮演一個好的模擬器，讓大家可以快速看到想像做法的影響，然後達成一個大家都能接受且可被執行的計畫。

這在專案進行中，其實也隨時發生著。 有人發現有工作漏掉要加入、有人生病沒人遞補、發生未預期的意外必須改變做法、機器壞了要先做另一部份的工作、以及各式各樣任何事情。 就如同開車到某一段時突然發現山崩過不去了。 你可讓自己手足無措，也可以倒車並讓GPS幫你模擬出來一條新路。

排程就是同樣的概念。 發生問題、發現進度不如預期、發現Schedule要調整、或是別人建議你不同做法，每一方案大家七嘴八舌都會說很好。 可是你怎麼證明哪個最好呢？ 就是即時在排程軟體上重新模擬，然後繼續借此談判、斡旋、並找出個能讓專案順利的做法。

這也是為何我一直跟人強調，當一個專案經理最基本要能培養的技術能力，就是要會排程，以及要能有個隨時能展現專案全貌的Schedule。 有這東西，才能真正Lead專案的進行，否則幾乎不可避免只會讓其他人牽者鼻子走的。

本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。