快推別說風涼話啦 – 如何量化個別開發人員和工程師的產能

0a4f6cee5752d6f5bbbcb09692964032

之前有討論過如何衡量團隊的產出和價值,接下來讓我們看看如何衡量個別開發人員(包含Programmer,Tester 和 Designer)的產能。

情境一,假設你是督導建金字塔的其中一個拖拉隊的工頭,團隊裡面有三個如上圖,兩個很賣力在工作,另一個很反骨,整天都在吵為什麼輪子不用圓的之類的,吵歸吵,大夥每個月還是可以運20趟。你是工頭,每個月底加菜金的時候要怎麼分呢?

不夠複雜嗎?情境二,大家聽了反骨仔的話,真的換了圓的輪子,結果可以多運10趟,共40趟,那現在月底加菜金怎麼分呢?

最後情境三,反骨仔不幸壓倒腳,那個月換他妹來帶班,結果他妹太正了,大家叫他坐在車上當拖拉隊鼓勵師,大家邊拉邊聊天,沒想到當月竟然超標拉了45趟。那加菜金怎麼分?

法老王要判斷給整體產品開發團隊的加菜金容易,就算趟數嘛。假設一趟給大家分一隻雞腿,情境一就是20隻,情境二是40隻,情境三就是45隻。但難是難在個別成員要怎麼分配大家才不會打架呢?反骨仔的建議值多少雞腿?他妹精神上的鼓舞又值多少雞腿呢?

如果連推拉隊都很難讓大家都分的心服,那過了四千年,我們寫程式開發Software的複雜度、抽象度都遠遠高過金字塔拉石頭,我們有辦法找到一個可以量化的方法來量化個別衡量團隊成員的貢獻嗎?Yves在去年就放棄找出客觀數值來評量的方法啦,正式放棄的那一天是聽了James Grenning的演講,演講完後Yves就問James,有什麼方法可以衡量Developer的能力和產能嗎?James沉吟了一下,說沒有辦法量化或衡量,如果真的要衡量,只能看到底有沒有解決問題。

所以Yves自己的解讀就是,客戶滿意(因為問題有被解決)就是好Developer,反之客戶不滿意就代表能力不足(先不管是技術能力還是溝通能力)。Scrum框架中,最可以代表客戶利益和態度的就是Product Owner(PO),所以PO的滿意度就是開發團隊的能力指標。總之,就是到最後還是只能靠PO的主觀意見來判斷團隊甚至個別成員的貢獻。

那,重要的問題就出現了,團隊和成員的績效獎金怎麼辦呢。之前上Bas CSM的課他的建議有兩個,一是全部不要有獎金,完全在月薪反應,二是按照薪資比例均分,這個大前提是每個人的貢獻和能力已經在薪資上公平的反應出來,所以團隊的成就應該按此分配。再說用任何其他量化的方式(可以參考上一篇團隊評量),都可以很容易的被操作扭曲。

但熟讀中國近代史的都會在內心響起一個聲音,這不就是所謂的大鍋飯嗎?Yves覺得有一個最大的差異,是這些人是自願在這團隊吃大鍋飯的,所以表示這個分配模式是大家都可以接受的。加上自我組織管理的前提團隊會對不公平的行為作出反應和行動,如要求個別成員增加成長速度或甚至離開團隊。

但在進化到共產主義理想程度之前,我們目前的做法是一半的獎金按照薪資比例均分,另一半就交給主管的判斷力來分配。至於主管按照什麼來判斷呢,百分之百主觀判斷,相信落實敏捷思維的主管會按照資訊做出最適當的安排。這是一方面讓大家了解每個人都要對團隊產出負責,另一方面讓主管可以微調的折衷方法。

在 2017 年後,新加坡商鈦坦科技導入新的制度,團隊可以自行決定團隊成員一半獎金的分配比例,如果團隊不想決定就由主管來分配。

因為就反骨仔的例子而言,不成熟的團隊會覺得他白吃白喝沒貢獻,但有慧眼的主管知道有他團隊才會持續找出更好的方法啊。

圖片來源:https://www.pinterest.com/pin/33354853464677032/

作者: 敏捷黑手阿一 Yves Lin

Trying being agile in the fun way. 喜歡并相信敏捷與正念,期許能帶入一些不同的思維,能讓華語圈不只軟體產業,都可以更高效幸福,開心自在。

在〈快推別說風涼話啦 – 如何量化個別開發人員和工程師的產能〉中有 2 則留言

  1. 文中的問題;小弟也是想過很多…
    管理強調數據..沒有數據;就無法客觀比較
    但過度追求數據;整個制度又很容易被扭曲、鑽漏洞..
    最後如您的作法..一半一半吧…

發表迴響

探索更多來自 黑手阿一的實戰報告 的內容

立即訂閱即可持續閱讀,還能取得所有封存文章。

Continue reading