需求优先级落地方案：产品经理开展需求排期的最佳实践案例解析

去年 11 月，我陪一家做工业设备后市场服务的 SaaS 团队复盘一次双周迭代。需求池里躺着 137 条待办，产品、销售、交付三方在会议室里争了两个小时，最后用「谁的声音大、谁的单子近」的方式定下 9 条。两周后上线，其中 3 条在灰度期调用次数为零，2 条被客户当场要求回滚，而真正卡住续约的那个对账差异核销需求，因为「看起来不复杂」，被排到了下个季度。团队的产品负责人很沮丧地问我：我们明明用了 RICE 评分表，为什么排出来的优先级一到执行就走样？

这个问题我遇到过太多次了。大部分团队在需求优先级上真正遇到的困难，其实不在「不会排序」这一层。他们真正的困难是：排出来的顺序对资源和承诺没有任何约束力。表格里排第一的需求，可以被一句「客户明天要」挤到第三；排第三的需求，没人说得清它为什么不是第一。没有约束力的排序，本质上只是一次集体情绪表达，不是排期方案。这篇文章我想把这件事拆开讲：需求优先级为什么落不了地、判断逻辑该怎么搭、一个 130 人规模的研发组织具体是怎么改的、以及在资源不够、关系要维护、时间还不能拖的情况下，到底该牺牲什么。

一、核心结论：排期的本质是一份带约束的资源契约

先把结论摆在前面，后面所有内容都是对这三句话的展开。

第一，需求优先级的产出不是一个顺序，而是一份契约。契约的含义是：我承诺在这个时间盒里交付这几件事，代价是明确放弃另外那些事；任何一方想改变这个承诺，必须付出对等的代价（移出同等成本的需求，或者追加同等成本的资源）。没有「代价」这个环节，优先级就只是建议。

第二，能落地的排期方案必须同时满足四个条件，缺一个就会塌。我用一张清单来检查客户的方案，四项里通常会有两到三项不达标，这也是排期反复返工的根因。

• 价值刻度统一：所有需求能被换算到同一种语言（钱、时间或风险），否则比较就是关公战秦琼。
• 成本可估算：不只有开发人天，还包括协作成本和机会成本，否则「小需求」会吃掉大需求的产能。
• 约束显式化：依赖关系、关键路径、合规截止日、外部承诺，必须写在排期表上，而不是留在某个人脑子里。
• 变更留痕：每一次插单都有记录、有原因、有出单，否则团队永远学不到自己的真实产能。

第三，排期真正的交付物是「不做清单」。我见过的优秀排期文档，最醒目的部分往往不是这个迭代做什么，而是一页明确写着「本期不做，原因是 X，预计在 Y 条件下重新评估」的清单。这份清单是产品经理对组织最有价值的输出之一，因为它把隐性的期望管理变成了显性的文字。

1. 为什么大部分团队的优先级一到执行就失效

把失效案例归因，会发现三种高度重复的模式，它们和团队规模、行业关系不大，和流程设计的粗糙程度关系很大。

（1）价值刻度不统一，比较从一开始就不成立

销售提的需求价值单位是「这个客户今年能签多少」，运营提的需求价值单位是「能省多少人工」，技术提的需求价值单位是「能少多少告警」。这三种单位在评审会上被塞进同一张表，用同一套 1 到 5 分打分，结果是谁的原始数字大，谁的折算分就高。我在一个项目里做过回溯，同样的 20 条需求，换三个人独立打分，前五名的重合度只有 2 条。

（2）排期没有约束，等于没有排期

如果排期表上只写「本期做 A、B、C」，不写「本期不做 D、E、F」，也不写「做 A 需要先完成基础设施改造」，那么这张表在第一次插单时就会失效。约束不是限制效率，约束是让所有人能算出「加一件事要付出什么」的唯一办法。

（3）变更没有价格，插单就会变成常态

插单本身不是问题，问题是插单免费。免费的东西一定被过度使用。我在三家不同规模的公司统计过同一个指标：一个迭代周期内未经等价置换的插单次数。低于 1 次的团队，交付准时率普遍在 85% 以上；超过 3 次的团队，准时率基本掉到 60% 以下，而且团队会出现明显的「排期免疫」，反正会变，先随便写。

2. 需求在价值，成本平面上从来不是均匀分布的

很多人默认需求池里的需求是「差不多重要、差不多难」的，所以纠结于排序。实际的分布要极端得多。下图是我在四个项目里汇总整理的需求分布（示意数据，按统一口径归一化后取中位数），横轴是交付成本，纵轴是延迟成本，气泡大小是涉及的业务方数量。

这张图我每次给团队看，都会引发同一个反应：原来我们花在「填充区」的时间这么多。是的，那 41% 的低价值低成本需求，单看每一条都不值得拒绝，合起来却吃掉将近一半的迭代产能。排期失控往往不是被大需求压垮的，是被一堆「顺手做一下」的小需求磨没的。

二、真实场景：一条需求从提出到上线的四次失真

要设计方案，先得看清需求在哪几个环节被扭曲。我把一条需求的生命周期拆成四段，每一段都有典型的失真机制。理解这四段之后，你会发现很多「优先级问题」其实发生在排期之前或之后，根本不在排序那一步。

1. 第一次失真：需求进入池子时已经被转述过一遍

原始诉求是客户说的「导出报表总是少两个字段」，经过客户成功经理转述变成「需要增强报表能力」，再经过产品经理归纳变成「报表模块重构」。三次转述之后，价值和成本都被放大了：价值从「五分钟能修好」变成「提升客户满意度」，成本从「改个 SQL」变成「两个月重构」。这类需求在池子里最难排，因为它的描述已经和真实问题脱钩了。

我的做法是强制保留原始语句。需求卡里必须有「客户/用户原话」这一栏，且不允许改写。这一栏在很多项目管理平台里是可以自定义的字段，实施成本极低，但对减少转述失真非常有效。

2. 第二次失真：评审会上价值被「会议政治」重新定价

评审会的真实结构往往是这样的：产品经理讲方案，业务方表达诉求，技术评估成本，最后由职级最高的人拍板。在这个结构里，声音大小、职位高低、和老板开会的频率，都会进入价值判断，而且是不留痕迹地进入。我统计过一场 90 分钟的评审会，真正用于讨论需求价值的时间不到 12 分钟，其余时间在澄清需求、争论实现方案、以及回忆上次类似需求为什么延期。

这带来一个反直觉的结论：评审会不该用来排序，排序应该在会前完成，会议只用来处理分歧和确认取舍。把排序放到会上做，等于把决策权交给了会议时长和嗓门。

3. 第三次失真：排期落到迭代时，产能假设是假的

排期表上写「本期 10 人 × 10 天 = 100 人天」，然后排进 96 人天的需求，看起来很饱满。实际上这 100 人天里要扣掉例会、答疑、线上问题、代码评审、环境等待、以及每个人不可避免的上下文切换。我在五个团队做过时间日志抽样，有效开发时间占名义工时的比例分布在 52% 到 71% 之间，中位数 61%。也就是说，一张排到 96% 的排期表，实际超出产能 35% 以上，延期是数学上的必然。

4. 第四次失真：上线后没有人回填结果

绝大多数团队的需求流程止于「已上线」。这条需求后来有没有被用、用了多少次、是否解决了原问题，没有人回填。于是下一轮排期时，团队手上没有任何历史校准数据，只能继续凭感觉。这是我认为最可惜的一处浪费：每一次交付其实都产生了一份免费的预测误差样本，只是没人收集。

下面这张折线图是我在某客户处连续跟踪 8 个迭代的数据（示意数据，样本为 3 个 12 人左右的特性团队），对比的是「迭代内累计插单数」和「需求交付准时率」的关系。

三、五个高频误区：把打分当成了决策

下面五个误区，是我在复盘中最常遇到的。它们的共同点是：看起来很专业，甚至用上了成熟的评分框架，但都没有解决「约束」和「代价」这两个核心问题。

1. 误区一：用加权评分代替判断

RICE、WSJF、Kano、价值/成本矩阵，这些框架本身没有问题，问题出在使用方式。很多团队把评分当成决策本身：算出 12.4 分和 11.8 分，然后宣布前者优先。但两个分数的差距远小于评分本身的误差范围，这种精度是虚假的。

我在一个项目里做过敏感性测试：把「影响范围」的权重从 0.3 调到 0.35，前五名的排序完全变了。也就是说，排序结论对权重设置的敏感度，远高于需求之间的真实差异。这种情况下，正确的做法不是把权重调得更准，而是承认评分只能用来分档，不能用来分先后。

所以我的建议是：评分只做粗粒度分层（如 P0/P1/P2），层内的先后由约束和成本决定，而不是继续比小数。

2. 误区二：把声音大小当成价值大小

有一个客户，某个年度最大的单子来自一家制造业集团，其 IT 负责人每周和我们的销售总开会，于是这家客户提的需求永远排在最前面。一年下来，这家客户贡献了收入的 23%，但消耗了 41% 的定制开发产能，而且其中 60% 的定制功能其他客户完全用不上。这是一个典型的「单客户价值被系统性高估」的结构性偏差。

修正的方法不是不听大客户，而是把价值计算口径从「单客户金额」改成「可复用价值 + 单客户金额 × 折扣系数」。折扣系数取多少取决于产品阶段：标准化程度高的产品可以取 0.3 到 0.5，项目制交付型业务可以取 0.8 以上。这个系数要提前谈定，写进规则，而不是每次临时判断。

3. 误区三：假设产能是满的、依赖是不存在的

这是工程上最容易犯、也最容易验证的错。名义产能和有效产能的差距通常在 30% 到 45%，这个差距不是靠「提高效率」能消除的，它是协作的固定成本。同样，依赖关系在排期表上不显式写出，就会在执行时以「等接口」「等数据」「等测试环境」的形式爆发。

我在一个中台团队看到过一个极端案例：一个迭代排了 14 条需求，其中 9 条依赖同一个数据组提供的埋点字段，而那个数据组当期的排期里根本没有这项任务。结果是 9 条需求里 7 条延期，团队连续两个迭代的准时率跌破 40%。这个问题在排期时花 10 分钟画一张依赖图就能发现。

4. 误区四：一次排全年，然后每季度推翻一次

年度规划有它的价值，对齐战略、申请预算、对外承诺。但把年度规划当成需求排期表使用，就必然失效。原因很简单：一年之后的技术条件、市场竞争、客户结构都会变化，年初的信息量不足以支撑年末的决策。

我的做法是把规划分成三层，每层的颗粒度不同：

1. 年度层：只写方向、主题和资源盘子，不写具体需求。
2. 季度层：写到需求组（epic）级别，明确目标指标和大概的范围边界。
3. 迭代层：写到最小可交付单元，明确验收标准、依赖和责任人。

关键的纪律是：越往下层，变更成本越低、变更频率越高；越往上层，变更越少但要更慎重。混乱的团队往往是反过来的，年度计划天天改，迭代计划反而不许动。

5. 误区五：只在工具里排序，不在会议里对齐

这一条听起来像是流程细节，实际上是决定成败的一环。工具里的排序是静态的、个人的；会议里的对齐是动态的、组织性的。只做前者，会有大量的人「不知道、不认同、不配合」，然后通过插单、拖延、消极执行来表达反对。

我的经验是：排序动作在工具里完成，取舍共识在会议里形成，两者缺一不可。会议不需要长，我已经把标准评审会从 90 分钟压到 35 分钟，靠的就是会前把所有评分和依赖关系放进系统、只在会上讨论分歧项。下面这张对比图是我在某客户处前后三个月的对比观察（示意数据）。

6. 侧面证据：缓冲是怎么被吃掉的

很多团队会留缓冲，但缓冲几乎总在迭代前半段就被消耗完。原因是缓冲没有归属、没有使用规则，谁都能用，于是谁都会用。下面这张瀑布图是我跟踪的一个 12 人团队，一个 10 天迭代里 100 人天名义产能的实际去向（示意数据，来自工时日志抽样）。

四、专业判断逻辑：三步把「感觉」变成可比较的数字

讲完误区，该讲方法了。我用的判断逻辑不复杂，核心是三步：统一价值语言、拆分成本结构、按延迟成本排序而不是按收益绝对值排序。三步之外再加两个纪律：约束前置、变更定价。

1. 第一步：把价值换算成同一种语言

价值语言只有三种，选一种作为主语言，其他两种做折算。选哪一种取决于业务形态，不取决于个人偏好。

一个实用技巧：不要追求换算精确，追求换算一致。同一个组织内所有需求都用同一套换算口径，即使系数不完美，排序结果也大概率正确，因为误差是同向的。反过来，如果每条需求都用不同的口径，即使每条都很精确，横向比较也没有意义。

2. 第二步：把成本拆成三层，而不是只算开发人天

成本被低估是排期失真的第二大来源。我要求所有需求至少拆成三层：

• 开发成本：编码、自测、联调的人天。这是大家都会算的一层。
• 协作成本：设计评审、跨团队接口对齐、测试环境准备、上线协调。经验值通常是开发成本的 25% 到 40%，跨团队需求更高。
• 机会成本：这件事占用的产能，本可以用来做哪件被推迟的事。这一层最容易被忽略，但它是取舍讨论的核心。

举一个具体的例子。两条需求 A 和 B，开发成本都是 6 人天。A 在单体应用内实现，协作成本 1.5 人天，总成本 7.5 人天；B 需要改三个服务的接口，协作成本 5 人天，总成本 11 人天。如果只按开发人天排，它们看起来一样重；按三层成本排，B 的实际负担比 A 高 47%。这个差距足以改变排期结论。

3. 第三步：按延迟成本（Cost of Delay）排序，而不是按收益绝对值

这是我认为最有价值的一个思维转换。收益绝对值告诉你「这件事值多少钱」，延迟成本告诉你「晚做一周损失多少钱」。后者才决定了顺序。

举个反例：一个功能全量上线后预计每年带来 300 万收入，但它不急，晚一个季度做损失很小；另一个功能只影响 20 个客户，每年 40 万收入，但这些客户的续约在两个月后，晚做一个月就可能集体流失。按收益绝对值，前者优先；按延迟成本，后者必须优先。

延迟成本除以交付时长，就是常说的 CD3（Cost of Delay Divided by Duration）。它把「价值密度」变成了可比较的数字。下面这张雷达图是我在某次真实评审中用的记录，四个候选需求在五个维度上的得分（10 分制，示意数据）。

4. 用累计延迟成本曲线检查排期是否合理

排完序之后，我还会做一步验证：按排定顺序画累计延迟成本曲线，看它是不是在早期就快速上升。如果曲线前段平缓、后段陡峭，说明高延迟成本的需求被排到了后面，排期有问题。

5. 约束前置：先排关键路径，再排价值

纯价值排序有一个致命盲点：它不认识依赖。A 需求价值最高，但它依赖 B 需求先完成，那么真正该先做的是 B。我的处理顺序是：

1. 先识别硬约束：合规截止日、合同承诺、外部依赖上线时间，这些直接锁定，不参与价值排序。
2. 再画依赖图，找出关键路径，把关键路径上的前置任务提前。
3. 剩下的产能，按 CD3 从高到低填充。
4. 最后检查：排进去的需求是否还在有效产能内（有效产能 = 名义产能 × 0.6 左右），超了就砍。

这个顺序不能颠倒。先按价值排满再考虑依赖，会导致大量返工和重排；先锁约束再填价值，虽然看起来「不最优」，但可执行性高得多。

6. 一个可以直接抄的评分脚本

上面的逻辑可以落成一个很小的脚本，二十几行，不依赖任何第三方库。我在好几个团队里直接给过这个文件，产品经理自己就能跑。

# cd3_rank.py ， 需求延迟成本排序的最小实现
运行方式：python3 cd3_rank.py

from dataclasses import dataclass

@dataclass

class Demand:

name: str

revenue_per_week: float    # 每周增量收入（元）

retention_risk: float      # 每周流失风险折算（元）

cost_saving: float         # 每周节省成本（元）

dev_days: float            # 开发人天

coop_ratio: float = 0.3    # 协作成本系数，跨团队需求建议 0.4~0.5

hard_deadline: str = ""    # 硬约束截止日，有值则不进 CD3 排序

def total_cost_days(d: Demand) -> float:

"""三层成本：开发 + 协作 + 预留的 10% 机会成本"""

return round(d.dev_days * (1 + d.coop_ratio) * 1.1, 2)

def delay_cost_per_week(d: Demand) -> float:

return d.revenue_per_week + d.retention_risk + d.cost_saving

def cd3(d: Demand) -> float:

"""CD3 = 每周延迟成本 / 总交付人天，越大越优先"""

cost = total_cost_days(d)

if cost raise ValueError(f"{d.name} 的交付成本必须大于 0")

return round(delay_cost_per_week(d) / cost, 2)

if __name__ == "__main__":

pool = [

Demand("对账差异核销", 42000, 18000, 3000, 6, 0.25),

Demand("批量导入模板优化", 6000, 1500, 800, 2, 0.2),

Demand("移动端审批流", 9000, 4000, 0, 11, 0.45),

Demand("等保合规日志改造", 0, 0, 0, 5, 0.3, hard_deadline="2026-03-31"),

]

第一步：硬约束优先锁定，不参与 CD3 比较

locked = [d for d in pool if d.hard_deadline]

for d in locked:

print(f"[锁定] {d.name}  截止 {d.hard_deadline}  成本 {total_cost_days(d)} 人天")

第二步：其余需求按 CD3 从高到低排

for d in sorted([d for d in pool if not d.hard_deadline],

key=cd3, reverse=True):

print(f"[排序] {d.name:7}  成本={total_cost_days(d):>5} 人天")

这段代码的重点不在算法，而在它把三个判断固化了：协作成本要显式加进去、硬约束不进价值排序、所有结果落到同一个数字口径上。跑一次之后，团队讨论的对象就从「我觉得」变成了「这个系数为什么取 0.45」，讨论质量完全不同。

五、案例观察：一个 130 人研发组织的排期改造

下面这个案例是文章里最具体的部分。对象是一家做企业协同办公的软件公司，研发组织约 130 人，分 6 个特性团队加 1 个平台团队，产品线单一但客户结构复杂，既有年费几十万的中小客户，也有年费千万级的集团客户。他们用的是 PingCode 做需求与迭代管理，这套工具主要服务中大型企业及 100 人以上组织，在这个规模上确实能撑住从需求池到迭代执行的全链路。

1. 改造前的基线：三个数字暴露了问题

改造前他们做了为期四周的基线统计，得出三个关键数字：需求池常驻条目 480 条左右，平均驻留时长 217 天；迭代内未做等价置换的插单率 31%；上线后 90 天内调用量低于 10 次的需求占比 26%。

这三个数字连起来看，问题就很清楚了：池子太深导致大量需求长期沉淀，插单太多导致计划频繁失效，无效交付太多导致产能被系统性浪费。注意这三个数字都不是「排序算法不够好」造成的，它们是流程结构问题。所以他们的改造重点也不是换评分模型，而是改结构。

2. 四个具体动作

（1）需求入口收敛：从 7 个入口收到 1 个

改造前，需求可以从销售群、客户成功工单、技术支持邮件、老板转发、运营口头、售前方案、客户拜访记录七个渠道进来，其中只有两个渠道有记录。改造后统一到一个入口，所有需求必须由指定角色录入，且必须填写「原始来源、原始原话、涉及客户、期望时间」四个字段，缺一不可。

这一步遇到的阻力最大，因为「随便说一句就能提需求」是很多人的隐性福利。他们的做法是保留一个快速通道，允许任何人提「一句话需求」，但这类需求默认进入待澄清区，不占排期名额。执行两个月后，需求池的月新增条目从 190 条降到 74 条，其中重复需求和无效需求占了减少量的六成以上。

（2）价值字段化：把口径写进系统，而不是留在 Excel 里

他们在 PingCode 的需求工作项上自定义了一组字段，把价值语言固定下来：影响客户数、预计年化收入影响、预计节省人天、合规风险等级、硬性截止日。每个字段有明确的填写规范和单位，不允许填「高/中/低」这种定性值。

这个动作的价值在于可追溯。以前评审会说「这个需求价值高」，现在必须说「影响 43 家客户，预计年化收入影响 128 万，涉及两个合同条款」。当价值必须被写成数字，会议上的虚张声势会自然减少。他们的产品负责人跟我说，最明显的变化是评审会时长从平均 95 分钟降到 38 分钟。

（3）迭代绑定容量：先扣减，再排期

这是效果最直接的一个动作。他们把每个团队的历史有效产能算出来（用过去 8 个迭代的实际完成人天中位数，而不是名义工时），然后规定迭代排期只能排到有效产能的 85%，剩下 15% 作为弹性产能，专门用于插单和线上问题。

规则的关键在于：弹性产能被用掉时必须登记，登记之后这个迭代的可承诺量就下降，需要向相关方公告。这一条让插单从「免费」变成「有价」，是两个季度内插单率从 31% 降到 11% 的主要原因。

（4）变更留痕与结果回填

每一次插单、砍单、延期都要在系统里留一条记录，包含原因分类（客户紧急/合同约束/技术阻塞/评估失误）。每个需求上线后第 30 天和第 90 天，由需求提出人回填一次使用数据。这一步最初被认为「增加负担」，实际执行下来每个需求平均多花 6 分钟，但产出的校准数据让后续估算误差从 ±60% 收敛到 ±25%。

3. 12 周后的数据观察

他们做了 12 周的前后对比，关键指标如下（企业内部实测数据，已做脱敏处理）：

下面这张漏斗图展示了这个组织一次季度初的需求筛选过程，能直观看到 137 条候选是怎么收敛到 9 条承诺的。

• 进入候选池: 137 条；说明=季度初各渠道汇总的候选需求，含重复与描述不清的条目
• 通过入口规范校验: 96 条；说明=剔除重复、缺少原始来源、无明确业务方等不合格条目，淘汰率 30%
• 通过价值字段完整: 71 条；说明=剔除无法量化价值、字段填写不全的条目，主要发生在中小客户诉求上
• 通过硬约束与依赖检查: 48 条；说明=识别出 9 条合规锁定项和 14 条依赖未就绪项，依赖项转入下季度条件评估
• 进入 CD3 排序: 39 条；说明=剩下的才是真正参与价值密度比较的需求，只有初始池的 28%
• 纳入本期承诺: 9 条；说明=按有效产能 85% 排入，其余进入「已完成评估但未排期」状态，保留完整上下文

说明: 这张图的关键信息是：真正需要靠「排序能力」解决的部分只占 28%，前面 72% 的需求是被入口规范、字段完整性和依赖检查过滤掉的，而这三种过滤往往比排序更能提升整体效率。

4. 必须说清楚的边界：哪些事没变

这个案例讲到这里容易被误读成「一套流程包治百病」，所以我要说清楚三件没变的事。

第一，老板依然可以直接指定需求。区别在于，指定之后必须从当期承诺里等价移出，并且公开记录。约束不是禁止特权，而是让特权显性化、有代价。

第二，大客户依然有优先权。区别是优先权的使用有了额度和规则，比如每个大客户每季度可动用两次加速通道，用完之后需要走正常的 CD3 排序。

第三，估算误差依然存在。他们改造后的估算误差是 ±25%，不是 ±5%。排期依然会不准，只是不准的幅度可预期、可缓冲，而不再是靠加班硬扛。

六、不同情况下的行动建议

方法论必须按组织阶段调整。同一套规则放在 8 人团队和 800 人组织里，效果可能完全相反。下面按规模和业务形态分四种情况给建议。

1. 10 人以下团队：只做一件事，写出不做清单

这个阶段上评分模型、上工具字段、上评审会，都是过度设计。团队小，信息传递靠面对面就够了，真正缺的是「明确放弃」的勇气和记录。

具体动作：

1. 每周固定 30 分钟，把所有待办列在白板或共享文档上。
2. 圈出本期要做的 3 到 5 件，剩下的明确标注「本期不做」并写一句原因。
3. 把这页拍照发到群里，作为本期唯一承诺。
4. 周五复盘时对比：承诺做了几件，插进来几件，插进来的挤掉了谁。

就这四步，不需要任何工具。我见过的最小团队是 4 个人，坚持了 11 周之后，交付准时率从 50% 左右稳定到 80% 以上，唯一的成本是每周 30 分钟。

2. 20 到 100 人单产品线：三段式排期最有效

这个规模开始出现跨团队协作，需要一定结构化，但还不至于要复杂的容量管理。我的建议是三段式：

• 季度层（每季度一次，半天）：定 3 个目标主题，每个主题下明确 2 到 4 个 epic，标注成功指标。
• 月度层（每月一次，1 小时）：把 epic 拆成需求，做一次 CD3 排序，锁定硬约束项。
• 迭代层（每两周一次，40 分钟）：按有效产能排入，明确依赖，登记弹性产能。

这个阶段最值得投入的是「有效产能口径」。只要把迭代排期从名义工时的 100% 降到 60% 到 70%，准时率通常能提升 20 个百分点以上，这是投入产出比最高的一个改动。

3. 100 人以上多团队：先修入口，再修容量池

到了这个规模，问题往往不在单个团队的排序能力，而在团队之间的需求入口和容量分配。这个阶段我建议的顺序是：先收口，再分池，最后才是排序。

（1）收口：把所有需求入口收敛到统一平台，禁止线下渠道直接进入排期。对中大型组织来说，这一步通常需要工具支撑，因为需求条目多、角色多、跨团队流转多。像 PingCode 这类面向中大型企业的平台，能提供从需求池、评审、排期到迭代执行的贯通链路，也支持自定义字段把价值口径固化下来，实际落地时省掉大量手工对表的工作。

（2）分池：把产能分成三块，承诺池（70%，本期必做）、弹性池（20%，插单与线上问题）、探索池（10%，验证性需求）。三块池子的规则不同，承诺池内的需求不允许被无代价移出。

（3）排序：在各池内部分别排序，跨池不比较。这一步能消除大量无效争论，因为「探索池的需求为什么排在承诺池前面」这类问题根本不会出现。

4. 按业务形态调整：To B 定制 vs To C 增长

业务形态对价值语言的选择影响很大，这一点常被忽略。

• To B 定制交付型：价值语言优先用「合同金额 + 续约风险」，排序时硬约束权重最高，因为违约成本是刚性的。这类业务要特别警惕单客户定制对产品标准化的侵蚀，建议设置定制需求占比上限（经验值 30% 到 40%）。
• To C 增长型：价值语言优先用「转化率变化 × 用户量 × LTV」，排序时更依赖实验数据而不是评审判断。这类业务的最优做法是提高实验频次，用更小的成本快速证伪，而不是在评审会上争论哪个假设更对。

七、不同情况下的取舍

写到这里，方法层面的内容基本讲完了。但实际做决策时，产品经理面对的不是「用哪个方法」，而是「牺牲哪一个」。下面四组取舍，是我被问得最多、也最难有标准答案的。

1. 价值最大化 vs 客户关系维护

严格按 CD3 排序，一定会得罪一部分声音大但价值密度低的客户。我的判断标准是看这件事的「可逆性」：如果拒绝之后还能补救（比如提供替代方案、承诺下季度、给临时脚本），就按价值排；如果拒绝会导致不可逆的后果（合同终止、行业口碑受损），就按关系排，但要把这笔账单独记账。

记账的意思是：因为关系而优先做的需求，单独标记，季度末统计它占用了多少产能、带来了多少实际回报。这个数字会让后续的关系判断变得更理性。关系不是不能照顾，而是不能无偿、无限、无记录地照顾。

2. 可预测性 vs 响应速度

这两者本质上是对立的。追求可预测，就要限制插单、锁定承诺；追求响应速度，就要保留弹性、接受计划变动。不可能同时最优。

我的默认选择是：在迭代层追求可预测，在需求入口处追求响应速度。意思是，迭代内的承诺尽量不动，但需求可以随时提，只是提进来之后要排队。这个组合能让客户感觉到「你在听」，同时让团队感觉到「计划稳定」。

3. 集中决策 vs 分散决策

集中决策的优点是全局最优，缺点是速度慢、信息损耗大；分散决策反过来。规模是主要判断依据：100 人以下可以集中，因为信息还能传得动；100 人以上必须分权，否则决策会成为瓶颈。

分权的关键不是把决策权一放了之，而是把「口径」集中、把「判断」分散。也就是说，价值语言、评分规则、容量分配比例由中央定义，具体某条需求排不排、排第几，由各团队自己定。这样既保证可比性，又保留灵活性。

4. 工具强约束 vs 轻流程

最后这组取舍很现实：工具能提供字段、留痕、报表，但也会带来填写负担和执行摩擦。我的经验分界线是团队规模：20 人以下用轻流程（文档 + 会议），50 人以上上工具强约束，中间地带按需求条目数量判断，如果每周新增需求超过 20 条，就值得上工具。

下面这张图用区间的方式展示了三种常见取舍策略下的交付周期波动（示意数据，来源于我对 6 个团队的观察区间）。波动幅度比平均值更重要，因为它决定了你能不能对外承诺。

5. 一个常被忽略的取舍：现在做 vs 现在做对

最后补充一组取舍，来自我自己的踩坑。有些需求的价值在于速度，先上线再迭代是对的；有些需求的价值在于一次做对，返工成本远高于前期多花的时间。判断依据是「返工成本占首次交付成本的比例」：低于 30% 的先做再说，高于 100% 的必须先想清楚。

我在一个权限体系改造上判断失误过。当时为了赶一个客户的交付节点，把角色模型简化实现，三个月后因为第二个客户的多组织架构需求，整个模型推倒重来，返工成本是首次交付的 2.3 倍。这件事之后我在排期表里加了一栏「返工风险」，由技术负责人填写，高风险需求不允许为了赶节点做简化实现。

结语：优先级能力的分水岭，在于你敢不敢写下「不做」

回到开头那个问题：为什么用了评分表，排期还是会走样？因为评分解决的是「怎么比」，而排期走样解决的是「谁敢定、定了算不算、变了有没有代价」。这三件事都不在评分表里。

我这些年最核心的一个判断是：需求优先级的水平差距，不在排序算法的精巧程度，而在组织是否愿意接受「明确的放弃」。愿意写不做清单、愿意给插单定价、愿意把有效产能而不是名义产能拿来排期，这三件事做到，用什么评分模型都能跑通；这三件事做不到，用再先进的框架也只是把争论从会议室搬到表格里。

另一个我想强调的独特视角是：排期质量的提升，大部分不来自排序环节。前面那个案例里，137 条候选需求只有 28% 真正进入了排序比较，剩下 72% 是被入口规范、字段完整性和依赖检查过滤掉的。这意味着投入在「收口」和「字段化」上的时间，回报远高于投入在「优化评分权重」上的时间。很多团队把精力放错了地方。

如果你现在就想动手，我建议按这个顺序走，两周内能看到变化：

1. 这周做一次需求池体检。把池子里所有需求过一遍，标出「三个月内没人提过」的条目，直接归档。多数团队能清掉 30% 到 40%。
2. 下周算出你们的有效产能。取过去 8 个迭代实际完成人天的中位数，除以名义工时，得到真实系数。下次排期就按这个系数的 85% 排。
3. 下一个迭代开始写不做清单。把本期不做的需求列出来，每条写一句原因和重新评估的条件，公开发布。这一个动作带来的沟通效率提升，通常比换一套评分工具更明显。

做完这三步，再去考虑要不要上评分模型、要不要换工具、要不要调整组织架构。顺序反了，前面所有的努力都会变成一次新的流程运动。