專案經理救進度的 3 項基本功：詳拆任務、精算時程、收斂待辦

「專案唯一不變的，就是它一定會變更！」台灣IBM 諮詢資深專案經理林憲哲解釋，客戶需求講不清楚、上周交辦的任務，下周又要改變，對於專案經理來說，這些都是家常便飯，他半開玩笑說「哪天不用更改，會感覺專案不正常。」

對於專案經理而言，一切都按計畫走是理想。因為，一旦發生意外，同仁可能為了趕上進度，草草做完，日後又要修改，陷入惡性循環；或者，需求增加太多，只能強迫團隊處理，最終導致專案失敗。

專案之所以會有各種意外，有 2 個主要原因。第一種是不清楚「必須完成什麼」；第二種是錯估時程。以打掃為例，第一種就是隨興地看到什麼收什麼，摺了衣服，倒了垃圾，才發現沒有掃廁所。第二種就是，以為一個上午可以收得完，結果花了 3 天。

善用工作分解結構，拆成待辦事項

如果單憑感覺、經驗列出待辦事項，很容易遺漏、忽略。《我懂了！專案管理》建議，可以採用工作分解結構（WBS，work breakdown structure），常見的方式有幾種：

以交付項目拆解：用「自行車開發專案」為例，想生產一台自行車，你必須擁有車體、變速系統、煞車、輪胎等零件，它們就形成第一層任務（別人要交付給你的項目）。之後，可以再往下細分，像是車體可分為車架、坐墊、踏板、車把。

以次專案拆解：如果專案規模龐大，每一項子任務彼此關聯性小，可以先分成「次專案」，再往下拆分。比如「高速鐵路」專案，可以先拆分成為車站站體、鐵軌工程、車體建置、營運系統等。下一層再根據地區細分，譬如「車站站體」可以分為台北、桃園、新竹。

以產品生命周期拆分：又稱流程分解結構（PBS，process breakdown structure），簡單來說，就是根據時間先後，依序排出任務。像是「軟體開發」專案，必須先「蒐集需求」，再進行「系統分析和設計」，之後才能「撰寫程式」「測試上線」。

工作分解沒有規定一定要拆成幾層或幾項，《學會專案管理的 12 堂課》提醒，原則上愈細緻，愈不會有誤解，但展開本身也要花時間，專案經理須從中權衡。《SCRUM 敏捷產品管理》指出，分解完項目，最好與團隊成員討論，確認工作量可行。

需求明確的專案，細分項目後再加總時間

至於時程估算，《學會專案管理的 12 堂課》建議 2 種方式，一是由上而下估算（top-down estimating）：如果公司曾做過類似專案，就可以根據它來推估時程。假設業界標準是一個人工作一個月（人月）能開發 16 個功能點，今天接到一軟體開發專案，根據過去的資料大約有 1600 功能點。專案時程就是 100（1600 / 16）人月，如果公司願意投入 5 位工程師，專案就能在 20 個月（100 / 5）完成。

之後，再根據 WBS 拆分的任務，估算每項任務的時間。比如「軟體開發專案（時間占比）」分為收集需求（15%）、系統設計（30%）、開發測試（50%）、安裝上線（5%），每項任務所需時間就很清楚，像是開發測試需要 10 個月。

由上而下估算，既快速又省成本，卻很粗略，由下而上估算（bottom-up estimating）優劣勢正好相反，估算精確，也比較花時間。簡單來說，就是利用 WBS 細分工作之後，算每項工作要花多少時間，再加總。以「收集需求」為例，可以分成問卷設計、蒐集問卷、文書處理、分析結果、撰寫報告等步驟，耗時都是 0.5 人時，加總是 2.5 個月。

林憲哲提醒，以上方式，只適合需求固定，變化不大的專案，像是建立人資系統；如果需求不明，比如數位轉型，由於市場還沒有先例，就得用「用戶故事點數」估算時程，比如以 T 恤尺寸（XS、S、M、L、XL）為任務難度分級。

《敏捷專案管理基礎知識與應用實務》指出，由於需求不清楚，估算誤差很大，所以估算時程最好用相對大小，像是用「費氏數列（即1、1、2、3、5、8、13、21…）」估算點數，由於每一個數字都是前 2 個數字的加總，代表距離愈遠的案子愈困難。例如，要爬到 4 棟樓的頂樓，要花多少時間？由於不確定建築的高度、老舊程度，以及自己的體力，因此把第 1 棟的分數假設為 1，第 2 棟是 3（1+2），第 3 棟是 5（2+3），第 4 棟是 8（3+5），時間愈靠後，分數愈高，難度愈高。

4 面向評估待辦清單，避免任務無限累加

如果出現意料之外的任務該怎麼辦？台灣敏捷協會理事林裕丞建議，採用「待辦清單」來管理專案需求，清單愈上方的任務愈重要，要先做；新增需求如果離主要目標太遠，就會安排在清單下方，最後可能會發現不做也沒差。

《SCRUM 敏捷產品管理》指出，可以從 4 個面向：價值、不確定性與風險、可發布性，以及相依關係，來建立待辦清單。

價值：該任務是不是產品上市的必要項目？不包含該項目，是否仍能達成預期效益？例如，蘋果（Apple）第一代手機訴求：流暢介面、行動上網和行動音樂，一上市就廣受歡迎。但你知道，一代蘋果是不能複製貼上的嗎？你不知道，因為這個功能沒那麼重要，所以可以列在產品清單最底部，甚至完全捨棄。

不確定性與風險、可發布性：專案的風險愈高，失敗機率愈大。風險代表不確定性，不確定性源自知識不足。因此，不確定性愈高的專案，優先度愈高，因為愈早做，就能愈早獲得新知識。Google 的第一版新聞應用，開發團隊不確定該按照日期或地點篩選新聞，最後乾脆都不做，先測試再說，結果有 300 人要求日期篩選，只有 3 人要求增添地點，答案自己浮現。

相依關係：簡而言之，就是任務與任務之間互有關聯。《學會專案管理的 12 堂課》建議，排定優先順序時，要注意 3 種關係，分別是前後關係（FS，finish to start），像是「粉刷壁面」完才能「貼壁紙」；同時進行（SS，start to start），比如「吃早餐」和「看新聞」；同時完成（FF，finish to finish），例如「每周運動 3 天」和「進行網球訓練」。

《SCRUM 敏捷產品管理》提醒，如果 2 個任務屬於先後或同時，可以考慮用不同方式分割。比如說，「身為使用者，我想寫文字訊息」和「身為使用者，我得寫 email。由於兩者都涉及文字處理，先處理哪一項，都能提升後一項的工作效率。不過，更好的方式是結合成「身為使用者，我想要輸入文字。」

總結來說，需求明確、固定，就套用 WBS，並由下往上計算時程；需求模糊、變動，就列出待辦清單，以用戶故事點數估算工作量。傳統專案管理和敏捷專案，並不是互斥的關係，清楚自己要什麼，它們就是互補的工具。