OKR與Scrum如何強(qiáng)強(qiáng)聯(lián)手?
OKR是一套明確、跟蹤目標(biāo)及完成情況的管理工具和方法,如何把它和其他框架結(jié)合起來(lái)使用呢?
我們收到很多問(wèn)題詢問(wèn)如何把OKR和其他框架結(jié)合起來(lái)使用,以便管理組織的人員、流程和活動(dòng)。
軟件開(kāi)發(fā)公司最喜歡用的框架之一就是Scrum,Scrum是一個(gè)誕生于20世紀(jì)90年代的軟件開(kāi)發(fā)框架,我們公司內(nèi)部一直在使用這一框架。
Scrum的優(yōu)點(diǎn)以及為什么它能優(yōu)于瀑布流開(kāi)發(fā)
相較于瀑布流開(kāi)發(fā)的其他傳統(tǒng)框架,Scrum最大的優(yōu)點(diǎn)是關(guān)注持續(xù)快速迭代以及對(duì)變化的適應(yīng)性。
如果使用瀑布流開(kāi)發(fā),在項(xiàng)目一開(kāi)始就要確定項(xiàng)目結(jié)果,并且要對(duì)此達(dá)成一致,通常還要有詳細(xì)的范圍和項(xiàng)目規(guī)范。
項(xiàng)目計(jì)劃是從這些規(guī)范中產(chǎn)生的,方法是通過(guò)以項(xiàng)目在未來(lái)的完成情況為出發(fā)點(diǎn),向后推進(jìn),以線形的方式規(guī)劃出時(shí)間、預(yù)算和依賴性。
靠這種方法做出的成品是一份路線圖,概述出到軟件推出之日為止,需要完成的軟件開(kāi)發(fā)工作。那么不足之處是什么呢?如果在軟件開(kāi)發(fā)過(guò)程中出現(xiàn)了變動(dòng),時(shí)間線,依賴性,以及在大多數(shù)情況下連預(yù)算都需要完全重做,實(shí)際上就破壞了計(jì)劃。
與此不同,Scrum關(guān)注的是為了達(dá)到一個(gè)理想終點(diǎn)的持續(xù)快速迭代。取代詳細(xì)計(jì)劃的是精益規(guī)范或者是需求和回顧會(huì)議,這些會(huì)衡量每一次迭代成果。
這些回顧應(yīng)該圍繞一個(gè)問(wèn)題:?“我們所做的工作有沒(méi)有讓我們離目標(biāo)需求更近?”
Scrum 的力量來(lái)自于它能夠管理工作,實(shí)現(xiàn)一個(gè)未知的、獨(dú)特的、或者前所未有的結(jié)果。?這一框架系統(tǒng)地、漸進(jìn)式地問(wèn)題解決過(guò)程。瀑布流開(kāi)發(fā)與此不同,只有在其所涉及的過(guò)程和工作都是可預(yù)測(cè)的,并且此前已經(jīng)有人嘗試過(guò)的情況下,瀑布流開(kāi)發(fā)開(kāi)發(fā)才能發(fā)揮最大功效。
這其中的差別猶如建一座橋和建一艘火箭搭載船的差別。
火箭技術(shù)相對(duì)較新,建造一艘火箭搭載船要有很多增量步驟,重復(fù)多次才能獲得成功。美國(guó)太空探索技術(shù)公司(SpaceX)為了能讓火箭在船上著陸所做的工作就是一個(gè)很好的例子。
反之,人們對(duì)建橋這一工程難題的理解十分透徹,也已經(jīng)無(wú)數(shù)次解決過(guò)這一難題。建橋不需要重復(fù)很多次,對(duì)時(shí)間和成本規(guī)劃的要求高,而這是瀑布流開(kāi)發(fā)經(jīng)常應(yīng)用的領(lǐng)域。
OKR和Scrum的異同
OKR和Scrum的相似之處在于?兩個(gè)框架都需要有一人專門(mén)管理框架的實(shí)施情況,?稱為“Scrum負(fù)責(zé)人”或“OKR負(fù)責(zé)人”。兩個(gè)職位職責(zé)明確,他們的責(zé)任是保證團(tuán)隊(duì)依照框架行事。
Scrum是一個(gè)高度規(guī)范的框架,有明確的職責(zé)和儀式。Scrum的益處包括透明性、項(xiàng)目可見(jiàn)性以及頻繁溝通。團(tuán)隊(duì)集體決定他們?cè)跒槠?周的一個(gè)短期“sprint”內(nèi)能夠完成什么樣的工作,這也使得Scrum是一個(gè)很民主的過(guò)程。
OKR也有一套規(guī)則,雖然這套規(guī)則不如Scrum的規(guī)則條理清楚。這些規(guī)則決定什么是目標(biāo)O,什么是關(guān)鍵結(jié)果KR,以及如何把二者結(jié)合起來(lái)衡量目標(biāo)的實(shí)現(xiàn)。
和Scrum一樣,OKR有時(shí)間表,但是比為期兩周的sprint要長(zhǎng)得多(季度和年度)。設(shè)定OKR首先需要做的是,公司領(lǐng)導(dǎo)決定需要實(shí)現(xiàn)何種目標(biāo),接著,團(tuán)隊(duì)設(shè)定自己的OKR,需要確保團(tuán)隊(duì)的OKR與公司的目標(biāo)保持一致。
如何把Scrum和OKR結(jié)合起來(lái)
只要每個(gè)人都清楚兩個(gè)框架的范圍和參數(shù),OKR和Scrum可以成功地結(jié)合在一起使用,效果也確實(shí)不錯(cuò)。我們?cè)诖_立公司OKR后,會(huì)進(jìn)一步落實(shí)實(shí)現(xiàn)OKR的行動(dòng)方案。Sprints和行動(dòng)方案能在行動(dòng)周期內(nèi)有機(jī)結(jié)合,促進(jìn)團(tuán)隊(duì)OKRs的達(dá)成。
為了能讓這兩個(gè)框架合拍,重要的一點(diǎn)是在每個(gè)季度開(kāi)始的時(shí)候,一位OKR負(fù)責(zé)人和一位Scrum負(fù)責(zé)人與他們的研發(fā)團(tuán)隊(duì)坐在一起,決定需要在這個(gè)季度完成的最重要的事情(通常為3項(xiàng))。
由于OKR周期更長(zhǎng),目標(biāo)更宏觀,而Sprint涉及的更具體的執(zhí)行層面工作,?因此需要首先考慮OKR。
要讓OKR在這一階段就能有效開(kāi)展,?相對(duì)于強(qiáng)調(diào)對(duì)結(jié)果實(shí)現(xiàn)的追求,更應(yīng)關(guān)注對(duì)結(jié)果的衡量。
比如,如果你想要解決的問(wèn)題是有缺陷的軟件,那么,統(tǒng)計(jì)消滅了多少個(gè)軟件缺陷就不是一個(gè)有效的關(guān)鍵結(jié)果。修復(fù)了一個(gè)缺陷,缺陷的數(shù)量就少了一個(gè),但是如果有更多的軟件缺陷被報(bào)出來(lái),你就沒(méi)有讓軟件變得更完善,你僅僅是在數(shù)自己修復(fù)了多少個(gè)缺陷。
一個(gè)更好的關(guān)鍵結(jié)果應(yīng)該是統(tǒng)計(jì)出現(xiàn)了多少缺陷,或者統(tǒng)計(jì)一個(gè)季度內(nèi)出現(xiàn)了多少客戶需求。如果這個(gè)評(píng)估指標(biāo)的趨勢(shì)有所下降,那么你就可以自信地認(rèn)為你正在解決你最初想要解決的問(wèn)題。
設(shè)定了OKR的目標(biāo)和關(guān)鍵結(jié)果后,就可以開(kāi)始規(guī)劃Sprint。在這一個(gè)階段,重要的是要決定Sprint的周期。如果一個(gè)Sprint為期一個(gè)月,一個(gè)單一的Sprint目標(biāo)很可能會(huì)直接對(duì)應(yīng)開(kāi)發(fā)團(tuán)隊(duì)3個(gè)OKR目標(biāo)的其中一個(gè)。至于更常見(jiàn)的為期2周的較短Sprint,Sprint目標(biāo)則變成OKR目標(biāo)的行動(dòng)方案。
我們更推薦第二種方法,因?yàn)檫@種方法在連接兩個(gè)框架的同時(shí)還保持了二者最初的目標(biāo),即Sprint管理生產(chǎn)和代碼傳輸,?而OKR設(shè)定目標(biāo),衡量評(píng)估工作結(jié)果。
但是,這也意味著每一個(gè)OKR都需要有自己的Sprint時(shí)間線。如果你有一個(gè)大型的開(kāi)發(fā)團(tuán)隊(duì)在一個(gè)產(chǎn)品的不同領(lǐng)域開(kāi)展工作,比如前期工作、后期工作和系統(tǒng)管理,這一方法就能發(fā)揮很好的效果。使用這種方法的話,每一個(gè)領(lǐng)域引導(dǎo)1個(gè)OKR和1條Sprint時(shí)間線,而整個(gè)小組內(nèi)部有3個(gè)OKRs。
對(duì)于規(guī)模較小,沒(méi)有能力運(yùn)轉(zhuǎn)3條Sprint時(shí)間線的開(kāi)發(fā)團(tuán)隊(duì),我們也推薦這種方法,但是只需要專注一個(gè)單一的OKR即可。
本文由 @倩 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來(lái)自Unsplash,基于CC0協(xié)議
- 目前還沒(méi)評(píng)論,等你發(fā)揮!