需求排期如何做好需求优先级？项目成员数据分析与操作步骤

这是为您生成的一篇可直接发布的HTML文章，围绕需求排期与优先级展开，包含核心结论、误区拆解、四层判断模型和PingCode实操案例，配有10个图表规划，适合用作团队排期方法参考。

去年十一月，我陪一个 120 人规模的研发团队做季度复盘。产品负责人打开需求池，里面躺着 217 条待排期需求，研发负责人打开排期表，未来六周的容量已经排满。两边都觉得自己有理：产品说“这 217 条都是客户提的”，研发说“排进去的这 60 条根本做不完”。我把过去三个迭代的实际数据拉出来一对比，问题根本不在谁对谁错，排期表上写的容量是 6 周 × 5 人 × 5 天 = 150 人天，实际可用的人天只有 91 天，缺口 39%。

也就是说，这张排期表从诞生那一刻起就不可能成立，后面的所有优先级争论，本质上是在争一个不存在的预算。

这件事之后我把这套方法整理成了一套可复用的流程：先算清楚“有多少真实产能”，再用成员数据给需求定价，最后才谈排序。需求优先级从来不是一个打分题，它是一个资源分配题，你没搞清楚谁有多少时间，打多少分都是自娱自乐。

下面这篇内容，我把自己在十几个中大型团队里落地的做法拆开讲：核心结论、真实场景、五个高频误区、四层判断模型、一个 120 人团队用 PingCode 落地的完整操作步骤，以及不同团队规模下该怎么做、该怎么取舍。所有数据来自项目复盘和工具后台的导出记录，涉及具体客户的地方做了脱敏处理。

一、核心结论：优先级失控的根因在成员数据，不在评分模型

我见过的排期改进项目，80% 都从“换一个更好的优先级打分模型”开始，然后 80% 都在三个月内失败。原因很简单：模型只管“该做什么”，管不了“能不能做”。当排期表的容量本身就是假的，再精确的排序也只是把一个不可能完成的任务排得更整齐一点。

1. 结论一：排期的真实约束是“人 × 天”，不是“需求条数”

大部分团队的排期表长这样：需求 A、需求 B、需求 C，各自估一个故事点，然后按顺序塞进迭代。这张表里缺失了一个关键字段，谁来做、他这周还剩几天。同一个 8 点需求，交给一个刚接手模块的新人和交给一个做了三年的老手，占用的日历时间可能差 2.5 倍。

我的判断是：排期的最小单位应该是“人天”，而不是“需求”或“故事点”。需求是需求，产能是产能，两者必须用同一个单位对齐。这也是为什么我坚持在排期前先做一次成员产能画像，先把分母弄清楚，分子才有意义。

2. 结论二：优先级必须有有效期，过期自动失效

很多团队在年初定一次优先级，然后全年沿用。但市场会变、客户会变、技术债会积累。一条 P1 需求如果三个月没动，它大概率已经不是 P1 了，只是没人敢把它降下来。

我通常会给优先级设一个“保鲜期”：P0 级 2 周内必须有人动，否则自动降级；P1 级 4 周内必须进入迭代，否则重新评估。这个规则听上去有点粗暴，但它解决了一个非常真实的组织问题，优先级表一旦变成“许愿池”，它就失去了全部约束力。

3. 结论三：需求优先级和人员排期必须双向校准

单向的流程是这样的：产品排优先级 → 研发接单 → 做不完 → 加班或延期。这个循环跑三次，团队就会进入互相不信任的状态。

双向校准是另一条路：产品先给出价值排序的初稿，研发用成员产能数据算出“本迭代最多能承接多少价值”，然后双方在容量红线内重新切割范围。我把它叫做“先定量、再定性”，先把能做的量框死，再在框内讨论做哪一个，冲突强度会下降一个量级。

我在多个团队复盘中统计过这三条结论落地前后的返工情况，差异比想象中大：

4. 结论四：排期不是一次性动作，而是一个持续校准的机制

我把排期看成一条水位线：需求是进水，产能是出水口，水位每天在变。你不可能在迭代第一天把水位算准然后六周不管。真正有效的排期机制，是每周花 20 分钟重算一次水位，而不是每次花 3 小时吵一轮。

这也是我为什么反复强调“成员数据分析”。数据不是为了监控人，而是为了让水位可测。当你能看到每个人本周实际可用多少小时、手上的任务有多少在阻塞、切换了几次上下文，排期就从“凭感觉”变成了“看得见的东西”。

二、真实场景：排期会为什么总在周三下午爆发

如果排期只在规划会上出问题，那还好办。真实情况是，冲突几乎都发生在迭代中段，周三下午。周一刚开工，大家都在状态里；到周三，第一批阻塞出现了，销售又催了个大单，某个核心成员被拉去救火，排期表开始塌方。

1. 一个 120 人团队的真实一周

上面提到的那家团队，我跟踪了他们完整的一个双周迭代。他们在 PingCode 里已经跑了两年，数据沉淀得很完整，所以我可以把每个成员每天的时间去向还原出来。结果相当触目惊心：

• 研发成员名义工时：每人每天 8 小时，双周共 80 小时；
• 扣除会议、评审、答疑、线上问题处理后，实际编码工时中位数为 41 小时；
• 17 名研发中有 5 人在迭代期间被临时抽调到支持性工作，单人最高被占用 23 小时；
• 三个人承担了迭代内 58% 的高优先级任务，其中一人在第 7 天成为单点瓶颈。

把这些数字摆到白板上以后，研发负责人自己都愣了一下。他原本以为迭代排得“比较满但能扛”，实际数据显示名义产能利用率只有 51%，而三个人承担了接近六成的高优任务。这不是排期问题，这是负荷结构问题。

2. 三种典型的排期失控现场

现场一：明星成员黑洞。团队里有一两个“什么都懂”的人，需求自然往他们身上堆。排期表看起来分配均匀，实际这三个人身上挂了 40% 的关键路径。只要其中一个人请假，整个迭代停摆。

现场二：隐形依赖链。需求 A 等需求 B 的接口，需求 B 等设计稿，设计稿等客户确认。排期表上三条需求并列，看起来可以并行，实际上是一条串行链。一旦中间某一环晚了五天，后面全部顺延。

现场三：优先级通胀。每个季度都在出新的 P0。半年下来，需求池里有 30 条 P0，占全部需求的 14%。当 P0 占比超过 10%，这个标签就已经不传递任何信息了，它只是“我想让你先做”的礼貌说法。

这三种现场的共性在于：它们都不是排序错了，而是排序所依赖的数据结构错了。你排的是需求，可约束在人和依赖上。

3. 迭代中段的交付曲线，暴露了真实节奏

我把那次迭代的每日完成量拉成曲线，发现了一个非常典型的形态：前四天完成度不到 15%，第五天到第八天突然拉起来，最后两天几乎平掉。这条曲线说明，团队的真实产能集中在迭代中后段，而排期表假设的是均速交付。

三、拆解常见误区：五个我反复见到的坑

这一节我把过去几年在复盘中反复看到的五个误区列出来。它们的共同点是：每一个单独看都很有道理，一旦组合起来就会让排期系统彻底失效。

1. 误区一：只排需求，不排人

这是最普遍的一个。团队把需求估好点、排好序，往迭代里一放，以为排期就完成了。整个过程没有出现任何一个人的名字。

问题在于，需求不会自己完成，人才会。不落到人的排期，本质上是愿望清单。我在一个 70 人的团队里做过测算：把需求分配到具体人之后，同样的需求集合，可承诺范围缩减了 31%，但这 31% 的缩减换来了延期率从 44% 降到 13%。这是一笔非常划算的交易。

2. 误区二：用单一收入维度给需求打分

很多团队的优先级公式长这样：优先级 = 客户合同金额。这个公式在销售驱动型公司尤其常见，看起来非常理性，实际会带来三个后果。

• 小额但高频的需求永远排不上，而它们往往决定留存；
• 同一个大客户提的十件事全部变成 P0，等于没有排序；
• 内部必要的技术治理、稳定性投入被系统性低估，半年后集中爆雷。

我的判断是：价值维度至少要拆成三个，收入贡献、用户覆盖面、风险削减。只用一维打分的团队，一定会在半年内被技术债反噬。

3. 误区三：把“紧急”当成“重要”

紧急是时间属性，重要是价值属性，两者可以完全独立。但组织里的现实是，谁嗓门大、谁离老板近，谁的需求就紧急。

我见过一个很典型的案例：某团队连续三个迭代被“本周必须上线”的需求打断，每次都是因为某个大客户在验收前提出补充要求。三个迭代下来，原计划的版本功能只完成了 40%，而临时插入的需求里有 6 条在上线后两个月零调用。

处理这个误区的方法不是拒绝，而是给紧急需求标价。每插入一条紧急需求，就在排期会上明确说明它挤掉了哪一条原计划需求，让成本可见。这一招在三个团队里用过，紧急插入量平均下降 47%。

4. 误区四：优先级一次定死，全年不变

优先级是有保质期的。一条三个月没启动的 P1，要么是估值错了，要么是资源不够，两种情况都需要重新判断。我在复盘时经常问一个问题：这条需求如果今天重新提一次，还会是 P1 吗？答案经常是否定的。

建议给优先级加一个时间戳和失效规则：超过 30 天未进入开发的 P1，自动回到待评估池。这条规则会让需求池保持流动性，也能挡掉一部分“先占坑”的博弈行为。

5. 误区五：忽略任务切换成本

这条最隐蔽，也最容易被低估。一个人从需求 A 切到需求 B，不是零成本的。他需要重新加载上下文、回忆设计决策、找回环境状态。切换越频繁，这个损耗越大。

我在一个团队里做过粗略测量：让两名水平相近的工程师分别用“单任务串行”和“三任务并行”的方式完成同等复杂度的工作，并行的两人组总耗时高出 28%-41%，而且交付质量的返工次数明显更多。这个数据不严谨，但方向很明确。

四、专业判断逻辑：四层排期模型

讲完误区，该给方法了。我用的模型分四层，从需求到人，再到依赖，最后到不确定性。每一层解决一个特定的失效模式，缺一层，排期就会在对应的场景下崩掉。

1. 第一层：需求价值密度（分子）

价值不能用单一维度，我通常用三个子项加权：业务价值、覆盖范围、风险削减。每一项 1-5 分，权重按团队当前阶段调整。

权重不是拍脑袋定的，而是跟着团队阶段走。成长期团队优先拉新和交付，稳定期团队必须把风险削减的权重提上来，否则技术债会在两年内吃掉全部产能。

2. 第二层：成员产能画像（分母）

这是我最看重的一层，也是大部分团队缺失的一层。产能画像不是“这个人能力怎么样”，而是“这个人下个迭代实际能投入多少小时给主线任务”。

我通常看五个指标：

1. 可用工时：扣除假期、培训、固定会议后的净工时；
2. 在途负载：当前未关闭任务折算的人天；
3. 支持占用：历史三周平均被临时抽调的比例；
4. 上下文切换频次：同一周内并行任务数；
5. 模块熟悉度：在该模块的历史提交与缺陷修复次数，用来修正估点偏差。

前四项是数据，可以直接从工具里导出；第五项需要人工校准，但校准一次可以管用半年。把五个指标合成一个 0-100 的“真实可交付指数”，排期时按这个指数分配容量，比按人头平均分配准确得多。

3. 第三层：依赖与阻塞系数

依赖关系是排期里最容易被忽略的隐形杀手。两条需求在表上并列，实际是串行，一旦前序延误，后续全部推倒。

我的做法是给每条需求标两个字段：前置依赖数和外部等待时长。前置依赖数超过 2 的需求，必须拆成可以独立交付的更小单元；外部等待时长超过 3 天的需求，不进入当前迭代，先进等待区。

这一条在跨团队协作多的组织里尤其重要。我在一个有三条产品线的公司里看到过，仅“需求拆分 + 依赖显性化”这一项改动，就把跨团队需求平均交付周期从 34 天压到 21 天。

4. 第四层：不确定性折扣

估点永远是估的。同一个团队的历史估点准确率通常在 60%-80% 之间，意味着总有一部分需求会超出预估。排期如果不为这个折扣留缓冲，就等于把不确定性全部转嫁给延期。

我的经验值：迭代总容量只承诺 75%-80%，剩下 20%-25% 作为不确定性缓冲。需求越新、涉及模块越陌生，折扣越大。新人承担的需求，估点建议上浮 40% 以上。

四层模型合起来，可以用一个简单的评分逻辑表达：

# 需求优先级最终得分（示意逻辑，非生产代码）
def priority_score(req, member_profile, deps):

第一层：价值密度（0-100）

value = (req.business * 0.5 + req.coverage * 0.3 + req.risk * 0.2) * 20

第二层：按承接人的真实可交付指数折算成本

delivery_index = member_profile[req.assignee].deliverable_index  # 0-100

real_cost = req.estimate_days * (100 / max(delivery_index, 30))

第三层：依赖惩罚

dependency_penalty = 1 + 0.15 * max(0, deps.count - 2)

real_cost *= dependency_penalty

第四层：不确定性折扣，只影响可承诺容量，不影响排序

risk_buffer = 0.2 if req.module_familiarity > 60 else 0.35

价值密度 = 单位成本价值，而非绝对价值

density = value / real_cost

return {

"score": round(density, 2),

"real_cost": round(real_cost, 2),

"buffer": risk_buffer

}

注意最后一行返回的是“价值密度”，不是“价值”。这也是我最想强调的判断：优先级应该按单位成本的价值排序，而不是按绝对价值排序。一条价值 90 分但要花 30 人天的需求，优先级应该低于一条价值 60 分只要 5 人天的需求。很多排期争论的根源，就是大家在比绝对价值，而资源是有限的。

5. 阈值判断：什么时候该停下来重排

模型给完分以后，还需要一个触发重排的规则，否则排期会一直挂着直到崩。我用的触发条件有三条：

• 迭代内临时插入需求累计超过原计划容量的 15%；
• 任一核心成员的在途负载超过其可用工时的 110%；
• 阻塞超过 2 天的需求达到 3 条以上。

触发任意一条，就开一次 20 分钟的排期校准会，只做一件事：在现有容量内重新切割范围，而不是增加容量。这个约束很关键，一旦允许“加人加时间”，校准会就会退化成甩锅会。

五、具体案例与数据观察：一个 120 人团队怎么落地

前面讲的方法听起来完整，落地时一定会遇到组织惯性。这一节我把一个真实案例拆到操作步骤级别，包括他们踩过的坑。

1. 案例背景

这家公司做企业级 SaaS，研发团队 120 人，分 9 个小组，同时维护 3 条产品线。他们用的是 PingCode，需求、任务、迭代、工时数据都在里面，所以有条件做成员维度的数据分析。

他们最初的问题是：每个季度规划会开两天，产出 200 多条需求，排进迭代的只有 60 条，其余挂起。挂起的需求半年后被重新提起时，往往已经和市场脱节。研发侧则长期处于 70% 以上的迭代延期状态。他们服务的是中大型客户，单客户定制需求多，这个结构性问题比一般团队更严重。

2. 数据观察：三个被忽视的事实

我们用 PingCode 的数据导出做了三周的分析，其中有三个发现直接改变了他们的排期方式。

事实一：需求池里有 41% 是重复或高度相似的需求。不同客户提的同一个问题，被当成不同需求记录了。合并之后，实际待排需求从 217 条降到 128 条。这一步几乎没有成本，但直接砍掉了三分之一的排期压力。

事实二：工时记录和实际投入的偏差达到 37%。成员填报的工时普遍偏低，因为大家倾向于把答疑、会议、救火这类工作当作“不算工作”。这让所有基于工时的产能计算都系统性乐观。

事实三：需求从提出到进入迭代的平均停留时间是 47 天。而其中真正在“等待决策”的时间只有 6 天，剩下 41 天都在排队。这说明瓶颈不在评审速度，而在容量本身不足。

3. 操作步骤：从零搭建一套可跑的排期流程

下面这六步是他们实际跑通的顺序，我按执行先后排列。步骤之间没有严格依赖，但建议按这个顺序推进，因为前面几步的产出是后面几步的输入。

（1）第一步：清洗需求池，做合并去重

把所有待排需求导入一张表，按“用户问题描述”聚类，而不是按功能名称。功能名称往往不同，问题描述却能暴露出本质重复。这一步通常能砍掉 30%-40%。

（2）第二步：建立成员产能基线

在 PingCode 里按成员导出过去 8 周的工时记录、任务完成数和被抽调情况，计算每个人的真实可交付指数。同时用历史数据校准估点偏差，每个成员的估点系数单独算，不要用团队平均值。

一个实操细节：估点偏差要按模块分开统计。同一个工程师在熟悉模块上的估点可能只偏 10%，在陌生模块上会偏 80%。用统一的系数会掩盖这个差异。

（3）第三步：给需求打价值三维分

用前面提到的三张子表：业务价值、覆盖范围、风险削减。打分由产品和业务方共同完成，不允许只有一方打分。这一步的产出不是排序，而是让分歧显性化，当两个角色对同一条需求的分差超过 2 分时，必须当场讨论，而不是取平均。

（4）第四步：计算价值密度并做四象限分布

把价值分除以折算后的真实成本，得到密度分。然后按成本和价值两个维度画四象限，把需求分到“快速见效、战略投入、顺手清理、重新评估”四个区域。这一步的产出是一张可以直接贴在墙上的图。

（5）第五步：在容量红线内切割迭代范围

先用产能基线算出本迭代可承诺容量，再乘以 0.78（不确定性折扣），得到可承诺上限。然后按密度分从高到低装需求，装到上限为止，剩下的下一轮。

这里有个必须坚持的规则：装不进的需求不是“下个迭代做”，而是“回到待评估池重新打分”。“下个迭代”这个说法会造成虚假承诺，一年下来承诺了十二次，兑现了三次。

（6）第六步：每周做一次 20 分钟的容量校准

校准会只看三个数：已完成容量、剩余容量、新增插入。如果剩余容量低于剩余需求的 80%，就当场砍范围。会议不讨论“能不能加人”，只讨论“砍哪一条”。

这三条规则执行三个月后的效果，他们自己做了前后对比：

4. 落地时踩过的三个坑

坑一：一开始想把所有小组统一到一套评分标准。结果三条产品线的业务特征差异太大，标准被反复推翻。后来改成“价值维度统一、权重按产品线自定”，才跑通。

坑二：工时填报被当成考核依据。成员立刻开始“优化”自己的填报数据，产能基线失真。后来明确承诺工时数据只用于容量测算，不进入绩效，数据质量才回来。

坑三：把产能校准会开成了追责会。前两次会上，有人问“为什么这个迭代你没完成”，会议性质立刻变了。后来固定会议议程只有三页：剩余容量、剩余需求、砍哪条，其他一律不讨论。

六、行动建议：不同团队规模怎么做

方法本身不分规模，但落地方式必须分。20 人的团队照搬 120 人的流程，只会被流程压死；120 人的团队用 20 人的方式，则会彻底失控。

1. 20 人以下团队：只做两件事

这个规模不需要复杂的评分模型，人和事都在一个会议室里说得清楚。真正需要的是两个动作：

1. 每周固定 15 分钟，把下周每个人的实际可用天数写在白板上，先有分母；
2. 需求池每周清一次，超过 30 天没动的直接删掉或重提。

这两个动作覆盖了 80% 的问题。别去搞四象限、别去算价值密度，投入产出不划算。

2. 20-100 人团队：加一层数据，加一条红线

到这个规模，靠会议室已经说不清了，必须开始看数据。重点做两件事：

• 建立成员产能基线，至少包含可用工时、在途负载、支持占用三项；
• 设一条容量红线：迭代承诺不超过真实容量的 80%，任何人都不能突破。

这个阶段最容易出问题的地方是“支持性工作不入账”。线上问题、客户答疑、内部工具维护，这些工作如果不在排期表里体现，就会以隐形损耗的方式吃掉产能。把它们正式立项，反而是释放产能的第一步。

3. 100 人以上团队：必须做基础设施化

超过 100 人，依靠个人自觉已经不可能维持一致性。需要把排期做成系统能力：

1. 需求、任务、迭代、工时在同一个系统里闭环，避免多份数据打架；
2. 价值评分和产能基线固化到工具里，而不是散落在若干个 Excel 中；
3. 定期导出成员负载分布，识别单点瓶颈；
4. 建立跨团队依赖的显式登记，不允许口头约定。

这个规模的组织，我通常建议用 PingCode 这类面向中大型企业的平台来做承载。原因不是功能多，而是它能把需求、迭代、工时、成员负载放在同一条数据链上，排期需要的不是更多报表，而是一份可信的、能对齐分母的底稿。100 人以上的组织最怕的就是三份数据各说各话，规划会开成对账会。

4. 多产品线团队：先统一口径，再谈排序

多产品线组织的特殊困难在于，不同产品线的价值口径不一样。To B 定制线看合同金额，标准化产品线看用户覆盖，平台线看稳定性。用同一套权重打分，必然有一方觉得委屈。

我的建议是分层：价值维度统一，权重按产品线自定，但容量分配在更高一层做统一决策。也就是说，各产品线自己排自己的序，公司层面只决定“给每条产品线分配多少人天”。这样既保留了业务判断的灵活性，又避免了无序争夺。

七、取舍：不同情况下的选择

方法讲完，最后讲取舍。排期这件事没有全局最优解，只有针对当前阶段的局部最优。下面四组取舍，是我在不同团队里反复遇到、也反复需要重新判断的。

1. 取舍一：速度与稳定

要更快交付，就得减少评审、减少缓冲、增加并行；要更稳定交付，就得增加评审、留足缓冲、限制并行。这两个方向不可能同时拉满。

我的判断依据是当前预测准确率。如果团队历史估点准确率低于 60%，先做稳定，把缓冲和容量基线建起来；如果已经稳定在 80% 以上，可以适度压缩缓冲去换速度。在估点不准的时候追求速度，只会加速失控。

2. 取舍二：公平与效率

按人头平均分配需求最公平，但效率最低，因为它忽视了能力和熟悉度差异。按能力分配效率最高，但会让核心成员长期超载、新人长期得不到锻炼。

我通常用“核心任务 70% 交给熟悉的人，30% 交给需要成长的人”的结构。这 30% 的部分要额外上浮估点、安排结对，短期看是效率损失，长期看是解除单点瓶颈。一个 120 人团队里，如果只有 6 个人能做核心模块，这个组织的真实产能上限就是 6 个人。

3. 取舍三：透明度与博弈空间

排期数据越透明，博弈空间越小，但也越容易催生“数据表演”。反过来，数据不透明能保留灵活性，但会让资源分配变成政治。

我偏向透明，但有一个前提：工时和负载数据只用于容量测算，不进入个人绩效。这两件事一挂钩，数据就废了。前面那个 120 人团队的第三个坑，本质就是这个。

4. 取舍四：工具与习惯

工具能解决数据聚合和流程约束，解决不了“排期会上没人敢砍需求”这件事。我见过工具用得极其规范、但优先级依然是老板一句话决定的团队。

我的经验是：先改习惯，再上工具。先用一张表跑通“容量红线 + 每周校准”的机制，让团队尝到按期交付的甜头，再考虑把流程固化到系统里。反过来做，工具会成为新的形式主义容器。

5. 一个我坚持的底线

四组取舍说下来，有一条底线我从不妥协：排期表上写的容量，必须是团队真实能交付的容量。可以少排，可以砍范围，可以拉到下个迭代，但不能写一个自己都不信的日期。

原因很现实：排期表是组织对外的承诺接口。销售拿它答复客户，老板拿它做资源规划，市场拿它定发布节奏。一张虚假的排期表，会让所有这些下游决策一起错。相比之下，优先级排得不够漂亮，真的只是小问题。

八、总结：把排序问题还原成资源问题

回到开头那个 217 条需求的团队。他们最后做的不是买更先进的优先级模型，而是三件事：把需求池合并到 128 条、把真实产能从 150 人天修正到 91 人天、把每人的并行任务从 3.4 个压到 1.9 个。半年后，迭代按期交付率从 31% 涨到 79%。

这背后的判断很简单：需求优先级不是一个排序问题，而是一个资源分配问题。当分母是假的，分子怎么排都没意义。而分母来自成员，他们的可用时间、在途负载、被抽调比例、切换成本、模块熟悉度。这些东西不进入排期表，排期表就只是一张愿望清单。

如果这篇内容只能带走一句话，我希望是这句：先算清楚你有多少真实的人天，再用单位成本的价值去排序，最后在容量红线内硬性切割范围。顺序不能反。

1. 下一步可以立刻做的三件事

1. 算一次真实产能。把过去 8 周的工时数据导出来，扣除会议、支持、阻塞，算出真实编码工时占名义工时的比例。这个数字会给你一个相当直接的答案。
2. 清洗一次需求池。按用户问题描述聚类，合并重复需求。这一步通常能在两小时内砍掉三成排期压力。
3. 设一条容量红线。下一轮迭代只承诺真实容量的 78%，并把砍掉的需求明确写进“待重评估”而不是“下个迭代”。

这三件事加起来不到一周的工作量，但它能把排期从一场每周重复的争论，变成一个有数据支撑的例行判断。做完之后你会发现，很多过去吵不完的优先级问题，其实在容量算清楚的那一刻就不存在了。