在 Kanban 最神奇的地方, 就是要求限制同時工作項目的數量 (WIP limit), 也就是讓團隊成員專心處理一件事情, 這樣會讓 cycle time 比較小.
可是你會遇到一個問題, 就是每個人的處理速度不一樣快, 或者每個工作的大小不一, 會導致你整個流程會走走停停. 例如下圖所示:
在 Kanban 最神奇的地方, 就是要求限制同時工作項目的數量 (WIP limit), 也就是讓團隊成員專心處理一件事情, 這樣會讓 cycle time 比較小.
可是你會遇到一個問題, 就是每個人的處理速度不一樣快, 或者每個工作的大小不一, 會導致你整個流程會走走停停. 例如下圖所示:
最近公司最近在 UCD 使用者中心設計高峰會中, 有一場關於使用者體驗旅程圖, 趁機惡補了一下, 期望能吸收同事們的日月精華
http://www.bnext.com.tw/edm/2014UCD/index.html
最近幾次 review 會議中的 demo, 讓我印象十分深刻, 不吐不快, 特別列了幾點和大家分享:
1. 使用實際資料
工程師們為了讓大家看到真實的一面, 很有勇氣的現場開始產生資料傳送給要 demo 的系統, 不是事先預錄 demo 流程. 我想有 demo 經驗的人都知道, 實際傳送資料是很驚險的事情, 很多原因會導致失敗. 可是我很喜歡大家勇於接受挑戰, 願意讓大家知道我們是玩真的, 不是來騙大家說一切都沒事.
當我們使用 Kanban 來管理專案時, 其中一個工作, 就是要訂定明確的 policy, 來告訴團隊成員事情要怎麼處理. 讓大家都是用相同方式來運作, 因而使得整個團隊工作更有效率.
那什麼地方可以有policy 呢?