31. 事情如何開始改變 (1)

source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook

在導入Kanban三個月後, 系統管理團隊在IT的部門中, 被管理階層評為"表現最好的團隊". 同時, 系統管理團隊在公司回顧會議中被評選為, 前三個"建設性經驗"中的其中一個. 公司的回顧會議是一個全公司性的事件, 每六週舉行一次. 這是團隊第一次出現在前三名的清單中! 誰想得到三個月前, 團隊曾處於瓶頸狀態, 並且很多人還一直在抱怨.

服務的品質已經增加了, 因此, 這是怎麼發生的?

這不可或缺的關頭是當大家開始通力合作, 經理提供了一個明確的重點, 並且保護團隊免於其它不屬於這裡工作的打擾, 因此團隊可以確保品質和交付期限. 我們大約花了三到四個月才出現這樣的狀況, 可是之後就暢通無阻. 不過不可能所有問題都消失了(那將會使我們都失去工作, 對吧??) - 我們現在面臨了新的挑戰: "我們如何讓團隊保持動力去改進(當他們已經不再是瓶頸之後)?"

在自我組織中一個重要的部份是, 導入"每個團隊有一個營運的聯絡人"的概念. 這意味著每個開發團隊在營運團隊中, 有一個他們屬於他們自己的聯絡人. 藉由允許營運團隊成員自己組織他們自己的工作, 預防過度操勞, 並且持續改進, Kanban讓這一切變成可能. 在此之前, 隨意一個人從序列中抽出一個工作, 盡他自己能力去解決它, 然後再處理下一個. 若是有任何誤解, 則意味一切需要重頭開始, 重新提出一個新的需求. 當一對一的觀念被部署後, 在不良的投入以及品質問題威脅到系統時, 支援的團隊會意外地有機會迅速做出反應

經過一段時間, 自訂的溝通協定逐漸形成. 營運人員開始使用即時通訊和他們交情良好的開發人員交談, 而用email跟哪些用寫會比用說好的人溝通. 如果要以最快的方式來解決問題, 則會使用電話.


改變之前

圖 10. 改變之前: 第一線經理人是團隊主要的連絡人. 任何重要的事情都需要經過他才能完成. 較小的問題, 通常程式開發人員的問題, 是經由問題追蹤系統來記錄. 很少有人與人直接互動.

改變之後

圖 11. 改變之後: "每個團隊有一個營運的聯絡人"的概念被部署. 開發團隊直接和營運團隊中的規劃好的聯絡人對話. 許多人對人的互動. 營運團隊成員會利用Kanban白板去自我組織他們的工作. 經理可以轉移焦點到大型專案的優先順序, 並且在當他們遇到困難時提供支援

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()