分數怎麼給？ – 如何評量開發團隊

關於軟體開發最經典的問題就是，要如何評量開發團隊？這不但是管理人員最頭痛的問題，連開發人員也很想知道自己怎麼被評量的。我們來看看能不能由產品（程式）或生產線（開發人員）上，找些東西幫助管理人員對開發團隊打分數。

從程式方面來說，常用的評量方法有

1. Number of Line of Code
   1. 幾行程式，越多越好。跟報告越厚老師給分數越高的道理相通。
2. Bugs per Line of Code
   1. 比第一個進步一點，Bug 除以程式，越少越好。聽起來合理，但好像處罰寫出精簡的程式碼的人。
3. Code Coverage
   1. 既然測試很重要，那測試覆蓋率越高總沒錯。但這分不出有效跟無效的測試。
4. Function Point
   1. 一個商業需求算一點，看完成幾個Function。聽起來很合理，但回到Function Point是誰定的呢？一般來說是PM，那PM是團隊的一員嗎？有沒有可能灌水呢？
5. Story Point / Velocity（跑Scrum團隊專用）
   1. 儘管老師都有說不要用Velocity打分數，但裝作沒聽到的人還是很多。原因呢？別忘了Story Point是誰給的。
6. Release 次數
   1. 一個Sprint 有多少Release 到Production。聽起來合理吧？但聰明的工程師不會分幾次Release嗎？

別誤會，上面有些數據都是可以拿出來參考，但有兩個前提，才能有效跟不失真。

第一個是團隊認為這指標很重要，第二個是這些指標要跟績效評量沒關係。

指標要跟績效評量沒關係！

指標絕對要跟績效評量一點關係都沒有！！（很重要！！！！！）

至於人員工作效率部分，常用的方法有

1. 待在電腦前多久
   1. 打卡計時，越久越好。
2. 打字速度有多快
   1. 打字越快output越高，最好鍵盤聲不絕於耳，像在彈鋼琴。
3. 看起來像不像工程師
   1. 越宅越好，不解釋。

看出上面的評量有什麼共通點嗎？

第一點，以上就算做到了，也不一定是好的產品。而且聰明的工程師一定可以讓數字變好看。

第二點，就是都沒解釋為什麼要開發這個軟體。

就像是搭計程車，不關心怎麼到達目的地，反而一直看司機有沒有坐端正，引擎轉速有沒有上四千。這些指標都是為了到達目的地，所以到目的地更重要。熟悉KPI制定的朋友，都知道KPI要衡量的是結果。而我們軟體開發出來是為了什麼呢？是為了充市佔率？如是為了賺錢？還是做爽的？

所以Yves覺得比較靠譜的衡量開發團隊能力的指標如下，可以針對組織情況和目標來選擇合適的：

1. 賺錢是重點
   1. 產品帶進來的毛利
   2. 毛利 / 開發與維護費用（每一塊錢的開發和維護費用可以換來多少收益）
   3. 毛利 / 開發團隊人數（收益人效）
2. 市佔率是重點
   1. DAU（Daily Active User）
   2. MAU（Monthly Active User）
   3. MAU / 開發與維護費用（每一塊錢的費用可以換來多少使用者）
   4. MAU / 開發團隊人數（使用者人效）
3. 爽是重點，不要小看這個，尤其是內部系統
   1. 關鍵stakeholders，包含老闆，有多高興
   2. DAU / MAU （黏著度）
   3. 客訴和發生問題的次數
   4. 客訴和發生問題的次數 / MAU
   5. 客戶滿意度

但這重點是衡量全體開發團隊，包含企劃、美術設計、工程師、營運人員、Product Owner、Scrum Master甚至主管，總之是掌控一個產品運行的全部人員。

至於個別人員的評量呢？主管跟PO好辦，就是跟所負責的產品掛鉤。其他角色的部分就比較複雜了，參考一下如何衡量個別開發人員的績效吧。

圖片：http://www.91q8.com/h5evhkqb4y2.html

作者: Yves Lin

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