前言<a id="orgheadline1"></a>
最近開始在公司內(nèi)嘗試使用 OKR 的思想進行管理，收獲了不少心得，也遇到了不少困難?，F(xiàn)在進行一個簡單的總結(jié)。 OKR 的介紹見文章最后的參考鏈接。
我理解的 OKR 的益處<a id="orgheadline6"></a>
對整個公司的燈塔效果<a id="orgheadline2"></a>
OKR 管理制要求公司每年、每季度都要確定一套 OKR，而且數(shù)量有嚴(yán)格的限制，最多有 5 個 O，每個 O 最多 4 個 KR。這意味著它確立了公司一整年的最核心的戰(zhàn)略，避免了做那些與核心戰(zhàn)略無關(guān)的事，提高整個公司做事的效率。
公司戰(zhàn)略的重要性無論如何強調(diào)都不過分，很多創(chuàng)業(yè)公司失敗最主要的原因就是戰(zhàn)略方向一開始就錯了，戰(zhàn)略錯了戰(zhàn)術(shù)上再怎么努力也無濟于事，甚至?xí)铀偈〉倪^程（不過對于創(chuàng)業(yè)來說，快速失敗也是一件好事）。
對于公司的核心管理層來說，這一點尤為重要，創(chuàng)業(yè)路上誘惑太多，哪個方向看起來都很好，如果不能找準(zhǔn)自己的位置和方向，別人做什么你也跟著做什么，失敗是 100% 的。
而對于員工來說，這一點也很重要，有很好的主動性的員工本來就很少，而具有主動性同時又能很好地規(guī)劃和執(zhí)行自己工作的員工更是少之又少，這種情況下花點時間好好地制定出一份 OKR，不管對于員工還是公司，都是有百利而無一害的。
挑戰(zhàn)性<a id="orgheadline3"></a>
OKR 要求目標(biāo)要有野心，有時候甚至要有些不舒服（按照谷歌的說法，Achieving 65% of the impossible is better than 100% of the ordinary）。中國古人說“生于憂患，死于安樂”，也是類似的道理。
其實，很多人也有親身的體會，往往在適度的壓力面前，自己的潛能就會被激發(fā)出來。而一旦長時間很舒服，回過頭來看，往往沒什么成績和成長。
主動性<a id="orgheadline4"></a>
OKR 建議 60% 以上的目標(biāo)是自下而上提出的，100%的目標(biāo)都是協(xié)商并同意的，不能是命令。也就是說更多地鼓勵員工自己找到問題，解決問題。這個做法有兩個好處：
- 找的過程本身就是一個學(xué)習(xí)、提高的過程，只會執(zhí)行的員工其實并不缺，缺的是能發(fā)現(xiàn)問題并主動去解決的員工；
- 如果這個目標(biāo)是自己主動想要達到的，那么往往更容易達到；
公開性<a id="orgheadline5"></a>
所有的 OKRs 都是對所有人開放的，開放意味著最低的溝通成本、最容易形成合力（多人抬重物的時候要喊著號子也是同樣的道理）。開放還意味著時時處處都能看到，不斷的刺激你的神經(jīng)，就像千篇一律的新聞聯(lián)播一樣，不知不覺我們就被洗了。當(dāng)然，與他們不同的是，我們的目的和結(jié)果都是雙贏的。
問題<a id="orgheadline9"></a>
OKR 雖好，但不是那么簡單就可以實施得起來的，我們在執(zhí)行時就遇到了一些問題，
OKR 的量化問題<a id="orgheadline7"></a>
我們是這樣執(zhí)行的，提前一兩天讓大家看了一下 OKR 的資料，周五下午開會討論公司存在的問題，會上很多人都準(zhǔn)確的指出了問題所在，說明員工都是非常具有觀察力的。
就著這些問題，我們緊接著分析了 OKR 對于解決這些問題的意義，從而達成了全面啟用 OKR 計劃的共識。
下一步就是如何實施了。大家利用周末的時間自己總結(jié)個人的 OKR，等到周一上午陸續(xù)收集上來之后發(fā)現(xiàn)一個非常普遍的問題，那就是幾乎所有人都沒有將 KR 定量。
我曾試圖著幫助幾個員工重新梳理他們的 OKR，但是最終發(fā)現(xiàn)，對于研發(fā)團隊成員來講，梳理出來的稱之為“OKR”的東西其實更像是產(chǎn)品需求，我認(rèn)為好的 OKR 不應(yīng)該是這樣的，需要重新思考一下這個問題：
- 在個人季度 OKR 里勉強地把一個個具體的“產(chǎn)品需求”定為目標(biāo)顯得很牽強，因為非常不容易定量，這種感覺肯定不是 OKR 的初衷
- 具體的產(chǎn)品需求本身應(yīng)該只存在在產(chǎn)品需求文檔里，OKR 應(yīng)該是對產(chǎn)品需求的實現(xiàn)結(jié)果進行量化的評估，而不是對需求本身做要求。
周 Review 的形式問題<a id="orgheadline8"></a>
OKR 里只說需要定期的 Review，并描述好“目標(biāo)，進度，遇到的問題，問題原因，下一步計劃”這 6 個方面的問題。除了第一個“目標(biāo)”問題不太確定其意義，其他問題從字面上可以理解和回答。
但是以什么形式匯報并沒有講。沒有更好的方案前，我們先用 Excel 表試驗了一個周。很快發(fā)現(xiàn)這種方案有幾個問題：
- 不夠開放
- 不方便集中瀏覽
- 不方便基于問題進行討論
- 不方便反復(fù)修改
那如何解決這個問題呢，我搜索了一遍相關(guān)的 APP 工具，協(xié)同工具（Worktile、明道之類的），但是似乎都不怎么適合，而且上一套新的協(xié)同工具是要非常慎重的，它帶來的是所有員工的學(xué)習(xí)成本。
那能否從我們現(xiàn)在正在用的工具方面想想辦法呢？我們目前正在用 Github 做代碼管理，眾所周知，Github 的作用并不僅限于代碼管理，它在團隊協(xié)同、需求管理、bug 管理、文檔管理等方面都有不錯的實踐。
經(jīng)過一番摸索，果然找到了一套邏輯上非常吻合的 OKR 實施方法。我的下一篇文章基于 Github 的 OKR 實施方法以及企業(yè)協(xié)同方法將詳細解釋。
<a id="orgtarget1"></a>
