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

團隊考核存在的問題

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

?1、目標不明確

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

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

2、考核的依據(jù)過于主觀

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

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

3、考核最終的呈現(xiàn)不透明

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

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

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

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

對此，有何方案

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

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

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

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

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

謝謝各位花時間閱讀！

本文由 @加減乘除?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。