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

團(tuán)隊(duì)考核存在的問題

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

?1、目標(biāo)不明確

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

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

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

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

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

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

一般我們IT人員搞開發(fā)，大部分還是拿穩(wěn)定薪水的，畢竟不壓榨開發(fā)人員，公司哪里來的收益，資本主義的概念在現(xiàn)代開發(fā)項(xiàng)目中最有體現(xiàn)，尤其是老板是業(yè)務(wù)出生的，你跟他說工作量，這個(gè)用了什么技術(shù)，那個(gè)通過什么算法，老板基本都是云里霧里，那是為什么？因?yàn)椴欢?，不懂技術(shù)啊，因?yàn)椴欢蕴烊痪蜁?huì)懷疑，因?yàn)閼岩伤圆⒉焕斫饧夹g(shù)人員在完成項(xiàng)目過程中的辛苦與汗水，完成之后，好一點(diǎn)的給個(gè)項(xiàng)目獎(jiǎng)，但是因?yàn)檎麄€(gè)過程沒有得到最希望認(rèn)可的人來理解，那么就算完成了還是成就感缺缺。

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

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

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

對(duì)此，有何方案

那么這三個(gè)問題，有沒有辦法解決？ 目標(biāo)該怎么定？工作量怎么評(píng)估？如何通過考核透明向老板正名？

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

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

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

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

謝謝各位花時(shí)間閱讀！

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