iT邦幫忙

2023 iThome 鐵人賽

DAY 9
2
Software Development

敏捷聖徒系列 第 9

Day 9:「SOP 救國?小心 Local Optimization!」- 談隱形的浪費

  • 分享至 

  • xImage
  •  

故事是這樣的

幾年前敏捷開發開始在國內萌芽,在眾多業界前輩努力推廣下,一些有志之士也開始試圖在公司內推動。筆者的朋友 Sam 就是。

與許多人一樣,Sam 在公司內也是前期少數接觸敏捷開發的人員之一,在團隊內部試行一陣子覺得不錯後,也想「推己及人」,把這樣的觀念也帶到公司其他團隊。

幸運的是,有些其他團隊看到 Sam 他們的工作效率與產出都有提升後,也對此躍躍欲試。於是一段時間後,在一群人不斷努力協調、改善工作流程之後,一個能整合全公司大多數部門的工作的「看板」就產生了。

https://ithelp.ithome.com.tw/upload/images/20230919/20107429QQ3TiNj5uz.png
看板,圖片來源: Wikipedia

不出意外的話,就要出意外了。

正當 Sam 與其他伙伴開始利用看板來找出現行流程的問題,並磨拳擦掌蓄勢待發蓄勢時,總經理來視察了。

「這麼大張花花綠綠的是什麼?」總經理問。
「報告總經理,這是看板,改善工作效率用的。」Sam 答。

總經理一聽馬上有了興趣:「改善工作效率?怎麼改善?」
Sam 看總經理有興趣,心想打蛇隨棍上,於是趕快補充:「是這樣的,我們誠實地把工作的情況更新上去,這些卡片就會移動,已完成的拿下,如果團隊之間協調出了問題,所有人一看這些未完成工作分佈的樣子就能知道,接著…」

「慢著,未完成?」不等 Sam 說完,總經理眉頭一皺,不悅地說了:「你們溝通有問題,自己私下解決就算了,拿出來給全公司人看像什麼樣子?萬一客戶走過去一看,這間公司未完成工作有這麼多,這不是讓人看笑話嗎?撤下來,你們照我給你們的 SOP 幹,每個人做好自己的 KPI 就好了,別整天搞這些亂七八糟的東西!」

語畢,總經理便拂袖而去,留下 Sam、同事,以及那張才出生沒幾週就被賜死的看板。

看板的運作原理

我們先來定義上面這故事的主角 -「看板」(不然你以為是 Sam 嗎?),而且是看板方法的大前輩:Toyota 的看板。

根據維基百科的定義,看板(カンバン)

Kanban is a scheduling system for lean manufacturing (also called just-in-time manufacturing, abbreviated JIT) ...to improve manufacturing efficiency. The system takes its name from the cards that track production within a factory...(後略)

因此我們知道了,看板的目的是為了在生產流程中,透過「下游向上游拿卡片」的方式,藉此減少生產中浪費的方法。而 Toyota 對於看板的操作,也有其規定:

  1. 每個(下游)流程需要用零件時,向其上游發出一張請求卡片。
  2. 上游根據此請求製造零件
  3. 沒有請求,不能製造任何零件
  4. 每一個零件永遠都要附上當初的請求卡片
  5. 每個流程都絕對不能產生有(已知)缺陷的零件
  6. 對流程之間的「待處理請求」加上一個上限,以即時期揭露生產過程中會影響效率的問題

筆者認為,上面的第 3 與第 6 點,乃看板方法能運作的關鍵規定。3 讓我們不會花時間做出沒人要的東西,6 讓我們不會花時間做出現在還不重要的東西。這些時間省下來,可以拿去支援別人,幫系統的瓶頸點解決問題。筆者認為,甚至讓作業員原地休息半小時,也都會比製造那些沒用的東西來得經濟。

隱藏的關鍵:透明度

如果我們再細究,有一個很重要的關鍵也同時影響看板系統的作用力:「透明度」。看板本身如果能與現實越接近、就越能從中看出目前流程上的瓶頸。看出瓶頸,才能針對瓶頸改善。

回到 Sam 的故事,總經理看起來相當在意把「未完成」工作暴露出來這件事,他認為未完成越多就代表工作沒做完。嗯…其實非也。這兩件事其實沒什麼關係,未完成工作多或少跟工作有沒有做好無關,我們更要在意的是未完成工作有沒有「老是在上限附近徘徊,並且從不超出上限」。當我們能做到這點,就代表生產系統上的每個子流程的生產力都能「在不製造浪費的前提下開到最高」。

所以...

這些未完成工作(Work in Process,WIP)的關鍵在其上限,而不在其數量。
這些未完成工作(Work in Process,WIP)的關鍵在其上限,而不在其數量。
這些未完成工作(Work in Process,WIP)的關鍵在其上限,而不在其數量。

同時,故事中的總經理信奉的「SOP + 做好自己的事」大神,在「一個團隊無法獨立生產一個完整產品」的場景下,也會無形中拉低產線的價值。

為什麼?

我們知道,一件事情如果流程不變、有固定做法,那麼制訂一個 SOP 並且要求操作者火力全開專心操作,必定能提高產出的量,並且能提高品質。這得合理,一件事重複操作幾萬次,肯定會越來越熟練的。熟能生巧嘛!你看唐伯虎畫春樹秋霜圖就知道。

https://ithelp.ithome.com.tw/upload/images/20230919/20107429oPEdASCs60.png
熟能生巧示意圖,圖片擷取自 bilibili

「咦?這樣不好嗎?」

我只能說,在理想狀況下很好。我們在前文中說過了,工廠的生產是一個設計,重複生產多個產品,但軟體開發的規劃開發測試,都只是設計流程中的一環。也就是,開發過程中不可控因素,會比工廠流水線多得多。當下游卡住了,你上游不幫忙想辦法解也就算了,還不斷照 SOP 產出越來越多的半成品,我就問你這些半成品是打算拿去賣給誰?

舉個例子,你想要多子多孫人丁興旺,啊太太就生病了還在治療中,你拼了命複製更多老公出來,也生不了更多孩子啊!

要我說,這些努力只是把資源投入在「Local Optimization」上,看似大家都很忙,實際上對價值是有害的。更麻煩的是,這些浪費是無形的,因為從 KPI 根本看不出來。

https://ithelp.ithome.com.tw/upload/images/20230919/20107429vczTJ6z2Qu.png
Local Optimization 示意圖,圖片來源:Wikipedia

此時再回頭看看 Sam 的看板,現在看起來總經理的 SOP 觀念沒有辦法一夕之間改變,那人微言輕的 Sam 應該怎麼辦?

話鋒一轉題外話:論安全

注意了!接下來我要說的話看起來有點暗黑,但,請姑且聽 Kuma 一言,你得先活著才能實現理想…

首先我是認為事在人為啦!你今天要從基層推起,本來就是一定會在某個層級遭遇到瓶頸,人生嘛,本來就不是所有遇到的問題都一定能解決,況且,你也不確定你的解法就一定能幫大家賺大錢。有沒有一種可能,你以為卡住的流程,其實是一個更龐大系統中維持微妙平衡的結果:有沒有可能當你把這個結解開了,結果那個更大的微妙平衡就被你破壞了,結果到最後原來你才是那個 Local Optimization?

什麼?聽不懂我說什麼?沒事,等你再長大一點你就知道了(菸)

當然,這不代表你就要擺爛不努力了,如前所述,事在人為。但當事情的推動不如預期,也不要太過灰心喪志,換個方法,重整旗鼓再來過便是。只要人還在,就不算失敗,

謎之音:「在對的時間做對的事,前提是要確保自己的安全。」

Reference

  1. Marcus Hammarberg, Joakim Sunden,看板實戰 : 用一張便利貼訓練出100分高效率工作團隊 (Kanban in Action),博碩,2017
  2. Kanban. (2023, August 20). In Wikipedia. https://en.wikipedia.org/wiki/Kanban
  3. Local optimum. (2023, July 31). In Wikipedia. https://en.wikipedia.org/wiki/Local_optimum

上一篇
Day 8:「你們怎麼估點數的?」- 談估算
下一篇
Day 10:「偉大的航道 1/3」- 這是一個驚心動魄的故事
系列文
敏捷聖徒30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言