「技术债」遗留的技术债务问题怎么解决？( 二 )

交付能力：以可量化的方式提高交付速度或产出质量。示例：将部署过程自动化，以便更快 / 更频繁地将代码从主干 / 主分支投入到生产环境中。

计划外工作：当延误会导致高昂的代价，且造成工期紧迫时，你应优先考虑这项工作，并立即解决问题，或者是与其他所有正在进行的事情一起解决，而不是将它们推迟到你的积压工作中或未来的周期，包括 bug、客户支持请求、生产事故等。示例：影响 20% 的客户的生产停工。通过将工作归类到这四个方面中，沟通工作的价值应该会变得更容易，并且腾出时间来处理技术债务问题也会变得更容易。

请注意，上述分类应该适用于整个积压工作，而不仅仅是技术债务问题，因为将时间分配给技术债务问题就意味着不能将时间分配给其他工作了。还要注意的是，技术债务可能会被归类为交付能力或计划外工作。
规划的层次结构
【「技术债」遗留的技术债务问题怎么解决？】前面我提到的 “在每个阶段” 是有原因的：能够在组织层次之间用一致的词汇进行沟通，有助于影响解决技术债务问题的投资决策。许多科技公司采用的模式是，每个小组、团队或 “双披萨” 团队往往负责管理受组织层次影响的积压工作。如果你的组织是这样运作的，那么让决策层了解这一框架将有助于你在术语、逻辑和论证上保持一致。译注：“双披萨”团队是指遵循两个披萨原则的团队。两个披萨原则最早是由亚马逊 CEO 贝索斯提出的，他认为如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了。因为人数过多的项目会议将不利于决策的形成，而让一个小团队在一起做项目、开会讨论，则更有利于达成共识，并能够有效促进企业内部的创新。亚马逊内部有所谓的 “双披萨” 团队，指的是团队的人数相当于可以吃掉 2 个披萨，这种组织理论非常知名。 “双披萨” 团队得名的由来，是因为团队的成员很少，只有 6-10 人，用两张披萨就能喂饱他们。 “双披萨” 团队最重要的不是规模，而是它的 “适度职责” 。它相当于为一个部门的损益负责，可以让团队保持专注、负上责任。在一些案例中， “适度职责” 本身就是为损益负责，例如，如果我是 SEM（搜索引擎优化）团队的一员，我的职责就是通过赞助链接提高营收，获得更多利润，降低点击的成本。一旦获得批准，团队就可以相对自治的执行，将 “适度职责” 最大化，它们可以寻找创新战略，然后将战略作为内部优先之事对待。一些工程师，搭配一个或者两个技术产品经理，配一个设计师，他们直接向 “双披萨” 团队的主管报告；在团队之间没有必要协作，他们可以独立在各部门间行动，将工作完成。这种模式让亚马逊在增长的同时保持敏捷和创新。
无法分类的技术债务问题
与任何模型或框架一样，也存在不适合其结构的极端情况。乍一看，你可能无法忽略某个问题，但又不能将其分类为交付能力或计划外工作。请不要在第一眼看到问题时就放弃：督促自己找到一种方法，通过稍微深入地研究问题的细节（或与同行、中小企业进行合作），将这些问题合理地归结为其中之一。如果在第二次尝试后仍然不适合，那也没有关系。 “这个代码很难测试。 ” —— 这是那些令人感到棘手的场景中的一个例子，在这种场景下，可能很难直接忽略它，或者说你不清楚如何对它进行分类。遇到这种情况，我建议采用以下方法：对你的代码做一些小规模的、渐进式的改进，不要试图花时间来解决 “大爆炸式” 项目。每个拉取请求（Pull Request）都应该改进你的代码、改进你的测试，并提高测试覆盖率（或者至少不能退步！）。 CI 系统中的质量检验甚至可以强制执行一些规则，例如不允许测试覆盖率下降超过 X% ，并且要求最低覆盖率为 Y% 。如果这看起来不是一个易于处理的方法，那么你可能需要找到一种方法来重新定义问题，以便将问题分解成更小的 “块”，也许其中一些部分可以被忽略，一些部分可以被分类，还有一些部分可以用上面提到的即用即付（PAYG）方法来处理。