cto-tech-debt

name	cto-tech-debt
description	识别和管理技术债务，制定还债计划
version	1.0.0
tags	["cto","maintenance"]
layer	L3-workstation
role	cto

📍 技术债务管理

触发条件

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

输入要求

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

执行步骤

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

输出模板

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

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

## Top 5 优先还债项

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

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

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

异常处理

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

边界

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