It switched from operating public number "
Ctrip Technology Center PMO
" (ID: cso_pmo)
One problem people often complain about: self-organizing Agile teams will require teams to "a difficult one, P Plus support", but why always feel agile team practice though, but people still feel very scattered, the team is not good with? Why can not always be "down with the desire"?
Encountered such a problem, I often went to observe the team, trying to find a cause through from the results, you will eventually find a common, that is complaining about in this team, you most often see the phenomenon is: there is always a so-called the "team leader" in the organization of work all the time, to distribute tasks Plan meeting. Team no product vision, needs no discussion, "team leader" It seems these are a waste of time. Team should carry out their duties, developers should work like clockwork as the unconscious, the whole team looks simply with "agile" hat during the waterfall.
In this sick system, the fundamental problem is that the reversal of the "causal chain." Agile is not the solution to all problems, it is just a mirror, so you see where the problem lies. Causality: the independent team and we have planted the agile foundation, will have a quick practice, not because agile so-called "tools" and meetings will become agile team members will become independent.
"Bodhisattvas fear causes, sentient beings fear fruit", with insight into the system of the eye, use the "causal chain" follow it to find connected to it "causal variables", to solve the problem.
system structure
The system is "a set of elements connected to each other." "Reality" system change in the world of emotion, complex, business systems, organizational systems, software systems, ecosystems and so on. However, if you cut off all the minutiae, remove all interference options, "abstract" point of view, any complex system, are built is its inherent simplicity.
All of the systems, the abstract, in addition to "elements", that is, four kinds of "connection" between the "elements": the causal chain, enhance the loop, the control loop, and lag-effects.
The "elements" in the role of the four connected relationship, will continue to change, then it is given a new name: variable. Like these, like Lego "structural module", a complex system built everything you see.
所谓 变量，就是系统中变化的数量。用系统动力学中经典的“浴缸模型”，来理解变量，与时间之间的关系。
在一个浴缸中，“水”这个“变量”，有两种不同的状态：
- 存量（Stock），就是在一个“静止的时间点”，浴缸中积蓄了多少水；
- 流量（Flow），就是在一个“动态的时间段”，有多少水流入浴缸（流入量），有多少水流出浴缸（流出量）。
在敏捷产品管理中，已有的功能是存量，新增的需求是流量, 它时刻准备在产品 Backlog 中， PO 不只要关心之后增加的新需求（流入量），也要关心真正的核心功能是否已经达到最优（存量）；PO 更要关心团队的速率是否保持稳定，有没有遇到问题需要解决；关心可交付的产物（流出量）是否达到预期，用户反馈如何。
这里有几个方法能够帮你更好的诊断你所在的敏捷团队。
1. 关注“核心存量”
有些存量，它的增长能明显提升实力，它的减少会迅速带来危机。这些存量，是你的“核心存量”。
比如你的产品的核心功能是什么？什么是用户为之疯狂或者依赖的功能？什么是缺失了这些功能，用户就会流失的关键点？
找到你的核心存量后，不遗余力地往里注入流量。不要太关心其他不重要的功能，不要总想着要满足所有用户的所有需求。要学会克制，所有你要新增的需求（流入量）能转化为“核心存量“才是你需要真正关心的。
流量改变存量，存量改变世界。你的核心功能又是什么？
2. 关注“流量增速”
普通的团队关注流量大小，但优秀的团队关注流量增速。
流量很重要，流量增速更重要。因为流量增速是存量的“放大器”。
比如 PO 在看数据时相比于注册量、下载量的累加，更应该关注每月/周注册增速和下载量比对。
比如相对于团队每次迭代能做多少故事点，我们应该更关注团队速率的稳步提高。实力靠存量，潜力靠流量，赶超靠流量增速。
又比如作为个人，如果你是一个公司职员，不要太关注35岁之前的收入，不要为了800元、1000元，跳槽到一家学不到东西的公司。把心思，放在“能力”这个流量增速的引擎上。35岁之后，你觉得今天这些钱，少得可笑。
3. 关注 “流出量”
相比较存量，我们更关注流量。相对于流出量，我们又更关注流入量。
比如在敏捷的实践中，我们谈论的更多是产品的愿景，故事的估算，地图的梳理，任务的流转，我们着急的输出，往往忽视了最后交付物的用户使用反馈。这其实是最重要的“流出量”，PO 往往以为自己可以代表用户，或者前期用户调研就是用户的真实需求，但其实用户有可能只是想要更快的交通工具，而不是跑的更快的马。关注用户的反馈，交付物的质量，甄别有用信息，输出真正对用户有用的需求。
又比如 PO 更关注下载量、注册量（流入量）。但是千万不要忽略用户流失率（流出量），因为用户离开的原因也许才是你产品最致命的地方。
这里需要注意两点：
- 流入量与流出量不需要完全平衡，可以相互独立，并且可以暂时失衡。
这就是库存的作用。在敏捷里就是产品Backlog，比如需求的准备和最终交付给到用户到反馈所产生的需求不需要完全保持一致，可以由产品 Backlog 存放所有的需求，这里可以随时增减和调整优先级，以保证团队用正常的节奏输出最核心的功能。
- 要素虽然是组成系统的核心部分，但是改变要素对于系统的影响是最小的。
这里不是说个人不重要，相反人是敏捷团队中最重要的部分，并且需要保证团队相对固定，不要频繁增减人员或是根据项目重新组建。敏捷团队是由每个人而形成的稳定长期的连接关系，要素的改变会影响连接关系的改变，本质还是连接关系的重要性。
更多内容
本话题更多内容，欢迎参与10月敏捷线下沙龙。
往期回顾
关注本公众号，回复“ctrip”获取历届敏捷沙龙精彩分享！
部分图片及电子书来源于网络，版权归原作者所有，仅供学习勿作它用。如果侵犯到您的权益，请联系我们撤除。