「我們的積壓是死坑；零經驗證據的頂級見解已經腐爛，整個 Scrum 團隊給出了 0 f*cks”
“讓我們每個月發布 5 個錯誤修復和 3 個新功能，並希望增長能夠留給我們”
“產品管理就像沒有截止日期的專案管理，我會因為所有著火的事情而受到攻擊”
“敏捷是胡說八道：讓管理層有更多理由隨意地將東西混入其中”
“那些開發人員應該停止打開和關閉東西”“管理層正在拋出毫無意義的術語，例如損壞的記錄” 取自個人經歷
如果您經歷過其中的一些或大部分，也就不足為奇了。開發團隊和業務團隊都在不斷地互相指責對方是他們的獨角獸成長軌跡上的障礙。
儘管這些對話的真實性令人不安，但有些團隊中的每個人都真正希望體驗成長，但似乎沒有什麼能讓他們做到這一點。
如果有更好的出路不是更好嗎？
在被多個團隊稱為「技術團隊的耳語」之後，我想分享我用來傳遞焦點並同時充當業務和開發之間橋樑的框架。
閱讀準備
但在您繼續閱讀之前，我假設您已經熟悉領先滯後指標分析、OKR 方法論和 Scrum 方法論。如果沒有，請不要害怕，這裡有一些很棒的閱讀材料和靈感，可以幫助您在深入研究之前趕上進度。
領先-落後指標
OKR方法論
- 費利佩·卡斯特羅 — OKR 與 KPI
- 里克·克勞 — Google 如何設定 OKR 目標
- Google reWork：透過 OKR 設定目標
- 很棒的 OKR 範例和模板
- 為團隊 < 4 提供免費 OKR 工具
Scrum 方法論
問題是什麼？
面對著解決數十億美元問題的壓力，快樂蜂家族的交易預算，以及公司的一切都在火熱進行中，大多數團隊只能下意識地根據距離的遠近來確定他們的時間和精力的優先順序。已經到最後期限了。
由於公司的大多數人都這樣做，真正重要的問題被迴避了，而這種努力從來都沒有道理。結果，列出了一系列難以忍受的噩夢，即使是最優秀的人也會發瘋：
- 缺乏真正有意義的進步與方向感
- 業務目標與技術目標之間脫節
- 在理解問題之前先思考解決方案
- 部門和職能組之間的協同作用為 0
- PM 工具只不過是一場混亂的垃圾箱火災
- 按隨機時間表強制未完成釋放
- 缺乏負責任的高階管理決策
您可能認為這對大多數公司來說都是正確的，但這些症狀可能會導致以下問題：
- 未能吸引/留住頂尖人才
- 團隊士氣低落，工作效率低下
- 浪費時間和精力
- 未能經歷成長
一定會有更好的辦法
如果事實是有的話。
許多聰明人一直在分享見解和出色的方法來幫助團隊集中精力並實現真正的成長。但看了文章和播客後，總覺得不太實用。
事實證明，OKR 計劃和 scrum 確實可以很好地結合在一起，而且令人驚訝的是，它們在兩個框架之間確實有一些相似之處。
這兩個框架確實對團隊的自主性抱有很高的期望，以提供足夠的數據點和資訊來發揮作用，並依賴團隊提出有效的解決方案。然而，它確實帶來了一些不可或缺的好處：
- 負責任的責任 - 可操作的物品不再只是掛在團隊的嘴角上
- 無微觀管理 - 向團隊提出問題而不是解決方案，讓那些知道自己擅長的人做他們擅長的事情
- 對進步有明確的貢獻感 — 不再在黑暗中行走，每項任務和功能現在都可以追溯到公司的目標
- 每個團隊都有明確的貢獻重點 — 不再對每一個微小的變化做出下意識的計劃和反應
- 高度透明的目標和重點 — 不同職能部門不再在沒有協作的情況下獨立工作，不再有事後悲傷
為了受益於所提到的巨大福利，以下是逐步說明。
- 步驟1。 落後指標和領先指標分析
- 第2步。 OKR規劃
- 步驟 3. Sprint 修飾/發布規劃
- 步驟4。 衝刺計劃
大多數公司並不缺乏「高層策略」或任何日常營運優化。從 LinkedIn 貼文、Medium 文章到 Spotify 播客，我們充斥著高階策略，公司將這些策略視為神奇的成長咒語，可以解決一切問題。
企業真正缺乏的關鍵，是戰略與戰術之間的「翻譯」。
“我們如何用正確的問題做正確的事”
步驟1.滯後指標與領先指標分析
優先事項是成長的關鍵；因為沒有足夠的時間做所有的事情。
相信一個人的力量，集中精力，讓它發揮作用。在讓整個公司都興奮地召開“腦力激盪會議”，希望其中的一些想法能夠實現之前，首先要做的是了解問題並對此保持透明。
為了快速診斷問題而不犧牲結果的準確性，我發現滯後和領先指標是最好的起點。它為建立焦點範圍帶來的簡單性是相當有利的。
通俗地說，落後指標和領先指標就是公司內部不同KPI之間的因果關係，以樹狀圖的形式表現出來。
每個公司都有自己的關鍵績效指標結構，取決於公司的行業和規模。例如，SaaS 公司的“MRR 和流失率”，以及餐飲公司的“庫存週轉率”。儘管如此，您可以打賭幾乎每一項指標都相互依賴。
這種分析與電子商務公司所做的非常相似，即轉換漏斗分析。此練習的目的是調查瓶頸在哪裡以及需要關注的內容。
我遇到的挑戰之一是在公司內部找到“成長”，同時解決公司期間遇到的所有其他問題。團隊想到的第一件事就是聘請一位新的使用者體驗設計師，以便能夠開發出更好的功能，從而有可能吸引更多用戶。
毫無疑問，更好的功能和更好的設計將吸引更多用戶。然而，從實用性來說，更好的設計真的是最重要的嗎？當有更好的選擇來解決相同的問題時，引入全職設計師是否合理？業務中是否還有其他地方需要更多關注而團隊沒有意識到？
在2020年增加收入的共同目標下，團隊發現購物車轉換是當前的成長瓶頸。
對維護優化的投資不足以證明投資報酬率是合理的。然而，由於最近的趨勢，市場正在迅速擴大，業務轉換得越好，團隊就越能證明新功能和開發工作的合理性。
步驟 2. OKR 規劃
現在我們已經真正將問題歸結為焦點，知道了“為什麼”和“什麼”，但我們還沒有找出“如何”。 “誰”或“何時”。但在我們開始集思廣益之前，下一步是確定我們稱之為改進的為期一年的計畫的「驗收標準」。
由於該公司唯一的收入是來自應用程式產生的收入，因此我們可以有把握地說，增加的 100% 直接貢獻並反映了公司的收入成長。
在簡單地感受到了我神奇的亞洲數學力量之後，我們的團隊一致認為營收成長 100% 是一個很好的成長指標，董事會非常高興能夠實現這一目標。
這是腦力激盪最有意義的時候。不再有區塊鏈技術的廢話，不再有“人工智慧機器學習”，這些只是幕後的“if-else”語句。
在 OKR 規劃的幫助下，團隊將「內容」分解為可關聯且可追蹤的「方式」。經過一些競爭對手的研究並重新審視團隊 Google 雲端硬碟中的所有用戶訪談後，這些建議是最有意義的。
一項任務有可能會產生多個關鍵結果，例如假設社群登入是轉換率低的原因之一。 OKR 任務分解的目的實際上並不是找出如何隔離貢獻，而是將注意力集中到手邊的問題上。
步驟 3. Sprint 梳理/發布計劃
現在團隊已經調整了資源和重點，是時候了解待辦事項清單了。這就是史詩、故事和衝刺發揮作用的地方。
史詩就像 OKR 規劃中的任務一樣：成為決定相應目標成敗的支柱。然後，應該將工作分解為上下文合理的任務，供團隊執行。越明確，團隊就越專注。
一旦在產品待辦事項清單中準備好史詩（關鍵任務）和故事（核對清單），我們就準備好規劃我們的發布。
這部分實際上是產品管理和專案管理唯一相似的部分，發布就像是無盡專案的里程碑。如果你願意的話，這是成就的標誌。與無止盡的迭代不同，里程碑有一個到期日。
發布計畫之所以重要，是為了讓不同的團隊能夠為了共同的目標進行協作。開發團隊無法在不讓用戶知道的情況下建立產品，我們正在幫助行銷團隊準備上市和發布策略對於成長也至關重要。
步驟 4. Sprint 規劃
在衝刺計畫中，自殺小隊的進展受到密切監控並確定優先順序。衝刺計畫的目標是保持開發速度恆定，使團隊能夠專注於深度工作。
在 Jira 等工具的幫助下，每個故事以及故事點都會分配給團隊成員，無論它屬於哪個 Epic 或哪個版本。這不僅消除了開發人員的所有規劃壓力，而且還使團隊能夠在有效管理自己的工作方面獲得動力和自由。
因為開發工作並不總是範圍明確且易於解釋：錯誤和功能可能具有像過去的王室一樣複雜和深入的依賴關係。只有合理地預期有足夠的資源和迴旋空間來完成開發，這取決於緊急程度，也可能會發生調整和範圍調整。
最後但並非最不重要的
最後，我要感謝 吳伊沃, 潘航, 和 立州 感謝他們在我開始 Tink Labs 的 Scrum 之旅時分享了豐富的經驗，並激勵我想出這個框架。
這篇文章被推薦於 使用者體驗集體 2019年12月26日
