标签频道
技术债
该标签下的文章、提问与讨论帖。
【背景】 做了 10 年性能优化，最常被 PM 和产品同学问的一句话是：「这个接口 P99 从 42ms 降到 41ms，用户能感知到吗？这 3 天的开发时间是不是浪费？」 我经历过两种极端： - 某电商大促前，一个商品列表接口 P99 是
背景 我做了 5 年技术产品经理，最近半年反复卡在同一个决策时刻：功能开发 95% 完成、业务方催上线、技术侧说「还差最后 5% 性能优化」（典型是 P99 从 800ms 压到 300ms、内存占用降一档、或某个长尾场景的抖动），但做完要
先抛个我最近反复纠结的问题：技术债到底该不该被写进 OKR / KPI？ 【背景】 我做了 8 年技术产品，带过 3 个团队。每次做季度规划，研发负责人都会说"这季度得留 20% 时间还技术债"，然后到季度末盘点，这 20% 几乎一定会被业
【背景】 我做 B 端 SaaS 产品 8 年，最近一个季度在排期评审上反复撞同一个墙：业务方（销售 + 客户成功）压一个"必须下周上线"的功能，研发评估说"直接加会引入 3 个服务的改动，P99 会变差，建议先花 2-3 周做一次小重构，
背景：我做了 3 年技术 PM，几乎每个季度规划都会卡在同一个问题——技术债要不要单独立专项迭代去还？这事在我们团队吵过至少 4 轮，每次结论都不完全一样，今天拿出来对线。 常见的三种做法： 1. 专项派：每个季度固定留 20%–30% 的
背景： 做了 8 年技术产品，我越来越觉得一个矛盾：技术债是研发最关心的事，但在产品路线图上几乎永远排不上号。每次 QBR 上研发说"这个季度至少 20% 的容量要还债"，业务方一句"客户等着呢"就拍回去了。 我复盘了 3 个 0→1 项目
背景： 做了 15 年技术产品，我几乎每个团队都绕不过「技术债」这个词。但每次排期会一开，分歧立刻出来：老板说「用户功能先上」，架构师说「再不上个季度就要重写」，一线开发说「每次都要先还债、KPI 永远完不成」。我统计过自己经手的 8 个团
先说背景，免得大家各说各话。 我做了 5 年技术 PM，带过两个 8 人以上的后端团队。每次迭代评审，最让我头疼的不是"这个需求要不要做"，而是下面这个反复出现的拉锯： 工程师说"现在不做，后面要还三倍的技术债"；我说"用户下个月就要用，先
«结论先行：feature flag 不是"代码里的布尔值"，它是"一条没被任何人正式退役的执行路径"。我们团队 18 个月里 feature flag 从 47 个涨到 312 个，其中 194 个（62.2%）实际上已经没有任何流量走旧
背景： 我做了 8 年技术产品经理，带过 3 个 0→1 的项目。每次排期会上，"先上 MVP 快速验证" 和 "干脆一次做扎实别返工" 这两派都会吵起来。有意思的是，同一个团队、同一个功能，最后选哪边，往往不取决于功能本身，而取决于当下面
背景 做了 5 年大数据平台，我见过太多团队在"要不要把半结构化数据塞进 JSON 字段"这件事上反复横跳。尤其是 MySQL 5.7+ 有了原生 JSON 类型、PostgreSQL 有 JSONB + GIN 索引之后，这个选项从"忍一
文
标题
摘要