起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品技術團隊：如何引入OKR工作法
本文作者將結合自身經驗與大家分享：產品團隊如何引進OKR？enjoy~
經常有團隊問我，團隊或者部門是否可以應用OKR工作法。我一般回答是否定的。像銷售、市場、人事、行政這樣的職能部門，如果彼此獨立設定OKR，幾乎必然是無法和公司的聚焦目標對齊的。
而且這些孤立的部門無法形成完整的業務鏈條，如果不能從公司或者事業單元的角度出發，就無法識別出影響成長的瓶頸問題和可能存在的增長動因，也就無法做有意義的聚焦。有些團隊強行實施，最終的結果只是把一般運營流程中的KPI換了一個名詞表達而已。
更糟糕的情況是各個部門和公司同時實施不同層級的OKR，結果部門的基層員工就很容易在部門OKR和公司OKR之間發生混淆。有雙重的目標指引，自然也就難以分辨優先度。
但是，這個問題在產品技術部門可能是個例外。尤其是產品型公司的產品技術團隊。一方面是因為產品型公司的聚焦重點經常會發生在產品本身上；另一方面是因為很多互聯網公司在產品技術方面遇到的問題和機會都非常接近，以至于我看到不少科技公司在企業層面的OKR設定都非常近似。
一. 先決條件
即便如此，也并非所有的產品技術團隊都適合獨立引入OKR方法。如果要讓這個方法在企業中發揮出成效，不產生部門本位主義，那么這個團隊要符合以下這些特征：
- 產品技術團隊能夠對產品的設計、開發和交付整體負責；團隊具備主控性，而不是受制于多個部門的配合；
- 非項目服務業務模式，產品技術團隊服務的是本企業的產品，而不是客戶的產品，否則這個團隊的核心管理體制很難超越項目管理本身。而且外包項目的生命周期也不足以來激勵OKR的實施。
- 公司的業務成效很大程度上取決于產品本身的定位、特性與市場需求的適配度和產品質量；銷售和營銷職能起的是放大器作用。消費者應用領域的公司大多符合這個條件。如果是2B的產品則要視情形來看。同時，這三個基礎條件也決定了產品技術主管一般都是公司的核心管理人員，對公司的資源分配，協調其他部門的工作能夠起到關鍵影響。
如果以上提到的先決條件不存在，那么這樣的團隊獨立實施OKR的成效是不樂觀的。實際上，如果缺乏自治度和管理關注度的產品技術團隊本身也很難有動力來自行發起目標管理。即使做，一般也只是為了響應公司從上至下的管理要求而已。
二. 常見的產品技術部門OKR類型
當我輔導了十家科技企業的OKR制定溝通會議以后，我發現這類企業的OKR選擇有非常明顯的規律。團隊相對容易達成一致的目標意圖（Objective）大體會分成這么幾類：
1. 產品特性交付里程碑
這可能是最常見的目標之一。產品技術團隊因為擔負交付產品和特性的責任，所以容易有這樣習慣性的思維——本季度發布xxx特性，交付2.0版本產品等。
在這個動因下，產品技術部門設定目標要有更清醒的頭腦和更整體的認知。為什么要交付2.0版本？2.0版本主要解決的問題是什么？
除了形式上的交付，用什么KR能夠更好地定義交付成功？一個好的產品交付目標應該揭示背后的商業意圖。比如：“通過2.0解決客戶自助部署問題”，“通過3.0解決合作伙伴增加銷售選項”就是更加完整的目標描述。
正是因為如此，這類目標所配套的關鍵結果（Key Results）也要能夠反映出意圖達成的KPI（請中性理解這里的KPI含義）。發布時間本身不應該成為KR，發布后能夠形成的一個關鍵數據指標才是。
比如上面“通過2.0解決客戶自助部署問題”的Objective可能需要配套一個KR：自助部署頁面的UV數量，它反映了這個特性交付帶來的客戶價值，每有1000個UV，說明可能有1000個用戶得到了自助部署系統的幫助。在第二個例子中，合作伙伴銷售中新產品的占比可能是一個有價值的KR。
在產品特性交付目標方面，我還經常發現一個常見困難，就是每個季度的OKR周期很難保證一個大宗的產品特性交付徹底完成，更加不要說獲得使用相關的數據。這時候，我們就需要定義更加細分的里程碑，而不是一個版本的交付，比如“完成單元測試”、“完成數據架構設計”等。
2. 提升開發和運維質量?
在產品型公司的早期，因為經驗和能力的原因，在產品開發和運維過程（devops）中存在大量缺陷。有一些質量問題也可能是因為“MVP”理念導致的。這些可能都是創業公司不可避免的階段。
但當公司開啟了商業化進程，建立了專門的銷售團隊，低質量的產品會消耗巨大的營銷投入，不僅無法轉化滿意的客戶，而且會讓整個團隊士氣低落。
但站在公司的角度看，剛剛建立了銷售團隊，管理層的注意力通常被牽制在銷售團隊的形成和管理上，有時候是難以顧暇，有時候是沒有意識到產品質量對于提高銷售效率的重要性。
與其等到部門之間相互指責和推諉，有全局觀的CTO應該盡快聚焦在提升質量的目標上。在達成這類目標時，產品技術團隊的自治能力至關重要。
技術產品的質量提升目標不難設定用于衡量的關鍵結果（KR），但指標選擇的過程最好依然是從下至上的，因為非專業人員很難有相關的知識背景。如果是和軟件缺陷有關的質量改進，這個關鍵結果最好能夠落在測試流程內部（用例的數量和覆蓋度，測試的自動化程度等），而不是去衡量客戶投訴率這樣的滯后性KR；
如果是和運維質量相關的目標，KR則更容易選擇一些，因為有足夠多的監控工具來直接提供有意義的指標。我說這類KR容易識別，有個前提，就是KR的選擇制定能夠充分地發揮主管工程師的領域知識，而不是管理者由上至下制定，簡單說，就是讓專業的人來測量。
3. 運營改善相關
產品運營的職能劃分在不同公司不一樣，但有很多互聯網企業很重視產品運營，并且意識到產品設計和研發團隊對運營管理的直接驅動力。所以，也有不少產品技術團隊會直接提出和運營改善有關的目標，這通常發生在企業的成長階段。
AARRR（獲取，激活，轉化，留存和推薦）是建立運營改善目標的最佳模型，它揭示出一個產品的總體成功來自這五個基本運營環節的成功。產品運營績效目標的達成依靠的是方法、智力的投入，比如通過User Onboarding Design（用戶上手指南設計）提升新用戶激活度，而它帶來的產出在財務上卻非常顯要。
卓越的產品運營能夠大幅降低平均營銷成本，提升用戶終生價值。從這個角度看，來自產品技術團隊的相關目標設定，能夠大幅影響公司的最終績效。
這類目標的描述可以非常直白，面對慘淡的留存，產品團隊應該意識到“提升用戶留存”是一個顯然的目標意圖，但是在每個公司的具體業務中，它的描述可以更加明確，比如“通過游戲化設計來加強用戶留存“，“通過Onboarding模塊加強用戶留存”等。目標的設定越明確，在OKR執行過程中的任務設計就越順暢，在復盤時頭腦也更加清醒，不會被干巴巴的數字所制約。
和開發運維質量提升相關的目標類似，產品運營的KR制定也有它的專業性要求，比如有關用戶留存的KR，專業領域內有幾十個可以使用的指標，到底哪個指標能夠反映當下目標的實現度？次日留存和次月留存可能有完全不同的暗示。這需要專業的產品運營自發來選擇指標，而不是等待管理層派發指標。
同樣，前面提到的目標描述的具體度也會影響我們選擇KR時候的精確度。當OKR的執行結果和個人的獎懲脫鉤的時候，我們就可以自發和客觀地選擇最科學的指標來衡量目標達成度。
4. 提升產品市場適配度
對于產品技術團隊來說，這是一個高難度的目標。但對大多數企業來說又是產品化過程中極容易遭遇的問題——產品不對路。產品的功能和特性和客戶的實際需求存在斷層，這是一個普遍的企業失敗原因，不僅在產品早期可能出現，在擴張階段也可能再次遇到。杰佛瑞·摩爾在經典著作《跨越鴻溝》中闡明了出現這種情況的必然性。
尤其是科技產品，早期用戶和主流用戶在需求和心理上的巨大差異使得一個新產品在進入早期市場和拓展主流市場的不同階段面臨完全不同的市場接受度。產品市場部門很難獨立定義這樣的目標。不僅可能缺乏足夠的決策信息，也很難有這樣的決策權威，因為它很容易挑戰到一個公司的品牌和市場定位，細分市場選擇。
所以，這類目標的設定通常都需要和管理層，銷售業務部門建立充分的溝通，對每個企業來說，都是頭等大事。在理想情況下，產品技術團隊從第一天起就十分重視客戶導向的產品開發流程，產品的每一步定義都小心謹慎地獲得客戶驗證，每一個特性擴展也都保持足夠的自律。
但在企業實踐中，這種理想情況很難達成。即便全員都高度客戶導向，也有選擇和取舍上的困難。我發現科技型企業在這個問題上的試錯成本總是最高的。
設定好這一類的目標的前提是企業對“理想客戶對象”有更加明確的定義，如果不能定義清楚目標客戶，那么所謂的適配度提升就缺失了參照對象。假設這個步驟能夠達成共識，那么產品技術團隊就需要和銷售業務團隊仔細溝通產品應該怎樣改進才能更好地滿足這類目標客戶的需求。
在以季度為周期的OKR執行中，聚焦解決那些能夠有助于提高產品市場適配度的關鍵特性。這時候，選擇對應市場的銷售轉化率作為KR可能是更明智的做法。因為所謂的需求匹配，最終是依靠客戶的買單來證明的，在客戶買單之前，我們很難找到可靠的前導性指標。
對于2C產品，驗證要更加容易一些，一般留存率和活躍度指標都能夠很好地反映需求匹配度。這個類型的OKR敘述起來比較抽象，我舉一個比較典型的例子。比如一個SaaS產品在運營兩年后，產品功能和模塊越來越繁復，導致產品在面對任何一個具體客戶的時候無法用簡明的陳述和演示來說明清楚產品價值。
如果通過OKR工作法來解決此類問題，就可能涉及到這類短期目標。比如“強化產品針對服務型企業的CRM特性”。與此相關的KR可以是服務型企業的成交轉化率或者留存率。雖然這個KR不得不滯后衡量，但它的確是反應這個意圖目標的實現程度。
5. 技術選型變更和償還技術債
在業務成長到一個階段時，有一些技術團隊會意識到緊迫的架構調整、技術選型升級等償還技術債問題。這更加是一個需要由下至上設定目標的領域，因為很少有公司的管理層和其他業務部門關注這一點。如果業務發展順利，用戶不斷增長，那么該發生的事情一定會發生。警惕性高的CTO們會未雨綢繆，在頻繁宕機之前，把問題提前解決。
設定這類目標時，要重視的是和管理層達成共識，因為這些技術工作必然會影響功能特性開發，鎖死一些常規事務的進展，也可能涉及一些可控風險。如果沒有事先的溝通，很可能會發生不必要的沖突。
當然，這些目標是否應該成為產品技術部門某季度必須面對的關鍵目標，這不能是CTO的主觀臆斷。它應該建立在數據的客觀分析和預測上。
衡量這類目標的KR也不難識別，甚至純技術層面的壓力測試就能夠很好地回答這個問題。我們有沒有讓基礎構架更加健壯？我們能否承受每小時100萬次以上的訪問？
設定了這類目標和關鍵結構，就公開給其他部門的同事，這樣既能夠讓團隊周知這些事務的重要性，爭取支持，也能夠激勵營銷和銷售部門，建立更強的業務拓展信心。
三. 執行和評估
我列舉了產品技術部門可能獨立制定的五類目標類型，它們中的一部分依然有賴于和其他部門的深度協作，KR的設計也考驗團隊的策略分析和批判性思維能力。
但這些都還只是開始，OKR目標的有效達成，并不是依賴選擇出科學的KR，而是需要設計出切實有效，盡責執行的任務項，并且連續跟蹤這些任務的完成狀況，遇到的問題，改進方案。
我為什么要強調“任務設計”，而不是“任務分配”？因為OKR目標所對應的問題通常不是一個常規運營問題，更加不是一個逐步改良性的目標，而是一個阻礙企業成長的關鍵問題，必須集中精力去躍升。如果依靠一般的任務分配所能夠達到的成效是很難有驚喜的。當OKR脫離了傳統的績效考核范疇，參與者就可以解放思想，采用創造性的手段來達成目標，這就是為什么要叫“任務設計”。
在產品技術相關的目標達成中，我發現卓越完成的情況往往依賴兩個重要的驅動力，一是成員的敬業度，二是成員的學習能力。
對于一個產品技術問題的解決，很少存在可不可行的問題，更多的是團隊暫時沒有取得相關的能力，不知道行業的最佳實踐是怎樣的。敬業度又和學習能力相輔相成，彼此關聯。
所以，想要OKR目標的達成度提高，CTO和產品VP們應該長期關注的是人才的選拔標準和團隊共同學習進步的具體安排。
我在管理明道的幾年中，最大的感悟就是這一點?？萍脊镜呐d起來自于關鍵技術能力的提前掌握，同樣，科技公司的衰敗也是因為沒有能夠跟上產品技術進步的洪流，它和團隊成員有沒有及時完成一個短期績效目標沒有太多聯系。
所以，OKR工作法看似是一個圍繞短期，高速迭代的執行落地方法，但它的有效性有賴于使用者對長期績效和價值創造的絕對關注。
以上就是明道對產品團隊如何引進OKR的理解，歡迎在下方留言交流~
作者：任向暉，明道創始人
本文由 @任向暉 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖由作者提供
這幾個不適合的先決條件我司全中，但是沒辦法