重构技术债务
如果我们把解决技术债务纳入计划，它是否能成为在系统中构建丰盈的机会？
技术债务——这两个词比在周五部署一个“快速修复”更让工程师厌恶，也比错过OKR截止日期更让产品负责人恐惧。
新的架构不会在一夜之间神奇地在你的白板上自我绘制完成。
通常，技术债务源于在构建功能时采取了过多的技术捷径。你熟悉这个流程：产品团队制定了一个雄心勃勃的路线图，几乎不留出错余地，而工程师则在一个已经过时的软件基础设施上修修补补以实现这些雄心。债务就像孩子踮着脚尖溜进厨房，从储藏室偷饼干一样悄然而至，导致系统效率逐渐被侵蚀——并留下一大堆需要清理的碎屑。当“快速而粗糙”的修补成为工程组织的默认模式时，倡导“正确”的做事方式、投入时间和精力来制定详细需求、构建健壮的解决方案或自动化手动任务就会变得困难。
偿还技术债务常被视为软件工程中不那么光鲜、不那么激动人心的一面。迁移并不有趣，用新依赖替换旧依赖也是如此。新的架构不会在一夜之间神奇地在你的白板上自我绘制完成。但如果长时间忽视，技术债务会从一个被忽视的麻烦演变成灾难性的故障。相反，如果主动应对，技术债务则代表了在我们的系统中构建韧性和健壮性的机会。
这就是为什么我提议我们将技术债务重新定义为技术财富。
引入技术财富
划出时间来偿还技术债务需要得到领导层的支持。获得这种支持很难，尤其是因为最终用户可能无法直接感受到许多技术债务投资（例如改进工具或自动化流程）的影响。事实上，许多开发团队普遍存在一种误解，认为既然技术债务不影响用户，就不值得优先考虑。但现实是，解决技术债务能让我们在未来投入更多时间进行功能开发。提前处理系统的弱点意味着工程师将来花在处理混乱代码或解决被忽视问题上的时间会更少。
通过将技术债务定位为技术财富，我们可以最大限度地减少与此类债务相关的负面含义，并消除这些错误印象。这种重新定位可以改变领导层对这些至关重要的幕后投资的看法，增加他们支持这项工作的可能性。在商业中，积累财富是需要尽快、非常谨慎和专注地完成的事情。同样，为使系统更强大、更高效而进行的基础工作也应被视为值得前期投资。
定义技术财富
我们花费时间完成特定任务能获得什么价值？我们因这项工作获得了什么收益？
根据定义，财富是大量有价值的财产、商品或资源。对于一个工程团队而言，积累财富可能意味着提高生产力、工程师幸福感、系统稳定性等等。当我们以这种方式理解我们的技术开销时，我们可以专注于沟通价值：我们花费时间完成特定任务或计划能获得什么价值？我们因这项工作获得了什么收益或资源？
构建技术财富意味着从我们正在创建的软件，以及我们开发和维护它的努力中，获取更多价值。当将技术债务重构为技术财富时，我们可以问自己以下问题，以明确可用的价值放大机会：
- 我们可以采取哪些步骤来帮助团队更快、更高效地工作？
- 我们可以做些什么来提高系统的可扩展性或稳定性？
- 哪些工作可以改善工程师维护这些系统的体验？
让我们以部署自动化作为一个实际例子。通过投入工程时间创建用于自动化生产部署的基础设施，你可能会获得技术财富，具体表现在：生产上线速度加快（因为用户能更快收到新功能或错误修复），开发者幸福感提升（因为工程师花在手动部署版本到生产环境的时间更少，可以专注于更具吸引力的工作，如功能开发），以及风险降低（通过消除部署过程中的人为错误）。这项高价值的投资改善了用户、开发者和系统本身的福祉。
规划技术财富
一旦团队将工程能力分配给新功能工作，通常就只剩下很少时间来构建技术财富。假设你无法暂停功能工作——尽管我很想看到一个工程团队尝试这样做！——以下策略可以帮助团队开始将技术财富纳入规划过程。
在每个规划周期内分配时间
你的工程团队是否使用一个复杂的公式来确定每个规划周期内有多少能力用于开发工作？如果是，可以考虑将其中一小部分但有意义的能力分配给构建技术财富。
适当的时间量取决于你团队的需求。例如，如果你想增加集成或单元测试覆盖率，将80%的工程时间分配给产品开发，其余20%用于构建技术财富可能就足够了。如果你的团队需要改进架构或系统以满足新需求，你可能需要留出60%的时间来构建技术财富，40%用于产品开发。
将技术财富纳入每个规划周期的优点是，它成为团队常规节奏的一部分，从而使这种做法常态化。你的团队甚至可以开始为每个周期积累的财富设定成功指标。例如，你可以跟踪在投资构建自动化测试覆盖率前后引入的错误数量。
如果你不使用复杂公式来确定工程能力，那就从简单的开始。如果你的团队足够大——比如至少四名工程师——可以让一个人在每个周期专注于构建技术财富。考虑建立一个轮换制度，让每个工程师都有机会参与技术财富项目，同时也能构建更引人注目的功能。
无论你采取何种方法，请务必定义并记录你的技术财富任务所产生的价值。这将有助于维持对这些投资的支持。
在季度末的几周集中投入
如果你无法在每个冲刺、迭代或规划周期承诺固定的时间，那么你可能需要改为每个季度划出一段特定时期。对大多数团队来说，季度末是一个合适的时机；一旦你完成了功能交付或正在进行功能的A/B测试，你很可能有更多的工程人员空闲。至于这段时间应该多长，取决于你想要积累的财富。如果你不确定从哪里开始，可以尝试几个为期两周的迭代，这应该有足够的时间开始充实你的技术财富储备。
与我前面阐述的第一种路径不同，这种季度性策略将需要你团队100%的能力，尽管是暂时的。我发现这在需要多名工程师投入时间和精力的投资情况下特别有帮助。这种方法鼓励专注并减少上下文切换，但需要意志力——以及一些坚定的边界设定——以确保业务或产品利益相关者不会悄悄联系你的工程师，希望做最后一次“快速修改”。这个策略的另一个好处是：你可以利用这段时间清理本季度早些时候团队为达成产品目标而实施的任何修补程序或变通方案。
如果你按季度构建技术财富，你可能会发现维护一个技术财富项目待办列表供团队参考很有用。例如，你可以创建一个专门的Jira项目或Trello看板来跟踪你计划构建的财富。这将有助于保持你未来的计划清晰，并让你的技术财富目标清晰可见。
创造技术财富，减少技术债务
通过规划技术财富，你实际上正在减少技术债务。这种视角的微妙转变可以给工程团队和领导者一个关于我们作为软件开发人员工作中这一必要——但或许不那么光鲜——方面的全新看法。
技术债务暗示着匮乏，而技术财富则意味着丰盈：你的系统拥有丰盈的安全性和稳定性，你的工程师拥有丰盈的时间和满足感。一旦你将技术债务纳入你的规划周期，你就能享受到这种丰盈带来的好处。你将能够精简系统，增加创新，并最终为用户构建更好的产品——即使他们不一定能看到你在幕后构建的所有华丽而闪亮的财富。