Stakeholder Criteria in Technical Debt Decision-Making: A Practitioner-Informed Taxonomy
基于对 11 位巴西软件从业者的定性研究，本文提出了一个由从业者启发的分类法和概念模型，将利益相关者在技术债决策中的标准分为六个家族，并区分了这些标准是如何作为债务获取的许可机制与债务偿还的授权机制发挥作用的。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下正在盖房子。有时，你需要快速入住，因为家里有宝宝要出生了，或者房东要涨房租了。于是，你决定暂时跳过安装阁楼里那些华丽、昂贵的隔热材料，而是只铺设一些薄薄的、廉价的面板。你知道这并不完美，也知道以后必须修复它，但你现在就需要搬进去。在软件世界中，这被称为技术债（Technical Debt）。这是为了节省当下的时间而采取的权宜之计，你知道以后会付出更多的精力（甚至可能是金钱）来偿还。
这篇论文提出了一个简单但棘手的问题：人们究竟是如何决定何时采取这些权宜之计的，又是如何决定何时最终偿还债务的？
作者发现，这些决策不仅仅关乎数学或代码。它们是业务压力、团队感受和办公室政治交织在一起的复杂产物。为了帮助我们理解这一点，他们创建了一个“菜单”（分类法），列出了人们用来做出这些选择的理由。
以下是他们研究结果的拆解，使用了简单的类比：
1. 同一枚硬币的两面
论文强调，背负债务（采取权宜之计）和偿还债务（修复问题）是两个截然不同的对话，尽管它们讨论的是同样的事情。
- 获取（采取权宜之计）： 这可以看作是一张**“准假条”**。团队在问：“现在跳过隔热安装可以吗？”他们使用的理由就像是准假条，上面写着：“可以，去做吧，因为宝宝明天就要出生了！”
- 偿还（修复问题）： 这可以看作是一个**“授权请求”**。团队在问：“我们可以停止建造新厨房，转而去修补阁楼的隔热层吗？”这要难得多。他们需要得到老板的“同意”，才能停止做新工作并开始处理旧问题。
2. 六大类理由（分类法）
研究人员采访了 11 位来自巴西的软件专业人士，发现每个人都会使用六种主要的理由来进行这些决策。你可以把这些看作是他们看待问题的六种不同“视角”：
面向利益相关者的价值（“客户的微笑”）：
- 内容： 客户会开心吗？产品能否按时发布？
- 类比： 如果这个权宜之计能让房子赶在生日派对前准备好，那就是“可以”。如果糟糕的隔热让客人在屋里感到太冷，那就是“现在就修！”
交付与资源压力（“滴答作响的时钟”）：
- 内容： 截止日期、预算以及团队的疲劳程度。
- 类比： “我们周五必须搬进去，所以不能等隔热材料到位。”但随后又说，“我们没法修隔热，因为我们正忙着刷墙。”
技术完整性与系统性风险（“结构的稳固性”）：
- 内容： 代码（或房子）会坍塌吗？它安全吗？
- 类比： “如果我们不修补地基，整个房子可能会塌掉。”这是工程师的声音。但通常，只有当房子真的在摇晃时，老板才会听取意见，而不仅仅是因为工程师说它“可能”会摇晃。
决策依据与认识论风格（“证据 vs 直觉”）：
- 内容： 我们如何知道这是一个正确的选择？我们是基于数据，还是仅仅在凭感觉？
- 类比： 采取权宜之计通常基于“直觉”或紧迫感（“我觉得我们可以这样做”）。而偿还债务通常需要“硬证据”（“看看这张图表，显示我们的房子每天都在流失热量”）。
治理与合法化（“办公室政治”）：
- 内容： 谁拥有说“是”的权力？这项决策是否符合公司规定？
- 类比： 你可能知道需要修补屋顶，但如果房东（组织）还没签署相关文件，你就无法进行。你必须说服他们这是一项合理的支出。
人类与团队的可持续性（“团队的情绪”）：
- 内容： 团队是否正在职业倦怠？他们是否感到沮丧？
- 类比： “如果我们不修好这个漏水的屋顶，工人们会因为受够了淋雨而辞职。”有时，偿还债务仅仅是为了让团队保持快乐和高效的工作状态。
3. 重大发现：“准假”与“授权”之间的差距
这篇论文最重要的发现是，获得采取权宜之计的“准假”要容易得多，而获得修复债务的“授权”却难得多。
- 为什么？ 当你采取权宜之计时，你是用一个未来的问题来换取一个当下的胜利（比如让客户开心或赶上截止日期）。“准假条”很容易签署，因为回报是即时的。
- 陷阱： 当你稍后试图修复债务时，你是在请求停止做那些新的、令人兴奋的工作，转而去处理旧的、隐形的问题。这种“授权”很难获得，因为回报是隐形的（防止未来的灾难），而代价是即时的（停止当前的进展）。
4. 决策是如何发生的
论文指出，这些理由并不只是静止的列表。它们会经历一个过程，最终转化为真正的决策：
- 解释（Interpretation）： 有人必须决定一个问题意味着什么（例如：“这是一个代码漏洞，还是一个业务风险？”）。
- 转化（Translation）： 技术团队必须用业务语言来解释问题（例如：不再说“数据库很慢”，而是说“如果网站变慢，客户就会流失”）。
- 合法化（Legitimation）： 最后，组织必须同意这是一个合理的理由，可以投入时间和金钱。
总结
这篇论文并没有给出一个关于应该承担多少债务的公式。相反，它为我们提供了一张软件团队内部对话的地图。它表明，决定采取权宜之计还是修复它们，不仅仅是关于“好代码”对比“坏代码”。它是截止日期、快乐的客户、疲惫的员工以及办公室政治之间一场复杂的舞蹈。
核心结论是：我们非常擅长为权宜之计辩护（因为这些理由声音很大且非常紧迫），但我们非常不擅长为修复行为辩护（因为这些理由声音很小且面向未来）。理解这种差距，有助于团队进行更有效、更诚实的关于技术债的对话。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。