本周在和一个团队的交流中，发现无论是开发还是QA都非常焦虑，据他们描述的原因如下：
- 开发的backlog持续的增加。
- 交付的时间固定，因为有不同的客户在等着交钱购买这些功能。
- 因为赶工，导致质量下降。
- 最严重的时候，1天能够产生70个bug，开发可以一天修改掉70个，与此同时产生新的60个bug。
- 随着时间的推移，团队的焦虑感越来越强烈。因为似乎无法看到尽头，等着的是无尽的加班和煎熬。
上面的情况是否似曾相识？你也有类似的焦虑吗？今天借着系统思考中的一个基本模型——饮鸠止渴，来分析一下这个团队的情况。让我们一起看看能否找到一些根本的原因。
图例说明
开始之前，让我们先了解绘制系统思考的因果回路图的一些基本元素：
- 增强回路，我用大写的 “R” 来表示。增强回路可以理解为各个因素随着箭头的方向持续地良性循环或者恶性循环。
- 调节回路图，我用大写的 “B” 来表示。调节回路可以理解为各个因素随着箭头的方向会自我调节，在一定范围内来回波动。
- “+” 正向影响符号，表示箭头方向上的影响是正向的。左侧的因素增加，右侧的因素也会增加。左侧的减少，右侧的也会减少。
- “-” 反向影响符号，表示箭头方向上的影响是反向的。左侧的因素增加，右侧的因素会相应减少。左侧的减少，右侧的会相应增加。
- “=” 延迟响应符号，用等号来表示。他放在一条影响箭头上的时候，代表箭头方向上的影响会有一定延迟，不会马上发生因果响应。
系统思考
-
调节回路： 下图是一个调节因果回路图。当团队感到压力大的时候，会尝试走捷径。这里的压力可能是任务过多？bug过多，交付时间短，客户抱怨等。走捷径的形式可以是只交付功能，但是不保证质量。或者只保证正向case不考虑边界条件，还可以是不进行足够的集成测试、压力测试、回归测试等。走捷径能够一定程度让交付的速度提升上来，从而缓解了一定的压力。按照调节回路的原则，压力减轻了，期待走捷径的行为就会减少。可以看到调节回路是一个自我调节的过程。在一定的时间范围内，团队会保持在一个相对稳定的状态。
yjzkleft.png
-
增强回路： 扩大这个调节回路，我们加入更多的因素，沿着红色箭头，可以看到行成了一个增强回路。因为走捷径会引入技术债等隐藏问题。而这些问题引发的bug增加并不会马上体现，可以看到有一个延迟响应符号在这条箭头上。这就是为什么团队在一开始走捷径的时候，会感觉好像问题并不是很严重，但是随着时间的推移，bug越来越多，返工也越来越频繁。而这些直接影响了交付速度。本来走捷径希望提高交付速度，而返工和bug的增加，加重了速度的下降。压力再一次增加。
yjzk.png
感受
“饮鸠止渴”这个名字非常形象的描述了团队的现状。团队因为交付速度带来的压力，选择走捷径，忽略工程实践和质量，希望偶尔的走捷径能够给团队带来一些缓解。但因为延迟响应的原因，走捷径就像是一个慢性毒药，一旦开始依赖它，整个因果回路将进入恶性循环。团队无法摆脱它，同时焦虑感会越来越强烈，最终导致团队的崩溃。
如果你的团队也有类似的情况。通过上面的系统思考，是否可以考虑一下还要继续走捷径吗？如何避免团队持续的压力增加？调整图中的哪个因素能够让团队走出这个恶性循环呢？重新审视一下当前的backlog的数量是否合理？追求交付的数量和质量哪个更重要？
每个团队的实际情况不同，上面的分析也只是我的一个思考并不全面。希望引发小伙伴的思考，尝试找到更多的影响因素，找到好的解决之道，系统思考带给我们最重要的一点是，不要将因果关系看成简单的静态关系，而要看到因素间的动态影响，甚至还有延迟响应。通过整体的动态的分析来获得全局视角，找到解决之道。
最后
欢迎小伙伴在留言区交流。如果你有更多的系统思考的问题或者案例，欢迎留言，我们可以一起分析和探讨。
参考引用
- 如何系统思考（第2版）（《第五项修炼》作者彼得·圣吉作品，系统思考入门指导书）邱昭良
践行敏捷实践，让工作去繁从简。欢迎留言，交流落地经验。
网友评论