專案狀態報告：你不可不知的四大法寶
不知道身為 PM 的你有沒有過這樣的經驗，當你走進公司大樓電梯，沒想到公司高階主管也走了進來並關上了電梯門（因此你想逃也逃不掉），緊接著，他冷不防地問你，「那個ＸＸＸ專案現在的狀況怎麼樣了？」
他不是你的直屬老闆，只是你老闆的上司或更高層的上司，所以平時你並沒有直接向他報告的機會，這個時候你會怎麼做呢？
什麼樣的專案適合使用敏捷式專案管理
對方向我介紹完他們公司後我才知道，原來他是這家新創軟體公司的共同創辦人。
用戶故事時間老是估不準？三大技巧助你敏捷團隊一臂之力！
「老師，我們公司有在使用敏捷方法做專案，可是團隊在估算用戶故事（User Story）時間的時候，老是估不準，有的時候會多留很多 buffer，有時候又少估很多時間，導致衝刺的工作做不完，這該怎麼辦才好？」
我在《Scrum 敏捷方法裡，渾然天成的九大風險管理把關設計》一文中談過，敏捷方法的框架其實隱含了不少巧妙的風險管控設計，其中當然包含了管控「因時間錯估而延誤」的風險。這裡我們先假設，這位學員提及的敏捷團隊，有確實遵守敏捷方法要求的原則來運作，沒有自行偷斤減兩，可是團隊對於時間的估算，卻依然不夠準確。在這樣的前提背景下，我們還有什麼其他的招數，可以來改善這樣的問題。
專案管理輔導紀實－國境之南篇
在我企業內訓接案的對焦經驗裡，有不少客戶，其「原本想要」的服務，其實可能根本就不是該公司「真正需要」的。只是有些客戶會認真聽你講，願意讓你的專業說服，走對路，預算用對地方；有些客戶則是早有定見，只想交差了事（如，老闆交代、消化預算、有培訓紀錄…），任憑你說破了嘴也沒有用。
當然啦，生意就是生意，能成交而且雙方都滿意就好，沒什麼對錯的問題。只是以我立場而言，既然客戶你付了錢，也讓員工花了時間，能讓員工有巨大收穫，能讓組織的問題獲得解決，這樣的合作不是會更有意義一些嗎？
2020 年倒數最後幾天，我收到一家南部電子大廠人資經理的來信，目的是想要邀約敏捷課程和顧問輔導服務。這個案子頗為戲劇化，也有些峰迴路轉，不過，最後的結果是，我把該公司「原本想要」的服務，轉變成該公司「真正需要」的方案，而且事後成效極大，滿意度極高。
優秀敏捷大師（Scrum Master）應具的能力和特質有哪些？
下課後一位學員來提問，「老師，我們公司想要開始導入敏捷方法做專案，我現在是工程師，我想轉換跑道做敏捷大師（Scrum Master），您覺得這樣好嗎？」
「好不好，我不知道，不過，如果你想做敏捷大師，除了剛剛課堂上談的之外，你還可以先想想這些問題，例如．．．」
敏捷產品負責人發生「決策錯誤後悔厭惡」，你該怎麼辦？
最近跟一位朋友吃飯，席間聊到他十年十多萬公里的老車，保養貴得不得了，於是他認真地研究了一下各廠新車的性能和配備，準備要換車，結果看來看去，只有日系Ｌ牌房車的性價比和妥善率最合他的胃口。
敏捷團隊遲遲無法高績效，大風到底吹不吹？
「老師，您覺得我需不需要定期把團隊打散，攪一攪比較好？」一位高階主管學員在課間休息時這樣提問。
這個問題違反了我多年來帶團隊的經驗和直覺，因此我好奇地回問，「您為什麼想要這樣做呢？」
你不可不知，「當責」對「專業」的影響有多大
最近跟一位裝潢設計師友人 Jean（化名）吃飯聊天，席間談到她的一個 case，這 case 不僅讓她多賠了一些錢，還弄得她客戶有點不太開心，讓她覺得有點委屈。
Jean 其實相當細心，設計功力不錯，且心地善良（因此生活上常被人詐騙^^!），因此，我出社會以後，多次的新房設計裝潢都是交給她負責的。以我吹毛求疵的高標準來說，她能多次從我手上活著完工結案，裝潢設計的品質和質感一定是掛保證、沒問題的。
那為什麼這樣的人依舊會出包，惹得客戶不開心呢？這點讓我很不解，因此我決定繼續深挖這個故事。
敏捷團隊裏的大牌與王牌
「敏捷大師」可以怎麼生出來？
敏捷大師（Scrum Master）之所以稱為「大師」是有它的道理的，「大師」是那個能帶領團隊走對方向，並在敏捷路上愈走愈順的賢者、智者，絕非隨意指派，給個稱號就行的。
在《大錯特錯！敏捷大師不是團隊的助理或秘書》這篇文章中，我曾經概略說明了敏捷大師這個角色的職責、資格和等級，可是如果組織就是欠缺這樣的理想人選，那又該怎麼辦？有沒有什麼方法可以把「相對適任」的敏捷大師給生出來呢？
「老師，請問您要怎麼向我們保證課程的成效？」
前陣子一家做遊戲的企業客戶找上門，詢問一些關於敏捷課程與顧問輔導服務的細節，在一些相關中階主管都在場的對焦會議上，對方窗口最後提出了一個問題，「老師，想請教一下，您要怎麼保證，我們上完課之後會有成效？」
「喔~這沒問題啊！只要貴公司可以保證，完全按照我教的去落實執行，那就可以保證課程和輔導的成效。」
奇了！過了不久，又有另外一家做儲存設備的企業客戶找上門，同樣也是類似的狀況。這讓我動了寫這篇文章的念頭。
Scrum 敏捷方法裡，渾然天成的九大風險管理把關設計
「老師，要管好專案的風險，您覺得是用傳統式的方法比較好，還是用敏捷式的方法比較好？」一位學員在課後向我這樣提問。
當下我還真楞了一下，倒不是因為我不會回答這個問題，而是自從教授敏捷相關課程這麼多年以來，這還是頭一遭有人問到這樣的議題。
先說我的結論，總體而言，我認為，敏捷方法比較技高一籌。
敏捷健檢：偽敏捷的三十大症狀，你的團隊或組織中了幾個？
教授 Scrum 敏捷方法課程多年以來，不論是在公開班上，或是在企業內部裡，不論是被運用在專案管理上，或是被應用在整體組織的改造上，我發現，不少團隊或組織在施行敏捷方法的時候，經常有意或無意地把一些敏捷方法的重要設計給省略掉，誤認為這樣就能省掉調整組織規章、組織結構和人員心態等的大量心力，仍可輕鬆獲致敏捷方法宣稱的巨大成效。
組織營運或專案管理出了問題，企業對外找專業講師或顧問來協助，是直接、有效且客觀的方法，本無可厚非，不過我得說，如同人生了病會去找醫生一樣，病人如果不照醫生指示去定期服藥治標，也不願意花力氣去運動調整體質來治本，那麼，病好不了，無法根治，也就怪不得醫生和處方了，對吧？
訂閱：
文章 (Atom)