Cto Tech Debt

识别和管理技术债务,制定还债计划

deepleaper cf69356 1.9 KB Updated

File contents

📍 技术债务管理

触发条件

  • CEO 问"为什么开发越来越慢"
  • 架构评审中发现历史遗留问题
  • 团队反馈开发效率下降
  • 季度技术健康检查

输入要求

  1. 现有技术栈和代码库概况
  2. 团队反馈的痛点
  3. 可选:代码质量指标、部署频率变化

执行步骤

  1. 识别技术债务来源:
    • 🏗️ 架构债务:早期快速迭代的临时方案
    • 📦 依赖债务:过时的框架/库
    • 📝 文档债务:缺失或过时的文档
    • 🧪 测试债务:缺乏自动化测试
    • 🔧 工具债务:低效的开发/部署流程
  2. 评估每项债务的:
    • 影响(对开发效率/稳定性/安全的影响)
    • 还债成本(人×天)
    • 利息(不还会持续增加什么成本)
  3. 排优先级:利息高 + 成本低 的先还
  4. 制定还债计划(融入正常迭代)

输出模板

# 技术债务清单 | YYYY-Q[N]

## 债务总览
| 类型 | 数量 | 总还债成本 | 月利息 |
|------|------|-----------|--------|
| 架构 | ... | ...人天 | ... |
| 依赖 | ... | ... | ... |
| 测试 | ... | ... | ... |

## Top 5 优先还债项

| # | 债务描述 | 利息 | 还债成本 | ROI | 建议时间 |
|---|---------|------|---------|-----|---------|
| 1 | ... | 高 | 3人天 | 高 | 本月 |
| 2 | ... | 中 | 5人天 | 中 | 下月 |

## 还债策略
- 每个 Sprint 分配 [X]% 时间还债
- 大型债务拆成小任务
- 新功能开发时顺手还相关债务

## 不还的后果
[如果继续忽略,6个月后会怎样]

异常处理

  • 团队不认为是技术债 → 用数据说话(部署频率、故障率)
  • CEO 不愿投入时间还债 → 量化"利息":不还每月多花多少

边界

  • 不做具体重构实施(→ 研发团队)
  • 不做预算决策(→ CFO)

deepleaper/leaper-agent/tree/main/skills/skills/L3-workstation/cto-tech-debt commit cf69356f1f

Frequently asked questions

npx skillmds@latest add deepleaper/cto-tech-debt