業務同事的績效很容易考覈，簽了多少單？賺了多少錢？清晰可見，容易衡量。對於做產品研發工作的我們來說，成本很好計算，但價值卻很難衡量。業務團隊能爲公司賺錢，研發團隊卻花公司的錢，研發團隊從此就變成了公司的“成本中心”。
我們需要有一套合理的績效考覈機制，衡量並驗證自己的價值。這套機制需要簡單易懂、操作方便，而且需要通過數據說話。有數據還有要對比，需要與自己比較，還要與別人比較。
本文將結合之前在“組織架構篇”中提到的內容，從績效考覈方面繼續探討下去。首先，我們針對研發團隊考覈模型，進行深入探討。
研發團隊考覈模型
我們的研發團隊分爲橫向“職能團隊”與縱向“項目團隊”，所有的研發人員都在職能團隊中，他們都在所在的項目團隊中，體現出自己的工作績效。因此，績效考覈是基於項目團隊進行的，而不是職能團隊。針對不同類型的項目團隊而言，需要制定不同的團隊目標，採用不同的考覈方式（如圖 1 所示）。
圖 1：項目團隊考覈方式
每種項目團隊都有共同的考覈部分，那就是“個人 OKR”，它包括兩方面：一是個人成長，二是團隊貢獻。個人成長又包括專業技能和綜合技能兩方面，前者是“硬技能”，後者是“軟技能”。個人是否得到成長，取決於和自己的曾經作比較，而並非與他人作比較。團隊貢獻包括的方面較廣，比如：技能培訓、經驗分享、償還技術債、制定並落地規範、組織團隊活動等。在本文下一節中將對 OKR 進行深入探討。
需要注意的是，個人 OKR 需要個人結合團隊目標來定義，由個人所在職能團隊來評審個人 OKR。 也就是說，OKR 是自底向上的，而 KPI 卻是自頂向下的。此外，我們認爲 OKR 和 KPI 既不衝突，還能相輔相成。將 OKR 與 KPI 有效結合，不僅可以激勵團隊成長，還能促進團隊完成公司的核心目標。
對於功能團隊而言，他們的目標是確保以最快的速度，高質量地讓項目上線。然而，速度和質量往往是相互制約的，速度太快，質量一般不會太高。也正因如此，我們才需要對功能團隊的速度加以限制，否則項目上線後，一個難以維護的成果即將誕生，可以想象，隨後效率團隊一定會踩坑無數。因此，我們需要對功能團隊定義一些“技術 KPI”，才能確保項目的順利交接，比如：上線時間、代碼質量、產品質量等。
對於效率團隊而言，他們的目標是優化現有產品功能並幫助業務實現目標。可見，業務的成功，決定於效率團隊的成功。我們無需像要求功能團隊那樣去要求效率團隊，因爲他們關心的不再是速度和質量，而是如何不斷提升業務效率，幫助業務團隊實現業務目標。因此，我們可將業務 KPI 作爲考覈效率團隊的參考標準。
對於創新團隊而言，他們的目標是幫助公司創造新的商業機會與盈利方式。往往需要通過收入的方式來考覈該團隊，我們需要同時設置業務 KPI 與技術 KPI 來驗證該團隊的價值，即投入與產出。
當然，不論哪種項目團隊，都需要考覈項目是否延期？上線後是否有 Bug？而且這些標準都應該是事先確定清楚並和團隊達成共識的。我們相信：先有共識，纔有共贏。只有大家一致認同的原則，纔可能有效地去執行。
以功能團隊和效率團隊爲例，在績效考覈的具體操作層面上，我們可採用“打分制”，根據具體情況進行加分或減分（如圖 2 所示）。
圖 2：績效考覈打分制
需要注意的是，效率團隊將對功能團隊的交付成果進行考覈，不僅是代碼，還包括文檔。確保功能團隊的 1.0 項目這根“接力棒”可以順利傳遞下去，未來在效率團隊的手中，讓它變成 1.1、1.2、1.3 等。若要開發產品功能 2.0，可認爲這是新的嘗試，同樣需要功能團隊來開發，2.0 功能上線後再次交給效率團隊進行功能迭代。
每個季度可進行一次績效考覈，具體的考覈成績將分爲 S、A、B、C 四個級別，S 表示大家心中充滿美好期待的那根線，A 表示努力跳起來就能夠得着的那根線，B 表示及格線，C 表示不及格。績效考覈的成績需要公示，考覈結束後根據具體成績進行獎金髮放。同時，個人 OKR 也在每個季度結束時進行考覈，但考覈結果不會體現在季度獎金中，而是體現到每年的加薪幅度上，因爲個人 OKR 是個人的能力提升與團隊貢獻程度的表現，與薪資掛鉤會更加合理。
關於 OKR 方面，雖然它無法直接反應在績效上，但它對團隊的成長是至關重要的，團隊成長了，績效才能提高。下面，我們專題討論一下 OKR 的十大要領。
OKR 十大要領
OKR 最早來自於 Intel 公司，隨後在 Google 公司得到了更好的應用，現在全球傑出的互聯網公司幾乎都在用 OKR。要在企業中更好的應用 OKR，完全取決於我們自己對它的認識。
OKR 包括兩大要素：O 和 KR，O 是 Objectives（目標）的縮寫，KR 是 Key Results（關鍵結果）的縮寫。O 用於描述我們心中希望通往的美好目標，KR 用於描述衡量實現這個目標的關鍵結果。
爲了讓大家更好地理解 OKR 的精髓，我們提出以下 OKR 十大要領：
- OKR 不是一款績效考覈工具，而是一款目標管理工具。
- OKR 包括自頂向下（制定）與自底向上（評審）的全過程。
- O（目標）需要做到簡潔且定性，要鼓舞人心。
- KR（關鍵結果）需要做到明確且定量，用數據說話。
- 一個季度制定一次 OKR，季度結束需對 OKR 進行評審。
- 每週做一次 OKR 回顧，每月做一次 OKR 調整。
- OKR 制定過程需進行多次評審，以確保它與上級目標不衝突。
- O 一般不要超過 5 個，O 所包含的 KR 一般爲 2-4 個。
- OKR 需要做到透明化，向團隊完全公開。
- OKR 評審結果可作爲加薪的重要參考依據，但不是唯一依據。
對於 OKR 而言，很多人容易將它理解爲績效考覈工具，認爲它和 KPI 是同類，這是一種誤解。如果將 OKR 理解爲考覈工具，我們一定無法用好它，也更無法從中受益。OKR 是一款目標管理工具，它管理的是我們所制定的目標，讓我們的目標更加清晰且容易實現。
KPI 是自頂向下的，老闆定義了 KPI，各級領導去背 KPI，員工去完成 KPI，大家各掃門前雪，達成自己的 KPI 即可。然而，OKR 卻是自頂向下和自底向上的全過程，老闆結合企業戰略去定義企業 OKR，領導結合企業 OKR 去制定團隊 OKR，員工結合團隊 OKR 去制定個人 OKR，這是 OKR 制定過程。通過一段時間的努力，隨後進入 OKR 評審過程，員工評審個人 OKR，領導評審團隊 OKR，老闆評審企業 OKR。可見 OKR 即包括了自頂向下的制定，也包括了自底向下的評審。
我們務必做到能用一句話來描述 O，這句話要讓團隊任何人都能完全理解，即簡潔且定性，還要做到鼓舞人心。例如，如果目前我們的團隊文化做得不太好，我們希望未來一個季度可以得到改善，O 如果寫成“改善團隊文化”，這句話雖然做到了簡潔且定性，但不夠鼓舞人心。我們可以將其改爲“打造更好的團隊文化，讓大家愛上這個團隊”，是否瞬間就產生了正能量？
每個 O 都有對應的 KR，它們用來說明爲了實現這個 O，應該做到的關鍵結果是什麼。KR 需要做到讓團隊任何人都能完全衡量，即明確且定量，還要做到用數據說話。例如，如果目前我們的系統架構中微服務的顆粒度較大，代碼的可重用性方面比較低，爲了解決這個問題，我們希望對微服務邊界進行切分，如果將其中一個 KR 寫成“切分顆粒度較大的微服務”，這樣是不合乎要求的，我們可將其表述爲“至少切分 3 個顆粒度較大的微服務”，增加了一個數字來描述，這樣的 KR 就更加容易衡量了。數字是最容易衡量的，此外“有”和“沒有”也比較容易衡量。
通過實踐我們發現，一個季度制定一次 OKR 是非常合理的，季度結束需對我們所制定的 OKR 進行評審。OKR 並非制定後就無法調整了，我們自己每週可做一次 OKR 回顧，自行將有問題的地方記錄下來，職能團隊每月在一起可做一次 OKR 調整，以及時修正我們的 OKR。對於個人 OKR 而言，並非完全由自己制定後就開始執行，個人 OKR 制定過程需要進行多次評審，以確保它與團隊 OKR 不衝突。O 和 KR 的數量也有限制，O 一般不要超過 5 個，O 所包含的 KR 一般爲 2~4 個。
最後，需要說明的是，OKR 要做到透明化，可用電子表格或紙質卡片來管理，這些表格需要向團隊完全公開。此外，每個季度末的 OKR 考覈結果可作爲加薪的重要參考依據，但不是唯一依據。
我們作爲團隊領導者，也需制定自己的 OKR，以下是一位研發團隊領導者的 OKR 示例（如圖 3 所示）。
圖 3：一位研發團隊領導者的 OKR 示例
寫在最後
一個團隊需要有目標，也需要對目標完成情況加以考覈，目標與考覈往往是相輔相成、缺一不可的。如果只有目標而沒有考覈，將無法檢驗團隊的價值；如果沒有目標而只有考覈，團隊將離我們越來越遠。
OKR 不是績效考覈工具，而是目標管理利器，所有人都能理解 OKR 的定義，但不是每個人都能很好的應用它，這也正是 OKR 的魅力之處，往往好的工具都是理解容易，但應用不易。大家可參考我們給出的 OKR 十大要領，再根據自身實際情況加以調整，就能順利地實施 OKR，在組織中發揮出它的效果。
我們認爲，衡量結果好壞的最簡單手段就是數據，只有數據纔會讓人信服，績效考覈關鍵就是用數據說話。
作者簡介
黃勇，現任特贊科技 CTO，圖書《架構探險》作者，開源項目作者，技術大會講師，企業培訓師。十年以上互聯網軟件架構與技術管理經驗，擅長敏捷開發，推崇“輕量級”架構思想。喜歡閱讀，熱愛交流，樂於分享。