敏捷开发--洞察敏捷模型，从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月敏捷线下沙龙。
往期回顾
关注本公众号，回复“ctrip”获取历届敏捷沙龙精彩分享！
部分图片及电子书来源于网络，版权归原作者所有，仅供学习勿作它用。如果侵犯到您的权益，请联系我们撤除。
