敏捷開發--洞察敏捷模型，從PO的角度看敏捷產品管理

時間 2019-11-07

標籤敏捷開發洞察模型角度產品管理简体版

原文原文鏈接

轉自本人運營的公衆號「攜程技術中心PMO」（ID：cso_pmo）

常常有人抱怨的一個問題：敏捷會讓團隊自組織，要求團隊能「一方有難，八方支援」，可是爲何總感受本身團隊雖然實踐了敏捷，但仍是以爲人心很散，隊伍很差帶？爲何老是不能作到「上下同欲」？

碰見這樣的問題，我經常會去觀察團隊，試着從透過結果找緣由，最終你會發現一個共性，那就是在這樣抱怨的團隊中，你最常看到的現象是：總有一個所謂的「團隊負責人」在無時無刻的安排工做，在 Plan 會議上分發任務。團隊沒有產品願景，需求沒有討論，在「團隊負責人」看來這些都是浪費時間。團隊應該各司其職，開發人員就應該像發條同樣無心識的工做，整個團隊看起來根本就是帶着「敏捷」的帽子在進行瀑布式開發。

在這個病態的系統中，根本問題在於顛倒了「因果鏈」。敏捷不是解決全部問題的方法，它只是一面鏡子，讓你看見問題所在。因果關係是：團隊自主了才種下了敏捷的基礎，纔會有敏捷的實踐，而不是由於實施敏捷那些所謂的「工具」和會議，團隊就會變得敏捷，成員就會變得自主。

「菩薩畏因，衆生畏果」，帶着洞察系統的眼睛，用「因果鏈」順藤摸瓜，找到與之相連的「緣由變量」，解決問題。

系統結構

系統就是「一組相互鏈接的要素」。「現實」世界中的系統變化萬千，錯綜複雜，商業系統、組織系統、軟件系統、生態系統等等。可是，若是砍掉一切細枝末節，去掉全部干擾選項，「抽象」來看，任何複雜的系統，都構建於其固有的簡單性。

全部的系統，抽象來看，除了「要素」，就是「要素」之間的四種「鏈接關係」：因果鏈、加強迴路、調節迴路，和滯後效應。

而「要素」在這4種鏈接關係的做用下，也會持續變化，這時就被賦予了一個新名字叫：變量。這些像樂高積木同樣的「結構模塊」，搭建了一切你見到的複雜系統。

所謂變量，就是系統中變化的數量。用系統動力學中經典的「浴缸模型」，來理解變量，與時間之間的關係。

在一個浴缸中，「水」這個「變量」，有兩種不一樣的狀態：

存量（Stock），就是在一個「靜止的時間點」，浴缸中積蓄了多少水；
流量（Flow），就是在一個「動態的時間段」，有多少水流入浴缸（流入量），有多少水流出浴缸（流出量）。

在敏捷產品管理中，已有的功能是存量，新增的需求是流量, 它時刻準備在產品 Backlog 中， PO 不僅要關心以後增長的新需求（流入量），也要關心真正的核心功能是否已經達到最優（存量）；PO 更要關心團隊的速率是否保持穩定，有沒有遇到問題須要解決；關心可交付的產物（流出量）是否達到預期，用戶反饋如何。

這裏有幾個方法可以幫你更好的診斷你所在的敏捷團隊。

1. 關注「核心存量」

有些存量，它的增加能明顯提高實力，它的減小會迅速帶來危機。這些存量，是你的「核心存量」。

好比你的產品的核心功能是什麼？什麼是用戶爲之瘋狂或者依賴的功能？什麼是缺失了這些功能，用戶就會流失的關鍵點？

找到你的核心存量後，竭盡全力地往裏注入流量。不要太關心其餘不重要的功能，不要總想着要知足全部用戶的全部需求。要學會剋制，全部你要新增的需求（流入量）能轉化爲「核心存量「纔是你須要真正關心的。

流量改變存量，存量改變世界。你的核心功能又是什麼？

2. 關注「流量增速」

普通的團隊關注流量大小，但優秀的團隊關注流量增速。

流量很重要，流量增速更重要。由於流量增速是存量的「放大器」。

好比 PO 在看數據時相比於註冊量、下載量的累加，更應該關注每個月/周註冊增速和下載量比對。

好比相對於團隊每次迭代能作多少故事點，咱們應該更關注團隊速率的穩步提升。實力靠存量，潛力靠流量，趕超靠流量增速。

又好比做爲我的，若是你是一個公司職員，不要太關注35歲以前的收入，不要爲了800元、1000元，跳槽到一家學不到東西的公司。把心思，放在「能力」這個流量增速的引擎上。35歲以後，你以爲今天這些錢，少得好笑。

3. 關注「流出量」

相比較存量，咱們更關注流量。相對於流出量，咱們又更關注流入量。

好比在敏捷的實踐中，咱們談論的更可能是產品的願景，故事的估算，地圖的梳理，任務的流轉，咱們着急的輸出，每每忽視了最後交付物的用戶使用反饋。這實際上是最重要的「流出量」，PO 每每覺得本身能夠表明用戶，或者前期用戶調研就是用戶的真實需求，但其實用戶有可能只是想要更快的交通工具，而不是跑的更快的馬。關注用戶的反饋，交付物的質量，甄別有用信息，輸出真正對用戶有用的需求。

又好比 PO 更關注下載量、註冊量（流入量）。可是千萬不要忽略用戶流失率（流出量），由於用戶離開的緣由也許纔是你產品最致命的地方。