目標管理，不要吧

February 21 15:22~17:10

記得兩、三年前看過一篇關於目標管理的文章，寫得很棒，剛剛花了點時間找到這篇文章，是Slack (中文版：別讓員工瞎忙)這本書第十八章。這本書Teddy看的是中文版，定價才250台幣，強烈建議各位鄉民們也去買一本來看。

簡而言之，這本書的第十八章告訴鄉民們，不要採用目標管理，因為目標管理只能達到局部最大（最佳）化，而非整體最大化。舉個例子，團隊的bugs太多了，於是聖上定了一個績效指標：產生bugs越少的開發人員，績效越好。

又是生命會找到出路這句老話，大智慧沒有，小聰明一堆的各位鄉民們，腦力激盪一下要如何「無腦減少bugs」。以下Teddy先拋磚引玉提供幾招：

• 不寫程式：所謂「沒有買賣，就沒有殺害，讓我們一起保護鯨豚，大家說好不好…XD」嗯嗯，應該是「沒有程式，就沒有bugs，讓我們一起不寫code，大家說好不好…」。這真是太偉大的發現了，跟無薪假一樣簡直可以得諾貝爾獎了。把禪宗「本來無一物，何處惹塵埃」的精神應用在軟體開發上面，真是令人忍不住想按一個讚。
• 不寫困難的程式：好吧，連一行程式都不寫也說不太過去，那就專門挑那些比較簡單，不容易出錯的工作來做好了。這樣子產生bugs的機率就降低了，績效也變好了。 那困難的程式誰寫？「關我屁事啊，我只負責每個月領錢」。
• 作假帳：每個做生意的人都知道，帳本有兩種，一種是外帳，給國稅局的人看得，讓國稅局的人覺得自己真是好可憐啊，稅就可以少繳一點，最好是可以不用繳稅還可以領補助金。另外一種是內帳，給自己看的，目的是讓自己看了以後今夜作夢也會笑。鄉民們可能會想，這全都是公司逼我的喔，聖上要看美麗的數據，那我就想辦法提供美麗的數據。怎麼提供？和其他開發人員先串通好，有bugs先不要回報，私底下先通知你。另外一種方法就是，打死不承認這是一個bug，或是說這個bug與我無關，都是別人的問題（不是你的錯，也不是我的錯，都是月亮惹的禍。可以把bugs算在月亮頭上嗎…XD）。所以開發人員大部分的時間都不是在寫程式，而是在想辦法撇清關係，以及找替罪羔羊。

實施此制度之後，bugs數量是降低了，公司也倒了…Orz，謝謝再聯絡，下一位。

類似的例子太多了，例如Teddy還在唸書的時候當過一門物件導向分析與設計課程的助教，需要幫學生review設計。作業要求學生必須在class diagram上面標示出使用了那些patterns（老師沒有硬性要求要用多少個patterns），但是既然有了這樣的要求，學生自然把這個要求當成績效指標。所以哩，哇賽，每一個人的class diagram都好精彩啊，各式各樣該出現、不該出現的patterns都跑出來見客，熱鬧程度簡直可以媲美清明上河圖…XD。

學生內心獨白：啊助教你不是想要看很多classes和patterns嗎，我就給你很多classes和patterns啊，誰怕誰啊。

Teddy：是誰告訴你Teddy要看很多classes與patterns？看的Teddy眼睛好累，說好的物件導向設計呢？

學生：物件導向是什麼東東，好吃嗎？

***

還有沒有類似的例子？有。某公司想量測programmer的「生產力」，偉大的「牠」建議：要測量每個programmer每天的LOC（line of code），LOC越多的，生產力愈高。

不要奸笑，Teddy知道鄉民們心裡在想什麼。嘿嘿，這還不簡單，我方只要派出ctrl + c與ctrl + v這兩員大將就搞定了。

啊，甚麼，你說是因為「指標訂得不好」才會這樣。那請問開發軟體要訂哪些指標才算好，留個言教教大家吧。

***

扯了這麼多，到底要如何改善軟體開發生產力與品質？套句Mobile01上鄉民經常講的一句話：請爬文。

Teddy介紹的書多看幾本，還有把搞笑談軟工上面的文章整篇背下來，再不行找Teddy去當顧問，這樣就差不多了。

鄉民內心獨白：人家要免費的答案啦。

Teddy：免費的牛肉要不要？

***

友藏內心獨白：風蕭蕭兮易水寒，Teddy一樣要吃飯。