需求排期如何做好需求优先级？项目成员入门指南与操作步骤

去年冬天，我帮一家 300 人规模的 SaaS 公司做季度复盘。他们的研发负责人给我看了一张排期表：Excel 里躺着 217 条需求，每一行都标着"高优先级"。我问他，如果下周只能做 5 条，你会砍哪 212 条？他沉默了很久，说："砍哪条都有人来找我。"

这个场景几乎是我过去几年做研发效能咨询时最常遇到的一幕。需求排期做不好，表面上像是"排序方法"的问题，实际上绝大多数时候是"决策权、产能账、退出机制"这三件事没有说清楚。团队不是不知道 RICE、KANO、MoSCoW 这些模型，而是知道了也没法用，因为没有人能承担"不做"的责任，也没有人算得清"做一个需求到底要花多少人天"。

这篇文章我想把这件事拆到底：先给结论，再讲我见过的真实场景和消耗结构，然后把常见误区逐条拆开，接着给出我自己在用的四维打分加产能建模的方法（含可以直接抄的表和代码），再拿一个 400 人企业的改造案例说明数据变化，最后按团队规模给出不同的行动建议和取舍建议。全文约 9000 字，适合从头读到尾，也适合按章节跳读。

一、先把结论说清楚：需求优先级是"约束下的放弃"，不是"排序"

我不想绕圈子，先把最核心的判断放在前面。如果你只记住一句话，我希望是这句：优先级不是把需求从高到低排列，而是在有限产能下，公开地、有依据地决定"哪些事这个季度不做"。排序是输出，放弃才是动作。

1. 排期问题里，只有三成是排序问题

我复盘过十几个排期失控的项目，把根因做了归类。真正因为"排序方法不对"导致的，大约只占三成；剩下七成分布在三个地方：产能账算不清（不知道一个迭代到底能装多少）、决策权不明确（谁都可以插单，没人可以否决）、退出机制缺失（需求进了池子就永远不会被删）。

排序方法是最容易学的部分，也是最不解决问题的部分。你把 RICE 算到小数点后两位，只要老板一句"这个客户很重要"，整张表立刻作废。所以做排期优化的正确顺序应该是：先定产能和决策规则，再定打分模型，最后才是排期表的呈现形式。顺序反了，做多少张表都是白做。

2. 优先级其实有三层，混在一起谈必然吵架

大部分排期会的混乱，来自把三个不同层级的问题放在同一张桌子上讨论。我把它们分开：

• 战略层（年度/半年度）：决定资源往哪条业务线倾斜，比如"今年 60% 研发投在 B 端、25% 投在稳定性、15% 投在新业务验证"。这一层不讨论具体需求，只讨论比例。
• 价值层（季度）：在既定比例内，判断某个需求值不值得做，用价值、成本、确定性、杠杆四个维度打分。
• 执行层（迭代/周）：在既定范围内决定先后顺序，主要看依赖关系、人员可用性、上线窗口（比如大促、财报、监管节点）。

这三层的决策人、决策周期、依据完全不同。战略层是 CEO 和业务负责人拍板，一季度一次；价值层是产品负责人主导，一月一次；执行层是研发负责人和项目经理，一周一次。当有人在周会上争论"这个需求对公司战略重不重要"时，你就知道层级混了，那是战略层该解决的问题，不该占用执行层的时间。

3. 有效的优先级，一定会产出一份"不做清单"

我判断一个团队的排期机制是否真的运转，不看他们的需求池有多整齐，只看一件事：他们能不能拿出一份明确写着"本季度不做，以及为什么不做"的清单。

这份清单的价值远超你的想象。它把"沉默的否决"变成了"公开的延期"，把"我忘了"变成了"我们决定了"。我服务过的一家企业，在引入季度不做清单之后，需求方在提需求阶段的自我过滤率从不到 10% 上升到了 40% 左右，因为大家知道，提了也会被认真评估并可能被明确延后，而不是靠嗓门大小抢资源。

二、真实场景：排期会为什么总会变成"谁嗓门大谁赢"

方法论讲完，我想先讲三个我亲历的场景。它们几乎能覆盖 80% 的排期失控情形，而且你会发现，问题从来不在"没人懂优先级"，而在"结构上就没人能做好优先级"。

1. 场景一：老板在群里转了一条客户消息

某次我驻场，周三上午十点，销售负责人在高管群里转了一条客户原话："这个功能不上，我们年底不续约。"老板回了两个字："优先。"三个小时后，原本排在迭代中段的两个需求被挤出去，两名工程师转向这个"紧急需求"。

问题不在于老板的决策错了，他掌握的信息可能比团队更全。问题在于：这次插单没有留下任何记录，没有人计算出它挤掉了多少人天，也没有人在两周后回来复盘这个客户到底续约了没有。于是下一次同样的剧情重演，而且频率越来越高，因为所有人都学会了：正常渠道排队没用，找老板最快。

我在这种团队里最常说的一句话是：插单不是问题，免费插单才是问题。任何插单都应该有代价记录，挤掉了什么、延后了什么、谁承担了这个后果。当代价被显性化，插单的次数会自然下降一半以上，不需要任何人去"管住老板"。

2. 场景二：三个部门都说自己的需求"下周必须上线"

这是最典型的场景。市场部说活动 15 号开始，运营说监管口径月底要改，客服说投诉已经压不住了。三条需求的"必须"都是真的，但团队的产能只够做一条半。

我做过一个统计：在我接触的中大型团队里，被标记为"最高优先级"的需求，通常占到需求池总量的 35%，55%。这个数字本身就说明优先级体系失效了，如果一半的需求都是最高优先级，那"最高"这个词就没有信息量了。

真正需要问的问题不是"哪个更急"，而是"如果三条都晚一周，各自的损失是多少"。市场部晚一周可能损失一次曝光，运营晚一周可能是合规风险，客服晚一周可能是 NPS 下滑。把"急"翻译成"损失金额或损失等级"，讨论才能从情绪回到事实。这一步我在每个团队都会做，而且几乎每次都能发现：三条"必须"里，只有一条的损失是可以被量化的，另外两条的紧迫感来自提出者的职位，而不是业务后果。

3. 场景三：需求池只进不出，两年攒了 400 条

有一家客户的需求池里有 431 条"待排期"需求，最老的一条创建于两年前。产品经理每周花半天时间维护这个池子，但从来不敢删，因为删了会有人来问"我的需求呢"。

这种池子的真实含义是：它不是待办清单，而是"大家的要求都被记录下来了"的心理安慰剂。431 条需求里，真正还有业务价值的不超过 80 条，剩下的是过期需求、重复需求、以及提出者自己都已经离职了的需求。

我建议的做法是引入"需求保鲜期"：任何需求超过 90 天未被评估，自动进入"待确认"状态，需要提出者重新确认一次价值假设才能回到池子。仅这一条规则，通常能把需求池缩减 40% 以上，而且缩减掉的部分几乎没有人来找。

4. 一个季度里，产能到底被谁吃掉了

大多数团队算产能的方式是：10 个工程师 × 每迭代 10 个工作日 = 100 人天。然后按 100 人天排需求。这个算法的问题在于，它把会议、答疑、线上问题、代码评审、休假、上下文切换全部当成了零。

我让团队做过连续 8 周的实际工时归集，结果相当一致：真正用于"计划内需求开发"的工时，通常只占名义工时的 55%，65%。剩下 35%，45% 消耗在插单、缺陷修复、技术支持、会议与协作开销上。当你按 100% 排期时，从第一天起就排了一个必然失败的承诺。

三、六个常见误区，逐条拆开

下面这六个误区，是我在不同团队反复见到的。它们有一个共同点：每一个单独看都像是"正确做法"，组合起来却会让优先级体系彻底空转。

1. 误区一：只按"重要性"排序，不看成本和确定性

"这个需求很重要"，这句话最大的问题是它只描述了一个维度。一个需求可以非常重要，同时成本是 200 人天、技术方案不确定、依赖三个外部团队。这种情况下，它的"重要性"排名第一，但"这个季度该做"的答案可能是"不该"。

我见过的最典型的翻车是：团队把年度最重要的战略需求排在了 Q1，结果因为技术方案要验证、外部接口要对接，实际到 Q3 才上线，而 Q1 本可以用来交付五个中等价值但确定性高的需求。价值高不等于该先做，价值除以成本和不确定性才是可比的量。

2. 误区二：把 RICE 当圣旨，算完分数就结束

RICE（Reach 触达、Impact 影响、Confidence 信心、Effort 投入）是个好模型，我也用它。但它的两个隐含假设经常被忽略：一是各项分值的口径必须全团队一致，二是 Confidence 必须真实反映不确定性。

实际情况是，不同产品经理打出的 Impact 分数完全没有可比性，A 认为"影响 3 分"是提升 10% 转化，B 认为"影响 3 分"是"感觉挺重要"。于是 RICE 分数变成了一种精致的伪精确：用精确的计算掩盖了不精确的输入。

我的改法是给每个分值写死锚点。比如 Impact 3 分必须对应"预计影响某个具体指标 5%，15%，且有数据或访谈支撑"，不满足就只能打 2 分。打分表的价值不在分数，而在逼迫提出者说清楚"影响什么指标、影响多少、凭什么这么判断"。

3. 误区三：把优先级当成一次性动作

很多团队在季度初花两天做一次排序，然后整个季度按表执行。但业务环境在变：竞品发了新功能、大客户改了采购节奏、监管出了新口径。三个月前的排序，到第二个月可能已经失真了三分之一。

我建议的节奏是"季度定盘子、月度调顺序、周度调执行"。季度定的是范围（做哪些大项），月度调的是顺序（先做哪个），周度调的是分工（谁来做、能不能并行）。范围不轻易动，顺序允许动，分工随时动，这条规则能同时满足稳定性和灵活性。

4. 误区四：没有"不做"和"延后"的正式出口

这是我认为最致命的一条。绝大多数需求池只有"待排期"和"已完成"两个状态，没有"已拒绝"和"已延后（含原因和复审时间）"。结果是所有需求都在"待排期"里无限堆积，看起来都还活着。

我在落地时一定会加三个状态：已拒绝（写明拒绝理由）、已延后（写明复审日期）、已合并（指向合并到的需求）。这三个状态不是行政动作，它们是优先级体系的排水阀。没有排水阀的系统，压力只会往上顶。

5. 误区五：用工具代替流程

我见过团队把工作项字段设计得极度完备：价值分、成本分、ROI、战略标签、客户标签、监管标记，一共 26 个字段。然后呢？填的人敷衍，看的人不看，最后所有决策还是在周会上靠讨论完成。

工具能固化流程，但不能替代流程。如果你的团队还没有就"谁来打分、谁来评审、谁有权否决"达成一致，那么再精细的字段设计也只是把混乱搬到了系统里。反过来，流程清晰之后，哪怕用最朴素的表格也能跑起来。

6. 误区六：把"紧急"当"重要"，紧急度污染全局

紧急和重要是两个独立维度，但在实际排期中经常被合并成一个"急不急"的判断。一旦合并，所有带时间压力的需求都会挤到前面，长期重要但不紧急的事情（架构重构、测试覆盖、文档补齐、性能优化）永远排不上。

我在做排期评审时会强制要求：每个季度的产能里，必须留出固定比例给"重要但不紧急"的事项，且这部分额度不可被紧急需求挪用。通常这个比例是 15%，20%。听起来像浪费，实际上它是唯一能阻止技术债滚雪球的结构性设计。

四、我实际在用的判断逻辑：四层过滤 + 四维打分 + 产能建模

讲完误区，该讲方法了。下面这套流程是我在多个团队落地后沉淀下来的版本，它不是理论最优，但在"能被真实执行"这个约束下，我认为是目前平衡得最好的。

1. 第一层：战略对齐，用"年度三件事"做硬门槛

在打分之前，先做一次粗筛。每年年初，业务负责人必须给出不超过三件的"年度必赢事项"，比如"把续费率从 82% 提到 88%""完成核心链路的技术架构升级""打开一个新产品线"。

任何需求进入价值评估之前，先问一句：它服务于这三件事中的哪一件？如果一件都不服务，它可以做，但只能占用"机动额度"（通常是总产能的 10%，15%），不能占用主额度。这一层的作用不是精确，而是快速排除，它能在十分钟内筛掉 30% 左右的"看起来很合理但和战略无关"的需求。

这里有个经验：如果筛完之后发现 80% 的需求都对齐战略，那说明"三件事"写得太宽泛了。好的战略表述一定是有排他性的，它应该让一部分需求明确地"不合格"。

2. 第二层：四维打分，比 RICE 多一个"杠杆"维度

通过粗筛的需求，进入四维打分。我在 RICE 的基础上做了调整，因为 RICE 的 Reach 在 B 端产品里很难量化，而"杠杆"（做一次能撬动多少后续工作）恰恰是 B 端最关键的判断维度。

注意我把成本权重压到了 15%。原因很简单：成本应该影响"怎么做"和"什么时候做"，而不是单独决定"做不做"。很多高价值需求成本天然很高，如果成本权重过大，团队会系统性地偏向小修小补，长期失去结构性竞争力。

另外，我强制要求每个维度的打分后面必须跟一句依据。没有依据的分数视为无效，直接按最低分计。这条规则能把打分从"拍脑袋"变成"写论证"，实施后通常会让高价值需求的数量下降 20% 左右，因为很多"高价值"在写依据的过程中自己就露馅了。

3. 第三层：产能建模，把人天换成"可交付周"

这是最容易被跳过、但收益最大的一步。大部分团队用"人天"排期，但人天有两个致命问题：它假设人可以无损切换任务，它忽略了并行度的上限。

我的做法是把人天折算成"可交付周"，并引入并行度约束。核心公式很简单：

可用产能（人天） = 团队人数 × 周期工作日 × 有效工时系数
有效工时系数 = 1 – (会议开销率 + 缺陷支持率 + 插单预留率 + 休假率)

以 10 人团队、双周迭代为例：

名义产能 = 10 × 10 = 100 人天

有效工时系数 = 1 – (0.14 + 0.15 + 0.10 + 0.05) = 0.56

真实可用产能 = 100 × 0.56 = 56 人天

并行度约束（关键）：

同一需求涉及 3 人以上协作时，实际耗时 ≈ 单人耗时 × 1.4

因此排期时需按 1.4 倍系数折算协作成本，而不是简单相加

这段计算看起来朴素，但它解决的正是"为什么每次迭代都延期"这个问题。当团队把排期基数从 100 人天改成 56 人天时，承诺量会立刻回归真实，延期率通常在两个迭代内就能下降 30 个百分点以上。

并行度那一条更容易被忽略。一个需要 5 个人协作的 30 人天需求，实际占用的日历时间不是 6 天，而是 8，9 天，因为接口对齐、联调、评审都在消耗并行效率。我在排期表里会单独标注"协作密度"，高密度需求每个迭代不超过两个。

4. 第四层：插单规则与缓冲带

前面说过，插单不是问题，免费插单才是。所以我的做法是把插单"定价"：在产能模型里预留 10% 的插单缓冲，并规定插单必须走三条规则。

1. 定价规则：任何插单必须明确说明它挤掉了哪个已排期需求，由提出者和被挤掉方的负责人共同确认。不需要上级审批，但必须留痕。
2. 额度规则：每个迭代的插单额度用完即止。额度用完后，新插单只能进入下个迭代，除非触发"重大事故"条款（如线上数据错误、合规风险）。
3. 复盘规则：每季度统计插单来源与占比。如果某部门连续两个季度插单超过 3 次，说明它的需求规划能力有问题，需要单独辅导，而不是继续挤压研发。

这套规则的核心不是"限制"，而是把隐性的资源争夺变成显性的成本转移。我实施过的团队里，插单占比通常从 20% 以上降到 8%，12%，而且几乎没有出现过业务方强烈反弹，因为规则是公开的，被挤掉的需求也有记录可查。

五、案例与数据观察：一家 400 人企业的排期改造实录

方法讲完了，必须上真实案例，否则就是空谈。下面这家企业是我 2024 年跟进时间最长的一个项目，改造过程有成功也有翻车，我都写出来。

1. 改造前的状态：三条业务线，一个需求池，零共识

这家公司约 400 人，研发 130 人，分三条产品线，服务的是中大型企业客户。改造前的典型症状是：

• 需求池 380 余条，其中标记"高优先级"的 167 条，占 44%。
• 双周迭代准时交付率 52%，且有明显的"月末冲刺"现象，每月最后一周加班率是平时的 2.3 倍。
• 每条产品线都有自己的排期表，格式不统一，跨线依赖靠口头同步，导致平均每月 2，3 次"联调时才发现对方没做"。
• 需求方满意度自评 2.8 分（5 分制），主要抱怨是"提了没反馈"和"不知道什么时候能做"。

他们的研发负责人跟我说了一句话，我印象很深："我们不是不会排优先级，我们是排完之后没人认。"这句话点出了问题的本质，优先级不是技术问题，是共识问题。

2. 我们做的四件事

整个改造分四步，前后用了大约 10 周。我没有推翻他们原有的工具，而是在原有基础上重建规则。

（1）把三条产品线的需求池合并，统一字段口径

第一步是统一。三条线原本用不同的字段定义"优先级"，合并后只保留五个核心字段：业务价值、确定性、杠杆效应、成本、战略对齐项。字段从平均 18 个砍到 5 个，填报时间从每条 12 分钟降到 4 分钟。这一步的意义在于：它让跨线比较第一次成为可能。

（2）建立季度"不做清单"和月度复审会

第二步是建立出口。我们规定每个季度末必须产出一份"本季度明确不做"的清单，每条写明原因（价值不足/成本过高/待验证/已合并），并同步给所有需求提出方。第一次发布这份清单时，有 9 个需求方来找，最后只有 2 个被成功"翻案"，剩下 7 个在解释完之后自己就撤回了。

（3）产能校准：从 130 人天到 72 人天

第三步是把产能账算清。原来每个双周迭代按 130 人 × 10 天 = 1300 人天排？不，他们实际是按每条线"感觉能做多少"排的。我们做了连续 6 周的工时归集，得出有效工时系数 0.58，然后把排期基数统一为名义产能的 58%，并预留 10% 插单缓冲。

这条改革阻力最大，因为产能基数一降，很多已承诺的需求要延期。但没有这一步，后面所有优化都是假的，你在一个虚高的产能基数上做任何精细排序，结果都必然延期。

（4）用统一平台承载流程，而不是用流程迁就工具

第四步是工具落地。他们最终选择了一个面向中大型组织的项目管理平台来统一承载需求池、迭代、工时和路线图，这里可以拿 PingCode 作为例子说明，它主要服务中大型企业及 100 人以上组织，比较契合这类多产品线、需要跨团队依赖管理的场景。

选它的关键原因不是功能多，而是三点匹配：一是需求池到迭代的流转可以配置状态机，正好承载我们设计的"已拒绝/已延后/已合并"三个出口状态；二是工时与迭代容量可以绑定，让 58% 有效系数这个数字能直接进入排期视图，而不是停留在 Excel 里；三是跨产品线的依赖关系可视化，解决了他们每月 2，3 次联调翻车的问题。

这里我要强调一个判断：工具的价值上限，取决于你流程的清晰度。同样一个平台，如果团队没定好谁打分、谁否决、插单怎么定价，用起来只会得到一个更精致的混乱。我见过太多企业把"上线系统"当成"解决问题"，结果半年后系统里堆着 500 条没人看的需求。

3. 12 周后的数据变化

改造从 3 月启动，6 月底我们做了一次完整复盘。数据不是全部向好，我照实写。

大部分指标改善明显，但需求平均流转天数反而从 47 天涨到 52 天。这一点我一开始没料到。复盘后找到原因：因为我们引入了"待确认"和"复审"环节，需求在流程里多停留了几天。这 5 天换来的是更低的返工率和更高的满意度，我认为是值得的，但它提醒我一件事：任何流程优化都会在某些指标上产生代价，关键是你要提前知道代价在哪。

4. 复盘：哪些做法有效，哪些踩了坑

我把这次改造的经验分成两类，供你直接对照。

效果最好的三件事：产能校准（一次性解决了延期归因的争论）、季度不做清单（把隐性冲突变成显性决策）、插单定价（插单量下降 60% 且无人反弹）。这三件事的共同点是：它们都不依赖"人变自觉"，而是改变了激励结构。

踩过的三个坑：一是起初想把打分做成自动化，结果模型太复杂没人用，后来退回人工打分加依据说明，反而更有效；二是一开始要求所有需求都必须写清"影响指标"，导致小额需求的填报成本过高，后来对小额需求（≤5 人天）改为简化流程；三是过早引入路线图对外的承诺，导致销售拿路线图去谈客户，反过来锁死了排期弹性，后来改成对外只承诺"季度主题"不承诺"具体功能"。

六、不同规模、不同情况的行动建议

方法不能照搬。下面按团队规模给出四套建议，你可以直接对自己团队的情况。

1. 10 人以下团队：不要上模型，先上节奏

小团队最大的浪费是"流程成本超过决策收益"。这个规模下我建议：不要搞四维打分、不要写详细评分依据、不要开月度复审会。你需要的是三件极简的事。

1. 每周一次 30 分钟排期会，只回答一个问题：本周做哪三件事，不做哪三件事。
2. 用一个共享列表维护需求，只有四列：需求、提出人、价值一句话、预估天数。没有"价值一句话"的需求直接不进列表。
3. 明确一个人拥有最终排序权（通常是创始人或产品负责人），其他人可以争论但不再投票。小团队最怕"平等协商"，它会消耗掉全部决策效率。

这个规模的判断标准很简单：如果一件事你说不清楚"做完之后哪个数字会变"，那它这一周就不该做。不需要打分模型，一句话说不清就是不够重要。

2. 20，100 人团队：重点是产能账和需求出口

这个规模是混乱的高发区，已经大到不能靠喊，又小到没有专职 PMO。我建议优先做两件事，其他都可以缓。

第一件：算清有效工时系数。连续两周让全员记录时间去向，按"计划内需求/缺陷/插单/会议/其他"五类归集。你会发现真实可用产能远低于预期，这个数字一旦摆到桌面上，排期争议会立刻减少一大半。

第二件：建立"已延后"和"已拒绝"两个状态。不需要复杂系统，哪怕是表格加一列状态也行。关键是要有书面记录和复审日期。这个规模下最大的隐性成本是"没人记得当初为什么不做"，导致同一个需求被反复讨论三四次。

打分可以用，但我建议简化到两维：价值和成本。四维打分在这个规模下容易变成形式主义，因为样本太少，杠杆效应很难判断。

3. 100，500 人团队：跨线依赖和统一口径是核心矛盾

这个规模的组织，问题会从"排不出顺序"变成"排了也对不齐"。三条产品线各自排期，跨线依赖靠口头，联调时才发现对方没做，这是我在这个规模段见到的最普遍问题。

我的建议是三步走。第一步统一字段口径，把所有产品线的需求池按同一套字段管理，至少保证"业务价值"和"成本"两个字段的定义一致；第二步建立跨线依赖看板，把所有跨团队依赖显性列出来，每周同步一次状态；第三步引入季度主题制，对外只承诺"这个季度我们在做稳定性"，不承诺具体功能清单。

这个规模段我通常建议引入专业平台承载，因为表格已经无法处理依赖关系和权限分层。前面提到的 PingCode 这类面向中大型组织的平台，在这个阶段的适配度较高，不是因为功能全，而是因为它能同时承载"需求池，迭代，工时，路线图"这条链，让排期依据和排期结果在同一个系统里可追溯。这一点在跨部门协作时尤其重要：当有人质疑"为什么我的需求排在后面"，你可以直接打开价值评分和产能视图，而不是靠回忆。

但我要提醒一句：不要在这个阶段追求"全量数字化"。我见过企业把 26 个字段全部上线，结果填的人痛苦、看的人不看。字段数量应该由"谁要用这个字段做决策"倒推，没人用的字段一律删掉。

4. 500 人以上多产品线：机制比工具重要，治理比机制重要

这个规模段的核心问题已经不是排期本身，而是"排期的治理"，谁有权改规则、规则冲突时怎么办、资源在业务线之间怎么调配。

我建议设立一个跨部门的"资源与优先级委员会"，成员包括各业务线负责人、研发负责人、财务代表，每月开一次会，只做三件事：审批跨线资源调配、裁决优先级冲突、复审插单异常。这个委员会不做具体排序，只做规则维护和冲突仲裁。

另一个关键动作是把优先级和预算挂钩。当某条业务线要求优先做它的需求时，问一句"你愿意用明年的预算换今年的产能吗"。一旦资源有了价格，优先级讨论就会从"谁更重要"变成"谁愿意付成本"，效率提升非常明显。

七、必须做的取舍：四组典型权衡

最后一部分我想讲取舍。因为排期的本质就是取舍，而大部分文章只讲"怎么做"，不讲"要付什么代价"。下面四组权衡，我认为是每个团队都绕不开的。

1. 交付速度 vs 技术债：不是二选一，而是分期付款

常见的错误框架是"要速度就得欠技术债"。这个框架的问题在于它假设技术债是免费的。实际上技术债是有利息的，而且利息通常以"缺陷修复工时"和"新需求开发成本上升"的形式在半年后集中爆发。

我的做法是把技术债当成"分期付款"来管理：允许为了交付窗口临时欠债，但必须在排期里明确写入"还款计划"，哪个月还、还多少、谁来还。没有还款计划的技术债，一律视为不允许。

具体到数字，我建议把每个季度产能的 15%，20% 固定用于技术债偿还，且这部分额度不可被任何紧急需求挪用。听起来很硬，但这是唯一能阻止债务滚雪球的方式。我服务过的一个团队执行这条规则两年，缺陷修复工时占比从 24% 降到 11%，相当于每年多出近三个月的有效产能。

2. 大客户定制 vs 通用能力：看客户集中度，不看客户大小

"这个大客户很重要，给他定制一下"，这句话在 B 端企业里几乎是日常。判断该不该做，我不用客户规模，而用两个数字：该客户收入占比，以及该定制在其他客户中的复用可能性。

我的经验阈值是这样的：如果单客户收入占比低于 5%，且定制需求的复用可能性低于 30%，原则上不做，改为提供配置或人工服务替代。如果占比高于 15%，可以做，但必须同时评估"续约概率提升"是否足以覆盖机会成本。

中间地带最难。占比 5%，15% 的客户，我的建议是做"最小可续约版本"，只做能保住续约的最小功能集，而不是客户提出的完整需求清单。实践中这个"最小版本"通常只占完整需求的 30%，40%，但能拿到 80% 以上的续约效果。

3. 确定性 vs 机会：给高风险需求一个"小额彩票额度"

排期最容易犯的错是"全都要确定"，所有需求必须有明确ROI、必须有数据支撑、必须方案验证过。这样做的结果是团队永远在优化已知的东西，错过结构性机会。

我的做法是留一个"探索额度"，通常是总产能的 10%。这笔额度专门用于高不确定性的尝试，规则是：单次投入不超过 15 人天，必须有明确的"停止条件"（比如两周内验证不出核心假设就终止）。

关键在于"停止条件"必须提前写死，而不是做到一半再讨论要不要继续。没有停止条件的探索，本质上是把机会成本变成了沉没成本。我见过太多项目做了三个月才发现方向不对，而如果一开始就定"两周验证核心假设"，第三周就能止损。

4. 透明度 vs 决策效率：对外只承诺主题，对内保持弹性

透明是好事，但过度透明会锁死排期弹性。最典型的翻车是：把详细路线图发给销售，销售拿去跟客户承诺"Q3 一定上线某功能"，结果 Q2 发现技术方案要变，整个排期被打乱。

我的建议是分层透明：对客户和销售，只承诺"季度主题"和"大致方向"；对内部团队，保持详细的迭代排期和调整空间。对外承诺的颗粒度越细，你失去的弹性就越多。

这条建议推行的阻力通常来自销售，因为客户喜欢确定的功能承诺。我的应对方式是提供"替代确定性"，不承诺功能上线时间，但承诺"每两周同步一次进展"和"优先响应你的反馈"。客户要的往往不是精确日期，而是"我被重视且信息透明"的感觉。实践中，这种替代方案能保住大部分客户关系，同时保留排期弹性。

八、把这套方法用起来：一份可以直接执行的三周计划

写到这里，方法论、案例、取舍都讲完了。最后我想给一个非常具体的落地路径，因为它比任何模型都重要，排期优化失败的最常见原因不是方法错，而是没人真的开始做。

1. 第一周：只做一件事，把产能账算清

不要一上来就改流程、上系统、做打分表。第一周只做产能归集：让全员连续五个工作日按五类记录时间去向（计划内需求、缺陷、插单、会议、其他）。

周末汇总出有效工时系数。我几乎可以保证，这个数字会低于你的预期。把这一个数字摆到排期会上，比你讲十页方法论都有用，因为它直接解释了"为什么我们总是延期"，而且它不指责任何人。

2. 第二周：清理需求池，建立三个出口状态

第二周做需求池清理。规则是：超过 90 天未评估的需求，全部转入"待确认"，由提出者重新确认价值假设，两周内不确认的自动关闭。

同时给需求池加上三个状态：已拒绝、已延后（含复审日期）、已合并。这一步不需要工具支持，表格加一列就能做。做完之后你会看到需求池缩减 30%，50%，而这部分缩减几乎不会引发任何反弹。

3. 第三周：跑一次真实的打分评审

第三周，从池子里挑出 15，20 条需求，用四维打分跑一次真实的评审会。重点不是分数，而是要求每条需求的每个维度都写出依据，没有依据的按最低分计。

这次评审的目标是产出两份清单：一份是本迭代要做的（通常 3，5 条），一份是本季度明确不做的（其余全部）。把不做清单公开发布，并说明原因。

三周之后，你会拥有三样东西：一个真实的产能基数、一个干净的需求池、一份公开的不做清单。这三样东西的价值，超过任何复杂的优先级模型。后面的四维打分、插单定价、季度主题制，都建立在它们之上。

4. 一个提醒：别指望一次改到位

我在开头提到的那位研发负责人，改造完成后跟我说了一句话："原来我们不是缺方法，是缺一个能让大家承认'做不完'的场合。"这句话我记了很久。

需求优先级这件事，最终解决的不是排序问题，而是让组织有勇气、有依据、有机制地说"这个我们不做"。任何模型都只是把这个过程变得可讨论、可追溯、可复盘的工具。如果你的团队还没有做好"公开承认做不完"的准备，那么再好的方法也只是让排期表变得更精致而已。

下一步，我建议你先做一件最小的事：在下一次排期会上，问一句"这个季度我们明确不做的是什么"。如果没有人能回答，那你的优先级体系还没开始运转，而这，恰好是最好的起点。