敏捷管理、傳統專案管理差在哪？哪類專案不適合敏捷？|經理人

蘋果創辦人史蒂夫．賈伯斯（Steve Jobs）曾說：「如果只靠客戶主動告訴我，他們需要什麼，以此打造產品，等到產品完成時，客戶又會改要其他東西了。」

賈伯斯認為，客戶反覆無常，因為多數人並不真正清楚自己需要什麼，而這也可能成為專案團隊最大的惡夢。舉例來說，客戶或許會這樣描述自己的需求：「我想做一款年輕人喜歡的飲料。」

為何鎖定年輕人？為什麼選擇飲料這個產品？《SCRUM 敏捷產品管理》一書指出，這些可能都是客戶無法一開始就釐清的核心問題，而需求愈模糊，客戶對專案的要求也愈容易更動。

《我懂了！專案管理》將這種情形稱為「無頭雞專案」，意即專案像是被剁頭的雞隻，不知道方向、胡亂衝刺，直到力氣耗盡、血流不止才倒地斃命。書中指出，很多數專案的失敗都源自在初始階段時，沒有釐清客戶做專案的目的、建立對專案的正確願景。

不要接到需求就開規格，釐清深層想法再提方案

因此，主動問清楚客戶需求，是專案邁向成功的第一步。《完全圖解計畫力》作者、專案管理顧問芝本秀德指出，想在初次討論時，就摸清客戶真實需求，建議使用「抽象階梯」方法，將客戶提出的要求，由上往下分為需求、規格、指示 3 種層次。

階梯頂端的需求指的是「為何要做」、規格是「用何種手段滿足需求」，作業則是落實規格的詳細執行計畫、行動步驟。舉例來說，當對方請你規畫某間門市的宣傳活動時，先別急著制定活動計畫書，因為規畫宣傳活動，只達到抽象階梯中的規格層次，而擬定執行活動的計畫書，則屬於指示層次。

企業想辦宣傳活動，背後一定有個更深層的需求，可能是為了行銷新產品或提升品牌知名度。專案團隊必須掌握到需求層次，才能找到更能滿足客戶需求的方法，像與社群網紅聯名、舉辦貴賓限定的座談會，宣傳效果可能都比辦門市活動更能提升品牌知名度。

芝本指出，多數客戶之所以只提得出規格層次的要求，是因為上層的需求較為抽象，規格則相較好表達。像前述的門市活動，就比提升品牌知名度更好理解。芝本秀德認為，透過 4 個連續問題，能讓客戶更具體描繪抽象需求、協助對方從規格，推導至需求層次：「發生什麼狀況？」「這個狀況對我而言的問題是什麼？」「該用什麼方法解決這個問題？」「為什麼要用這個方法解決？」

若以前述例子解釋，「發生什麼狀況？」可能是品牌知名度不如同業，「對客戶而言的問題」則是銷售動能低落，因此客戶想到的解決方法是辦門市活動，此時專案團隊可用「為什麼要用此方法解決？」來確認客戶原先開出的規格跟需求間的適配性。

「電梯行銷」簡潔陳述專案願景，確立共識仍須測試、修正

在掌握客戶的真實需求後，《敏捷專案管理基礎知識與應用實務》一書建議專案團隊可用電梯行銷術，簡單複述客戶期待的解決方案，凝聚雙方對專案的共識、建立共同願景。

電梯行銷術是透過以下 6 句話、在坐一趟電梯的時間內，簡潔向客戶陳述該專案、產品如何滿足、解決需求：

1.「該專案是為某人/某事（目標客群、欲處理的問題）而做。」
2.「因為他們想要⋯⋯/造成⋯⋯問題。」
3.「所以提出 XXX 這個產品/解決方案。」
4.「這個產品/解決方案，提供⋯⋯等功能。」
5.「不像其他產品/解決方案，有⋯⋯缺點。」
6.「此產品/解決方案有對手沒有的特色。」

《SCRUM 敏捷產品管理》提醒，在凝聚專案或產品願景的同時，請謹記少即是多的原則，報告的專案特性、功能盡量濃縮在 6 點內，才能凝聚、激發客戶對這些功能的興趣。

《產品專案管理全書》指出，即便雙方對專案有穩固願景，但在落地、執行的過程中，仍可能因消費者行為改變、市場趨勢等外在因素，需要改變執行方向，才能抵達雙方原本預期的目的地。

產品陽春也無妨，用核心功能測試市場

《SCRUM 敏捷產品管理》建議透過打造最小可行性產品（MVP，minimum viable product），縮短專案執行期間、產品開發時間，提早讓產品進入市場，好頻繁測試、取得客戶與市場的回饋，這樣一來，如果客戶的需求更動，產品也能盡早修正，所冒風險與損失的成本都相對較低。

《精實創業》作者、知名創投顧問艾瑞克．萊斯（Eric Ries）指出，有時最小可行性產品甚至不用做出實際原型，也能測試產品符不符合客戶期待。像是在個人雲端共享服務 Dropbox，2008 年首度問世時，僅以 3 分鐘的影片向市場介紹、模擬產品功能，一夕間吸引7萬多名用戶排隊預訂。

但如果專案目標並非面向消費者市場的產品，也沒有消費、使用者回饋當作評價，專案團隊該如何替最小可行性產品，設定成功標準？《專案管理：玩一場從不確定到確定的遊戲》一書提醒，專案團隊在設定目標時應謹記「數字＋時間」原則。

無論設定任何指標，例如專案要提升產品多少良率，或替組織省下多少材料成本，都得加上期限。例如良率提升 5 個百分點是要在一年內還是一季內？如果太晚達到成效，就失去執行的意義。且在原指標上，設定更細緻的時間期限，例如專案內容是 3 個月內替某產品減少 20% 材料成本，拆分成每周該達到的進度，也有助隨時確認執行方向是否落後目標。

打點利害關係人，避免各方意見干擾執行

即便與客戶、團隊溝通好目標，但後續執行卻常遇到供應商或贊助商等利害關係人的意見加入，造成專案需求不斷增加。《學會專案管理的 12 堂課》指出，有這樣的狀況是因為組織內各部門的利益不一致。舉例來說，一項避免水庫淤積，而興建攔砂壩的專案，水利局會想要用最划算的成本興建完成，但當地村長，則會希望攔砂壩上頭增建行人陸橋、涼亭，當地居民才不會覺得工程破壞景觀，於是專案很容易因為多方干擾，需求膨脹，浪費許多資源。

此時除了透過利害關係人矩陣，平衡為達原本專案目標，需維繫的權力關係外，還可透過「目標與關鍵結果」（OKR，objectives and key results）的方式對標，讓專案不因閒雜人等的要求偏離計畫。

《產品專案管理全書》舉例，如果是一項設計 App 的專案，用戶體驗團隊在乎介面互動功能、工程部門則在乎程式編碼夠不夠安全，以避免駭客攻擊。這時專案領導者應聚集不同部門，溝通專案的頂層目標（objectives）為何，將原本各自在乎的指標，整合成從大目標拆分下來的關鍵結果（key results），協調不同職級、部門的利益。

「專案唯一不變的，就是它一定會變更！」台灣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，並由下往上計算時程；需求模糊、變動，就列出待辦清單，以用戶故事點數估算工作量。傳統專案管理和敏捷專案，並不是互斥的關係，清楚自己要什麼，它們就是互補的工具。

敏捷管理、傳統專案管理差在哪？哪類專案不適合敏捷？

市場多變、客戶善變！用「敏捷管理」回應明日的變局

專題主題 市場多變、客戶善變！用「敏捷管理」回應明日的變局