如果能发现“要害点”，作为优先改进的点，且有方法来“啃硬骨头”，那么就能让持续改进切中要害，成效更大。
实践敏捷、精益或DevOps的团队，都在进行“持续改进”。但在持续改进中，会面临两个痛点：
找不到起始点：不知道该优先改进哪个点，感觉没有方向；啃不下硬骨头：优先选的点改进成本太高，让人望而却步。如果发现改进起始点这块“骨头”太硬，你是不是想换一个“软一点的柿子”，作为改进的第一步？如果按这个思路进行改进，那么成本高的改进点是不是就一直没有机会被改进？这就解释了为什么很多团队只做低成本的代码层面的重构，但很少进行软件系统架构和基础设施这些成本高的改进。如果能发现“要害点”，作为优先改进的点，且有方法来“啃硬骨头”，那么就能让持续改进切中要害，成效更大。找到起始点，啃下硬骨头
先说解决方案，可以用“优先改进象限”来识别改进的起始点，用“敏捷阶梯模型”来啃下硬骨头。优先改进象限，有两个坐标轴，横轴越往右，表示质量越差；纵轴越往上，表示价值越大。改进的起始点，应该是价值最大，质量最差的那个待改进点。敏捷阶梯模型，表示团队在互信的基础上，以消除“价值最大、质量最差”这个最大瓶颈为愿景，“尽早、频繁、小批”地进行PDCA（Plan/Do/Check/Adjust）迭代，一个迭代进步一点地进行改进。
我创造“优先改进象限”，是受了技术债墙的启发。偿还技术债也是在做持续改进，所以道理是相通的，但技术债墙很容易被团队误用。
在这个技术债墙四象限中，右下角“投入少、见效多（止痛多）”的技术债优先偿还，而左上角“投入多、见效少（止痛少）“的技术债就不值得偿还。
人人都愿意做“投入少，见效多”的事情。但就如同绘制该图的博客作者所说，在他们回顾技术债时，发现“投入少、见效多（止痛多）”的技术债很少。作者的解释是他们在日常工作中，已经顺手把这类技术债给偿还了，所以这是个好现象。但好现象后面隐藏着危机：对于右上角“投入多、见效多（止痛多）”的技术债，该如何处理？那篇博客没有提及。这就是技术债墙四象限容易被误用的地方：团队往往只
