实践敏捷、精益或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）先按价值大小，上下排序（可以众人排队，每人一次只能移动一个改进点的上下顺序，轮流进行，直到不再有改进点的移动）；
3）再按质量优劣，左右排序（可以众人排队，每人一次只能移动一个改进点的左右顺序，轮流进行，直到不再有改进点的移动）；
4）右上角的痛点，就是优先改进点；
5）大家讨论，如何用敏捷阶梯模型，尽早、频繁、小批地改进刚刚识别出的“优先改进点”；
6）定期举办优先改进工作坊，重复上述过程
总结一下，团队在进行持续改进时，往往有两个痛点：找不到起始点，啃不下硬骨头。约束理论在团队进行瀑布式大批量交付的情况下，难以识别最大的瓶颈，这样就难以找到最佳的优先改进点。技术债墙虽然能识别“投入少、见效多”的优先改进点，但很容易被误用，因为大家往往只”捏软柿子“，不”啃硬骨头“。此时，团队可以在”优先改进工作坊“中，一起绘制”优先改进象限“，识别”价值最大、质量最差“的改进点作为起始点，然后参考敏捷阶梯模型，“尽早、频繁、小批”地”啃下这块硬骨头”，并循环往复，形成正反馈循环，最终让每个迭代的持续改进，都切中要害，并收获更大成效。
