最近聽朋友推薦，讀了《阿米巴模式》這本書，正好最近在思考IT部門內部績效考核的事情，所以就有了一些靈感和想法，正好在這里與大家一同分享和探討。

團隊考核存在的問題

現在創業公司的技術開發部門其實很難進行考核，無論是KPI還是OKR，我覺得在實際操作過程中都有不少問題，這不是說考核的方法不對，而是我覺得在落地操作的時候并不那么的接地氣，那么問題或者阻礙有哪些呢？

?1、目標不明確

這是創業公司都會存在的問題，因為創業公司的首要任務是活下去，所以朝令夕改，邊做邊調整的情況是司空見慣的，而習慣于瀑布式開發的團隊，對于這樣的做法做著做著就不行了，關鍵是開發人員非常反感需求的頻繁調整，這對于開發團隊的士氣也會造成較大的影響。

那么有人會說，敏捷開發不就解決這些問題了？是的，在一定的條件下，的確可以解決問題，但是這對于開發人員、項目經理、產品經理，甚至于部門負責人的要求都是非常高的，真正用好敏捷開發的我自己看來屈指可數。

2、考核的依據過于主觀

一般來說，無論哪種考核方式，都是要評估工作量的，但是開發與賣產品不一樣，開發人員在接到任務的時候，其實是不知道要做多久的，很可能都是做著做著發現其實需求并不合理，一問業務部分，然后又改了需求，但是修改之后工作量可能就變化了（這個關于工作量的問題，我也是在讀《人月傳說》時特別有感受），所以大部分的項目都是由項目經理來評定的，萬一項目經理的經驗不準，或者老板極其強硬的縮短開發周期，那么團隊就會死的很難看了。

尤其是拼命干了之后，開發人員并沒有得到充分的認同，對老板來說可能老板更加相信是自己的眼光和遠見，團隊越是這樣完成任務，接下來任務會更緊，而且變得更加的理所當然，這也是程序員特別苦悶的地方，誰讓我們IT人當老板的不多呢？

3、考核最終的呈現不透明

一般我們IT人員搞開發，大部分還是拿穩定薪水的，畢竟不壓榨開發人員，公司哪里來的收益，資本主義的概念在現代開發項目中最有體現，尤其是老板是業務出生的，你跟他說工作量，這個用了什么技術，那個通過什么算法，老板基本都是云里霧里，那是為什么？因為不懂啊，不懂技術啊，因為不懂所以天然就會懷疑，因為懷疑所以并不理解技術人員在完成項目過程中的辛苦與汗水，完成之后，好一點的給個項目獎，但是因為整個過程沒有得到最希望認可的人來理解，那么就算完成了還是成就感缺缺。

歸根結底，對于技術人員開發的考核不透明，對開發人員自己不透明，做的只有自己知道，對外就更不透明，大部分開發人員做出來的功能，其實是沒人去用的，處理自己和測試人員，沒人知道這個功能有多棒！

那么，是不是有什么方法解決呢？

有啊，比如：招個特別牛的IT總監就可以，因為人家經驗豐富，對于這些問題應該比較了解，通過他再跟老板溝通應該就會好，當然這也是很多企業解決的方法，但問題是，我看到更多的還是CTO是個大坑這樣的言論（各位CTO先不要噴，并不針對人，只是存在這種存在情況）。

對此，有何方案

那么這三個問題，有沒有辦法解決？ 目標該怎么定？工作量怎么評估？如何通過考核透明向老板正名？

看了《阿米巴模式》之后，我就有了下面的一個實施方案，拿出來大家討論討論：

1. 由全體人員對工作量進行評估，而不是僅僅由項目經理負責；
2. 評估之后取全體人員評估的平均值；
3. 選3個開發人員，按照其對于團隊的了解，基于平均值進行調整，最后選用最合適的方案，方案使得每個人的工作量最終應該差不多時間完成，而團隊以完成最長的那個人評估的工作量作為整體項目完成時間，而方案的擬定人作為這個項目任務的負責人；
4. 項目實際開發時，計算個人實際完成和團隊實際完成天數，比照原來估計的分別產生個人完成效率和團隊完成效率；
5. 個人完成效率可以迭代到下一次任務中作為平均值調整的參數，團隊完成效率之外可以再提供一個項目完成時的表現打分，僅僅是大家對于開發人表現的打分，其實也可以理解為，大家對于個人在整個項目完成過程中這個人對于團隊的共享價值。

依次反復之后，會有一些結果， 我自己按照上述方法在我自己的開發團隊執行了4次，第一次誤差比較大，畢竟沒有什么借鑒，但是隨著一次一次的嘗試，一方面團隊的人員會比較熟悉這套方法，除了每個人具體評價的值不透明，所有過程都是透明的，公開的，自己都可以計算；另一方面的確有激勵的作用，畢竟原先一個人評價20天完成的任務，12天完成了，成就感就非常高（無論是團隊內部，還是上升到老板層面），所以解決了上述的一些問題。

但是，這個方法本身還存在問題需要繼續完善，比如：除了開發其他崗位的執行并不理想、人員太少的情況下不太適合、臨時或者突發增加的任務依然還需要靠項目負責人來分配等等，這也沒辦法。但是，我希望通過團隊和大家的努力共同打造一個合適我們IT技術人員的考核方法。

謝謝各位花時間閱讀！

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