把飯吃完就可以玩遊戲嘍

June 08 00:14~01:00

 

幾個月前有一位鄉民告訴Teddy，說他們老闆要求針對每一個被記錄在issue tracking系統裡面的bug（可能是QA或是客戶回報的bug），要開始記錄所謂的「代罪羔羊 責任歸屬人員」。也就是說，要找出每一個bug的「罪魁禍首」（怎麼有種公布十大槍擊要犯的感覺…XD）。老闆認為，只要把產生bug的人給找出來，以後工程師就會比較注重品質，而「不敢隨便產生bug」。換句話說，老闆打考績的時候，bug責任歸屬人員是會跟效績扯上關係的。怎樣的關係？當然是名字出現在issue tracking系統裡面次數越多的人，考績越爛啊。

等一下，看到這邊有沒有覺得有一種怪怪的感覺？如果有，恭喜你，平常有認真的在看「搞笑談軟工」。Issue tracking系統的重點是為了要「解決問題」，也就是儘量把問題發生的環境、畫面、重複產生bug的步驟、回報者這些資料記錄下來，以便於日後除錯時可以参考。至於要把bug追究到某隻代罪羔羊身上，然後紀錄在系統中以便日後進行公審，這到底是那位天才老爹想出的策略啊？如此一來，以後困難的功能都沒有人想去做，因為困難的功能發生bug的機率會比較高，被列入黑名單的機會也大大增加。不然就是造成以後大部分的時間都不是花在開發系統，而是耗費在「尋找責任歸屬人員（推卸責任）」這件事情上面。翻成白話文就是，空轉。耶，怎麼跟台灣的近況好像啊（迷之音：證所稅到底要有幾個版本啊？）。

話說回來，也不是說就不應該檢討為什麼會發生bug。如果該團隊有採用Scrum，可以在retrospective meeting中檢討品質不良的問題。家裡有位這麼天才的老闆這位鄉民的團隊當然是沒有採用Scrum的啦。但是也可以考慮定期（例如兩週）開個1-2小時的流程檢討會議，這樣總比把「責任歸屬人員」紀錄在系統中要來的有用。

如果老闆真的要記錄bug的「責任歸屬人員」，最後結果一定是變成Teddy在「目標管理，不要吧」這一篇所講的情況。Teddy念書的時候雖然沒有修過「算命」這堂課，不過有時候這張烏鴉嘴還滿準的。

***

Teddy昨天跟Kay講了這個「責任歸屬人員」的故事，Kay告訴Teddy另外一個故事。話說Kay有兩個小姪女，為了哄她們吃飯，Kay的哥哥（兩位小姪女的爸爸）就跟她們說：「乖乖吃飯喔，只要吃完飯之後就可以去玩遊戲了」。

各位鄉民們請猜想一下，結果如何？兩位小姪女會乖乖的卯起來把飯吃光光，然後快快樂樂地去玩遊戲嗎？

錯！不要小看小朋友的智慧。用這種方式想要誘導小朋友吃飯，結果適得其反。兩位小姪女為了能夠趕快去玩遊戲，「飯越吃越少」，一下子就說她們「吃飽了」、「吃不下了」。原本爸爸的「美意（誘導小朋友乖乖地把配額內的食物吃光光）」，沒想到居然造成反效果。

鄉民們，軟體工程師會比這兩位小朋友還要笨嗎？

***

把心思花在「非工程面」的管理手段上面，保證不會讓軟體變得更好，只會死得更快。就好像一艘船上破了一個洞，船長命令所有船員「加班」把水往外舀，但是卻沒有人想要去把破洞補起來。也許舀水的動作可以減緩沈船的速度，不過也有可能在舀水的過程中不小心把破洞弄得更大，讓船沈得更快…Orz。而且，無論如何，僅僅是靠「舀水」這個只花體力不花腦筋的方法，還是改變不了船最後往下沈沒的這個事實。

老闆心態不改，神仙難救。

***

友藏內心獨白：叫你導入Scrum你又不聽（丟筆~~~）。