時間過得很快，一轉眼就是1個月過去了，這個月里面我按照之前的設想執行了新的考核方法，具體可見《一個案例：創業公司的開發團隊考核新方法探索 》，于上周整個項目終于上線完成了，而經過幾天的整理，我也重新回顧了一下整個過程，下面跟大家一同分享一下。

一個案例（續）

在整個開發開發過程中，團隊人員沒有變化，于上周完成所有任務并部署到正式環境中，按照新的考核方法，對整個開發成果進行了評定。

5、項目結果評定（個人部分）

新的考核方法中，我們對于所有開發人員的工作量認定是由全體成員共同參與并決定的，這個是認定值，而根據每一個開發人員的實際開發情況得到的完成情況，則是實踐值，其結果匯總的情況如下：

對于上表中需要說明的包括：

1）開發過程

開發過程是在項目啟動之后，由相關部門提出的修改意見，雖然我們已經做了非常多的努力（公司每一次開發有內部的審批流程保證），但是依然無法杜絕需求的層出不窮，不過有了新的考核方法之后，對于新增的需求評定就容易了很多，此次項目增加后的工作量就是由項目負責人根據實際完成情況以及開發人員和產品經理的意見之后確認的，雖然也會有誤差，但是相對于之前的拍腦袋更加有依據。

2）個人基礎得分

個人基礎得分是根據提前完成的工作量計算得到的，計算方式很簡單，以 開發1 為例：

個人基礎得分 =? (9+5-9) / (9+5) = 5 / 14 = 3.57

如果有未能如期完成的開發人員，那么設置最低為0分，即沒有提前完成的積分獎勵。

3）個人調整得分

個人調整得分是由【個人基礎得分】與【個人系數】的乘積得到的，【個人系數】我們統一設為0.5，這是因為我期望的是個人的努力與團隊的努力應該各占一半。

6、項目結果評定（團隊部分及最終評定）

這部分的評定是由團隊全體人員對每一個人在整個項目中的表現打分，分值從0-10分，可以自己衡量一個標準的人員作為標桿，將其定義為5分，比這個標桿好的，則分數超過5分，反之亦然。這里面包含的內容就很多了，畢竟一個項目剛開始的時候很難確認其具體的過程是難是易，是不是有人搗亂，這些內容無法非常標準的進行客觀評價，所以直接開放由所有人打分，但是這里要特別說明的是，作為部門的負責人一定要自己心里有數，誰的表現更好，誰的表現更糟，并且能夠正確的引導和指引團隊成員更加有效的打分，比如我在此次評定的時候，會講一些例子，XXX完成的很快，然后幫助XXX加快了完成進度，產品經理收到了很多需求，但是并沒有全盤接受，而是有選擇的進行接受，并與開發人員溝通很流暢等等，這些都是可以作為加分項，而同時，如果有開發人員在開發過程中，只顧自己，完全沒有團隊意識，造成調試和接口傳輸的時候有很多坑的，這些就是負面案例，好在我的團隊還沒有這么糟糕的情況，還是先把團隊的評價情況拿出來看看吧：

對于上表中需要說明的包括：

1. 團隊也是有基礎分的，就是以【個人基礎得分】最低的人為準，因為開發任務完成是以最慢完成人為準的。
2. 【團隊評價】是由所有人進行打分之后，取平均值得到的評分，雖然我期望的是能夠接近5分，但實際看來還是超過了我的預計。
3. 【團隊調整得分】是由上面兩項以及【團隊系數】再除以10（因為團隊評價是0-10分的，需要除以10進行調整）得到的。
4. 【總分】是由【個人調整得分】和【團隊調整得分】的合計值。

7、總結和體會

以上只是將計算過程展示出來了，但是我期望新的考核方法能夠帶來更多的改變，所以我總結了一下自己的體會，與大家一同分享：

1）參與感加強。 這個應該從提出新的考核方法時，就是這么期望的。因為從項目開始，到最終評定，所有團隊成員全部參與到目標制定和最后執行的過程中，除了大家各自打分值不清楚之外，其他所有的步驟以及完成情況全部是透明的，能夠達成開發人員可以更加合理的安排自己的開發任務，如果有很強的上進心和目標性，會主動加班，即便不是在單位里面，回到家里也會一樣加班，我覺得就是因為每個開發人員清楚知道自己能夠達到的成就，所以會愿意付出更多的時間和精力。

2）效率提高了。由于有了透明的計算方式和實現過程，每一個開發人員都會注意到其他人的完成情況，也會知道自己在團隊中的位置和完成情況，雖然我們一直說不要在意他人的意見，但是程序員本身還是愿意競爭的，所以沒有人愿意自己表現的比別人差，而因為目標和過程的透明性，使得大家有強的自主性完成任務，在潛移默化中團隊整體的效率提升了，對于團隊本身管理來說也是樂見其成的。

3）溝通能力得到鍛煉。與產品經理不同，程序員一般溝通能力比較差，而此次項目中，我覺得溝通能力其實每一個團隊成員是提高的，我仔細想了一下，因為制度透明，大家都愿意為了統一目標努力，而且整體的工作氛圍是非常正面和良性的，這就使得大家在溝通的時候更加耐心，也更加原因傾聽和表達，而這點我其實是非常欣慰和提倡的，也算是這個新方法推行之后的以外之喜吧！

寫在最后

任何事情都有兩面性，就像此次推行的考核方法有值得肯定的地方，也有很多不足，比如：對于開發人員的考核只見正面未見負面（其實負面是放在測試人員的考核中，以抓bug的數量作為依據）、個人得分與團隊得分相比更加被重視（是的，這是設計之初就想到的，是希望更加容易推行新方法，后續應該會調整）、團隊規模問題等等，這些問題我也同樣在思考和分析，希望通過更多的方法來客服，畢竟這個是一種嘗試和探索，并不能說很成熟，但是至少走出了一小步。

新的考核方式是一種嘗試，最后的目的是體現技術人員的價值，而這個價值是標準和非專業認可的，自從實施該方法之后，其他部門的認可度是慢慢提高的，至少原先很難溝通的地方也逐漸理解和明白了，我覺得這個是意外的收獲，但是同樣也很重要，畢竟一個公司的成長不會僅僅依賴幾個人，還是要靠所有人的！

謝謝大家，我也希望繼續分享自己的項目和產品心得希望大家共同進步！

相關閱讀：

一個案例：創業公司的開發團隊考核新方法探索

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