l

2012年2月22日 星期三

目標管理,不要吧

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一樣要吃飯。

7 則留言:

  1. 有個idea, 用scrum的team可以用.

    completed story point /per month

    所以...誰先出無限大就贏了.

    回覆刪除
  2. To mumu:

    Story point 估算的時候雖然可以出無限大,但是最後定下來的story point不會有「無限大」這個值....啊...Teddy又認真了,輸了...XD。

    回覆刪除
  3. 正常的scrum master 應該看到大家都出 13 點以上的 point 就要喊 stop and please break down 了吧.... :P

    出無限大? 我不記得正常的planning poker有這張牌啊,了不起只能一直出 "?" 跟 "coffee" 吧。 不過.... 一直出這個應該很快就被 scrum master 請去喝咖啡了... (怎麼我也認真了 XD

    回覆刪除
  4. To 理查 & Teddy:
    我們家是用山羊牌的點牌估計story point.
    不太清楚其他的牌組有沒有無限大.
    實際上當然不可能無限大結案,
    無限大只代表會要開久一點,
    或者先丟人下去研究再回報.
    而且也跟理查說的一樣,
    story不幸超過13的話就會再拆.

    其實, 我的想法是story point是整個team一起簽字蓋章的. 估出來數值是已經受過公評的, 拿story point出來當績效, 理論上比較不會有爭議.

    當然, 人心真的很難測. 能測的通常只有自己.

    回覆刪除
  5. 我們這邊用的牌組沒有無限大哩,取而代之的是 "?" (代表的是我對這個task沒概念)。

    btw, 用點數來做為績效考量,似乎有些不妥,過度的與某些指標連結,套句Teddy所提過的,這些值只會被人局部最佳化。要Run Agile感覺還是要hire對人才會有最好的效果,不然只要被這些愛鑽漏動人搞東搞西的,沒兩三下就 Fail 了。

    回覆刪除
  6. 今天到天瓏買了Teddy的書,回來後看到這篇,真是超認同!離開紅茶就是因為老大出了這個政策。還曾有Bug還不知道怎麼repo之前,就被人(別單位主管)找去要"負責",開了不知什麼意思的會到晚上1點。那位仁兄自然是公司的寶囉…

    回覆刪除
  7. To 工程師:

    感謝支持,搞笑談軟工上面還有很多『寶』,歡迎加入挖寶行列 XD。

    回覆刪除