PMBOK(專案管理知識體系導讀)闡述的是專案管理知識與概念，說明了專案管理所依循的五大程序群組 (Process Groups) 和九大知識體系領域 ( Knowledge Areas)各定義，但真正上了戰場執行專案時，靠得是PM自己內化後展現的功力，以及如何用不同的工具加速這些理念的達成。今天要介紹的工具是看板(Kanban)管理，正確來說它是一種具體的管理方法，而非一個標準的軟體工具(如Microsoft Project)。
看板隨著Scrum(註1)逐漸普及而廣泛被討論與使用，它的概念並不複雜，不論用在傳統的瀑布式專案，抑或是個人的工作排程管理，都相當實用。看板，顧名思義，是將專案的相關事項書寫於公開的白板、布告欄等，在強調團隊溝通的Scrum隊形(註2)中顯得特別重要，因為它的目的就在於，潛移默化讓所有人都能持續地接收最新訊息。最簡單的看版由待處理、處理中、已處理三列組成，如第一張圖所示。團隊成員將手邊的工作事項，依據處理情況以便利貼貼於其上，然後再透過每日的站立會議快速同步資訊。
看板可以針對團隊需求適當做一些變形，例如增加編碼、測試、批覆(核准)等不同流程，或橫向增加分隔泳道，每個泳道可依故事或成員區分，讓同類型的項目可在同一個序列中處理。在開發案中，一個Case處理完成後，可能需要交付另一位成員進行驗證與測試，但不同流程之間耗費的時間不同，為了避免太多任務積在同一個流程，導致部分成員負擔過重，因此可以訂定每個階段容許的最多工作項目。例如測試階段最多同時進行2個Case，當已有2個Case在進行測試的時候，即便已完成開發編碼，也不能進入下一個程序。但是，這樣不是變相造成回堵嗎? 就像交流道設置了匝道號誌一樣，雖然高速公路順暢，但卻苦了平面的用路人? 其實，敏捷開發並不特別強調快速，而是講求精實，如果團隊在開發過程中，能將每個細小的功能做到最好，未來也可以節省許多重製、維護的成本，也因為底層架構鋪建完整，更能依據市場的變動來調整方向。因此，當測試階段任務已接近滿載時，可以適時調整工程師的工作，例如回頭檢視底層架構、協助其他成員進行Code Review等，在等待測試階段消化完工作前，透過協作讓其他的工作更加有效率。當然，如果經過幾次運作後，仍會出現塞車的情況，或許就該檢視人員是否充足? 訂定的上限是否合理?
看板管理的精神，並非單純使用於敏捷式開發的專案，任何團隊協作過程都可以透過看板進行有效的控管，以下圖為例，我所在的部門使用Trello這個看板工具軟體，將成員每日的工作依據今日清單、處理中、完成區分，另拉出待辦事項、已封存清單作為事前準備與事後查察，每個成員今天要處理什麼事情、進度如何，都能透過看板一目了然。必要的話，也可以下載App版本，隨時隨地都能進行工作排程管理。而我自己也藉由Trello看板來管理工作以外的雜事，除了讓自己更有效安排時間，也有備忘錄的功用。
看板的基本原則並不難，但最重要的是如何善用工具的優點，來改善工作效能。看板的好處是能輔助團隊成員養成每日計畫排程、檢視工作成果的基本能力，並透明化呈現工作進度，建立團隊互助的風氣(而非競爭、dead line壓力)，但它卻不一定能替代文件管理或開發紀錄，因此，選用工具之前，要先確認自己的需求及目的，並且充分了解工具背後的精神，才能真正發揮作用，進而事半功倍。
註1 : Scrum是一種敏捷式開發的方法學，敏捷開發強調將產品以「最小可行產品(MVP)」的方式推到市場上，然後依市場反應透過快速迭代，改善缺失。
註2 : 一般來說，Scrum建議一個團隊的成員數最好落在5~9人之間，才能將敏捷開發發揮到極致。
留言列表
