为什么还技术债的人总是我?

为什么还技术债的人总是我?

基本认知

技术债务的含义

• 所谓技术债务，通俗地讲，其实就是那些技术上没做好的事情，会逐渐体现为长期的成本。
• 如果把视野再拔高一点，其实不单单是技术有债务的问题，业务发展带来各种各样的债务，例如团队管理、项目管理、知识管理等，其实都可能形成债务。
• 关于技术债务准确的定义与分类，因为不影响核心的思考，这里不做展开。

技术债务无法消除

• 技术债务其实无法彻底消除的，只要业务在持续运转，就一定会产生债务，重点是控制债务的规模，使其受控即可。
• 

典型成因

• 从不同的维度看，技术债务的成因会有各种各样的类别。这里我们仅从研发团队的内外视角出发，可以分成外因和内因两大类。

外因

• 技术发展

• 由于技术的发展，原先采用的技术已经落后业界，体现为落后于时代的生产力，研发效能落后于竞争对手。

• 业务发展

• 由于业务的发展，原先采用的技术已经无法适应业务，体现为业务受限，或研发效率、质量产生下滑。

• 团队变动

• 由于组织结构调整，遗留下来的祖传老业务，若不能舍弃，在反复交接后导致维护越来越困难。

内因

• 团队管理

• 急功近利的文化，习惯性地将长期利益让位于短期利益，过度追求短期交付效率。团队人员的选、育、用、留不当，人才培养跟不上，体现为团队成员的能力不足。（没招到 / 没留住 / 没培养出合适的人才，导致团队能力实质上无法匹配所需解决的问题）

• 基础薄弱

• 团队所采用的基础设施落后，没有建设好统一的技术栈底座（基础库、框架、中间件等）。

• 标准缺失

• 团队没有根据最佳实践，持续建设好标准规范并遵循。

应对的方法论

以专业做事为纲

• 这里想换个自顶而下的视角，不盯着债务本身。不单纯地为解决技术债而解决技术债，而是本身就是按照最专业最科学的方式来做事情，这样自然结果之一就会是技术债规模可控。

专业地做事

• 做什么

• 有宏观战略思考，目标导向，不要忙于战术而不自知，避免形式主义，不要混淆方法手段和目标，不要使用伪方法论。

• 需要有洞察力，对业务、技术、组织架构、组织能力进行顶层思考，做 zero-based thinking。

• 怎么做

• 按时间维度展开，大致可分为以下环节：

• 背景与问题分析：按照 MECE 准则进行问题拆解，注意不要急着讨论方案，要先明确问题及其边界。现在有一种广泛的观点，“带着自己的思考建议来讨论”，有思考自然是好事，但不必急于介入到解决方案的讨论，否则可能会把大家的节奏带偏，在不明确是否要做的时候，就耗费大量时间讨论如何去做。因此对于一些很重要的问题，要充分地分析清楚问题，确定所要达到的目标，然后再去讨论解决方案。 明确专业领域：如果有短板，需要补齐学习相关的知识，避免成为 “民科”。例如想做增长，那起码要先了解下 “增长黑客”。业界解决方案：参考对标业界成熟的解决方案，看看是否和我们的问题相匹配，有些时候直接采用即可。（例如想做单测，可能直接引入 gtest 要比从头自己做要更合适）自己的方案设计：在充分了解专业领域以及业界方案之后，结合第一性原理做思考，设计自己的方案，明确创新点、差异点。在方案选型时，用开放性的视角，使用多元的价值观，有时候不一定非此即彼，而是两者的融合，兼而有之。方案本身要关注到实际落地，规划好系统的边界和接口，重视统一性（标准化）、可扩展性和易用性，可以针对方案做全流程的投产推演。排期与计划执行：做项目管理，从时空两方面对工作进行拆解，可以分多个迭代，可以分多个模块。评估内外部资源投入，控制资源的投入规模与节奏，考虑组织调度资源的方式，例如组织架构是否需要调整、是否需要招聘借调人力等。（有时候这点要提前考虑，如果资源真的有硬限制，会影响方案选型，甚至会影响是否要做的战略决策）度量与结果对比：要有适当的度量方式，能通过数据来说明问题解决的效果。（有时候这点也要提前考虑，以免说服力不足导致无法推进）展望规划：看的更长远一些，适当考虑未来的发展。总结复盘：讨论、沉淀，内化为团队的方法论和能力。（例如完善最佳实践，完善代码库、基础组件等）

• 专业化习惯

• 目标导向：反复自省长短期目标是什么，并动态观察路径、工具、方法、资源（人 / 财 / 物 / 关系）、时机节奏等。复杂问题分而治之：时间上分迭代，空间上分模块，很多一开始没思路的问题分解之后就能迎刃而解。标准化：有章可循，沉淀形成团队的规范合集。范式化：对于很多重复的事情范式化，形成最佳实践，最好进一步固化下来，沉淀为模板、框架、库、组件、工具等。工具化：通过工具化、自动化来提升生产效率（例如 git、codecc 代码扫描、tapd、iwiki、流水线、代码生成等）。算法化、系统化：通过技术角度来解决问题（例如人工配置变为基于画像的智能决策）。迭代思维：任务分期拆分迭代，小步快跑，闭环复盘，持续自省。灰度：渐进过渡，平滑演进。调研：市场调研，用户调研。ROI：考虑成本收益与风险。知行合一：实践 - 理论 - 实践，螺旋式结构。zero based：站在最新的当下视角，不受内外部成见影响，再次审视问题。

应对的方法论

• 团队文化层面，需要形成自顶而下的统一认知，重视技术事务，在团队的正负向激励方面也予以配合，鼓励那些主动清理债务的员工。
• 团队管理层面，从能力和意愿角度识别员工，鼓励学习，为大家赋能，同时淘汰价值观不匹配的员工。从以人为本的角度讲，只要员工素质好了，技术债也就自然受控。
• 组织架构上可以设立技术中心、公共组之类的，主要是可以明确权责，方便长期持续性地维护好基础技术栈。如果仅仅是一些平行的业务研发小组，最后就会缺乏统一的质量把关控制，也没有稳定的人力投入。
• 项目管理层面，采用迭代运作，迭代中除了业务需求，也可以安排技术需求（但很难固定一个人力的百分比）。单个具体需求的评估中，需要包含有设计、文档、自测等工作的时间。
• 大的技术专项（如技术栈演进），需要自顶而下驱动，并注意做好各个角色之间的沟通。
• 当老的系统确实积重难返，改好的成本甚至高于重写，此时可以跳出现有系统去思考，考虑立新以破旧，另起炉灶采用更先进更合适的技术。但一定要考虑好如何平滑过渡，要当心新已立而旧难破的情况，同时也要评估好风险，从性能、安全、稳定性、扩展性等各方面评估新技术。例如：欢乐游戏的云原生技术栈演进。
• 持续沉淀最佳实践，形成标准、规范，并最好沉淀为模板、框架、库、组件、工具等。
• 适当采用开源开放的技术栈，通常比自己造轮子相对来讲会更加与时俱进，被技术发展淘汰的风险可能小一些。
• 从笔者个人过往经验来看，统一性（识别共性问题并采用统一的解决方案）、扩展性（功能和性能都方便扩展）、可维护性（不要搞黑科技，不要看复杂的手册才能维护），会是相对重要的几点系统非功能性需求。
• 充分利用好故障复盘的机会，推动相关技术债的偿还。

写在最后

技术债治理需要有价值观的坚守

• 对技术债的治理是一项价值投资，要做时间的朋友，如果没有价值观上的坚守，是断然坚持不下去的：
• 这个需求是急着要上线的，而且是老板重点关注的！ 看，东西不是也做出来了么？ 这么跑起来好像也没啥毛病啊？ 都已经好几年如此了，何必再去动呢？
• 在顶住压力，努力促成了团队对技术事务的正确认知后，一定还要牢记老祖宗的话：苟日新，日日新，又日新！

放任技术债会破坏团队

• 技术债的累积是一种慢性病，它不会一下子要命，但是一旦累积到一定程度，就会病入膏肓，到那时想找特效药？对不起，这个真没有！
• 当技术债累积到一定程度后，会限制业务的发展，研发效率、研发质量都会下滑。但是笔者这里更想强调的，是其对人的影响。
• 毕竟，谁会开开心心地长期在地雷阵、沼泽地里前行呢，那些技术负债过重的团队，必然口碑崩坏，也留不住优秀人才，而一旦人才都跑了，想必业务早晚也凉凉。
• 那么债务累积严重的程度是否有办法度量呢，很困难，如果是为了度量而度量，其实就会落入形式主义的误区！或许可以换个角度，尝试对研发效能做度量，一旦效能显著下降，就说明技术债务可能变多了。

要保持对技术事务的资源投入

• 没时间，没人力？
• 这恐怕是用的最多的理由，笔者个人自己的看法是 … 无论是生活中，还是工作中，其实相当大比例的时间，一定是被浪费掉的。
• 有多少事情是战术上的勤奋使然？有多少事情是真正能产生价值的？尝试性的临时性的事情占比合理么？做了那么多事情，业务会不会还是原地踏步甚至下滑，有事后总结复盘过么？
• 任何团队都可以复盘，如果复盘得到的答案，是真的忙得其所，很有价值，那恭喜恭喜！既然那么有价值，老板肯定也看得见，那是不是可以申请到更多的资源，这样团队依然可以适当保持对技术事务的投入。
• 不要总是将长期利益，让位于短期利益，正确战略方向下的慢，远远好过错误方向下的快！既要有百米冲刺的速度，又要跑马拉松的距离？这绝对是很不人道的研发模式，长此以往，且不说业务系统会出问题，但凡有点能耐的员工肯定就真 run 了！

要因地制宜

• 那究竟还能不能真的为赶工采用临时的次优实现呢？
• 假如不是跑马拉松呢，例如本就是一波流的业务，又或者是涉及生死存亡的来自某种神秘力量的需求呢？老实说，此时的快糙猛似乎也没什么不妥。因此鼓励收敛技术债，未必要遵守所有的条条框框，不能搞教条主义。
• 由于业务背景的千差万别，以及债务度量本身的困难性，所以没有一把标准的尺子可以衡量。技术债务的程度目前如何，技术事务的人力投入比例值定为多少，都需要持续的实践和思考。就像有 “中国特色” 的社会主义一样，业务团队都需要从实际出发，结合实践，探索有 “业务特色” 的技术债治理方案。
• 所以到底债务多少合适呢？这里引用技术债讨论沙龙《通过系统思考理解业务债务并有序消除》中分享的观点：

再谈专业地做事

• 虽然文章标题是有关技术债的思考，但其实笔者本人更想强调的反而是专业地做事这一点，挂羊头卖狗肉 …
• 对于有些团队而言，业务都不稳定，也没有找到稳定的收入来源，大谈技术债的治理注定是空谈。在这种寒冬之下，做点新东西，还要盈利不错，难，很难，非常难！
• 也正是考虑到这点，笔者在上面讲应对技术债的方法论时，并没有直接针对技术债本身来讲，希望那些因为眼前的苟且而选择践行快糙猛的团队，也至少可以采用更专业的姿势。
• 如果从发现并度量问题，到解决问题，再到反思避免问题的典型问题解决步骤来讲，专业地做事是利于事前 “避免问题” 的，因为往往领域内的专家早就思考总结过了，可以避免团队自己去踩坑再反思。如果债务一旦产生后就难以专门腾出人力来收拾，那是不是尽量参考专业领域内专业的方式来做事，起码让债务产生的慢一些、小一些。