消除浪費 (4)：Handoffs

Oct. 10 22:39~23:40

『七浪費』之四：Handoffs，英翻中的解釋是『交接』。為什麼交接是一種浪費？舉個例子，有點年紀的鄉民們，應該都知道一種叫做『喝水傳話』的遊戲，玩遊戲的人排成一排，主持人先把謎底（通常是一句話）告訴第一人，然後這個人嘴裡要含著一大口水，頭朝上把剛剛主持人告訴他的那句話傳給第二個人，依此類推一直傳下去。通常最後一個人所聽到的內容和原本的那句話早已差了十萬八千里了。

一件工作，轉過一手之後，所剩下來的知識若能有原本的 50% 就算是很不錯了，所以，如果這件工作轉了 5 手，那麼就只剩下 3% 的知識：

第一手 50% -> 第二手 25% -> 第三手 12%-> 第四手 6%-> 第五手 3%

知道的東西越來越少，就需要花更多的時間才能把事情做好，所以交接是一種浪費的行為。

***

『交接』，從另外一個角度來看，又可以稱為：把『屎虧（不想去碰的工作）』丟給別人去做。相信大部分的鄉民都有把工作交接的別人，或是從別人那裡獲得交接工作的經驗，通常這種經驗都很差。

交接者內心獨白：我已經使盡渾身解數把知道的告訴你了，沒學到算你笨。

被交接者內心獨白：東西這麼多，交接時間那麼短，你又講的這麼籠統，我怎麼可能學得會。一定是存心想要留一手不告訴我。（Teddy 補充：套句學弟常常說的話，『學長又沒交接給我！』）


一件工作丟來丟去，經驗傳承下去的比例也就越來越少，所以接到『屎虧』的人就要花更多時間去完成這件工作，這種經驗流失與需要耗費額外時間（包含把工作交接給別人所花的時間）才能完成工作當然也是一種浪費。

***

那麼，要如何減少交接的浪費呢？書上提了幾個方法：

• 降低交接的次數（Teddy 內心獨白：這不是廢話嗎...XD）。
• 組織 design-build 團隊（就是 Scrum 所說的 cross-functional teams）。關於這一點 Christopher Alexander 早就提出類似的建議，請參考 Teddy 另一篇『Architect-Builder』。
• 使用『寬頻』溝通方法。盡可能用面對面溝通（face-to-face）取代文件式溝通。（Teddy 內心獨白：Apple 聽到您的心聲，所以開發了 FaceTime。眾鄉民們還不趕快乖乖掏錢去買一隻 iPhone 4。）
• 儘早且頻繁地釋出部份（先期）作品以便於獲得回饋。這句話 Teddy 要解釋一下，原文比較長：『Release partial or preliminary work for consideration and feedback--as soon as possible and as often as practical.』假設團隊中有 programmers 和 testers，如果 programmers 『自認為』程式已經做完了，所以把程式交給 testers 去測試（這就是一種『交接』）。但是如果在開發的過程中，programmers 從來都沒有跟 testers 討論過，那麼經過交接之後，testers 很可能不知道要如何測試，或是說無法測出真正的問題，甚至會測錯（都算浪費）。如果 programmers 在開發的過程便可以和 testers 討論，那麼便可以減少這樣的問題。

最後補充一點， Teddy 認為用來減少 relearning 的 agile practices，像是 pair programming 或 collective ownership 也都可以減少 handoffs 所造成的浪費。

*** 

友藏內心獨白：國慶日還沒休息，夠意思了吧。