技术债要不要被写进 OKR？我见过三种做法，各有翻车现场

先抛个我最近反复纠结的问题：技术债到底该不该被写进 OKR / KPI？

【背景】 我做了 8 年技术产品，带过 3 个团队。每次做季度规划，研发负责人都会说"这季度得留 20% 时间还技术债"，然后到季度末盘点，这 20% 几乎一定会被业务需求挤掉——因为业务需求有明确验收标准，技术债没有。最后的结果是：债越滚越大，下季度还是那句话，形成死循环。

为了打破这个循环，我见过三种典型做法：

【做法 A：不写进 OKR，靠"自驱 + 技术周"】 每两周留一个技术日专门还债。听起来很美，实际问题是：业务压力一大，技术日第一个被砍；而且"还债"这个动作本身没有验收标准，做完做没做完全凭良心。 翻车现场：某团队连续 4 个季度承诺"技术日"，代码里那个 4000 行的上帝函数到现在还在。

【做法 B：写进 OKR，但只写"结果型"指标】 比如"核心接口 P99 从 200ms 降到 100ms""单测覆盖率从 40% 提到 70%""故障率下降 50%"。 好处：可量化、可验收、老板看得懂。 坏处：容易变味——团队会"挑好做的指标做"，覆盖率刷到 70% 但全是断言 assert True 的那种；或者为了 P99 数字好看，把超时阈值悄悄调大。指标成了 KPI 之后，指标本身就开始扭曲行为。

【做法 C：不写进 OKR，但写进"项目前置条件"】 每个业务需求立项时，强制要求评估"这个需求会新增多少技术债、依赖哪些欠债模块"，如果新债超过阈值，必须先还旧债才能开工。 好处：把还债嵌进了业务节奏，不用额外抢时间。 坏处：评估成本高，容易变成流程负担；而且"债"的量化本身就是主观判断，谁来判？研发自己判自己，还是产品判？

【我的倾向】 我目前偏向做法 C 的变体：不直接写进 OKR（避免指标扭曲），但每个季度做一次的"技术债盘点"要写进 OKR 的"过程项"里——不是还了多少债，而是"识别了多少债、优先级怎么排的、哪些被业务挤掉了"。让债可见、让取舍透明，比追求一个漂亮的还债数字更重要。

但我一直没想通一个矛盾：产品视角的"债"和研发视角的"债"经常不是一回事。产品觉得"这个功能改 3 次说明设计有问题"是债，研发觉得"这 3 次改动都是合理迭代"不是债。这个分歧谁来裁决？

【想听大家聊聊】

1. 你所在团队，技术债是怎么被"管理"起来的？写进 OKR 还是别的机制？
2. 有没有遇到过"指标化之后指标本身开始骗人"的具体例子？
3. 产品和研发对"什么算债"分歧很大时，你们怎么对齐？是产品说了算、研发说了算，还是有个第三方（架构师 / 技术委员会）拍板？
4. 如果让你给一个 10 人小团队设计技术债管理机制，你会先做哪一件事？

欢迎带上具体场景和数字来聊，抽象的"应该重视技术债"就不必了。