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

轉自本人運營的公眾號“ 攜程技術中心PMO”（ID：cso_pmo）

經常有人抱怨的一個問題：敏捷會讓團隊自組織，要求團隊能“一方有難，八方支援”，但是為什么總感覺自己團隊雖然實踐了敏捷，但還是覺得人心很散，隊伍不好帶？為什么總是不能做到“上下同欲”？遇見這樣的問題，我常常會去觀察團隊，試著從透過結果找原因，最終你會發現一個共性，那就是在這樣抱怨的團隊中，你最常看到的現象是：總有一個所謂的“團隊負責人”在無時無刻的安排作業，在 Plan 會議上分發任務，團隊沒有產品愿景，需求沒有討論，在“團隊負責人”看來這些都是浪費時間，團隊應該各司其職，開發人員就應該像發條一樣無意識的作業，整個團隊看起來根本就是帶著“敏捷”的帽子在進行瀑布式開發，在這個病態的系統中，根本問題在于顛倒了“因果鏈”，敏捷不是解決所有問題的方法，它只是一面鏡子，讓你看見問題所在，因果關系是：團隊自主了才種下了敏捷的基礎，才會有敏捷的實踐，而不是因為實施敏捷那些所謂的“工具”和會議，團隊就會變得敏捷，成員就會變得自主， “菩薩畏因，眾生畏果”，帶著洞察系統的眼睛，用“因果鏈”順藤摸瓜，找到與之相連的“原因變數”，解決問題，

系統結構系統就是“一組相互連接的要素”，“現實”世界中的系統變化萬千，錯綜復雜，商業系統、組織系統、軟體系統、生態系統等等，但是，如果砍掉一切細枝末節，去掉所有干擾選項，“抽象”來看，任何復雜的系統，都構建于其固有的簡單性，所有的系統，抽象來看，除了“要素”，就是“要素”之間的四種“連接關系”：因果鏈、增強回路、調節回路，和滯后效應，而“要素”在這4種連接關系的作用下，也會持續變化，這時就被賦予了一個新名字叫：變數，這些像樂高積木一樣的“結構模塊”，搭建了一切你見到的復雜系統，所謂變數，就是系統中變化的數量，用系統動力學中經典的“浴缸模型”，來理解變數，與時間之間的關系，在一個浴缸中，“水”這個“變數”，有兩種不同的狀態：

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

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

這里有幾個方法能夠幫你更好的診斷你所在的敏捷團隊， 1. 關注“核心存量” 有些存量，它的增長能明顯提升實力，它的減少會迅速帶來危機，這些存量，是你的“核心存量”，比如你的產品的核心功能是什么？什么是用戶為之瘋狂或者依賴的功能？什么是缺失了這些功能，用戶就會流失的關鍵點？找到你的核心存量后，不遺余力地往里注入流量，不要太關心其他不重要的功能，不要總想著要滿足所有用戶的所有需求，要學會克制，所有你要新增的需求（流入量）能轉化為“核心存量“才是你需要真正關心的，流量改變存量，存量改變世界，你的核心功能又是什么？

2. 關注“流量增速” 普通的團隊關注流量大小，但優秀的團隊關注流量增速，流量很重要，流量增速更重要，因為流量增速是存量的“放大器”，比如 PO 在看資料時相比于注冊量、下載量的累加，更應該關注每月/周注冊增速和下載量比對，比如相對于團隊每次迭代能做多少故事點，我們應該更關注團隊速率的穩步提高，實力靠存量，潛力靠流量，趕超靠流量增速，又比如作為個人，如果你是一個公司職員，不要太關注35歲之前的收入，不要為了800元、1000元，跳槽到一家學不到東西的公司，把心思，放在“能力”這個流量增速的引擎上，35歲之后，你覺得今天這些錢，少得可笑， 3. 關注 “流出量” 相比較存量，我們更關注流量，相對于流出量，我們又更關注流入量，比如在敏捷的實踐中，我們談論的更多是產品的愿景，故事的估算，地圖的梳理，任務的流轉，我們著急的輸出，往往忽視了最后交付物的用戶使用反饋，這其實是最重要的“流出量”，PO 往往以為自己可以代表用戶，或者前期用戶調研就是用戶的真實需求，但其實用戶有可能只是想要更快的交通工具，而不是跑的更快的馬，關注用戶的反饋，交付物的質量，甄別有用資訊，輸出真正對用戶有用的需求，又比如 PO 更關注下載量、注冊量（流入量），但是千萬不要忽略用戶流失率（流出量），因為用戶離開的原因也許才是你產品最致命的地方，

這里需要注意兩點：

流入量與流出量不需要完全平衡，可以相互獨立，并且可以暫時失衡，

這就是庫存的作用，在敏捷里就是產品Backlog，比如需求的準備和最終交付給到用戶到反饋所產生的需求不需要完全保持一致，可以由產品 Backlog 存放所有的需求，這里可以隨時增減和調整優先級，以保證團隊用正常的節奏輸出最核心的功能，

要素雖然是組成系統的核心部分，但是改變要素對于系統的影響是最小的，

這里不是說個人不重要，相反人是敏捷團隊中最重要的部分，并且需要保證團隊相對固定，不要頻繁增減人員或是根據專案重新組建，敏捷團隊是由每個人而形成的穩定長期的連接關系，要素的改變會影響連接關系的改變，本質還是連接關系的重要性，更多內容本話題更多內容，歡迎參與10月敏捷線下沙龍，

往期回顧

2019.08-敏捷總動員
2019.05-OKR專場
2019.03-專案經理敏捷轉型
2019.01-企業敏捷轉型
2018.12-需求和創新

關注本公眾號，回復“ctrip”獲取歷屆敏捷沙龍精彩分享！

部分圖片及電子書來源于網路，著作權歸原作者所有，僅供學習勿作它用，如果侵犯到您的權益，請聯系我們撤除，

轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/7231.html

標籤：其他

上一篇：利用百度大腦，快速搭建一個紅酒識別的小程式

下一篇：Linux中防火墻命令