看板方法導入 PART 4 - Daily 迭代(消除浪費)
【看板方法導入 PART 4 - Daily 迭代(消除浪費)】
豐田汽車副會長-大野耐一，創造了「豐田生產方式(TPS)」：是提高企業生命力的一整套概念和方法的體系。它是豐田公司通用的製造方法，其基本思想是"徹底杜絕浪費"，通過生產的體整化，追求產品製造的合理性以及品質至上的成本節約。
其中豐田的浪費指的是以下七項：
●運輸 (把原本沒有必要的物資運送到生產流程中)
●庫存 (所有零件、半成品和成品在儲存中的浪費)
●運動 (人員和設備搬來搬去，超過生產必要的人員走動)
●等待 (等待下一個生產環節)
●生產過剩 (生產比需求多)
●多餘加工 (來源於設計問題、生產工具有誤產生的復工)
●瑕疵 (耗費了參與檢查和修復瑕疵的投入)
既然我們在資訊業跑的看板方法是來自於豐田，也確實成功改善並運用在許多公司，那就要先對"浪費"有些概念，套用到資訊業會是怎樣的情境，才能讓我們從容應對看板導入團隊時，有可能會產生的任何問題。
轉換一下上面七項浪費變成資訊業的語言，大概就是
佈署、半成品功能、來回無效溝通、需求定義、Bug、分析、等待、不必要的流程。有這些概念後，再來對應到實際看板導入過程來消除浪費，藉由每天的Daily來培養對問題的敏感度。
提供實際反應過的問題給大家參考：
●DB開發分析做完後怎辦?
●零散的工作項，佔的工時很小，是否要貼TASK任務單?
●為何整合欄位一堆單，都沒進入到自測狀態?
●有組別開發欄位是空的?
●提前做完，離上線還有一段時間的需求單放哪?
●自測欄位的單子停很久?
●開發欄位單子停很久?
●有張任務單不曉得現在狀態在哪，該放哪邊?
●需求單從完成欄位又被拉回來開發狀態?
●一直停留在追蹤狀態?
●如果分析完後的任務單，不用上線也沒有後續發展，如何處理?
●看不到環境、佈署狀態
●驗收狀態停太久，中間有問題卻沒在Daily反應，反而是在回顧會議提出?
●開發欄位滿出來?
●待確認需求單與開案中需求單的定義?
●欄位間的流動似乎不順暢，彼此等待的時間影響?
以上問題視看板的欄位還有團隊原本的開發狀態而不同，但背後反應出來的本質差不多。
那"消除浪費"為的是什麼?
為的是讓我們過的更好，讓我們有更多的盈餘時間(Slack Time)去思考、安排其它有效益的活動，例如優化、重構、服務提升、自動化、DevOps、測試、Agile、XP、Lean、Design Sprint、Design Thinking...等等，很多技術與非技術層面，都有助於我們打造更好產品，與客戶產生更多的連結點。
在我目前看來，WIP的運用，會是在所有的不良習慣先改善，且開發流程也有一定的成熟度，才用的上WIP來挖掘更大效率。所以，初期我選擇先透過看板來把體質調整好，後期再來強壯自己的身體做更多的事情。
團隊歸納出三個核心要改善的體質調整「資訊、認知落差」、「時間管理」、「消除浪費」，後續再補上這三個核心是怎被歸納出來的囉!!
結論：
"消除浪費"的是行動，核心是發覺到根源問題或瓶頸，針對其根本解決，才不會一再發生或衍生出更多問題。有絕大多數問題是原本行為錯誤導致，畢竟看板是建立在原本運作中的開發流程上，一一反應出問題，有時候只是過於習慣而沒發現到，其實可以做小小改變或順序調整，就有大大效益。
上一篇：看板方法導入 PART 3 - 第一次Daily
留言
張貼留言