思考:在創業公司,該如何解決技術開發團隊的考核問題?

3 評論 10025 瀏覽 32 收藏 8 分鐘

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

團隊考核存在的問題

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

?1、目標不明確

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

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

2、考核的依據過于主觀

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

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

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

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

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

那么,是不是有什么方法解決呢?

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

對此,有何方案

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

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

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

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

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

謝謝各位花時間閱讀!

 

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 選3個開發人員,按照其對于團隊的了解,基于平均值進行調整
    不太明白這個是怎么操作的。

    來自浙江 回復
    1. 計算之后的平均值是有高低的,假設一個開發團隊是6個開發,計算之后的平均值分別是 20、18、16、17、21、16,但是因為每一個人的效率比不同,比如6個開發的效率比為:0.8、0.5、0.7、0.7、0.8、0.9,這樣的話,重新按照效率比計算后得到:16、9、11.2、11.9、16.8、14.4,如果按照這個工作量開發,就會發現作為一個團隊,大家的完成速度差別太大,至少是預期的情況下已經有較大差異了(9 和 16.8),所以這樣肯定不合適,我期望的目標是大家能夠差不多時間完成,比如: 15 和 16,這就意味著,之前的平均值需要調整以滿足最后大家的工作量能夠差不多,所以這個時候需要有人進行調整,但是如果只是一個人,主觀性太強,而且容易考慮不周,所以我想到的辦法就是從開發中選3個人,目標是能夠達到完成速度差不多,但是調整的過程會不同,比如:可以將10個報表的任務,分解一下,如果沒有那么好分的,對于牽涉開發工作量比較大的,比如7天的開發,就可以分解一下,讓2個人分別做4天,雖然2*4=8超過7了,但是時效上卻是提高了,從7天降為4天了。那么又因為每個人的思考過程不一樣,有的對于7天是按照 4/4分解的,有的是按照 3/3/3分解的,那么只要有充足的理由或者想法,我都是接收的。再要具體的話可能需要以一個實際案例來說明,我看看這兩天有空的話,可以寫一個大家可能就比較有感覺了,謝謝

      來自上海 回復
  2. 重溝通輕文檔的敏捷式開發模式
    最大的核心就是每個成員角色都要主動,盡責

    回復