系列文章｜OKR與敏捷（三）：賦予團隊自主權

OKR與敏捷開發的原理有着類似之處，但已經使用敏捷的團隊再用OKR感受會顯得多餘。這種誤解的根源就在於對這兩種模式不夠了解，運用得當的狀況下，OKR和敏捷能夠造成強強聯合的效果，他們能夠創造出以價值爲驅動的團隊，改變團隊的工做方式。

本文最後一部分分析了OKR的正確使用方法，以及如何賦予團隊更多自主權。

回顧第一部分請點這裏：系列文章｜OKR與敏捷（一）：瀑布式目標與敏捷的衝突
回顧第二部分請點這裏：系列文章｜OKR與敏捷（二）：實現全棧敏捷

使用OKR的正確方式

與其餘工具同樣，OKR也可能會被濫用並淪爲待辦事項列表。但若是你想要專一於價值實現，那麼你的目標就必需要體現這一點。所以你須要設訂價值導向的關鍵結果：

價值就像講笑話：你無法告訴對方它到底好很差。

價值導向的OKR不只僅衡量結果。你還須要明白對你的客戶和公司來講，什麼樣的結果纔是有價值的。

下面的例子展現了兩種關鍵結果的差異：

在敏捷中使用行爲導向的關鍵結果會產生摩擦。既然敏捷團隊已經有了明確的路線圖，爲何他們還須要OKR呢？我遇到的全部嘗試將OKR與敏捷相結合的團隊，都在專一於開發活動自己。

使用價值導向的OKR可以帶來變革，它能夠成爲鏈接敏捷和精益的橋樑，彌補產品和開發之間的空白。

改變側重點

儘管敏捷使用的命名法專一於交付。咱們也須要拋開一些概念，好比「完工、燃盡圖、速度」。

與之相反的，咱們應該專一於價值。咱們不須要驗收標準，須要利用OKR來定義成功的標準。

從意見轉變爲數據
敏捷並非獨立的數據驅動，而是HiPPO（HighestPaid Person’s Opinion）模式，即遵從薪酬最高者的意見。

《谷歌的經營之道》一書生動形象地描述了這個模式：

這種敏捷模式下隱藏着一個巨大缺陷。即公司的利益相關者告訴團隊應該去作什麼工做，並對工做進行審查。

羅恩·傑弗里斯（Ron Jeffries）描述了一場與利益相關者的虛擬對話：

「每週你能夠告訴咱們你最看重什麼，而後咱們會告訴你哪些要求是咱們能夠實現的。一週以後，你就能夠拿到咱們的成果。若是你樂意，你就能夠交付出去。」

按照泰勒管理模式，由利益相關者來決定團隊應該作什麼，以及交付的成果是否能夠出售。這種作法默認利益相關者知道什麼具備價值，且他們的意見能夠做爲實際價值的衡量指標。

但數據代表實際上正相反。例如，羅恩·卡哈維發表了一篇論文，對微軟的一系列創意和結果進行了分析。結果，僅有 1/3的創意對指望指標在統計層面產生了積極效應。

若是敏捷開發摒棄了數據統計和成果衡量，轉而選擇HiPPO（遵從薪酬最高者的意見）來決定應該開發什麼功能，那麼其偏差將超過66%。

不少公司還在使用「客戶意見至上」的管理模式。這種模式中，個別人的意見表明了終端客戶。在過去這個作法尚且行得通，由於在數據採集上很困難。但到了數字化的現代社會，這已經成爲了瀑布模型的又一個遺留問題。

用實驗取代HiPPO模式

事實上，開發團隊不須要個別人來表明客戶的意見。由於團隊能夠本身採訪客戶以判斷開發行爲是否得當。OKR能夠取代HiPPO，經過實驗讓團隊學習和覆盤。

OKR能夠幫助團隊採用假設驅動開發模式，巴里•歐萊禮將其描述爲：

咱們認爲……
可獲得……
當……咱們有信心繼續進行……

在這個模型中，覆盤再也不是爲了展現可交付成果。團隊在覆盤中經過討論主題和主要假設來不斷完善交付成果。

賦予團隊自主權

命令與控制依然存在。

命令與控制心理依然貫穿敏捷交付的全過程。利益相關者有權決定開發什麼功能。所以，團隊的工做模式依然是「由於這是山姆說要作的」，直到「山姆以爲不錯」以後纔算完工。

公司發展須要團隊全身心的奉獻，因此他們須要理解公司的業務問題並可以就構建內容發表意見。

馬蒂·卡根曾寫道：「若是你只讓你的工程師寫代碼，那你只獲得他們一半的價值。」

爲了賦予團隊自主權，你要給予他們自主決定如何實現預期成果的自由。所以團隊的目標也須要改變：

瑪麗·帕彭迪克（Mary Poppendieck）曾寫道：

「或許敏捷開發實踐最大的缺陷是哪一個來團隊決定作什麼的方式。在很長時間以來，人們認爲團隊自己並無責任來回答應該作什麼這個問題。」

團隊不須要執行由利益相關者提出的瀑布式計劃，他們能夠利用雙軌敏捷和設計衝刺等方法來發現有價值的產品。

原文做者｜Felipe Castro
內容編譯｜Worktile
文章來源 | Worktile官方博客文章轉載在請註明出處。