OKR是一套明確、跟蹤目標及完成情況的管理工具和方法，如何把它和其他框架結(jié)合起來使用呢？

我們收到很多問題詢問如何把OKR和其他框架結(jié)合起來使用，以便管理組織的人員、流程和活動。

軟件開發(fā)公司最喜歡用的框架之一就是Scrum，Scrum是一個誕生于20世紀90年代的軟件開發(fā)框架，我們公司內(nèi)部一直在使用這一框架。

Scrum的優(yōu)點以及為什么它能優(yōu)于瀑布流開發(fā)

相較于瀑布流開發(fā)的其他傳統(tǒng)框架，Scrum最大的優(yōu)點是關(guān)注持續(xù)快速迭代以及對變化的適應(yīng)性。

如果使用瀑布流開發(fā)，在項目一開始就要確定項目結(jié)果，并且要對此達成一致，通常還要有詳細的范圍和項目規(guī)范。

項目計劃是從這些規(guī)范中產(chǎn)生的，方法是通過以項目在未來的完成情況為出發(fā)點，向后推進，以線形的方式規(guī)劃出時間、預(yù)算和依賴性。

靠這種方法做出的成品是一份路線圖，概述出到軟件推出之日為止，需要完成的軟件開發(fā)工作。那么不足之處是什么呢？如果在軟件開發(fā)過程中出現(xiàn)了變動，時間線，依賴性，以及在大多數(shù)情況下連預(yù)算都需要完全重做，實際上就破壞了計劃。

與此不同，Scrum關(guān)注的是為了達到一個理想終點的持續(xù)快速迭代。取代詳細計劃的是精益規(guī)范或者是需求和回顧會議，這些會衡量每一次迭代成果。

這些回顧應(yīng)該圍繞一個問題：?“我們所做的工作有沒有讓我們離目標需求更近？”

Scrum 的力量來自于它能夠管理工作，實現(xiàn)一個未知的、獨特的、或者前所未有的結(jié)果。?這一框架系統(tǒng)地、漸進式地問題解決過程。瀑布流開發(fā)與此不同，只有在其所涉及的過程和工作都是可預(yù)測的，并且此前已經(jīng)有人嘗試過的情況下，瀑布流開發(fā)開發(fā)才能發(fā)揮最大功效。

這其中的差別猶如建一座橋和建一艘火箭搭載船的差別。

火箭技術(shù)相對較新，建造一艘火箭搭載船要有很多增量步驟，重復(fù)多次才能獲得成功。美國太空探索技術(shù)公司（SpaceX）為了能讓火箭在船上著陸所做的工作就是一個很好的例子。

反之，人們對建橋這一工程難題的理解十分透徹，也已經(jīng)無數(shù)次解決過這一難題。建橋不需要重復(fù)很多次，對時間和成本規(guī)劃的要求高，而這是瀑布流開發(fā)經(jīng)常應(yīng)用的領(lǐng)域。

OKR和Scrum的異同

OKR和Scrum的相似之處在于?兩個框架都需要有一人專門管理框架的實施情況，?稱為“Scrum負責人”或“OKR負責人”。兩個職位職責明確，他們的責任是保證團隊依照框架行事。

Scrum是一個高度規(guī)范的框架，有明確的職責和儀式。Scrum的益處包括透明性、項目可見性以及頻繁溝通。團隊集體決定他們在為期2周的一個短期“sprint”內(nèi)能夠完成什么樣的工作，這也使得Scrum是一個很民主的過程。

OKR也有一套規(guī)則，雖然這套規(guī)則不如Scrum的規(guī)則條理清楚。這些規(guī)則決定什么是目標O，什么是關(guān)鍵結(jié)果KR，以及如何把二者結(jié)合起來衡量目標的實現(xiàn)。

和Scrum一樣，OKR有時間表，但是比為期兩周的sprint要長得多（季度和年度）。設(shè)定OKR首先需要做的是，公司領(lǐng)導(dǎo)決定需要實現(xiàn)何種目標，接著，團隊設(shè)定自己的OKR，需要確保團隊的OKR與公司的目標保持一致。

如何把Scrum和OKR結(jié)合起來

只要每個人都清楚兩個框架的范圍和參數(shù)，OKR和Scrum可以成功地結(jié)合在一起使用，效果也確實不錯。我們在確立公司OKR后，會進一步落實實現(xiàn)OKR的行動方案。Sprints和行動方案能在行動周期內(nèi)有機結(jié)合，促進團隊OKRs的達成。

為了能讓這兩個框架合拍，重要的一點是在每個季度開始的時候，一位OKR負責人和一位Scrum負責人與他們的研發(fā)團隊坐在一起，決定需要在這個季度完成的最重要的事情（通常為3項）。

由于OKR周期更長，目標更宏觀，而Sprint涉及的更具體的執(zhí)行層面工作，?因此需要首先考慮OKR。

要讓OKR在這一階段就能有效開展，?相對于強調(diào)對結(jié)果實現(xiàn)的追求，更應(yīng)關(guān)注對結(jié)果的衡量。

比如，如果你想要解決的問題是有缺陷的軟件，那么，統(tǒng)計消滅了多少個軟件缺陷就不是一個有效的關(guān)鍵結(jié)果。修復(fù)了一個缺陷，缺陷的數(shù)量就少了一個，但是如果有更多的軟件缺陷被報出來，你就沒有讓軟件變得更完善，你僅僅是在數(shù)自己修復(fù)了多少個缺陷。

一個更好的關(guān)鍵結(jié)果應(yīng)該是統(tǒng)計出現(xiàn)了多少缺陷，或者統(tǒng)計一個季度內(nèi)出現(xiàn)了多少客戶需求。如果這個評估指標的趨勢有所下降，那么你就可以自信地認為你正在解決你最初想要解決的問題。

設(shè)定了OKR的目標和關(guān)鍵結(jié)果后，就可以開始規(guī)劃Sprint。在這一個階段，重要的是要決定Sprint的周期。如果一個Sprint為期一個月，一個單一的Sprint目標很可能會直接對應(yīng)開發(fā)團隊3個OKR目標的其中一個。至于更常見的為期2周的較短Sprint，Sprint目標則變成OKR目標的行動方案。

我們更推薦第二種方法，因為這種方法在連接兩個框架的同時還保持了二者最初的目標，即Sprint管理生產(chǎn)和代碼傳輸，?而OKR設(shè)定目標，衡量評估工作結(jié)果。

但是，這也意味著每一個OKR都需要有自己的Sprint時間線。如果你有一個大型的開發(fā)團隊在一個產(chǎn)品的不同領(lǐng)域開展工作，比如前期工作、后期工作和系統(tǒng)管理，這一方法就能發(fā)揮很好的效果。使用這種方法的話，每一個領(lǐng)域引導(dǎo)1個OKR和1條Sprint時間線，而整個小組內(nèi)部有3個OKRs。

對于規(guī)模較小，沒有能力運轉(zhuǎn)3條Sprint時間線的開發(fā)團隊，我們也推薦這種方法，但是只需要專注一個單一的OKR即可。

本文由 @倩 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議