日前與前來邀課的客戶進行課程對焦會議，與會人員有副執行長、承辦人資以及 IT 主管，涵蓋了高層決策主管與關鍵受訓對象，會議成員組成完整，人人謙沖樸實，顛覆了我對該組織原有的一些刻板印象。
副執行長首先說明其管理眾多專案時的痛點，接著
IT 主管說明其專案執行的實際做法與相關痛點，從上到下的觀點都表達得相當清晰，我把它們歸納如下。
- 團隊對專案的進度延誤不痛不癢。
- 缺乏掌握專案整體全局視野的人員。
- 各單位對自己的需求講不清楚、說不明白。
- 各單位立場迴異，需求經常互相衝突，專案執行單位無所適從。
- 即使需求互不衝突，也無人可以整合各方需求，理順工作流程（work-flow）。
這些痛點乍聽之下相當複雜，但在我看來，其根本原因與多數組織的專案管理經驗並無太大不同。
根據 IT 主管說法，IT 單位已自行實施敏捷式專案管理方法好幾年了，照理說，這個組織對於敏捷式專案管理的手法應該已經相當熟悉，可是不知道為什麼，卻還有這麼多的痛點，並且痛到下定決心尋求外部顧問的協助。
我想，客戶的組織不是缺了兩個重要角色，就是這兩個重要角色因某些因素（如組織結構設計）而無法發揮應有的功能。這兩個角色分別應執掌：（一）統籌協調一個產品或系統的所有相關需求並負完全成敗責任（二）領導相關人員如期完成一個產品或系統。
一、統籌協調一個產品或系統的所有相關需求並負完全成敗責任
一般而言，商業組織都需要不斷打造新產品或服務，以對外銷售，營利生存。然而，組織也往往需要打造不少的系統供內部使用，以提升組織營運績效，本文客戶案例即屬後者。
對外銷售的產品或服務，我們通常有產品經理的角色來統籌協調一切相關事宜，可是供內部使用的系統卻經常缺乏這樣的角色，正因為如此，內部用系統才更容易功能逐漸發散、複雜化，並且無人聞問。
舉個例子，去年財會單位的某用戶 A 向 IT 單位提出過系統需求，IT
單位派甲工程師照需求修改系統，今年同單位的某用戶 B 又向 IT
單位提出另一需求，IT 單位再派乙工程師照需求去修改系統，如此運作幾年下來，結果這個財會系統變得愈來愈難用。原因可能就在於，A 和 B 完全沒有協調討論過，甲和乙也在不同的時空去更改系統，可能也都沒有商量過。
您也許會問，IT 單位不是應該有系統分析師（System Analyst）的角色來統籌管理這些相關的需求和系統變更嗎？Well，這就得看組織是否有明確賦予系統分析師這樣的責任，以及系統分析師自己對一個系統的 ownership 而定了。
就我觀察，系統分析師多半只做到「把需求『翻譯』成工程人員聽得懂的語言」，以讓工程人員可以開工，而這裡的『翻譯』卻常缺乏「與既有使用者經驗完善融合」的完整一致性考量，這樣就容易造成原本良好的使用者經驗被一點一滴地侵蝕破壞，讓整個系統愈來愈沒有整體一致感，像隨意拼湊出來的東西。
那麼，到底誰應該扮演一個內部系統的產品經理角色呢？以財會系統為例，我認為，該系統的重度使用者最合適擔任此系統的產品經理，而非財會主管，只要主管能充分尊重並授權此人做決定即可。
這樣建議的理由是，重度使用者通常使用最廣泛的系統功能，也使用得最為頻繁，各種體驗相對深刻，而財會單位主管卻未必能達此境界。此外，坦白講，主管也未必有空或有意願去深入瞭解這麼多的旁枝細節，並及時給 IT 單位回饋。
這樣建議的理由是，重度使用者通常使用最廣泛的系統功能，也使用得最為頻繁，各種體驗相對深刻，而財會單位主管卻未必能達此境界。此外，坦白講，主管也未必有空或有意願去深入瞭解這麼多的旁枝細節，並及時給 IT 單位回饋。
此產品經理的角色，在敏捷式專案管理的做法，就相當於產品負責人（Product Owner）的角色。
二、領導相關人員如期完成一個產品或系統
據此客戶的說法，IT 部門內已經成立了一個專案管理小組，下轄三位專案經理，而專案經理的角色在敏捷式專案管理的做法裡就相當於敏捷大師（Scrum Master）的角色，這個部分初步看來沒什麼大問題，但有些專案經理和敏捷大師之間職責差異的細節，倒是可以再注意一下。
例如，在敏捷式專案管理做法下，向專案贊助人等級的上級主管，也就是副執行長，做進度報告的人應該是產品負責人，而不是敏捷大師，因為審查驗收開發團隊成果，並向客戶（副執行長）報告進度的就是產品負責人。
敏捷大師是一個「不斷想辦法提升開發團隊效能（包含排除團隊障礙）」的領導者角色，進度是由開發團隊自己承諾並承擔的，因為敏捷團隊應該事先已經得到了來自高層的高度自主運作授權。
關於工作流程（workflow）的設計，可能會牽涉到跨職能單位的溝通協調，也就是跨產品或跨系統的溝通協調，可以由系統分析師召集相關的產品負責人一起討論制定，這樣才能在保持系統完整性與一致性的前提之下，盡可能滿足各方的需求。
為什麼要花錢花時間上課？
網路上的確有很多 Scrum 敏捷式專案管理方法的相關資源可以參考，不過這些資訊不是瑣碎片段，就是以純軟體專案開發為觀點，對於非軟體開發背景的人來說，實在難以消化理解。
加上 Scrum 的原始設計極為精簡，以致於許多自學者，在不了解各種設計的背後原因之下，就匆匆導入，誤以為這樣就可以迅速看到成效，其實，這是對 Scrum 敏捷式專案管理方法的一大誤解。
本客戶在自行嘗試施行 Scrum 敏捷式專案管理方法多年，遭遇許多不明原因困境後，並未因此歸咎於方法本身，也未因此而放棄敏捷方法，反倒是開始深思自省，向外尋求專業顧問／講師與系統化的課程，以求精進，更上一層樓，這樣的學習態度讓我非常敬佩。相信，這個組織在專案管理上，很快就能夠大幅躍進。