頁面內容 Table of Contents
我為什麼要讀這本«超級專案管理»？
「為何計畫總是出錯？為何專案不是超支就是超時？」
專案超支超時似乎是個常態。為了避免成為那種亂承諾、亂壓日期的 PM，我上了許多課，做了很多努力，還是時常會遇到改時間改範圍，我累、大家也累，不管是哪個角色，總能說出一句：「和想得不一樣吶～」
專案管理書的解法是更多的進度報告、例行會議和 milestone；搞得整天都在開會寫文件，實際做事的時間被占用。總覺得哪裡不太對，一定有更好的方法吧。
推薦有一份寫著：
「他深知為什麼大型專案會失敗──也知道為什麼偶爾會成功，整個閱讀體驗令人感到興味盎然。」
──捷爾德．蓋格瑞澤（Gerd Gigerenzer），《直覺思維》（Gut Feelings）作者
看到這句我就買了。我想知道，除了更多文件和會議，有沒有更簡單有效的方法，能讓專案按時完成。
«超級專案管理»這本書在說什麼？
«超級專案管理» 作者研究了上百個超大型專案，歸納出專案成功和失敗的特徵，並提出實際執行方法，而且不是更多的會議、文件或更細WBS！
書中反覆提到「慢思快行」這個概念。慢思是仔細的規劃，避免製作階段還改來改去；快行是縮短專案製作時間，避免意外。書中比喻製作階段像打開的窗戶，如果只打開一下，可能只會飛進蒼蠅蚊子之類的小東西，能輕鬆解決；如果開得太久，意外就難以避免，如跑入的黑天鵝，專案失敗機率記高得多了。
慢思不只是寫文件，而是包含以下三項：
- 觀察類似專案，預測適當的時間和金錢：過於樂觀的預估常導致專案延誤（或是故意報低時間和金錢要讓專案通過）；如果原本要做三年，那預估一年的那一刻起，專案就注定要 delay 大家要加班無法準時完成。書中提到好方法就是認清自己專案並非獨一無二，參考類似專案的時間和成本來當作預估錨點。如果大家都做三年，自己的專案幾乎就不可能在一年內完成，認清現實永遠是預估的第一步。
- 要使用、尊重過去的經驗：經驗非常重要且無價，要多使用有經驗的人、被驗證過的技術，並參考過去專案的經驗來吸取教訓。有經驗的人和技術，具備讓專案成功的實踐智慧，不用走在迷霧中。很多事情都是我們說的「眉角」，很難一個一個寫出來傳授，只有親身做過才會知道。
- 快速進行原型測試，確保所有事情都能執行：著名的例子就是雪梨歌劇院，當初設計圖紙上的圓弧殼形屋頂結構從未被實際驗證過能否蓋出來，歌劇院的工程就倉促開始。中間遇到困難時，才退回去更改設計。整個歌劇院原先計畫四年完工，最後花了 14 年、超支 1457%。快速進行原型測試，就是要盡快確保專案中所有關鍵部分都能夠執行，減少開工後產生未知問題再回頭修改設計的情況。
這些方法乍看之下都很常識：準確預測、套用過去經驗、快速測試等。然而，在實際執行專案時，時間、金錢和老闆的壓力一來，很容易落入「快思快行」，做到一半才發現錯誤，結果花上更多時間和金錢來修正。
這本書適合所有專案人員，書中的大量失敗例子可以作為寶貴的學習經驗。許多教訓都是我親身踩過雷才學到的。如果能提前知道這些坑在哪裡，就能避免自己踩進去，省下不少跌倒的痛苦。
能從別人的經驗中學到東西，何必自己跳下去撞得頭破血流呢？
我學到可以馬上應用的 3 件技巧
1. 如何用「參考群組」準確的預估時間和成本？
標準的預估時間和成本方法是：1. 定義功能範圍（scope），2. 拆解工作（WBS，work breakdown structure）3. 依照各個項目分開計算時間和成本 4. 加上一點緩衝時間和預算。然而，這套方法需要很多時間和背景知識才能準確計算，在實務上很難每次都被正確的實行。
曾經有一位點子很多的老闆，老是抓著我就問：「唉唉唉，UP，我有一個點子，這樣那樣一定能大賣。這樣的專案你要做多久，需要多少人。」如果每次都要拆 WBS 計算時間，老闆還沒被煩死我就先累死了。所以最終都和大家一樣：有經驗的憑經驗，沒經驗的憑感覺。然後大約整個專案 80% 都是憑感覺預估的哈哈哈。
書上提供一套精準預估時間和金錢的方法，叫做「參考群組預測」。是這樣運作的：
- 依照專案屬性的大分類，找出類似的專案。例如把軟體新增功能的，就拿之前或別的類似性質公司新增功能的專案來參考
- 收集幾個專案的數據，計算平均時間和成本。即使只有一個專案的數據，也可以參考其時間和成本。
- 得出的數據就是預估數據。
對，你會發現裡面只有拿「類似專案」的執行成果來預估，不管目前專案的 WBS。
為什麼這方法特別有用，且比傳統WBS加總方法更有效？
因為 WBS 是加總已知的事情，但專案最可怕的是未知事項帶來的變動。而參考群組預測使用來自真實世界的經驗數據，而非預測，不受心理或其他因素影響。其他專案已經踩過你可能會踩到的地雷，時間和成本已經考慮了那些未知事項。用這種方法預估時間是基於事實，而非理想。
這種方法的預估基於事實，而非理想，比個人體感加上樂觀偏誤的預估更準確。
在透過改善方法、提高預測準確度方面，運用參考群組是最重要的建議。
— 《快思慢想》
2. 只應用成熟的技術（老熟人很好）
有一個剛出社會的慘痛經驗，過了 10 幾年仍歷歷在目。
在第一份工作時，接到任務是製作一個後台報表系統，那時候公司內部有另外一位大老寫了個 PHP 框架讓我們使用。大老寫的當然比不上社群上維護的框架功能齊全，所以我就選了個社群維護但少人用的 PHP 框架叫做 Kohana。我覺得自己超新潮、很獨特，使用了一個更新更好用的框架來撰寫這個後台系統。
完成後，我連續和各大主管開了一個月的檢討會。開會是同一個問題：為什麼不用大老開發的，哪裡不好，新的哪裡好？你選的這個新的，比業界主流的 CodeIgniter 好用？
現在回頭看看，那時候確實是傻。我在想，那時候只是開會，大家還願意聽我說話；沒有臭罵或寫檢討書，算是便宜了。
這件事情犯了幾個錯誤：
- 弄出了一個只有我自己能維護的專案：因為 Kohana 太少人使用。對公司來說，沒有人可以接手就是個變數。
- 不用公司內部標準大老的框架、又不用業界標準 CodeIgniter：我心裡想的其實是「我就是想要跟別人不一樣！」但不能說出口。檢討時只能說 Kohana 這個好那個好，但提不出根本因素來說服主管老闆們這是個合理決定。對公司來說，新東西也被驗證過，那就不應該貿然使用。
現在我學乖了，要挑選系統、技術，只能挑主流的業界標準。有幾個好處：
- 事前可以略過冗長的工具比較：容易說服所有的人，例如這是 XXX 主流有 75% 專案都使用、其他公司比較過 X 個工具最後選這個
- 出事的時候，比較好過關。這是業界標準，如果它難用或爆雷，代表這業界暫時沒有更好更成熟的東西能用。大家只能摸摸鼻子接受現況。
- 最重要的是，執行時穩定：文件比較齊全、地雷比較少。和想像的一樣運作。因為很多人使用，通常已經排除了大部分常見問題，還有最佳實踐（Best Practice）可以直接套用。
在做專案過程中，最害怕的就是任何意料之外的事情。選一套成熟的業界主流工具或軟體，能把這種驚嚇降到最低，專案過程順暢比什麼都重要。
大型專案，不適合搞特殊。
大部分的大型專案不會獲得最先、最高最大或是什麼的好聽稱號，只是相對平凡的公路、軟硬體、活動等。人們不期待他們留下重大的文化里程碑，也不求天馬行空的驚人創意，但的確會期待這樣的專案在預算內準時完成。帶來預期中的效果，優良可靠、維持水準。 我們要運用現成的科技、雇用有經驗的人、仰賴可靠的人事物，可以的話不要賭、不要當第一個、不要追求專門為這一次而設計的特製版本。
— 《超級專案管理》
3. 堆樂高：想辦法找出專案中的模組
做新專案的時候，我最喜歡嘗試新技術了，一個用完再換另一個，用過的套件和框架是五花八門，Express.js, Koa.js, Backbone.js, Mobx, React.js。
當我成為跨區域技術主管後，這種習慣根本害死人。
公司跨了三個國家，有三個辦公室，要帶領這三個辦公室的團隊進行類似的工作。原本風土民情就已經不同，再用上不同的技術，那根本就是穀倉效應的超級推手。
有成功的經驗都很難複製到另外一個辦公室，變成各自為政；當發現有個作法好用時能節省大量時間，要套用到另外一個辦公室時候就發現，啊不對，底層技術要整個重頭來，太麻煩了要和好多人重新溝通、花上許多時間製作，想想還是算了吧。
後來有個成功的經驗，是在兩個辦公室推行了同樣快速製作網頁的流程（公司每月需更新和製作約 20 個活動網頁）。時間一久，發現大家用同一套流程、同一套程式碼真是太棒了：
- 新功能互補：當一個辦公室需要新功能，製作以後就能馬上分享給另外一邊。做一送一，超開心的。
- 教學文件統一：當寫系統教學文件的時候，可以直接提供給兩個辦公室同事查看。一邊有問題，補完以後，下次另外一個辦公室同樣的問題就能直接看文件。
- 開發統一：因為是同一套程式碼，我們乾脆把所有開發都交給同一個國家的開發團隊。省下許多溝通成本。開發團隊因為重複製作，變得超熟悉這套程式碼，省去那種「這是誰寫的爛程式碼」的哀嚎。
- 支援方案統一：因為是同一套流程，當有人請假，另一個國家的人能迅速接手。
- 疊代效率化：由於限制了版型，這讓版型微調和使用者經驗改進變得可能。原本有 20 多個網頁，修改小地方就會變得很沒勁又討厭。使用同一套版型後，團隊能針對版型打磨細部改進使用者流程，並立馬套用到兩個國家的所有網頁。
透過單一版型、同一套流程，應用到多個辦公室的網頁，不斷執行流程讓流程最佳化。單一版型也讓打磨網頁細部變得可能，每次改進都是所有網頁的改進。
現在我認為，能重複使用、不斷打磨的模組，比起一直嘗試新東西期待某一樣突然成功，更有效率且更有效果。
要盡量設計出能重複使用的工作流程，就能越做越順暢。
改變一切的不是重大行動,而是你每天生活中做的、最微小的事情。
– 《原子習慣》
結論：專案成功的關鍵在於減少意外
我們總會覺得，自己手上的專案是獨一無二，別人的經驗無法套用。結果根本不是，同樣領域的專案都非常類似。失敗的專案有共同的特徵，成功原因的也差不多。有時候我們會覺得某個專案進行得特別順利，那可能是不小心符合了成功專案的某些特徵，但自己不知道。
我看完本書以後的改變是：在面對重要專案時，不再一味追求最新、最大、最快的技術，而是更加注重前期規劃和持續改進。而其中重要的實際作法是：
- 前期做好準備工作
- 選用成熟技術
- 模組重複利用
書中一共有 11 項作法，不管你在什麼階段，總是有一兩項是能夠套用，增加專案成功機率的。
推薦給工程師、工程師主管和 PM：
- 對工程師：教你辨識出壞專案的特徵、早期改進或快逃啊。這包括那些憑直覺估時間的專案、追求第一最大最快的專案，或是沒有明確目標和範疇的專案。認識到這些問題，能幫助你在專案初期趕快提出建議，或者選擇離開一個注定失敗的專案。
- 對主管或 PM：在規劃專案時，如果能做好前期的事情，後面就會少很多驚嚇時刻，而且大家會喜歡。這些技巧包含前期的 MVP、只選成熟技術、想辦法讓元件重複、讓經驗重複等。
專案能順利完成，這才是最重要的。如果專案失敗，再多的新技術、再多的文件或程式碼都是白費工。如果能從別人的經驗便宜學習，幹嘛要自己跳下去壯得頭破血流親身學到經驗？
開始累，過程就不會太累；開始不累，過程就會很累。
— 專案管理：玩一場從不確定到確定的遊戲
延伸閱讀：
- 大人學«流程設計與跨部門溝通»心得 認真工作就會有好產出？你可能放錯重點了
- «QBQ！問題背後的問題» 如何問出好問題，做出更好的決定
- «哈佛這樣教談判力»心得 最適合工程師的談判入門書，即使不擅言詞也談出好結果
購書連結：
（用連結買書我可以收到一點點回饋，幫助我寫更多的文章～）
