咱們真的須要KPI嗎?

前言

工做十幾年，經歷過很多的公司，每一個公司都有本身的管理方法，其中大公司比較偏心使用KPI考覈，小公司則直接靠人來管理。下面談談以前公司KPI考覈制度和如今「鬆散」管理的對比。

嚴格的KPI制度

以前的公司在武漢研發中心有大概五六百的技術人員，每一個團隊的項目經理只考慮需求溝通、任務分配和資源協調。徹底不用管團隊成員是否有認真幹活，員工的管理依賴KPI制度。當時開發崗的考覈制度大體以下：

工做量

任務系統的任務都會評估出一個工做量，以天爲單位。計算方法爲在季度末算出整個季度中完成的工做量和總出勤天數的一個比例。代表上看這個指標很是好，公司不用怕員工偷懶，相反員工還會主動去找事情作，由於擔憂工做量不夠。當因爲各類任務之間的銜接、各類內耗，每每會形成「忙」的假象。

bug量

bug量的計算方法是一個季度所作的任務的有效bug量和所作任務的工做量的一個比例，最終算出天天的平均bug量是多少，再根據這個bug量來打分。設置bug量這個指標的初衷是爲了提升開發人員的開發質量，減小測試與開發之間往返的消耗。但這個指標至少會帶來兩個弊端：

一、開發人員和測試人員的對立

由於測試崗也有bug量的質量，他們是平均每日找到多少個bug，因此不少時候開發人員都在和測試人員糾結bug有效性的問題，其實開發 和測試的目標應該是一致的，都是爲了軟件可以高質量的交付。

二、事不關己，高高掛起

常常會在項目中發現一些不合理的代碼，若是這些代碼不是本身負責的，開發人員不會去進行重構，由於可能會帶來更多的缺陷，而這些缺陷最終會記在修改者的頭上，即使重構不會帶來任何的風險，也沒有人會關心這個，人們更多關心的是軟件能不能正常的運行。正是因爲這個指標的存在，隨着時間的增加，項目中的壞味道會愈來愈多。

關鍵節點達成率

任務系統中的每一個任務都會設置關鍵節點，對於開發來講關鍵節點就是某個任務提交測試的時間點。計算方法是未超時的任務數和總任務數的比例。這項指標的初衷是保證開發的效率，但也帶來了一些問題：

一、互幫互助少了

雖然公司一直都強調同事之間要多溝通，多互相幫助，但正是有了這個指標當你的任務已經快到關鍵時間點的時候，你就沒有多餘的時間去顧及其餘的事情了。

二、多任務的處理

當你正在處理設置了關鍵節點的任務的時候，忽然來了緊急bug任務，正常邏輯應該是優先響應緊急bug，但也有了這個指標，開發人員就會先保證當前任務不超時，而不會去響應bug需求哦。

「鬆散」的管理模式

近些年在一箇中小公司負責產品團隊，團隊規模很小，天然也就沒有嚴格的KPI考覈制度，開發人員都是有個性的，都不會喜歡被KPI所束縛。但沒有KPI制度的管理也會碰到各類問題。

太理想化

我一直想象的理想團隊是每一個成員都應該是自我驅動型的，當須要經過制度或是人來管的時候，天然是作很差事情的。現實狀況是，人都是有惰性的，團隊並不會了一個偉大的共同目標去努力奮鬥，天天朝九晚九僅僅只是當成了一個工做。起初最典型的一個表現是，分配的任務老是在截至時間的最後時刻完成。

公平

沒有KPI這種量化的考覈，對團隊成員的考評就會偏主觀，就可能帶有感情色彩，就可能有失公平。作事快的人可能會被分配更多的任務；bug多的人可能會感受一直都處於「忙碌」的狀態；效率高的人可能會被認爲不夠努力。

總結

任何管理方式都會各有利弊，包括最近兩年比較火的OKR，相信在實踐過程當中同樣會遇到各類問題。既然都會遇到困難和問題，我我的仍是偏向鬆散的管理模式。

鬆散的管理模式，並非說無論理，而是要努力作到讓每位團隊成員從「要我作」到「我要作」的轉變。我認爲能夠嘗試如下一些方式：

一、領導要對團隊成員要有足夠的信任，用人不疑，疑人不用；二、技術人員廣泛比較悶，不肯說出心裏真實想法，須要常常和他們去溝通，瞭解他們心裏真實想法，能力範圍以內解除他們後顧之憂；三、團隊內部須要常常組織一些活動，提高團隊凝聚力。好比一個開發階段完成後，組織吃飯唱歌等；四、按期給團隊內部培訓，要讓每一個成員都瞭解產品的思想，瞭解客戶真實需求，瞭解公司的願景。目的是讓你們可以一塊兒爲了一個共同的目標努力，而不僅是本身負責的一個功能模塊。但同時也要階段性讓團隊成員看到收益，而不僅是畫餅子；五、創建獎懲制度，賞罰分明，公平、公正、公開；六、若是公司領導容許，或許能夠嘗試下阿米巴的方式。