管理文章如何搞砸你的敏捷轉型計畫(二)
次閱讀
為什麼想要搞敏捷的你（或公司），有80%是失敗的。
二、錯誤的結構設計
企業導入「敏捷或scrum」最常犯的問題是錯誤的團隊結構設計
因為敏捷是源自於軟體開發產業，故最常看到導入敏捷模式的也自然是軟體開發部門，不管是五個程式設計師或者再多加兩個QA或者再加上一些所謂的ui/ux，就關起門來做敏捷。
敏捷的團體結構設計本身有防呆機制會設置了一個PO來帶入商業資訊，但如果商業資訊的處理僅僅由PO來溝通是會出問題的，因為PO與工程師（這邊指的工程師不僅僅是軟體，餐飲的內場師傅或美術設計都可以稱為工程師）所使用的語言以及關注點都不同。
最佳的團隊結構設計是：工程師與非工程師比例約為5:5，也就是說，如果您是餐廳業者，想要導入敏捷，那你所建構的敏捷團隊必須包含內場、外場、客服、行銷、甚至美編；如果你是硬體生產業者，你的團隊必須有軟體工程師、硬體工程師、品質檢驗人員、系統設計人員、客服、業務等。
多元的團隊，在解析專案、產品問題時，可以用不同的角度，一起去找出設計最佳的解決方案。因此，不論你是什麼產業、行業，在設定敏捷團隊的時候，請不要只有工程師，你可以讓你現在的敏捷團隊有一點不同，試著把軟性職務放進去，讓他們每天跟團隊一起開會，一起討論業務的進展，一定會有不一樣的成效，我敢保證效能至少提高30%以上。
第二個常見問題是Scrum Master的配置與訓練
多數企業選用傳統Project Manager擔任SM，但卻未給予充分、完整的SM應有的訓練，其包含對敏捷的完整認知、關於領導與激勵團隊成為自組織的知識，也缺乏協調組織內部政治問題的柔軟性、經驗。
尤其常會看到一些職缺貼著Technical需求的Scrum Master，凸顯用人單位、人資部門對於此職務的錯誤認知，自然也導致敏捷團隊的失敗。確實，要能啟用純粹的Scrum Master並不容易，但至少不要再把傳統專案管理的職能要求強灌在這個職務上，尤其那些帶著專案管理威壓能力的SM，一邊要求團隊建立自組織模式，一邊又用甘特圖配合PO押時程。優秀的SM是能扮演著多種角色，如潤滑劑、溝通者、協調者，幫助團隊釐清商業迷霧。
最後是Product Owner的問題
這個職務與傳統的Product Manager並不相同，很可惜，你會很容易看到部門或上級主管無法判斷，而要求傳統產品經理去擔任產品負責人，光是對產品、盈利能負責任的狀況就天差地遠。沒有受過實際訓練，只有花錢買證照的PO對商業價值毫無概念，無法協調組織上級需求，只能照本宣科的把公司想要做的產品做出來。
而這個角色其實對於價值描述與定義扮演著重要的影響性。如何判斷PO的價值？一個優秀的PO必須要做到的事情是，即使把手上的資源減半，他也能找出產品的最佳價值應該在何時呈現、何種樣貌呈現，並且清楚的知道敏捷迭代的原則，願意接受迭代交付的不完整。
筆者曾經看過一個團隊，開發成員抱著盡善盡美的理念，試著把所有細節做好再交付（因為這個開發團隊內含著瀑布流程，管理開發團隊的組長不願意交出迭代式作品），在大型產品、資金充沛的組織或許這是應該這麼做，但PO、SM沒有發現拖了半年的產品幾乎燒光了小公司一半的資金，接著上市後發現產品不如客戶所喜愛，現金回收的可憐，要再改動就更困難了。
因為類似這樣的狀況，我們在下一個篇章來談一下錯誤的迭代模式如何把你的敏捷團隊送入火葬場。
講師介紹敏捷教練-王可帆 | |
 | ♦經歷： ♦學歷 ♦認證： ♦著作： |