關於軟體開發最經典的問題就是,要如何評量開發團隊?這不但是管理人員最頭痛的問題,連開發人員也很想知道自己怎麼被評量的。我們來看看能不能由產品(程式)或生產線(開發人員)上,找些東西幫助管理人員對開發團隊打分數。
從程式方面來說,常用的評量方法有
- Number of Line of Code
- 幾行程式,越多越好。跟報告越厚老師給分數越高的道理相通。
- Bugs per Line of Code
- 比第一個進步一點,Bug 除以程式,越少越好。聽起來合理,但好像處罰寫出精簡的程式碼的人。
- Code Coverage
- 既然測試很重要,那測試覆蓋率越高總沒錯。但這分不出有效跟無效的測試。
- Function Point
- 一個商業需求算一點,看完成幾個Function。聽起來很合理,但回到Function Point是誰定的呢?一般來說是PM,那PM是團隊的一員嗎?有沒有可能灌水呢?
- Story Point / Velocity(跑Scrum團隊專用)
- 儘管老師都有說不要用Velocity打分數,但裝作沒聽到的人還是很多。原因呢?別忘了Story Point是誰給的。
- Release 次數
- 一個Sprint 有多少Release 到Production。聽起來合理吧?但聰明的工程師不會分幾次Release嗎?
別誤會,上面有些數據都是可以拿出來參考,但有兩個前提,才能有效跟不失真。
第一個是團隊認為這指標很重要,第二個是這些指標要跟績效評量沒關係。
指標要跟績效評量沒關係!
指標絕對要跟績效評量一點關係都沒有!!(很重要!!!!!)
至於人員工作效率部分,常用的方法有
- 待在電腦前多久
- 打卡計時,越久越好。
- 打字速度有多快
- 打字越快output越高,最好鍵盤聲不絕於耳,像在彈鋼琴。
- 看起來像不像工程師
- 越宅越好,不解釋。
看出上面的評量有什麼共通點嗎?
第一點,以上就算做到了,也不一定是好的產品。而且聰明的工程師一定可以讓數字變好看。
第二點,就是都沒解釋為什麼要開發這個軟體。
就像是搭計程車,不關心怎麼到達目的地,反而一直看司機有沒有坐端正,引擎轉速有沒有上四千。這些指標都是為了到達目的地,所以到目的地更重要。熟悉KPI制定的朋友,都知道KPI要衡量的是結果。而我們軟體開發出來是為了什麼呢?是為了充市佔率?如是為了賺錢?還是做爽的?
所以Yves覺得比較靠譜的衡量開發團隊能力的指標如下,可以針對組織情況和目標來選擇合適的:
- 賺錢是重點
- 產品帶進來的毛利
- 毛利 / 開發與維護費用(每一塊錢的開發和維護費用可以換來多少收益)
- 毛利 / 開發團隊人數(收益人效)
- 市佔率是重點
- DAU(Daily Active User)
- MAU(Monthly Active User)
- MAU / 開發與維護費用(每一塊錢的費用可以換來多少使用者)
- MAU / 開發團隊人數(使用者人效)
- 爽是重點,不要小看這個,尤其是內部系統
- 關鍵stakeholders,包含老闆,有多高興
- DAU / MAU (黏著度)
- 客訴和發生問題的次數
- 客訴和發生問題的次數 / MAU
- 客戶滿意度
但這重點是衡量全體開發團隊,包含企劃、美術設計、工程師、營運人員、Product Owner、Scrum Master甚至主管,總之是掌控一個產品運行的全部人員。
至於個別人員的評量呢?主管跟PO好辦,就是跟所負責的產品掛鉤。其他角色的部分就比較複雜了,參考一下如何衡量個別開發人員的績效吧。
圖片:http://www.91q8.com/h5evhkqb4y2.html
This depends in your state, nevertheless.
scurm team 好像都會遇到這個問題
如何評估 team member 是困難的..
所以就不要評估了..(誤 XD)
哈哈,有點劇透關於Team Member的評量
這應該是每個 scurm team 都會遇到的問題…
實在是很難評估每個 team mebmer
是的,Team member的衡量又比Team總體的衡量要困難許多。