目录
最近在一个边重构边上云的项目里，受到些来自于非研发部门的压力（为什么要花这钱/时间，为什么要放着业务需求不做干这个…），搞得技术团队的小伙伴有点儿委屈：
软件系统需要不停还技术债，这个认知都没有吗？项目难度这么大，不是非干不可我们还不想干呢…
我安慰大家，「这个认知都没有」其实很常见，因为人家没有欠这个债。
我使用「技术债」这个类比从来都很小心，特别是在管理团队推进这样的项目时。因为没有技术背景的人多半有下面的心理模型：
- 这个债叫是技术团队欠下的，所以叫技术债，说明他们干得有问题，需要去填自己挖下的坑；
- 他们要花成本还债，但花这么多时间和钱，即使一切顺利，系统也只是大致做了跟之前一样的事情；
所以要怎么推进这样的项目比较好？
什么是技术债
「技术债」这个术语由敏捷大佬 Ward Cunningham 在 1992 年提出，在 1999 年被 Martin Fowler 用四象限分类后在技术圈迅速变成通识，现在已经有人可以对它做全生命周期的建模。
就我个人而言，所有这些类比都有过度抽象的嫌疑。在具体工作中，我们把包括但不限于代码质量（可理解性、效率、可维护性等）到架构质量（领域模型、核心抽象、应用边界、接口质量等）到基础设施质量（稳定性、弹性、可用性、可靠性等，以及是否采用或者停用某些技术、框架、设施）的所有非产品功能的开发需求，都归入「技术债」，好像是表达有天我们应该「偿还」它。
如果要在公司里推进这类项目，需要在研发内外建立不一样的心理模型。
内部心理模型
和号称的不同，大部分人不喜欢改变。
很多优秀的工程师尤其不喜欢对还在工作的旧轮子进行重构：大家宁愿造点儿新的轮子。
要让研发内部形成一个心理模型：我们研发的软件系统，本质上是整个组织基于对未来的预测，下的赌注的放大器。
如何让这个放大器稳定、高效、灵活，是我们在完成功能开发的同时，需要持续不断投入的本职工作。而不是已经做完了所有需求，给公司完成的「额外部分」。
这步如果有意识地去推，应该不太难：毕竟是内部，还有很多管理上牵引的办法和工具。
外部心理模型
更重要的是，在公司里要建立一个统一的心理模型：技术债是整个公司欠的，并且不可避免。
为什么是整个公司欠的？
因为我们的系统，既覆盖基础设施、需求开发、产品上线，也覆盖管理、设计、运营、销售、市场、组织战略。
可以说，公司的每个部门都代表了对外部用户或内部用户的某种承诺。这些承诺只要还有没有完美交付的地方，只要这些地方涉及软件上的改进，那么就是「技术债」：它不是技术部门的债务，它是需要用技术投入解决的债务。
为什么不可避免？
因为技术债本质上来自于复杂度，而复杂度不可避免。
大部分人厌恶复杂度，因为教育阶段训练我们用简单的线性思维来思考问题。
但公司管理团队大部分经过人生历练和有效学习之后，对复杂度会有理解和预期。
在这步感到很困难的同学很多，因为大量都不是技术上的工作而是「人」上的工作。很多技术管理者往往意识不到，让自己的团队「被认为」在正确和高效的工作，和他们「实际上」在正确和高效的工作，是同样重要的。
甚至在某些阶段，前者更加重要，不然连让大家「实际上」在正确和高效工作的空间和时间可能都拿不到。