非軟體產業也能掌握的敏捷式團隊工作術：4/24 公開班

主辦單位：大人學（識博管理顧問公司）

《敏捷方法的成功密技》系列文章總覽

課程滿意度總覽（部分紀錄）

【傳統式專案管理】實戰輔導簡章

緣由

為因應愈趨激烈的市場競爭，培養良好的專案管理能力已成為提升組織執行力與競爭優勢的重要手段之一。然而，單靠培訓課程並無法令組織的專案管理能力得以快速提升，主要原因如下，

1. 以 PMP 為名的培訓課程，目的在協助學員考取證照，而非解決專案管理實務問題。
2. 許多講師缺乏專案管理實務經驗，或觀念嚴重錯誤，無法對組織實務狀況給出有效建議。
3. 課程內容流於空泛、理論，缺乏實作演練，既無趣又艱澀，難以消化並落地應用。
4. 課堂時間有限，學員與講師無法充分深入探討具體實務細節。
5. 專案管理的議題相對廣泛而複雜，學員課後仍需持續耐心試誤應用，一段時間之後方可見效。

從 Netflix「王冠」影集看領導管理－權力與同理心

我上健身房的時候，都會用手機的 Spotify 邊聽音樂邊運動，由於我不是付費會員，所以 Spotify 會隨機強迫推薦一些非我播放清單的歌曲給我，不過，它推薦的歌還蠻合我胃口的，所以我也樂得「享受」這些優質又免費的強迫推薦服務。

（嗯~~免費服務做太好，竟反而讓用戶更不想花錢買付費服務，這是不是有些弔詭？如何區隔付費服務和免費服務，還真是個困難的藝術~~）

有一次，Spotify 推薦的一支音樂讓我聽得起雞皮疙瘩，於是我停下運動想看看這曲子的來歷，一看之下發現，原來它是 Netflix 原創影集「王冠」的主題音樂，這讓平常不太追劇的我，起了強烈的追劇慾望，所以我就~~付費訂閱了 Netflix（這算成功的異業合作行銷案例嗎？ XD）

「敏捷大師」可以怎麼生出來？

敏捷大師（Scrum Master）之所以稱為「大師」是有它的道理的，「大師」是那個能帶領團隊走對方向，並在敏捷路上愈走愈順的賢者、智者，絕非隨意指派，給個稱號就行的。

在《大錯特錯！敏捷大師不是團隊的助理或秘書》這篇文章中，我曾經概略說明了敏捷大師這個角色的職責、資格和等級，可是如果組織就是欠缺這樣的理想人選，那又該怎麼辦？有沒有什麼方法可以把「相對適任」的敏捷大師給生出來呢？

「老師，請問您要怎麼向我們保證課程的成效？」

前陣子一家做遊戲的企業客戶找上門，詢問一些關於敏捷課程與顧問輔導服務的細節，在一些相關中階主管都在場的對焦會議上，對方窗口最後提出了一個問題，「老師，想請教一下，您要怎麼保證，我們上完課之後會有成效？」

「喔~這沒問題啊！只要貴公司可以保證，完全按照我教的去落實執行，那就可以保證課程和輔導的成效。」

奇了！過了不久，又有另外一家做儲存設備的企業客戶找上門，同樣也是類似的狀況。這讓我動了寫這篇文章的念頭。

【報告技巧】實戰輔導簡章

緣由

「報告」是職場上下階層（或主僱關係）之間的重要溝通和管理工具，無論是書面或口頭，幾乎所有的職場工作者，都需要向上司、客戶或股東做定期／不定期的報告，且多數人也還同時需要審閱並聽取部屬或供應商的報告，因此，良好的報告技巧無疑是職場工作者最重要的基本功之一。

然而，身為主管（或客戶），許多人對「如何教導部屬（或要求供應商）做好報告」這件事感到困擾和迷惘，致使「報告」這個工具，在多數時候都無法發揮「有效協助掌握交辦任務（或專案）狀態」的重要功能。

此外，若部屬（或供應商）所提供的報告品質不佳，也極可能造成主管（或客戶）對任務（或專案）狀態的誤判，繼而導致任務（或專案）的失控，嚴重損害主管與部屬（或客戶與供應商）之間的互信，造成雙方關係緊張等諸多不利的影響。

Scrum 敏捷方法裡，渾然天成的九大風險管理把關設計

「老師，要管好專案的風險，您覺得是用傳統式的方法比較好，還是用敏捷式的方法比較好？」一位學員在課後向我這樣提問。

當下我還真楞了一下，倒不是因為我不會回答這個問題，而是自從教授敏捷相關課程這麼多年以來，這還是頭一遭有人問到這樣的議題。

先說我的結論，總體而言，我認為，敏捷方法比較技高一籌。

敏捷健檢：偽敏捷的三十大症狀，你的團隊或組織中了幾個？

教授 Scrum 敏捷方法課程多年以來，不論是在公開班上，或是在企業內部裡，不論是被運用在專案管理上，或是被應用在整體組織的改造上，我發現，不少團隊或組織在施行敏捷方法的時候，經常有意或無意地把一些敏捷方法的重要設計給省略掉，誤認為這樣就能省掉調整組織規章、組織結構和人員心態等的大量心力，仍可輕鬆獲致敏捷方法宣稱的巨大成效。

組織營運或專案管理出了問題，企業對外找專業講師或顧問來協助，是直接、有效且客觀的方法，本無可厚非，不過我得說，如同人生了病會去找醫生一樣，病人如果不照醫生指示去定期服藥治標，也不願意花力氣去運動調整體質來治本，那麼，病好不了，無法根治，也就怪不得醫生和處方了，對吧？

掌握敏捷方法之道，以利有效精準應用，高階主管你可以怎麼做？

敏捷方法表面上看起來相當精簡，只有些簡單的框架、流程，和原則，因此讓許多人誤以為，敏捷方法是一劑可讓專案神速完美完工的特效成藥，自己上藥房買來吃就能見效，然而事實上，卻一點也不是這麼回事。

敏捷雖如專案管理巧婦，無米無灶也難為炊

日前為一家規模龐大的組織進行敏捷式專案管理課程，課前一天傍晚，副執行長熱情晚宴款待，席間提及，某個老舊資訊系統更新專案，執行兩年以來延誤不斷，掌握不了可靠的結案日期，令他相當頭疼，不過在他的話語之間，我倒是感受不到絲毫的怪罪之意！

副執行長雖然熟稔傳統式專案管理手法，但卻謙沖承認自己是敏捷方法門外漢，在我向他簡略介紹完敏捷方法之後，副執行長略顯無奈地提出了這樣的疑惑，「聽說敏捷方法可以把專案做得又快又好（客戶／用戶滿意），可是我們 IT 團隊已經用敏捷方法做專案好幾年了，這個專案還是延誤成這樣，不僅開發人力資源卡死在那兒，使用單位也抱怨連連，到底問題會是出在哪裡呢…」

員工非轉職不可？老闆最後才知道？問題到底出在哪兒？

自擔任企業內訓講師和輔導案顧問以來，有緣接觸大量不同職務的職場工作者，學員的位階也涵蓋了董事長、執行長等最高主管到各類基層員工，也許是我分享的實務領導管理經驗讓一些人有了深刻共鳴，因此，每隔一陣子就會有人用 Line 或 Messenger 私訊我，想「請教」我對他們職涯發展上的看法和建議。

說「請教」，這實在是不敢當。別說我對這些當事人的學經歷背景和能力是一點也不了解，當事人公司的管理文化和營運狀況，我更是沒半點掌握，加上當事人往往會不自覺地隱匿關鍵資訊（這才是正常人），在沒見到面，看不見肢體語言的情況下，跟個陌生人對談短短幾十分鐘，能給出什麼客觀又有效的看法和建議呢？

為何敏捷式專案管理在我組織內效益普普，諸多問題依舊？

日前與前來邀課的客戶進行課程對焦會議，與會人員有副執行長、承辦人資以及 IT 主管，涵蓋了高層決策主管與關鍵受訓對象，會議成員組成完整，人人謙沖樸實，顛覆了我對該組織原有的一些刻板印象。

副執行長首先說明其管理眾多專案時的痛點，接著 IT 主管說明其專案執行的實際做法與相關痛點，從上到下的觀點都表達得相當清晰，我把它們歸納如下。

1. 團隊對專案的進度延誤不痛不癢。
2. 缺乏掌握專案整體全局視野的人員。
3. 各單位對自己的需求講不清楚、說不明白。
4. 各單位立場迴異，需求經常互相衝突，專案執行單位無所適從。
5. 即使需求互不衝突，也無人可以整合各方需求，理順工作流程（work-flow）。

這些痛點乍聽之下相當複雜，但在我看來，其根本原因與多數組織的專案管理經驗並無太大不同。

你不可不知，老闆和客戶砍你專案時間的四大理由！敏捷 Scrum Can Help！

曾經有學員向我提出這個問題，「老師，不管我們的專案時程評估得多有道理，老闆總是不分青紅皂白，就先砍掉 20% 的時間，我該怎麼辦啊？」

我聽過不少學員訴說這類的困擾，可是，我們回頭想一下，第一，為什麼會有不少的主管和客戶都這樣幾近無理取鬧地（至少從團隊的角度看是這樣的）壓縮專案的時程呢？第二，如果這就是短期無法改變的現實，那麼我們又能如何因應呢？尤其是，敏捷方法到底能不能幫上忙呢？

《EZ風險管控與向上管理》一日班簡章

敏捷專案管理模式下，開發團隊成員能不能動態進出專案？

日前在為某企業進行敏捷式專案管理的導入輔導時，有位同仁這樣問我，「老師，敏捷開發團隊的成員，從頭到尾都不能換人嗎？譬如，臨時加人進來，或有人完成工作後就離開，去做其他專案的事？」

「你為什麼會想在要這樣做呢？」

「因為有的人比較熟悉這個衝刺要做的任務，有的人比較熟悉下個衝刺的任務，這樣安排不是可以讓他們工作得更有效率嗎？」

關於這個問題，我會說，方法沒有絕對正確或錯誤，只有「適合」與「不適合」，或是「有效」和「無效」。

【33張圖秒懂OKR】推薦序

照片由采實文化提供

身為敏捷方法的講師和教練，我發現敏捷方法的許多做法和精神，與 OKR 都頗為神似，只不過敏捷方法多聚焦在短期的專案管理之上，而 OKR 則是聚焦在中長期的組織經營績效之上，兩種方法均一致推崇以下的做法：

1.        尊重個人想法，但更重視團隊合作。

2.        高層給方向，但授權由下而上制定執行決策，並給承諾。

3.        鼓勵盡早失敗，盡早改善調整，以靈活應變。

4.        鼓勵面對面形式的簡單有效溝通。

5.        計畫與施行狀態公開透明。

管理學本就是一門高深的藝術，沒有一體適用的萬靈丹，唯有具體實踐並不斷調校，才有可能練就一身好功夫。

本書以圖解方式介紹 OKR 的各種施行原則和背後的精神，是絕佳的參考手冊，可隨時快速複習，溫故知新，協助你調校你的 OKR 施行策略，以臻成功。

博客來連結：https://www.books.com.tw/products/0010855940

專案審查會（Project Review meeting），你不可不知的三大經典謬誤

「老師，你不知道，客戶真的很機車，一直在刁難我們…」

在一個 Project Review meeting 的中場休息時間，接任此事業群最高主管不久的 Tony（化名）這麼說著，聽起來似乎是在為團隊開脫並為專案的延誤緩頰。接著，本輔導案的推手，也是一位高階主管，Sherry（化名）竟也接著如此附和。

兩位高階主管都這樣反應，令我感到相當意外。顯然他們完全 buy-in 會議中團隊的說詞，沒有觀察到（還是刻意不觀察！？）團隊言行之間的矛盾與漏洞。

敏捷式專案管理的導入輔導，該怎麼找教練？

「老師，上課前，我以為 Scrum 很簡單，自己上網看就好了，根本沒必要來上課，今天上完課才知道，原來還有這麼多實務上的眉角（台語）要配，敏捷方法才會有明顯成效，而且，這些都是在網路上沒看過的！還好當初我沒有拒絕老闆派我來上課…」

「恭喜你有收穫啊！Scrum 敏捷方法的原創，只有描述一些非常簡潔的框架（framework）和原則（guidelines），讓很多人誤以為，任何團隊都可以立刻上手，馬上見效，可是事實上，就像上課時談的，事情並沒有這麼簡單！」

「老師，我可以參加你接下來的『敏捷式專案管理輔導案』嗎？」