寫在前面
隨着 OKR 在國外英特爾、谷歌等公司，國內字節跳動、華為等公司的成功實踐，越來越多的企業意識到 OKR 對於組織發展的重要性，開始紛紛引入 OKR。引入 OKR 企業文化，一款強大的 OKR 工具必不可少，CODING OKR 可以為企業提供豐富的過程實踐和協作提醒，提升員工敬業度並促進公司運營和產研運維一體化的成功。下文將以 CODING OKR 為例，闡述大多數企業在推行 OKR 時會遇到的問題以及一些思考。
網絡上常見的 OKR 定義
1、OKR 與 KPI 的區別
OKR 的定位首先是溝通工具，是一個 plan-do-check-action 的循環，OKR 要求的是如何更有效率地完成一個有野心的項目，所以眾多項目管理工具廠商喜歡設計 OKR。而 KPI 的本質是一種管理工具，它主要是從結果上來考察績效，不關注過程，一切用指標來說話。KPI 強調的是如何保質保量的完成預定目標。
KPI 理論上是必須嚴格按照 SMART 標准制訂的，是否達到甚至達到比例多少（小於 100% 還是大於 100%）都是要能測量的。而 OKR 目標的設定是要有野心、有一些挑戰、有些讓你不舒服的。一般來說，“最佳”的 OKR 分數在 0.6-0.7 之間，如果某人拿到了 1 分，那么他的 OKR 制訂的目標顯然是野心不夠的；但是低分數的人也不應該受到指責，而是應通過工作上的數據，幫助他改進下一季度的 OKR 目標。CODING OKR 也即將引入評分系統和評分報告，幫助企業更快速地建立反饋機制，幫助員工更好的樹立責任感。
CODING OKR 可以關聯事項，通過關聯事項的完成情況去標示進度並且動態記錄，從而去評估 OKR 的最初制定和最終完成是否有強關聯導向，方便負責人隨時靈活調整。
目標可以跨項目關聯，關聯事項與目標和關鍵結果的進度互不影響
基於 OKR 是挑戰舒適區的定義來看，承諾目標可以理解為 KPI，超常規設定目標可以理解為 OKR。OKR 是路徑，KPI 是結果，不變的是結果，變的是路徑，KPI 有非常強的結果導向，而 OKR 需要多個迭代循序漸進，這跟 CODING 提倡的敏捷 Scrum 的中心思想特別類似，都需要敏捷執行，快速擁抱變化 。
2、 OKR 推行多久才能感受到效果？
OKR 本身並不復雜，相較於其他傳統的管理工具來說，簡單易操作，越是簡單的事物越有生命力。一般來說，OKR 在企業中運行一個周期后（一般情況下一個周期是指一個季度，但也可執行雙月 OKR ，例如飛書），團隊就可以掌握 OKR 制定、對齊、跟蹤、復盤等各個環節的操作流程和方法。經過兩三個周期后，團隊可以根據自身工作的實際情況，對 OKR 的操作進行一些優化，使其與實際的工作場景和業務流程更匹配。四個周期以后，團隊將會更多地思考如何用 OKR 促進自我成長和實現組織目標。所有這些變化，帶給團隊最大的收獲就是感受到希望，並推動他們更加主動地促進這些積極的變化。
OKR 和其他管理方式一樣，都是為了幫助組織提高資源利用的效率，資源的數量和質量對利用企業資源的目的並不會產生直接影響。我們運用 OKR，應當追求突出 OKR 聚焦戰略、注重邏輯、對齊協同、自下而上、公開透明、積極反饋的特征，只有在實踐中不斷強化這些特征，OKR 才能發揮其應有的作用。
3、 OKR 的最終結果是否應該與績效或獎金掛鈎？
OKR 不是員工評估的代名詞，也不是為了考核員工，而是時刻提醒每個人的核心任務是什么，OKR 與公司的目標以及每個員工如何為這些目標做出貢獻有關，績效評估（完全是評估員工在固定期間的績效）應獨立於其 OKR。當企業開始接觸 OKR 時，管理者們普遍表達了這樣的擔憂：既然 OKR 和考核無關，團隊在實踐時會有積極性嗎？這種擔憂其實反映出三個問題：
一、 管理層對 OKR 的認識不夠；
二、 管理層不確定自己有沒有能力和心力促進員工的內在能動性，擔心沒有外在誘惑會導致工作推進乏力，這其實也是管理中的一種懦弱表現；
三、 管理層本身在執行 OKR 的中后期不夠堅持和堅定，OKR 倡導對齊協同，實現組織的合力。
過度激勵個人，會弱化協同的力量，導致內部競爭，破壞公開透明的場域。所以相對於個人的激勵，我們更應該重視對於團隊的激勵。
4、 怎樣開展 OKR 制定討論會議？
制定 OKR 的議程一般為：
- CEO（或 Team Leader）闡述願景和大目標，以及介紹當前行業變化、競爭環境和趨勢判斷等內容；
- COO（或小組組長）兼主持人會把初擬的業務指標和事件畫到白板上，或用投影儀展現；
- 就准備的重要業務指標和事件展開討論；
- 根據自身的職責定位，每個人把自己認為重要的 O 寫在 CODING 個人目標欄上，如果不在剛剛討論的業務指標和事件里，就在填寫時加上標注；
- 每人解讀自身設定的 O，有時為了節約時間，也會分開按小組呈現和解讀；
- 投票確定 O，並創建在 CODING 團隊目標對應位置；
- 用同樣的流程確定 KR，關聯對應事項；
- 確定 OKR 的負責人和執行驗收時間。
目標詳情頁提供了完整的目標情況
5、 如何衡量團隊成員對 OKR 的接受程度，確保 OKR 順利推行？
團隊需要建立 OKR 推行、跟進、復盤、評分四大階段中的三種文化氛圍，即：尊重、反饋與認可。
尊重
最初嘗試推行 OKR 的半年到一年中，需要鼓勵員工自主設定個人目標，同時聯動團隊目標的衡量結果，自主執行和反饋，團隊管理層不做強干預，定期觀察和協助即可。雖然很多 OKR 文章告訴我們“團隊目標大於個人目標”的理念，但是建議前期執行時反其道而行之，鼓勵員工按照 OKR 的 SMART 原則，先思考自己的價值和能力邊界，再探索關聯和延展性，同時告訴員工，我們都實現了大約 60% 的目標，這才表明我們的目標是正確的，不妨大膽一點。
個人目標的設定、進度查看和調整
反饋
我理解很多 HR 或者 Team Leader 在推行 OKR 初期時，會擔心團隊成員的接受程度。其實員工都希望能夠被“授權”和“激勵”，而不是管理者對他們的工作指指點點，員工也希望向管理者表達自己的觀點，而不是努力工作一年，最后才知道經理對其工作表現的褒貶；員工也渴望定期將自己的目標、計划與他人分享，同時也希望了解同事工作的進展情況。
公開、透明的 CODING OKR 可以幫助激發他們從不同角度思考問題：這些是我/你/我們應該關注的正確的事情嗎？如果我/你/我們完成了它們，會被視為一個巨大的成功嗎？你對我/我們如何才能做得更好有什么建議嗎？
反饋可以是非常有建設性的，但前提是它必須足夠具體。在發展型組織中，反饋通常是由人力資源部門主導和安排的。在更為成熟的組織中，反饋多是不受約束、實時和多方向的，並且多是不分時間、不分地點在組織內以開放式談話的方式進行的。對企業來說，員工與上級之間實現雙向交流的機會是非常寶貴的，比如員工可以詢問管理者需要自己做什么才能取得成功，同時管理者也可以知道自己需要從員工那里獲得什么幫助。類比 CODING 中敏捷 Scrum 文化的導入，其中有五大活動分別為：
- 待辦事項整理會議（Backlog Grooming Meeting）；
- 迭代計划會議（Sprint Planning Meeting）；
- 每日站會（Standup Meeting）；
- 評審會（Retrospective Meeting）；
- 反思會（Retrospective Meeting）。
Scrum 五大活動
參照上圖，在 OKR 推行循環周期里，也可以召開一些 OKR 啟動會、撰寫評估會、季度執行復盤會、優秀 OKR 執行表彰會等等。CODING 中的 Scrum 是敏捷的一種，CODING OKR 也是敏捷的一種，實施主要看人，強調是自組織、自驅動的，只有不斷地在實際應用中仔細體會，才能感受到企業和組織隨着敏捷或 OKR 的循序漸進變得越來越高效和具有創新力。
認可
- 鼓勵同事間認可：當員工的成就獲得同事的一致認可時，就會激發一種感恩的文化；
- 建立明確的標准：正確識別員工目前進行的是行動還是結果：完成特殊項目、實現公司目標，還是展示公司價值；
- 分享有利於增加認同感的故事：可以使用實時通信工具、公司內部知識庫或 CODING Wiki 分享這些成就背后的故事，賦予認可更多的意義，提高認可發生的頻率和可獲得性。即便是很小的成就，也應當予以贊揚。比如為在截止日期前完工而付出的額外努力、對提案進行潤色完善，或者是做一些在管理者看來是理所應當的小事。
6、 OKR 是否倡導部門全員公開可見？
是的，公開透明是 OKR 的重要原則之一。例如字節跳動有個非常有特色的管理理念，叫做「基於上下文，而不是基於控制」（Context,not Control），即希望員工能在完整的信息基礎上判斷事情該怎么做，鼓勵員工主動思考，而非強調流程、上下級與命令。在字節跳動，大家的 OKR 是公開的，即使是入職第一天的員工，也可以直接看到張一鳴的 OKR。
“比如我們有非常多的跨部門合作，‘開會坐在一起卻不認識對方是誰’的情況很常見，我經常的做法是，拿起手機，打開他的頭像，看一眼他的 OKR，半分鍾就知道他的主要職責和工作重點是什么了。”因此在字節跳動，OKR 不僅是自上而下拆解的結果，除了與上司有關，還與本部門同事、跨部門同事有關，是高效溝通與協同的基礎。使用 CODING OKR 即可根據組織架構設定不同角色的查看權限，當然，我們鼓勵全員公開可見。
在「團隊管理」->「權限配置」中為相應的用戶組設置權限
7、 OKR 中的 KR 應該怎么寫？顆粒度應該如何把握？
- 如果你的 KR 超過 2 行，它很可能是不清晰的。
- 如果你的 KR 描述中充斥着內部團隊術語，例如“發布 CI 元數據串聯和門禁能力”，那它們通常就不是好的 KR。真正重要的不是“發布”這個動作，而是其所造成的影響（Impact）究竟是什么。為什么“元數據串聯”很重要？更好的表述是這樣的：“發布 CI 元數據串聯和門禁能力，提升研發規范，增加數據流視角”或者簡單寫成：“提升研發規范，增加數據流視角”。
- KR 請使用真實日期，如果所有 KR 的截止日期都是季度最后一天，你制定的計划就很可能是有問題的。
- 確保你的 KR 是可度量的，KR 必須是每個季度末可以進行客觀評分的。“提升注冊用戶數”不是一個好的 KR，“在 6 月 1 日前提升日均注冊用戶數 25%”則是一個好的 KR。
- 確保度量指標是清晰的，如果你說“一百萬用戶”，你要指明這指的是全時段用戶，還是只是 7 天活躍用戶。
- 必須是產出導向，而非動作導向。如果你的 KR 包含有像“咨詢”、“幫助”、“分析”、“參與”這樣的詞匯，那么它描述的實際上是動作而非結果。與之相反，如果描述的是這些動作對最終用戶所帶來的影響，例如：“在 6 月 7 日前更新自動化用例庫，實現快速、精准的自動化執行”，就是一個合格的 KR，而 “更新自動化用例庫” 則不是。
- 必須能自證其是否已完成，這個證據是可輕易獲取的和可信賴的。例如證據可以是 CODING 上的 Wiki、網盤或是具體的一個項目動態，比如項目內的變更列表、文檔鏈接、已發布的質量報告等。
支持關鍵結果的新增和編輯，支持調整指標權重
8、 程序員如何制定 OKR ？
程序員的工作怎么量化？Bug 數？代碼行？版本數？但這些指標都是不可行的。或是比較團隊間的代碼行、Bug 數、版本數或者分享次數？這些其實都不行。前瞻性的工作誰願意做，有風險的工作誰願意做？例如引入 ElasticSearch 理論上可以提升搜索性能，但可能在引入的這一年反而會帶來很多問題，而能帶來多少收益還不確定，這時該如何制定 OKR ？
假設技術總監接收到 CEO 指定的大的戰略目標是“用戶量增長 20%”這樣的指標，他就應該根據團隊的資源優勢去制定本部門成員可以理解且着手的 KR，例如：
-
影響用戶增長量的技術指標有“安裝包大小”、“App 啟動時間”、“App 崩潰率”、“App 耗電情況”等等，假設經過分析后技術團隊認為目前安裝包太大，並且 App 啟動時間較長，那么可以將這兩項相關的優化作為技術團隊的 OKR：App 安裝包從 20M 縮減到 8M、App 啟動時間從 2s 優化到 500ms，而這兩個 KR，業務負責人幾乎是不可能提出來的。
-
影響用戶良性反饋的原因之一是發版節奏過慢，過慢則是因為版本多而測試環境不足，測試環境不足是因為機器不夠，那么可以得出一個目標：解決測試環境不足導致版本等待的問題。分解出來的 KR 可以是“添加 4 台測試環境機器”（是的，雖然是一件很簡單的事情，但這也可以作為 KR），也可以是“引入 Docker，支持一台機器搭建 20 套環境”（這個 KR 比較符合技術人員的理解）。
-
影響用戶分析和增長的原因之一是內部協作和需求流轉過慢，產研側往往需要一周的時間才能把用戶故事拆分至對應版本，拆分和評估用戶故事的過程很可能是通過一些易用性不強的工具來記錄和提醒。而重新評估一個研發項目管理工具就尤為重要。CODING 是一個包含代碼管理、項目協同、測試管理、持續集成、制品庫、持續部署、團隊知識庫等工具的一站式軟件研發管理平台，在項目協同環節有迭代管理、需求細分和靈活跟進的看板視圖，很適合創新型企業靈活的管理需求和快速迭代。
強大靈活的項目管理功能，讓團隊高效協同
通過以上方式進行思考和分解，最終技術團隊要做的事情如下：
- 使用 CODING 快速落地敏捷開發與 DevOps 開發方式，實現研發效能升級。
- App 安裝包從 20M 縮減到 8M。
- App 啟動時間從 2s 優化到 500ms。
- 引入 Docker，支持一台機器搭建 20 套環 境。
總結
OKR 是敏捷的戰略業務管理以及項目規划和組合管理的一個重要框架，希望通過 CODING 能幫助團隊將 OKR 的啟動、撰寫、跟進、復盤四個階段執行得愈加完善，隨時記錄團隊成員周期內完成的挑戰及為團隊做出的貢獻。