很多人認看維護團隊適合使用看版, 所以我很理所當然地在維護團隊中嘗試它. 一開始時, 我定義處理的流程如下
To Do —> In Prog —> Done
有問題來時先放到 to do 欄位中, 維護工程師開始處理時便移到 in prog 欄位, 處理完後便放到 done 欄位. 因為問題會何時來很不確定, 何時可以解完也無法估算, 因此認為這樣流程很適合 event-driven 的 case.
可是執行一陣子之後, 發現事情並不是我想像的那樣, 因為發現某些工程師身上會處理 4-5 個問題. 為什麼會這樣呢? 可能的狀況有以下幾種:
1. 問題來的時候可能資訊不全, 需要找支援工程師或是顧客要更多資訊, 因此我們的維護工程師不能進一步處理
2. 當維護工程師可以重現問題, 可以找出大約是什麼狀況時, 接下來會交付給開發工程師去修復.
3. 但問題被處理完後, 需要給 technical writer 撰寫發行文件, 這時候也是需要等待
等到 writer 把文件補齊, 並且開發工程師也修復完畢, 這時候維護工程師才能開始準備 hotfix, 確認是否問題被修復.
這整個過程會牽涉到好幾個部門, 每個部門都各自有要負責的事情, 會需要有個機制把這些事情整合起來, 我們才知道事情處理到哪裡, 哪些需要更多人手, 哪裡需要多叮嚀.
這時候看版的用法便需要調整: 我們會採用兩階層的看版
1. 組織階層的看版
這個看版顯示的組織階層的流程, 讓你可以很快知道目前這個問題處理到哪個部門. 上層可以快速了解進度, 可做出適當的決策或是資源調度.
例如上面這個範例, 我們便可以使用這樣的流程
clarify case (維護部門) —> request more information (客服部門) —> fix case (開發部門) —> write release notes (技術文件部門) —> pack hot fix (維護部門) —> verify solution (維護部門) —> deployment solution (客服部門) —> done
2. 部門階層的看版
記錄每個問題進到每個部門後, 詳細被處理的狀況. 例如: 技術文件部門他們就是依序消化進來的事情.
To Do —> writing —> review —> done
所以當你的工作需要跨部門合作時, 看版的兩階層的做法可以幫助你整體的觀點, 然後又可以對細部詳加管理
全站熱搜
留言列表
