需求优先级管理指南：跨部门团队如何做好需求排期，制度设计全流程

需求排期最容易失控的时刻，往往不是需求太多，而是每个部门都能证明自己的需求“最急”。销售说客户等着签约，运营说活动日期不能改，研发说技术债已经影响稳定性，管理层又临时提出战略项目。会议开了两小时，最终排期仍靠谁声音大、谁级别高。我的判断是：优先级管理不是给需求打分，而是建立一套让价值、成本、容量和承诺彼此对得上的决策制度。

一、先讲核心结论：排期不是排序，而是资源承诺

1. 优先级不等于需求价值排名

把需求从高到低排成一列，看起来清楚，执行时却经常失真。一个价值很高的需求，可能还缺少关键规则；一个紧急需求，可能只影响少量客户；一个成本很低的改动，也可能让团队从当前主线频繁切换。优先级回答“应该先考虑什么”，排期回答“在什么时间、由谁、以什么范围交付”。

因此，制度至少要分开管理三个问题：需求是否值得做、需求是否已经准备好、团队是否有能力在目标时间内做完。三个问题的结论可能不同。例如，某项客户能力长期价值很高，但验收标准不明确，就应进入“待澄清”而不是直接进入本月迭代。

2. 先建立四道决策门

我建议把需求从提出到交付拆成四道门：入口门负责判断信息是否完整；价值门负责判断是否值得投入；准备门负责判断能否进入排期；容量门负责判断何时承诺。任何一门未通过，都不应靠会议上的口头承诺绕过。

1. 入口门：是否有明确的提出人、目标用户、问题描述和期望结果。
2. 价值门：是否说明业务影响、用户影响、风险或合规要求。
3. 准备门：产品、业务、技术和验收相关人员是否对范围达成基本共识。
4. 容量门：是否有可用人力、依赖条件和合理的交付窗口。

这四道门的意义不是增加审批，而是把“想做”与“能承诺”分开。尤其对跨部门团队，很多排期冲突本质上并非价值判断冲突，而是某个需求尚未准备好，却被提前当成确定交付项。

3. 决策权与建议权要分开

产品、销售、运营、研发和管理层都可以提供重要信息，但不代表每个角色都对同一类决策拥有最终决定权。业务负责人应说明结果价值和期限来源；产品负责人应整理问题与范围；技术负责人评估实现成本和风险；资源负责人确认容量；最终的组合取舍应由明确的产品或业务治理角色承担。

如果没人对取舍负责，团队就会用“先都放进去”逃避冲突。结果是承诺越来越多，实际交付越来越少。制度应写明：谁提出、谁评估、谁拍板、谁通知，以及发生争议时由谁升级处理。

二、背景和真实场景：跨部门需求为什么会在排期会上打架

1. 每个部门看到的“紧急”并不是同一种紧急

销售关注客户签约、续费和竞争压力；运营关注活动节点、转化漏斗和人工工作量；财务关注收入确认、成本或审计节点；研发关注系统稳定性、架构约束和维护负担。各方使用不同的时间尺度和结果指标，因此同一个需求很容易被描述成四种优先级。

例如，销售提出“本周必须支持某客户的批量导入”，背后可能是签约阻塞，也可能只是客户提出的偏好。运营提出“活动前要增加一个配置项”，可能是活动无法启动，也可能只是希望减少几次人工操作。排期制度要追问紧急背后的损失，而不是照搬提出人的紧急标签。

2. 需求数量不是工作量，排期风险常藏在依赖里

一条需求在看板上可能只占一行，实际却依赖数据清理、权限调整、接口联调、法务确认和客户培训。若团队只按需求条数规划，就会把复杂性隐形化。更可靠的做法是把需求拆到可以估算、可以验收的工作单元，并把外部依赖列为显式条件。

排期会议里，我尤其警惕“方案还没定，但先占个位置”这句话。它通常意味着团队把不确定性转化成了未来的延期。对于探索型需求，可以先安排短周期验证；对于范围明确的需求，才适合承诺完整交付窗口。

3. 跨部门排期需要治理，不只是一个共享看板

共享看板能让信息可见，却不能自动解决谁有权插队、容量如何切分、延期如何处理等问题。工具负责记录状态和决策依据，制度负责规定决策规则，两者缺一不可。中大型企业及 100 人以上组织往往有多个团队、多个业务线和共享平台团队，依赖关系多时，单团队排序更容易造成局部最优。

例如，一个业务团队把需求排为最高优先级，不代表数据平台、风控团队和基础架构团队也能同步腾出资源。排期需要在团队边界上建立依赖确认机制，而不是等到开发中途才发现关键接口没有人负责。

4. 需求治理要同时保护交付与探索

如果制度只偏向确定性，团队会把所有探索需求都挡在门外；如果只鼓励创新，稳定性、合规和客户承诺又会被挤压。可行的做法不是要求每项需求都用同一套收益算法，而是设置不同的工作类别和容量边界，让维护、风险控制、业务增长与探索都有明确入口。

三、常见误区：为什么打了分，排期仍然不可信

1. 把紧急程度直接当成优先级

“客户催得急”“领导要求尽快”“活动马上开始”描述的是压力，不一定描述价值。真正需要问的是：如果不在指定时间完成，会造成什么可验证的损失？损失影响多少用户、多少收入、多少工时，是否存在可行替代方案？

如果把每个需求都标成紧急，紧急标签就失去区分作用。制度可要求紧急申请填写截止日期、期限来源、逾期后果和替代路径。无法说明逾期后果的需求，应按常规流程评估，而不是自动插队。

2. 只看收益，不算成本和机会成本

“预计提升转化”听起来很有吸引力，但如果没有基线、目标人群和观察周期，收益数字只是愿望。即使收益成立，还要比较交付成本、维护成本、协同成本，以及它挤掉了什么。排期的真实问题不是“这件事有没有价值”，而是“现在做它是否比其他可选项更值得”。

我会把机会成本写进评审记录：若本项进入本期，哪些事项延后、取消或降级。没有替代项清单的插队决定，通常只是把冲突推给执行团队。

3. 用复杂公式制造客观感

公式很容易让讨论看上去科学，却无法补齐缺失的数据。给收益、紧急度、客户数和战略价值分别打分，再乘以权重，可能只是把主观判断包装成小数点。评分适合做候选需求的初筛，不适合取代管理层对重大取舍的解释责任。

评分项应少而可理解，分值要有锚点。例如，“影响范围 1 分”可以定义为单一内部角色，“3 分”定义为多个客户群体，“5 分”定义为核心业务链路或广泛用户群。没有锚点时，不同部门会把同一分数解释成不同事实。

4. 把估算值当成承诺工期

估算是规划输入，不是交付保证。探索性需求、外部依赖和高不确定技术改造，适合给出区间或先做验证，而不是把一个看似精确的日期写入计划。若将初步估算直接变成对客户或管理层的承诺，团队会倾向低报成本，后续再以延期解释偏差。

应分别记录工作量估算、依赖风险、置信程度和目标窗口。需求准备度越低，时间承诺越宽；关键假设验证后，再缩小区间。这个机制不会让计划变慢，反而能减少反复改期和过早承诺。

5. 把排序一次完成，之后不再调整

业务环境会变化，法规、客户承诺、事故和资源状态也会变化。优先级不应成为永久标签，而应在固定节奏上复核。复核不等于频繁推翻计划：只有新信息改变了收益、期限、风险或容量，才触发重排。

如果每周都大范围改计划，问题往往不是“市场变化太快”，而是入口控制不严、承诺过早或没有保护执行容量。稳定节奏与例外机制必须同时存在。

四、专业判断逻辑：从价值、时限、风险到容量

1. 先做分类，再在同类需求中比较

把所有需求放在同一个分数池里，会让不同性质的工作互相误伤。明确的安全修复不应和营销实验比预期收入；法定合规事项也不应被一个高收益但可延后的体验改进轻易压过。先分类，后比较，能把不可妥协的约束与可选择的机会区分开。

2. 用评分辅助判断，但保留硬性门槛

对于可比较的常规需求，可以采用五项评分：业务影响、受影响范围、时间敏感性、证据可信度和实现成本。每项采用 1 至 5 分，成本分数反向设置，成本越低分数越高。建议将评分结果用于候选排序，不直接映射成具体交付日期。

一个简化的参考模型是：候选分 = 业务影响 × 受影响范围系数 × 时间敏感性 × 证据可信度 ÷ 实现成本。模型的关键不是数学形式，而是让团队解释输入依据。若证据可信度很低，即使预期收益高，也应考虑先做验证，而非立即进入完整开发。

对法规截止、安全风险、重大故障等事项，应设置硬性门槛或单独通道，不与常规评分竞争。对战略项目，则要在组合层面讨论它占用的容量和放弃的机会，不能仅凭“战略”二字免于估算。

3. 明确时间敏感性，而不是只问“急不急”

时间敏感性关注延迟一天、一周或一个周期会不会显著改变价值。营销活动有明确开始日期，可能过期后价值迅速下降；基础能力建设的收益通常较长期；客户续约窗口可能在特定时点出现。判断时应记录价值衰减曲线或关键期限，而不只写一个“尽快”。

可以使用四档描述：无明确期限、存在建议窗口、存在业务截止日、存在外部强制期限。每一档都要附依据。这样排期会上讨论的是期限是否真实、能否调整，而非彼此争夺“紧急”标签。

4. 评估准备度与不确定性

高价值并不代表马上开工。准备度至少包括问题定义、目标用户、范围边界、验收方法、依赖方和关键假设。对于其中一项尚不清楚但潜在价值高的需求，可以安排澄清或验证任务，并限制投入时间，例如先用数天完成技术验证或用户访谈。

我更愿意接受“先花 3 天验证关键假设，再决定是否投入 4 周”，而不是“先承诺 4 周，边做边看”。前者把不确定性变成可控成本，后者则容易把探索、开发和返工混在一起，最后无法说明延期究竟来自需求变化还是估算偏差。

5. 做组合优化，不只看单项分数

团队容量有限，项目之间还可能共享同一专家、系统接口或数据资源。单项需求分数高，不代表它适合此刻进入组合。排期负责人需要检查依赖冲突、工作类别占比、关键人员负荷和交付批次，避免把高分需求全部塞进同一阶段。

对外承诺时，最好使用“承诺范围、目标窗口、前置条件”三件套。比如承诺第一阶段支持核心导入流程，目标窗口为某月下半段，前提是业务在某日期前提供字段规则。若前置条件未满足，时间窗口应重新评估，而不是默认团队承担全部延期责任。

五、制度设计全流程：从需求入口到复盘关闭

1. 统一需求入口与最小信息集

跨部门需求应进入统一入口，避免聊天记录、邮件和会议纪要成为互不相通的“隐形队列”。入口表单不宜长到让人放弃提交，但必须收集能支持判断的最低信息：提出人、需求对象、现有问题、目标结果、期限依据、影响范围、替代方案和相关证据。

不要求每位提出人都写完整方案。入口阶段重点是说清楚问题，而不是让业务部门替产品和研发设计实现方式。若需求描述只有“增加一个按钮”，就追问这个按钮解决什么问题、谁会使用、当前如何完成任务，以及如何判断改动有效。

2. 进行初筛和需求合并

需求管理员或产品负责人先检查重复项、信息缺口、明显不适配事项和跨团队依赖。多个部门可能用不同语言描述同一个底层问题，应合并成一个问题空间，再保留不同场景作为子用例。这样可以减少重复开发，也避免让提出顺序决定资源分配。

初筛应有时限，例如两个工作日内给出“进入评估、补充信息、合并讨论、暂缓或不纳入”的反馈。暂缓和不纳入都要写明原因与重新评估条件。没有反馈的需求会持续被提出人当作“已答应”，因此状态解释本身也是制度的一部分。

3. 评估价值、成本、依赖和风险

常规评估可由业务代表、产品、技术和交付负责人共同完成。业务方提供目标、影响范围和期限证据；产品方澄清用户问题、范围与成功指标；技术方评估复杂度、依赖、安全和维护影响；交付负责人核对容量、窗口和资源冲突。

评估会议不宜逐条念需求。会前先异步补齐材料，会上只处理分歧和取舍。每项讨论应落在四个问题上：价值依据是否充分、现在不做会损失什么、交付成本与风险是什么、是否有更小的验证或替代方案。

4. 设定准备度门槛和进入排期的条件

可将准备度划分为“待澄清、可评估、可排期、已承诺”四种状态。可排期的需求至少应有明确范围、验收条件、估算区间、负责人和依赖计划；已承诺则还需获得容量确认和必要的外部前提确认。

这一状态模型能减少“排了但没法做”的伪计划。建议不要把所有产品想法都塞进未来路线图的具体月份。远期需求可以保留方向和价值假设，随着信息增加再进入可承诺状态，避免路线图被误读成合同。

5. 组织固定节奏的组合排期

需求优先级评估和迭代排期可以分开。评估会判断候选项的相对价值、风险和准备度；排期会核实团队容量、依赖和交付顺序。对于节奏稳定的团队，可按双周或月度滚动规划；对变化较快的业务，也应保留固定复核周期，不建议每天随需求变化重排。

排期时先扣除已知的支持、维护、休假、会议和历史平均中断成本，再安排可承诺的计划工作。不要把所有工作时长都当作可用于新需求的容量。团队连续几个周期的实际完成量，比纸面人力乘工作日更适合作为规划基线。

6. 规定插队机制和例外审批

紧急通道要存在，但必须窄而透明。适用情形可以包括生产事故、明确的监管期限、重大安全风险，或经过核实的关键客户承诺。申请人需说明不处理的后果、最小解决范围、目标期限、受影响团队及被挤出的工作。

插队批准后，应同步更新原计划，并明确延期或取消哪项工作。例外审批人不能只批准新增项而不承担取舍。若同一团队连续多个周期频繁走紧急通道，应启动机制复盘，判断是容量不足、需求入口失控，还是上游计划缺乏信息。

7. 公开决策记录并形成反馈闭环

每次重要决策至少记录候选项、评分依据、容量假设、被延后的事项、决策人和复核时间。记录不是为了追责，而是让下一次讨论能基于过去的判断质量。若收益假设未实现、工期偏差明显或依赖反复失败，就应修正评估模型和计划方式。

对于中大型团队，可用 PingCode 这类面向研发与项目协作的管理工具承载需求池、评审状态、负责人、依赖和排期记录。工具配置前应先定字段和治理规则，否则只会把原先分散的混乱搬进系统。关键是让业务人员能看懂状态，让研发人员能追踪执行，让管理者能看到容量和取舍。

六、具体案例和数据观察：用一组模拟排期检验制度是否有效

1. 案例背景与候选需求

以下是一个跨部门团队的情景模拟，不代表某家企业的真实经营数据。团队由产品、研发、测试、数据和运营支持人员组成，规划周期为四周，按历史完成情况估算可用容量为 80 人日。扣除支持与维护的 16 人日后，需求交付容量为 64 人日。

本周期收到五项候选需求：客户批量导入、活动配置能力、权限审计补强、核心流程性能优化和自动化报表。它们分别来自销售、运营、合规、研发和财务，不同部门都认为自己的事项应优先进入计划。

2. 为什么没有按部门声音大小排序

权限审计补强虽然不一定带来直接收入，但有明确整改期限，属于不能任意延后的风险工作。客户批量导入的商业价值可能较高，但团队先核实客户是否处于真实签约窗口，并把首期范围限制在关键字段与必要校验，避免为少数个性化要求开发过宽方案。

性能优化的问题则是影响真实存在，但解决方案尚未完全确定。团队没有直接承诺 20 人日的完整优化，而是先安排测量与定位工作，确认瓶颈来源后再决定投入规模。自动化报表有明确的效率价值，但因现有人工流程仍可运行，优先级低于整改期限明确的事项。

3. 用容量而不是愿望形成排期

在 64 人日可交付容量中，团队先为权限整改安排 10 人日，为批量导入的最小版本安排 16 人日，为活动配置核心范围安排 10 人日，为性能测量与局部优化安排 12 人日，合计 48 人日。剩余 16 人日作为跨团队依赖、缺陷处理和估算误差缓冲，而不是立即塞入自动化报表。

这个安排的重点不在于数字看上去精确，而在于每一项占用都有边界。性能优化达到什么指标才算完成，客户导入首期不支持哪些字段，活动配置是否允许人工兜底，均需在承诺前写清楚。否则，排期只是名义上的资源分配。

4. 复盘指标要检查制度，而非只检查交付率

假设一个周期后，团队完成了 4 项中的 3 项，表面交付率为 75%。单看这个数字无法判断制度好坏：如果延期来自业务临时改范围，问题在变更控制；如果来自未识别依赖，问题在评估流程；如果完成项都按时但关键结果未改善，问题在价值假设和验收设计。

建议同时看计划稳定性、插队率、准备度通过率、估算偏差、需求结果和被挤出工作。指标应按周期观察趋势，不用单月数据直接给团队排名。更重要的是让指标触发改进动作，而不是鼓励团队通过缩小需求范围或隐藏延期来优化数字。

七、不同团队阶段的行动建议：先解决最影响交付的那个环节

1. 团队规模较小、流程刚起步

小团队不需要一开始就建立复杂委员会。先统一入口、补齐最小信息、设置每周一次的优先级复核，并要求每项新增需求写出“现在不做的后果”。负责人可以兼任需求管理员，但要避免只有提出人自己判断优先级。

先运行四至六周，再观察哪些字段没人使用、哪些冲突反复出现。制度初版应轻，但不能缺少责任人、状态定义和插队规则。过度设计流程会把团队时间花在审批，而不是解决用户问题。

2. 多部门共享研发资源、冲突频繁

这类团队应增加组合排期和跨部门容量核验。对共享数据、平台、安全等团队，建立依赖清单与服务窗口，明确需求从业务团队进入共享团队的条件。业务线不能只把自己的开发工作量算清楚，还要把依赖团队的工作量纳入总成本。

当一个共享专家同时支持多个项目时，应由资源负责人统一看负荷。不能让多个项目负责人各自假设“只占一点时间”，最后把关键人员排到超过可执行的状态。冲突无法由评分解决时，必须由有权调整项目组合的角色决策。

3. 需求变化快、探索性工作多

对不确定性高的工作，设定验证预算和退出条件。比如先投入不超过一周验证关键假设，达到某项用户行为或技术指标后再进入产品化排期。未达到门槛时，结束实验也应视为有价值的决策，因为团队减少了继续投入的风险。

这类团队不宜用过长周期锁死全部容量，可以采用较短的承诺窗口与滚动规划。但滚动规划不是随时换方向：已启动工作需要明确停止成本、未完成资产和对外影响，由负责人评估后再决定是否中断。

4. 合规要求高、客户承诺明确

先建立专门的必需工作通道，并要求保留法规条款、合同依据、审计记录或正式客户承诺。外部期限应提前识别，设置提醒和责任人，避免所有合规任务都以“紧急”方式进入开发。

如果业务要求无法被当前容量满足，应尽早升级决策：缩减范围、调整期限、增加资源，或接受并记录风险。不能用“团队尽量赶”代替风险决策，也不应把业务层的延期责任自动转嫁给执行团队。

5. 正在引入管理工具的组织

先把流程、角色和状态定义好，再配置某项目管理平台。建议先试点一个有代表性的团队，验证需求表单是否够用、跨团队依赖能否追踪、审批是否过重、管理视图能否呈现容量和被挤出的工作。跑通后再复制，而不是先做全公司统一的大型字段改造。

工具验收不应以“看板都建好了”为标准，而应看决策信息是否更完整、重复沟通是否减少、状态是否可信、排期变化是否可追溯。若工具让一线重复录入、管理层仍靠私聊要进度，说明配置和治理还没有形成闭环。

八、不同情况下的取舍：没有一套规则能让所有需求都赢

1. 价值高但证据弱：先买信息，不先买完整方案

当需求潜在收益很高，但用户问题、采用意愿或实现路径证据不足时，优先安排访谈、原型测试、数据分析或技术验证。验证投入要有上限，也要提前规定继续条件。若验证后仍无法证明价值，就应暂停，而不是因为已经投入了一些时间就继续追加预算。

这类取舍适合探索型功能、新市场尝试和重大流程改造。它牺牲短期交付数量，换取更低的错误投资概率。对于已经有明确合同义务或法规要求的事项，则不能用“先验证需求”拖延必要动作。

2. 期限明确但价值有限：判断是否缩小范围

如果活动、客户交付或内部节点确有截止时间，但完整方案成本过高，应讨论最小可行范围、人工兜底和分阶段交付。最小范围必须仍然满足核心结果，不能只是把未完成部分藏在“后续优化”里。

当人工方案成本可接受、风险可控且只需短期使用，暂不自动化可能更合理；若人工操作量大、错误代价高或会长期重复，则应把自动化带来的长期成本节约计入价值判断。不要把“自动化”默认等同于优先，也不要把临时人工方案默认视为低成本。

3. 需求收益高但挤占稳定性投入：设置底线容量

如果增长需求连续挤压可靠性、维护或安全工作，短期排期看上去很满，长期交付风险会越来越高。团队可以依据故障趋势、性能数据和维护负担，设定最低稳定性容量或风险触发线。一旦达到阈值，新增增长工作需说明如何承担风险。

底线不应机械固定。初创探索阶段与高交易量成熟系统的风险结构不同；发生重大事故后，稳定性投入可能需要临时提高。规则应允许基于证据调整比例，但不应允许所有业务方都无成本地申请例外。

4. 高层临时事项与已承诺项目冲突：显性接受机会成本

管理层可以改变战略优先级，但调整应明确带来的影响：哪项工作暂停、客户如何沟通、已投入资源如何处理、恢复项目需要什么条件。临时事项不应被包装成“额外加一点”，因为每一次上下文切换都会产生实际成本。

如果决策者不愿说明被挤出的工作，说明组织还没有完成真正的优先级决策。团队可以提供成本和风险建议，但最终取舍应由拥有资源组合权限的人承担，并留下可追溯记录。

5. 估算不确定且依赖复杂：拆分承诺边界

复杂需求可先承诺探索、接口验证或首个可交付切片，而不是一次性承诺全部范围。每个阶段结束时重新评估剩余成本、风险和收益。拆分不是把一个大承诺切成几段后仍默认全部完成，而是给组织保留根据新信息调整投资的权利。

如果项目必须整体交付，例如涉及强制切换或端到端合规要求，就应提前识别关键路径、资源瓶颈和回退方案。此时不要用拆分掩盖整体风险，应对依赖网络和缓冲时间做更严格的管理。

九、落地检查清单：让制度能执行，也能被修正

1. 启动前确认五个制度要素

制度上线前，我会先检查是否明确需求入口、评估角色、状态定义、容量核算和例外规则。缺少其中任意一项，都容易出现“需求有人提、无人维护”“分数有人打、无人负责”“计划有人写、没有资源”等断点。

• 入口表单是否能解释问题、目标、期限依据和影响范围。
• 需求提出、价值评估、技术评估和最终决策是否有明确责任人。
• 待澄清、可评估、可排期和已承诺是否有清晰区别。
• 规划容量是否扣除支持、维护、休假和历史中断成本。
• 插队审批是否要求同步说明被延后或取消的事项。

2. 每个周期复核六类信号

周期复盘不必追求复杂仪表盘，但至少应看到需求来源、准备度、计划变更、插队比例、交付结果和估算偏差。数据要能回到行动：如果准备度长期偏低，就改入口和澄清；如果插队高，就检查期限核验与容量；如果交付率高但价值结果差，就改需求定义和验收指标。

指标应按团队和需求类别拆分。把合规整改、探索实验和常规功能混在一起计算平均交付率，容易得出错误结论。用指标比较团队时尤其要谨慎，因为团队承担的依赖、风险和工作类型不同，数字不具备天然可比性。

3. 用复盘改规则，不用规则替代判断

制度需要稳定，也需要修正。建议每季度检查一次评分锚点、例外类型、容量比例和状态停留时间，询问哪些规则减少了冲突，哪些规则制造了新的等待。对于频繁发生的例外，应判断是规则设计不适配，还是组织在绕过规则。

最好的制度不是把所有需求都变成可计算的分数，而是让争议可以被描述、被比较、被决策，并且让后果可见。人的判断仍然重要，但判断应有依据、有责任、有复核节点。

十、结语：把“谁更急”改成“为什么现在做，以及放弃什么”

需求优先级管理最重要的变化，不是从口头争论改成打分表，而是让组织正面回答三个问题：这项工作解决什么问题，为什么现在做，做它要放弃什么。只要最后一个问题没有答案，排期就不是决策，只是愿望清单。

我的建议是从一个团队、一个规划周期开始：统一入口，区分价值判断与容量承诺，设置准备度门槛，记录插队的被挤出项，再用连续几期数据修正规则。先让一项决策可解释、一次承诺可追踪，再逐步扩展到跨团队组合治理。

好的排期制度不是让所有人都满意，而是让被选择的事项有明确依据，让未被选择的事项知道何时、在什么条件下重新进入讨论。下一步可以挑出最近一个周期的十项需求，逐项补齐期限依据、估算范围、依赖和被延后事项；通常这一步就能看出团队真正缺的是容量、信息，还是决策权。