之前在這里跟大家分享了一篇關于開發團隊考核的想法 《思考：在創業公司，該如何解決技術開發團隊的考核問題？》，沒想到大家的反饋很積極，有一些也發來了疑問，那么我想可能寫一個實際的操作案例可以了解的更加清楚。所以，這兩天抽時間寫了一個，希望可以對大家的疑問有一些解釋；同時，也希望通過這個案例來改進和發現一些問題，使得我們在實際的管理中可以有更加進一步的探索和成果。

一個案例

我管理的開發團隊差不多有9個人，1個產品經理、1個前端、2個測試、5個開發人員，從開始實踐新的考核方法已經經歷了3個項目，目前正在進行的一個開發任務是第4個，我就以目前的這個為例，來說明一下整個的過程吧。

1、基本定義

在整個操作中會有一些基本的名詞定義需要約定和說明。

效率比： 指完成一個項目的時效比。

比如： 認定的完成期望是20天，實際操作中用了16天就完成了，那么效率比就是：16/20=0.8，即這個項目的效率比就是0.8。

2、基礎數據

就是為了執行我們的這個新考核方法需要收集和統計一些基礎參數，說明如下：

開發效率比。以之前經歷過的3個項目為樣本數據，計算每一個人員平均值（如下圖）

3、項目評定

雖然已經經過了3個項目的鍛煉，但是在實際操作中依然遇到了不少問題，畢竟要讓開發人員像產品經理一樣去思考需求還是有點困難的，不過這個還是要做的，此次的溝通和前期準備差不多用了1周的時間。以開發人員的評價情況為例：

通過以上的打分，可以計算得到每個開發的平均值，當然為了使得團隊每個人參與性較高，功能模塊是自發認領的，并且在準備的這1周時間內，需要對全部的需求都有了解，然后在評定的過程中，發表自己的建議，由其他人根據初步認領結果和評定的情況，對人和功能進行打分評價。

4、項目評定調整

我挑選了3個團隊人員（選取的標準還是看在團隊中對于業務、需求和能力較強的）作為候選評定方案的擬定人，他們要做的事情分別是：

（1）根據以上的平均值，通過效率比進行調整核算，按照以上的平均值，我們重新計算后結果如下：

在以上計算中，我發現效率比可以進行參數調整，比如：開發1計算的效率比為0.89，但是直接拿這個值計算，對于開發的壓力就比較大，那么為了推進和緩和，我們可以打個折扣，80%，計算為 1-（1-0.89）*0.8，為 0.91，當然如果任務壓力大，可以提高這個值，甚至就像銷售指標一樣，超額提高一樣；

（2）發現調整值差距較大，9.28 和 14.17，分別為最低和最高值，所以這個時候就需要發揮擬定人的想象力了，需要重新調整原先的認定值，在這里各位肯定要問，這不又回到原先主觀判斷的老路上了嗎？我想還是有點差別的，首先認定值本身調整的依據比原來項目經理自己拍腦袋想要靠譜（畢竟是大家自己打分出來的），其次每次項目的擬定人會變化，通過人員權利的傳遞克服一個人主觀判斷的問題。

在實際操作中，有一位擬定人的打分結果并不理想，直接忽略，而兩個擬定人比較之后，確認的調整結果如下：

其中，開發1的去掉了0.5天，開發2去掉了1天，開發4去掉4*1.7=6.8天，開發5增加8.3天，然后最終計算后，就是上面的結果，跟我們的目標比較接近，差不多整體在10天左右完成，所以整體項目的開發時間為10天。

至此，完成了開發人員的工作量評定，那么測試人員的工作量是多少呢？

我的計算方式如下：

開發人員調整值合計*測試人員評定系數/測試人員數量

58.33*0.5/2 = 14.58

另外，產品經理的工作如何恒定呢？我是通過小量工作合計的方式進行計算的，例如需求是一個功能或者一個模塊來確認的，所以一個模塊，我分給產品經理3天，如果可以2天完成，那么這個小項目就是3-2的關系，最后將所有的小項目合計就可以了。

寫在最后

目前來說，這個項目還在進行中，等到項目完成之后，可以將結果作為一個單獨案例與大家一同分享。整個過程中我希望能夠體現的點：

1. 將計算透明化，激發開發人員以及整個團隊人員的工作熱情。
2. 將權利下放和轉移，激發整個團隊的管理意識，同時克服一個人主觀判斷。

當然，存在的問題還有不少，希望通過分享可以改善技術人員的管理現狀，讓開發人員和我們團隊領導者都可以滿意！

本文由 @加減乘除?原創發布于人人都是產品經理。未經許可，禁止轉載。