关于 managing-tech-debt
面向产品与工程团队的技术债务管理技能，帮助判断紧迫性、选择渐进改进或其他方案，并为减少技术债务建立业务依据。
主要功能
- 01评估债务状况与业务紧迫性
- 02选择渐进修复或重构
- 03评估整体重写的风险
- 04量化偿还债务的价值
- 05识别用户可见的债务迹象
- 06清理无用代码和积压缺陷
适用场景
- 01确定拖慢交付的债务优先级
- 02向利益相关方说明维护成本
- 03判断应重构还是整体重写
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/managing-tech-debt确认已加载。
附带文件references/guest-insights.md
详细介绍
管理技术债
借助 18 位产品负责人的见解，帮助用户以战略性方式管理技术债。
如何提供帮助
用户寻求技术债方面的帮助时：
- 了解情况 - 询问债务的性质（遗留系统、代码质量、架构局限）、表现形式（开发速度缓慢、故障、无法发布）以及业务背景
- 判断紧迫程度 - 确定这是否阻碍了关键业务需求，还是一个影响较慢的问题
- 选择合适的方法 - 帮助他们决定是逐步改进、针对性重构，还是（极少数情况下）彻底重写
- 构建商业论据 - 帮助量化债务成本，并向利益相关者传达其价值
核心原则
重写几乎从来行不通
Camille Fournier：“工程师向来、向来、向来会大大低估将旧系统迁移到新系统所需的时间。顺便说一句，你在开发新系统的同时还得支持旧系统。”彻底重写是个陷阱。应优先逐步演进——提升特定组件，而不是从头开始。
技术债就是产品债
Ebi Atawodi：“基础设施就是产品。就这么简单。我不可能在摇摇欲坠的地基上建摩天大楼。所以这也是你的问题——不能让工程师一个人去敲门争取。”产品经理应将技术债作为“产品债”来负责，而不是将其视为纯粹的工程问题。将其列入你的十大问题清单。
初创公司应有策略地承担债务
Gaurav Misra：“作为初创公司，你的工作就是承担技术债，因为这样你才能比大公司运作得更快。”债务是一种杠杆——评估问题是否可以留给未来招聘的人解决，而非现在解决。但要监控“利息”——如果 80-90% 的时间都花在维护上，你的时间余量就耗尽了。
删除代码比编写代码更多
Farhan Thawar：“我们有一个删代码俱乐部。我们几乎总能找到一百多万行代码可以删除。一切都会变得更容易——代码库加载更快，也更容易理解。”安排专门时间或组建团队，专注于删除未使用的代码。删除代码能提升开发速度和清晰度。
用户能感受到技术债
Matt Mullenweg：“你可以从界面或产品彼此之间的集成方式中看出[技术债]。”界面零散、功能之间集成不佳，都是累积的技术债在用户侧的表现。留意不一致之处，找出债务累积的位置。
量化偿还债务的价值
Casey Winters：“影响最大的项目最难衡量，因此长期得不到足够的资金支持。建立自定义指标来展示其价值，进行小规模测试，证明这项投入值得。”建立自定义指标并开展实验，以展示业务价值。与工程和设计团队协调一致，形成统一立场。
立即修复 Bug，不要将其积压
Geoff Charles：“我们没有 Bug 积压。一旦发现 Bug，我们几乎都会立刻修复。”将 Bug 直接分配给值班工程师，确保他们能立即感受到问题带来的影响。Bug 积压清单最终只会变成无人问津的坟场。
债务扼杀创新
Eeke de Milliano：“有时团队会被紧急工作拖住——技术债太多、Bug 太多、系统不稳定。如果他们整天都埋头处理故障，就不可能专注于更宏大、更有创意的工作。”判断团队是否陷入“需求层次”困境。优先减少债务，为创造性工作腾出思考空间。
技术债是甜蜜的烦恼
Julia Schottenstein：“如果有技术债，我们真是太幸运了，因为这说明有人在使用产品。我们在发布时并不需要分布式调度器——那时我们还没有用户。”先构建最简单、最朴素的版本。接受技术债，将其视为让产品尽快交到用户手中的权衡。
为漫长的隧道做好规划
Melanie Perkins：“我们以为需要 6 个月……结果两年都没有发布任何产品。”大规模重写就像“黑暗隧道”，会拖慢产品发布。如果不得不重写，就把工作游戏化，在漫长的苦熬中保持团队动力。
为 1–2 年后的需求做设计
Austin Hay：“想想一两年后我们会需要什么。设置工具时，问问自己：‘如果一年后我什么都不改，会发生什么？’”尽早实现 SSO 或规范的数据架构等基础要素，避免之后进行灾难性的迁移。
帮助用户思考的问题
- “这项技术债务是否阻碍了关键业务需求，还是属于较缓慢显现的问题？”
- “有多少比例的工程时间花在维护上，而不是开发新功能？”
- “你是否试着估算过重写实际需要多长时间？是谁做的估算？”
- “如果再过 6 个月什么都不做，会发生什么？”
- “有没有办法逐步改进，而不是重写？”
- “你会如何向利益相关者量化这项债务的成本？”
需要指出的常见错误
- 计划全面重写 - 重写几乎从来不会按计划进行。实际耗时会达到预估的 2–3 倍，而且你必须同时维护两套系统
- 把技术债务当成工程团队的问题 - 这是产品债务。产品经理应与工程师共同负责
- 任由 Bug 积压 - Bug 积压最终会变成无人问津的坟场。要么立即修复，要么决定彻底不修
- 在产品市场契合之前过度设计 - 债务是幸福的烦恼。先构建简单的解决方案，并接受债务是学习的代价
- 没有量化成本 - 由于价值没有得到衡量，技术债务相关投入往往资金不足。建立指标并开展实验，以证明投资回报率
深入了解
18 位嘉宾分享的全部 20 条见解，请参阅 references/guest-insights.md
相关技能
- 技术路线图
- 平台与基础设施
- 工程文化
- 权衡评估