优先改进哪个点：捏软柿子还是啃硬骨头？

如果能发现“要害点”，作为优先改进的点，且有方法来“啃硬骨头”，那么就能让持续改进切中要害，成效更大。

实践敏捷、精益或 DevOps 的团队，都在进行“持续改进”。但在持续改进中，会面临两个痛点：

1. 找不到起始点： 不知道该优先改进哪个点，感觉没有方向；

2. 啃不下硬骨头： 优先选的点改进成本太高，让人望而却步。

如果发现改进起始点这块“骨头”太硬，你是不是想换一个“软一点的柿子”，作为改进的第一步？

如果按这个思路进行改进，那么成本高的改进点是不是就一直没有机会被改进？这就解释了为什么很多团队只做低成本的代码层面的重构，但很少进行软件系统架构和基础设施这些成本高的改进。

如果能发现“要害点”，作为优先改进的点，且有方法来“啃硬骨头”，那么就能让持续改进切中要害，成效更大。

要想达到这个目的，首先要解决“找不到起始点，啃不下硬骨头”这两个问题。

找到起始点，啃下硬骨头

先说解决方案，可以用“优先改进象限”来识别改进的起始点，用“敏捷阶梯模型”来啃下硬骨头。

优先改进象限，有两个坐标轴，横轴越往右，表示质量越差；纵轴越往上，表示价值越大。改进的起始点，应该是价值最大，质量最差的那个待改进点。

敏捷阶梯模型，表示团队在互信的基础上，以消除“价值最大、质量最差”这个最大瓶颈为愿景，“尽早、频繁、小批”地进行 PDCA（Plan/Do/Check/Adjust）迭代，一个迭代进步一点地进行改进。

我创造“优先改进象限”，是受了技术债墙的启发。偿还技术债也是在做持续改进，所以道理是相通的，但技术债墙很容易被团队误用。

在这个技术债墙四象限中，右下角“投入少、见效多（止痛多）”的技术债优先偿还，而左上角“投入多、见效少（止痛少）“的技术债就不值得偿还。

人人都愿意做“投入少，见效多”的事情。但就如同绘制该图的博客作者所说，在他们回顾技术债时，发现“投入少、见效多（止痛多）”的技术债很少。作者的解释是他们在日常工作中，已经顺手把这类技术债给偿还了，所以这是个好现象。

但好现象后面隐藏着危机：对于右上角“投入多、见效多（止痛多）”的技术债，该如何处理？那篇博客没有提及。

这就是技术债墙四象限容易被误用的地方：团队往往只关注“投入少、见效多”的技术债，而对“投入多、见效多”的则视而不见。

如何偿还“投入多、见效多”的债？

比较好的做法，是将右上角“投入多、见效多”的大技术债，拆分成“投入少，见效多”的小技术债，并移至右下角的象限，参考“敏捷阶梯模型“，尽早、频繁、小批地偿还。

比如，一个团队在维护一个有 10 余年历史的遗留系统。该系统 80%的业务逻辑都写在了难以维护的 PL/SQL 里面，不仅很难阅读、重构和编写单元测试，其中还有大量的重复代码。将 PL/SQL 中的业务逻辑，改造成易于阅读、重构和编写单元测试，就应该属于偿还“投入多，见效多”的技术债。

由于该遗留系统 80%的业务逻辑，都写在 PL/SQL 里面了。要想在短期内治理全部 PL/SQL 的业务逻辑难以维护的问题，是不可能的。但可以使用“优先改进象限”，先识别出价值最大的几个业务逻辑，再从中识别出质量最差（多次出现生产事故）的一个业务逻辑，做为改进的第一步。然后就可以集中优势资源，集中治理这一个业务逻辑的维护性差的问题。比如可以考虑使用 PL/SQL 转 Java 的工具，将业务逻辑转移 Java 中，并编写单元测试并重构。如果能解决这个 PL/SQL 的业务逻辑难以维护的问题，那么就能让这个曾经多次出现生产事故的“脏乱差”，变成易于维护且高价值的“首善之区”。这样还能增强团队士气，促使大家识别下一个“价值最大、质量最差”的改进点，从而形成正反馈循环。

除了技术债墙的启发，Jim Highsmith 的敏捷三角，也启发了我创造出“优先改进象限”。

既然敏捷三角告诉我们，敏捷团队工作的主要目标，应该是价值和质量，而不仅仅是“范围、时间、成本”，那么当进行持续改进时，首先要改进的点，也自然是价值最大，且质量最差的。因为只有这样，才能更有效地达成追求”价值和质量“的目标。

除技术债墙之外，另一个常用的识别优先改进点的思路，是使用约束理论。即先绘制价值流图，标上各道工序的增值时间、等待时间和返工时间，并据此识别系统中最大的瓶颈。之后优先将这个最大的瓶颈“扩容”。等“扩容”后，再识别下一个最大的瓶颈，循环往复。但在软件开发相关的持续改进中，尤其是当要治理一个大泥球系统时，经常会面临深陷“泥潭”的局面，哪里都有问题，难以找到最大的瓶颈。另外，如果团队使用大批量交付的瀑布式开发方式，那么就难以搜集和度量增值时间、等待时间和返工时间这些识别瓶颈的数据，让瓶颈识别难上加难。

此时如果使用”优先改进象限“，那么识别出来的”价值最大、质量最差“的改进点，在大概率上是系统的最大瓶颈。这是因为，”价值最大“，意味着改进点位于价值流的主干上；”质量最差“，意味着返工最多（价值往回流，浪费很惊人），可以视作价值流动最大的瓶颈。所以，使用”优先改进象限“，可以快速地找到系统的返工的巨大瓶颈，有”投资少、见效快“的好处。

“优先改进象限”该如何落地？

可以召集团队所有成员，召开“优先改进工作坊“，一起绘制“优先改进象限”。

团队成员全员参与“优先改进工作坊“，一方面能提高优先改进点的识别准确率，另一方面能增强团队成员改进的主动性，有助于改进的落地。

工作坊主持人可以参照下面的方法，来主持“优先改进工作坊”：

1. 召集团队所有成员；

2. 每人把痛点写在便利贴上，每个便利贴只写一个痛点，贴到白板上，合并相同的点，然后分类；

3. 先按价值大小，上下排序（可以众人排队，每人一次只能移动一个改进点的上下顺序，轮流进行，直到不再有改进点的移动）；

4. 再按质量优劣，左右排序（可以众人排队，每人一次只能移动一个改进点的左右顺序，轮流进行，直到不再有改进点的移动）；

5. 右上角的痛点，就是优先改进点；

6. 大家讨论，如何用敏捷阶梯模型，尽早、频繁、小批地改进刚刚识别出的“优先改进点”；

7. 定期举办优先改进工作坊，重复上述过程。

总结

团队在进行持续改进时，往往有两个痛点：找不到起始点，啃不下硬骨头。约束理论在团队进行瀑布式大批量交付的情况下，难以识别最大的瓶颈，这样就难以找到最佳的优先改进点。技术债墙虽然能识别“投入少、见效多”的优先改进点，但很容易被误用，因为大家往往只”捏软柿子“，不”啃硬骨头“。

团队在进行持续改进时，往往有两个痛点：找不到起始点，啃不下硬骨头。约束理论在团队进行瀑布式大批量交付的情况下，难以识别最大的瓶颈，这样就难以找到最佳的优先改进点。技术债墙虽然能识别“投入少、见效多”的优先改进点，但很容易被误用，因为大家往往只“捏软柿子”，不“啃硬骨头”。此时，团队可以在“优先改进工作坊”中，一起绘制“优先改进象限”，识别“价值最大、质量最差”的改进点作为起始点，然后参考敏捷阶梯模型，“尽早、频繁、小批”地“啃下这块硬骨头”，并循环往复，形成正反馈循环，最终让每个迭代的持续改进，都切中要害，并收获更大成效。

作者简介：

伍斌_Ben，ThoughtWorks 软件开发咨询师。潜心进行软件开发技术的操练与悟道。因经常办技术操练道场，人称“道长”。著有《驯服烂代码》。自 1993 年大学毕业以来，先后做过程序员、测试工程师、项目经理和软件开发咨询师。2013 年 4 月创办全栈开发者的编程操练社区“bjdp.org 北京设计模式学习组”。微信公众号 bjdp_org。

本文转载自 ThoughtWorks 洞见

原文链接：

https://insights.thoughtworks.cn/continuous-improvement-priority/