（Photo by charlesdeluvio ，from Unsplash）

隨著 PM 解決的案子越多，交辦到手上的專案也就越來越棘手，因為主管們發現你是專案管理的箇中高手，於是那些陳年無法結束的、犧牲無數同仁的，或者負責人突然消失不見的專案，第一時間就會想到找你來處理。

在我的經驗中，多數延宕多年的專案都有一個共通點，那就是範疇過大或難以界定，造成後續經常性變更、專案成員缺乏共識等衍生問題，當問題一個接一個串起來的時候，想要找出根因對症下藥就變得更加困難，因為每一個環節每一項任務看起來都像是壞掉的零件一樣，卡住整個專案的運作。

範疇邊界／Roadmap

面對範疇交代不清楚的情況，越需要花更多時間去釐清關聯及劃定邊界。哪些是現階段該做的事？哪些必須與外單位協作？ 有了明確的定義之後，接著展開的任務才能與目標對焦。當然，界定範疇並不是一件容易的事，通常必須從「需求」開始著手，需求的來源可能是產品使用者，也可能是公司內部的期望（例如建立阻擋追隨者的技術門檻 ）。

某些較具規模的企業有設立使用者研究等相關單位或部門，可以透過質化或量化的方式來分析用戶需求，面向較廣，但所需的時間相對較長。若沒有足夠的時間與資源，至少可以藉由需求訪談、走廊測試（註1）來收集相關資訊。

確認需求後，還需要經過妥善分析，畢竟要滿足使用者所有需求並非容易的事，過度在意某些難解的議題反而會成為專案的絆腳石，PM 應帶領團隊辨識需求的急迫性與必要性，並依據資源、成本等面向評估最適當的短、中、長期目標。越是歷經失敗的團隊越需要重新擬定 Roadmap ，讓團隊回到相同的軌道上。有了一致的 Roadmap 方向後，便可針對各階段範疇進行細部的定義，包含資料流、協作單位、利害關係人等，並確認哪些是模糊的邊界，哪些是可能的關鍵因素或人物。

所謂模糊邊界是指某些較難以定義的範疇，雖然知道這項任務存在，但所知的資訊還不足以展開更細的子任務，可能是尚未釐清權責單位的工作，也可能是還沒經過分析的新需求。這些通常就是專案潛藏的不安定因子，務必列入風險管理計畫當中，密切監控。

里程碑

前述已為範疇過大的專案進行需求分析以及 Roadmap 定義，此時我們應該對專案的「逐步完善」有了基本的理解，既然需求無法一次滿足，專案也無法一步登天，因此更需要有循序漸進的計畫作為輔助，並且為專案目標訂下分段達成的里程碑。

想像執行大型專案就像行駛在一條超長的公路上，里程碑猶如道路旁的數字指標，是一種不耗用專案時間的檢查標記  （我們並不會為了查看里程數字而刻意停下車），告訴我們現在位於公路的哪一個位置上，這樣我們才知道何時該休息補充體力，何時該加速衝刺。專案里程碑通常是某項活動或某幾個連貫性任務的完成時間，那些任務通常具有代表性，例如前述模糊邊界的釐清、關鍵要素取得等等。

時間內無法達到預期的里程時，我們通常會提升速度  （加班趕工）、變換路徑  （調整執行工法），如果是因為燃料沒了  （缺乏資源），就盡快尋找加油站補足，也就是說，當專案里程碑落後時，不需急著尋找戰犯、進行懲處，而是透過里程碑的檢核來幫助我們了解專案執行的成效，並適時修正做法，將專案拉回正軌。

完工區間／信心程度

範疇越大，越難以估算完工的時間，即便已經將大型任務切分成數個小任務或專案，但是在前期工作尚未完成之前，要估算後期的時間確實有點強人所難，這時候我們可以用「相對機率」的概念來替代。

所謂「相對機率」是估計專案可能的完成區間，例如圖中曲線內的範圍都是被認可的交付日期，它並不是個單一的時間點，而是幾周、幾月，甚至幾季的時間，依據專案的規模還有時間遠近而有差異，但我們可以推估信心度較高的時間點大約落在何處。隨著時間推進，未知的範疇與事件逐一被釐清之後，完成區間的範圍就會隨之縮減，直到可以取得一個明確的時限為止。

總結來說，專案是一個逐步完善的過程，初期範疇過大、定義不清的情況是十分常見的，PM 最需要做的並不是馬上立下完工承諾，而是在眾人都感到疑惑的當下，提出完整的管理計畫，讓團隊和主管們相信專案會走向正確的道路。

註1：走廊測試，是一種簡易的可用性測試，目的是藉由部分用戶的使用情況來評估產品是否滿足需求。「走廊」的含義係指受訪的用戶可以是辦公室走廊上經過的隨機人員，或街道上隨機選取的對象，相較於正式的可用性測試容易執行。