节选：技术债务墙——一种让技术债务可见并可协商的方法
8 minute read
越乱的地方，越需要有人担起责任
2020-02-25 修改，统一将【管理】替换成【处置】。本文的用意是真正将事情办好，提升工作效率和公司效益。【管】【控】这类字眼在中文语境已变质，变成某些阶层无本生利的手段之一。很可悲，一个中性词变成了贬义词。
本人对原文做出了一些修改。
why: 技术债务需要处置
问题并不是技术债务本身，而是未经处置的技术债务。任何一家合格的公司CFO都精确地知道有多少财务债务。他们拥有债务表格、季度报告、支付计划、以及再融资或出售债务的选项。但是如果你问一家公司的CTO，他所在的组织有多少技术债务，你会得到吞吞吐吐的回答：“额，…挺多的吧？”
what: 广义技术债务
技术债务并非都是代码：构架、文档、测试、以及数据模型都可能欠下技术债务。
how: 处置技术债务的最佳实践
让老板看到并看懂
当一个团队申请时间解决技术债务时，老板并不能直接看到商业上或者用户可获得的收益。
添加一些 € 或者 $ 符号到墙上。毕竟钱是通用语言，并且亏钱两次是令人肉痛的。不妨量化成时薪，或者公司日运营成本。
让债务可见
保证它最大限度公开可见。不妨就在所有内部交流平台上：例如公司邮箱、basecamp。
不要过度优化
如果你碰到丑陋或奇怪的代码，但你没有因此浪费时间，那就不要标记它。我们不是在测量你是否喜欢它，只是在测量它消耗的时间。
没有证据显示该债务会让你继续付出成本？那就让子弹飞一会儿，从现在开始收集更多的点。
建立习惯
每当你在工作时：
- 思考债务问题：是什么让你变慢了？是什么让代码变得难以理解？是什么导致了BUG难以跟踪？哪些部分应该有更好的文档？哪些部分应该有更好的测试？然后在便签上记下你所遇到的技术债务。但是要保证事后你知道自己写的是什么。
- 估计机会成本：如果这些问题不存在，你可以花在其他事情上的时间有多少。把你的估计写在便签上。商定好时间标记，例如计数符号(Tally_marks)或每个点表示半天。相对于时间估计的精确度，更重要的是让机会成本估计本身被团队成员所知道，遵循可见性大于精确度的原则。
- 估计修复时间：需要多久修复这个问题？同样的需要在便签上写下这个估计。
- 考虑怎样修复：可选的，你可以写下怎样才能修复该技术债务。你可能会在一个issue处置软件里跟踪该问题的修复，写下issue处置软件里对应的ID。
- 最后，把便签贴到技术债务墙上。
- 每当有人碰到同样的问题，添加更多标记，累计损失的时间。
记住：每当你引入了一个技术债务的时候就应该自觉添加一个技术债务便签。对自己诚实，这没什么好羞耻的，因为你并不是你写的代码。
记住：技术债务是一笔投资，不是一次犯罪。—-除非你在隐藏债务
定期协商
关键不在于解决所有的技术债务，关键在于学会协商什么时候添加、修复、以及规避技术债务。在此之前，这些通常都在看不见的地方发生着，团队中的成员在不知道全部细节的时候，默默添加或修复技术债务。而现在，集体的智慧加上真实的数据，在发挥力量。
防患于未然：当引入了一个新的技术债务，考虑一下团队是否可以对临时做法或山寨做法说不，立刻就修复它，并且保持最小代价。我们不应该问：“我们有时间吗？”，而应该问：“这个债务是否值得延后关注？代价多大？”。答案应该在“没关系，就提交这个债务吧”到“很多事情都依赖它，在继续前进之前，让我们干掉它”之间。
无论何时，如果有人给已存在的债务便签上的时间记号增加一个点，就应同时和团队讨论该技术债务。比较该债务上已经浪费掉的时间和预估的修复它所需要的时间成本。当然，你可能需要花一天时间修复它，但是相比于你每周都要在这上面浪费两个小时，你很快就回本了。又或者，它并不值得你去修复。技术债务再也不是一个审美问题或观点问题了，而是一个经验收集的指标问题。恭喜你们学会了集体协商，并懂得取舍。
To be, or not to be
在阅读了我（译注：指原文作者@mathiasverraes）在2013年的博客后，一家创业公司引入了技术债务墙。它们是一家很小的公司。他们曾被完美主义和临时方案之间以适应快速的市场变化所困扰。技术债务墙帮助他们打破了困局，从而很快地运转了起来。我们听到很多成功使用技术债务墙的团队故事，也许你也可以。