07-技术经理必修管理知识技术债治理、工程文化与持续改进技术债就像信用卡账单——你可以选择最小还款额但利息会越滚越大。终有一天你会发现大部分开发时间都在还利息而不是创造新价值。前言为什么工程文化是技术团队的操作系统见过很多技术团队技术栈很先进、人也都很聪明但交付质量就是上不去。Bug 频出、线上事故不断、新人上手慢、系统越来越难改。问题不在技术在工程文化。工程文化是技术团队的操作系统——它决定了代码怎么写、流程怎么走、问题怎么解决、知识怎么传承。好的工程文化让平凡的人做出不平凡的成果差的工程文化让优秀的人疲于奔命。这篇文章从技术债治理、工程文化建设、持续改进机制三个维度展开帮你建立一个能持续产出高质量交付的技术团队。一、技术债管理框架1.1 技术债的本质Ward Cunningham 在 1992 年首次提出了技术债这个概念。他的核心比喻是技术债就像财务债——你可以借债来加速交付但将来需要连本带利偿还。┌─────────────────────────────────────────────────────────────┐ │ 技术债复利模型 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 偿还成本 │ │ ▲ │ │ │ · │ │ │ · · │ │ │ · · │ │ │ · · │ │ │ · · │ │ │ · · │ │ │ · · │ │ │ · · │ │ │ · · │ │ └──────────────────────────────────────────────→ 时间 │ │ │ │ · 如果不还本金不重构利息额外开发成本会指数增长 │ │ · 早期偿还的代价远低于晚期偿还 │ │ · 当利息超过本金时系统就进入了死亡螺旋 │ │ │ └─────────────────────────────────────────────────────────────┘1.2 技术债的分类类型定义例子应对策略战略债为赶进度有意为之知道需要偿还为了快速上线跳过单元测试纳入偿还计划定期清理非战略债无意识累积等发现时已经很多频繁的临时方案堆砌成屎山立即评估重点清理架构债架构决策失误导致的系统性问题单体架构过度膨胀立项重构专项治理代码债代码层面的质量问题大量重复代码、复杂度过高日常 Code Review 重构1.3 技术债治理四步法┌─────────────────────────────────────────────────────────────┐ │ 技术债治理四步法 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ 第一步 │──│ 第二步 │──│ 第三步 │──│ 第四步 │ │ │ │ 识别 │ │ 分类 │ │ 量化 │ │ 治理 │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ Step 1: 识别 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 工具辅助 │ │ │ │ · SonarQube代码异味、复杂度、重复率 │ │ │ │ · ESLint/PMD代码规范检查 │ │ │ │ · 依赖扫描过期的依赖、已知漏洞 │ │ │ │ · APM 工具接口响应时间趋势、错误率趋势 │ │ │ │ │ │ │ │ 人工感知 │ │ │ │ · 这个模块每次改都要花好长时间 │ │ │ │ · 新人看这段代码要问好几天 │ │ │ │ · 改一个 Bug 引出三个新 Bug │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ Step 2: 分类 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 按影响分 │ │ │ │ · 高影响 高概率 → 立即处理 │ │ │ │ · 高影响 低概率 → 纳入计划 │ │ │ │ · 低影响 高概率 → 日常处理 │ │ │ │ · 低影响 低概率 → 记录监控 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ Step 3: 量化 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ · 技术债清单列出所有已识别的技术债项 │ │ │ │ · 估算偿还成本每个债项需要多少人天 │ │ │ │ · 估算利息成本不偿还的情况下每月多花多少工时 │ │ │ │ · 建立技术债墙可视化 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ Step 4: 治理 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ · 每个 Sprint 固定 20% 时间处理技术债 │ │ │ │ · 重大技术债立项为独立项目 │ │ │ │ · 技术债偿还进度纳入团队 Sprint Review │ │ │ │ · 定期向产品经理和上级同步技术债状况 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘1.4 技术债可视化——技术债墙技术债墙是让团队和上级看到技术债严重程度的最佳工具┌─────────────────────────────────────────────────────────────┐ │ 技术债墙示例 │ ├────────────┬────────┬────────┬──────────┬──────────────────┤ │ 债项描述 │ 影响 │ 偿还成本│ 偿还状态 │ 负责人 │ ├────────────┼────────┼────────┼──────────┼──────────────────┤ │ 订单模块 │ 高 │ 15人天 │ 进行中 │ 老张 │ │ 代码耦合 │ │ │ ▓▓▓▓░░░ │ │ ├────────────┼────────┼────────┼──────────┼──────────────────┤ │ 支付接口 │ 高 │ 10人天 │ 待开始 │ 小李 │ │ 缺少幂等 │ │ │ ░░░░░░░░ │ │ ├────────────┼────────┼────────┼──────────┼──────────────────┤ │ 商品搜索 │ 中 │ 8人天 │ 进行中 │ 老赵 │ │ SQL 慢查询 │ │ │ ▓▓▓▓▓▓░░ │ │ ├────────────┼────────┼────────┼──────────┼──────────────────┤ │ 用户中心 │ 中 │ 5人天 │ 待开始 │ 小陈 │ │ 缺少单测 │ │ │ ░░░░░░░░ │ │ ├────────────┼────────┼────────┼──────────┼──────────────────┤ │ 全局 │ 低 │ 3人天 │ 已完成 │ 小王 │ │ 日志规范 │ │ │ ▓▓▓▓▓▓▓▓ │ │ ├────────────┼────────┼────────┼──────────┼──────────────────┤ │ 依赖升级 │ 低 │ 2人天 │ 待开始 │ 实习生 │ │ (安全修复) │ │ │ ░░░░░░░░ │ │ └────────────┴────────┴────────┴──────────┴──────────────────┘ 总偿还成本43 人天 | 已偿还3 人天 | 进行中23 人天 | 待开始17 人天二、工程文化建设2.1 工程文化的三个支柱┌─────────────────────────────────────────────────────────────┐ │ 工程文化三支柱 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ │ │ │ 代码质量 │ │ │ │ Code Quality │ │ │ ├──────────────┤ │ │ │ · Code Review │ │ │ │ · 单元测试 │ │ │ │ · 静态扫描 │ │ │ │ · 代码规范 │ │ │ └──────┬───────┘ │ │ │ │ │ ┌───────────┼───────────┐ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │知识 │ │心理 │ │持续 │ │ │ │共享 │ │安全 │ │改进 │ │ │ │ │ │ │ │ │ │ │ │技术 │ │容错 │ │回顾 │ │ │ │分享 │ │文化 │ │复盘 │ │ │ │文档 │ │试错 │ │度量 │ │ │ │ │ │鼓励 │ │驱动 │ │ │ └──────┘ └──────┘ └──────┘ │ │ │ └─────────────────────────────────────────────────────────────┘2.2 代码质量Code Review 强制化Code Review 是工程文化中最基础也最重要的实践。它不仅提升代码质量更是团队知识共享和代码标准对齐的核心机制。Code Review 规范要求说明强制性任何代码合并前必须经过至少 1 人 Review时效性Review 请求发出后 4 小时内响应24 小时内完成标准化建立 Review Checklist命名规范、边界检查、异常处理等建设性评论聚焦代码不针对人提出问题时附带建议面对面复杂的逻辑问题先文字评论再当面讨论Code Review Checklist 示例┌─────────────────────────────────────────────────────────────┐ │ Code Review Checklist │ ├─────────────────────────────────────────────────────────────┤ │ │ │ □ 命名是否清晰准确变量、函数、类名 │ │ □ 函数长度是否合理建议不超过 50 行 │ │ □ 是否有充分的边界检查和空值处理 │ │ □ 异常处理是否完善不会吞掉异常 │ │ □ 是否有必要的日志记录 │ │ □ 是否有安全隐患SQL 注入、XSS、硬编码密码 │ │ □ 是否有单元测试覆盖新增/修改的逻辑 │ │ □ 是否考虑了并发安全 │ │ □ 是否有性能隐患N1 查询、大对象、内存泄漏 │ │ □ 注释是否必要且准确好的代码不需要多余注释 │ │ │ └─────────────────────────────────────────────────────────────┘2.3 心理安全Google Aristotle 项目的发现Google 花了两年时间研究什么让团队高效最终发现排名第一的因素不是成员的智商、不是技术能力、不是团队规模而是心理安全Psychological Safety。心理安全的核心含义团队成员敢于提出问题、承认错误、分享想法而不用担心被嘲笑或惩罚。┌─────────────────────────────────────────────────────────────┐ │ 心理安全建设四要素 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 1. 容错文化 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ · 犯错是正常的重复犯同样的错才需要关注 │ │ │ │ · 线上事故复盘是无责复盘——对事不对人 │ │ │ │ · 鼓励快速试错、快速学习的实验精神 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ 2. 倾听文化 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ · 任何人在会议上提出反对意见都不会被否定 │ │ │ │ · 技术经理主动征求不同意见有没有人持不同看法 │ │ │ │ · 初级工程师的声音和高级工程师一样被重视 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ 3. 坦诚反馈 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ · 用 SBI 模型情境-行为-影响进行反馈 │ │ │ │ · 反馈是双向的经理反馈成员成员也可以反馈经理 │ │ │ │ · 定期匿名收集团队氛围反馈 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ 4. 尊重差异 │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ · 尊重不同的技术偏好和工作风格 │ │ │ │ · 不用技术鄙视链用 XX 语言的都不懂计算机 │ │ │ │ · 接受合理的多样性而非要求所有人按同一模式工作 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘2.4 知识共享让知识流动起来技术团队最怕的不是技术债而是知识孤岛——某个人掌握着某个系统的全部知识其他人一问三不知。知识共享机制机制频率说明技术分享会每双周 1 次每人轮流分享技术话题30-45 分钟内部 Tech Blog持续在 Confluence/飞书文档上发布技术文章文档即代码持续重要系统的架构文档和 API 文档与代码同步维护新人导师制持续每个新人指定导师加速知识传递架构评审会按需重大技术方案邀请团队集体评审三、持续改进机制3.1 Sprint 回顾会议Retrospective回顾会议是敏捷实践中最容易被忽视也最有价值的仪式。它的目的不是追责而是让团队持续反思和改进。回顾会议四阶段┌─────────────────────────────────────────────────────────────┐ │ 回顾会议四阶段 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 阶段一数据回顾10 分钟 │ │ │ │ │ │ │ │ · Sprint 目标完成情况OKR 进度 │ │ │ │ · 交付量对比计划 vs 实际 │ │ │ │ · 质量指标Bug 数、线上事故、测试覆盖率 │ │ │ │ · 流程指标Story 完成率、WIP 波动 │ │ │ └─────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 阶段二收集反馈15 分钟 │ │ │ │ │ │ │ │ 每人回答三个问题 │ │ │ │ · 做得好的是什么继续保持 │ │ │ │ · 需要改进的是什么想办法解决 │ │ │ │ · 有什么想尝试的新想法 │ │ │ │ │ │ │ │ 形式便利贴 / 在线投票 / 匿名收集 │ │ │ └─────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 阶段三讨论与优先级排序20 分钟 │ │ │ │ │ │ │ │ · 把所有反馈归类流程/技术/人/工具 │ │ │ │ · 投票选出 Top 3 最需要解决的问题 │ │ │ │ · 针对每个问题讨论改进方案 │ │ │ └─────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ 阶段四行动项5 分钟 │ │ │ │ │ │ │ │ · 每个改进项明确负责人和完成时间 │ │ │ │ · 在下个 Sprint 中跟踪执行 │ │ │ │ · 记录到回顾会议文档 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘3.2 根因分析RCA5 Whys 方法当线上事故发生时不要只修 Bug 就完事。用5 Whys方法找到根本原因┌─────────────────────────────────────────────────────────────┐ │ 5 Whys 分析示例 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 问题线上订单接口超时影响了 5 分钟 │ │ │ │ Why 1: 为什么接口超时 │ │ → 因为数据库查询耗时突然增加 │ │ │ │ Why 2: 为什么数据库查询耗时增加 │ │ → 因为一个大查询没有走索引 │ │ │ │ Why 3: 为什么没有走索引 │ │ → 因为上线前的 SQL 审核遗漏了这个查询 │ │ │ │ Why 4: 为什么 SQL 审核会遗漏 │ │ → 因为审核流程依赖人工检查没有自动化手段 │ │ │ │ Why 5: 为什么没有自动化 SQL 审核 │ │ → 因为团队没有建立慢查询自动检测和告警机制 │ │ │ │ ────────────────────────────────────────────────────── │ │ │ │ 根因缺少慢查询自动检测和告警机制 │ │ 行动项 │ │ 1. 给所有查询接口添加慢查询监控负责人老张3 天 │ │ 2. 建立 SQL 上线前的自动化审核规则负责人小李1 周 │ │ 3. 接入 APM 工具的数据库慢查询告警负责人小陈2 天 │ │ │ └─────────────────────────────────────────────────────────────┘3.3 DORA 指标驱动的持续改进DORA 四大指标是衡量工程效能的国际标准应该成为技术经理持续改进的北极星指标定义怎么提升部署频率单位时间内成功部署到生产环境的次数CI/CD 自动化、小批量发布变更前置时间从代码提交到成功运行在生产环境的时间自动化测试、流水线优化变更失败率导致生产环境服务降级或需要修复的部署比例测试覆盖率、灰度发布服务恢复时间从服务降级到完全恢复的时间自动回滚、故障自动转移Goodhart 定律警示当一个度量指标变成目标时它就不再是一个好的度量指标。不要为了追求指标数字而优化要回到指标的初心——快速、安全、可靠地交付价值。写在最后技术债治理是打扫房间工程文化建设是养成好习惯持续改进是每天比昨天好一点。三者循环往复螺旋上升。不要期望一蹴而就。工程文化的建设是一个缓慢但确定的过程——它需要技术经理每天通过一个个具体的行动来塑造一次高质量的 Code Review、一场坦诚的回顾会议、一次无责的事故复盘、一次真诚的知识分享。你团队的工程文化就是你日常行为的总和。参考来源Google Project Aristotle 研究报告Ward Cunningham 技术债概念DORA State of DevOps Report《Accelerate》Gene Kim 等CSDN 技术债管理框架实践系列文章导航编号文章标题01从程序员到管理者的角色认知与思维转型02技术领导力构建与团队影响力塑造03高效技术团队组建与人才梯队建设04目标管理与敏捷交付实践05一对一沟通、绩效管理与激励机制06冲突解决、跨部门协作与向上管理07技术债治理、工程文化与持续改进本文08从管理到领导——高阶技术管理者的自我修养