需求排期是把已确认的需求按优先级、依赖关系和可用产能分配到具体时间窗口，并明确负责人、交付节点和跟踪方式的过程。本文按“先定产出物、再备输入、然后执行排期、明确角色、跟踪偏差”的顺序展开，最后给出一个完整走查示例和一份可逐项核对的完成检查清单，帮助团队把排期从会议共识落到可查的工作项与状态字段上。
要点总览（TL;DR）
- 需求排期的核心交付物是一张可跟踪的排期表，至少包含需求标识、优先级、负责人、计划起止时间、依赖和状态六个字段，并写明填写人与更新时点。
- 排期前要备齐三类输入：通过准入检查的需求、有规则可依的优先级判定、扣除休假与支持性工作后的可用产能，缓冲额度写进排期表。
- 排期按拆解标注依赖、填充时间窗口、设置缓冲与交接点、评审确认四步执行，产能排满即停，超出部分留在待排区。
- 需求提出方、产品负责人、研发负责人与排期决策人分工明确，确认采用评审会加书面记录，跟踪由需求负责人按日看状态、按周看趋势。
- 偏差按约定规则判定并分级处理，重排需记录原因并保留原计划与新计划对照，用于校准下一周期的估算与缓冲比例。
需求排期要产出什么：一张可跟踪的排期表
需求排期的核心交付物是一张可跟踪的排期表。它回答三个问题：每个需求计划在什么时间做、由谁负责、当前进行到哪一步。排期表可以是一份独立文档，也可以是工作项上的字段集合；形式不重要，关键是每个字段都有明确含义、填写人和更新时点，任何人打开都能判断进度。
排期表与需求池、迭代计划的关系是：需求池负责“收”，排期表负责“排”，迭代计划负责“做”。需求从池中通过准入检查后进入排期表，被分配到具体时间窗口；采用迭代方式的团队，排期结果通常体现为需求被规划进某个迭代。三者共用同一套需求标识，避免同一需求在不同表里对不上号。
| 字段 | 含义 | 填写人 | 更新时点 |
|---|---|---|---|
| 需求标识 | 唯一编号与简短标题，关联需求池原始记录 | 产品负责人 | 入池时生成，排期时引用 |
| 优先级 | 按统一规则判定的等级，附判定理由 | 产品负责人 | 排期前确定，重大变化时复核 |
| 负责人 | 对该需求交付结果负责的人 | 研发负责人指派 | 排期确认时填写，变更时同步 |
| 计划开始/完成时间 | 承诺的时间窗口，含缓冲说明 | 研发负责人 | 排期确认时填写，重排时更新 |
| 依赖 | 前置需求、外部团队交付物或环境条件 | 需求负责人 | 拆解时标注，依赖变化时更新 |
| 状态 | 待排期、已排期、进行中、阻塞、已完成等 | 需求负责人 | 状态变化当日更新 |
这张表的价值在于可查。排期结论只留在会议纪要里，执行中一旦出现分歧就无从对照；字段落到工作项上，状态变化、时间调整都有记录，跟踪和复盘才有依据。ONES 的统一需求池与任务、工单体系可以作为承载这类字段和状态流转的平台，具体字段配置需结合团队实际在试用中确认。
排期前的输入准备：需求池、优先级与产能
排期动作开始前，需要三类输入达到合格标准：需求本身够清楚、优先级有规则可依、产能有可信口径。任何一类不达标，排出来的时间窗口都只是数字。
需求池的准入条件
进入排期的需求应具备三项内容：需求描述说明要解决什么问题、面向谁；价值说明交代预期收益或影响范围；验收口径写明怎样算做完。三项齐备才进入排期候选，缺项的需求退回补充，不占用排期会议时间。这条规则的作用是防止排期会上反复讨论“这个需求到底要什么”。
优先级规则的设定方式
优先级建议用少数几个维度组合判定，并写明判定理由，便于复核。常用维度包括：
- 价值：对用户或业务目标的影响程度，可按高、中、低分档并附一句理由。
- 紧急度：是否有明确的时间约束，如合同节点、合规期限、线上问题。
- 依赖顺序：某些需求是其他需求的前置条件，前置项优先。
规则要事先约定冲突时以哪个维度为准，例如价值相近时紧急度优先、依赖前置项不受价值排序影响。规则写下来，排期讨论就从“我觉得重要”变成对照规则判定。
产能估算口径与缓冲
产能按团队在排期周期内实际可投入的人天估算，扣除休假、支持性工作和例行会议。缓冲比例没有统一标准，常见做法是在周期总产能中预留一部分应对估算偏差和临时插入，比例由团队根据历史偏差情况确定并定期校准。缓冲要写进排期表，让所有人知道哪些时间是不可挪用的余量。
排期操作步骤：从需求到时间窗口
输入准备完成后，排期按四步执行。每步都有明确输入、动作、输出和完成标志，做完一步再进入下一步。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 拆解与标注依赖 | 通过准入的需求 | 把需求拆成可估算的工作项，标注前置依赖和外部条件 | 工作项清单与依赖关系 | 每个工作项有估算值，依赖项已指名到具体需求或团队 |
| 2. 填充时间窗口 | 工作项清单、优先级、产能 | 按优先级与依赖顺序把工作项排入周期，前置项先排 | 初版排期表 | 每个工作项有负责人和计划起止时间，无依赖倒置 |
| 3. 设置缓冲与交接点 | 初版排期表 | 在周期内预留缓冲，标出跨团队交接的时间点与交付物 | 含缓冲与交接点的排期表 | 缓冲有明确额度，每个交接点有接收方和确认方式 |
| 4. 评审与确认 | 含缓冲的排期表 | 召开排期评审，相关角色逐项确认范围、时间和责任 | 确认版排期表 | 决策人确认，异议项有处理结论并记录 |
拆解环节的粒度以“能估算、能指派、能判断完成”为准。功能复杂的需求可拆成多个子项并关联研发与测试任务，把需求、开发、测试串在同一条链路上。填充时间窗口时，先排依赖链上的前置项，再按优先级填充其余工作项；产能排满即停止，超出部分留在待排区，不硬塞进当前周期。评审环节的重点是让执行者确认时间是否可行，而不是单向宣布结果。
角色分工与交付物：谁排、谁确认、谁跟踪
排期涉及三类角色，各自职责和交付物不同。分工清楚，排期才不会变成某一方单方面填表。
| 角色 | 排期中的职责 | 交付物 |
|---|---|---|
| 需求提出方 | 提供需求描述、价值说明和验收口径，参与优先级讨论 | 合格的需求条目与价值说明 |
| 产品负责人 | 维护需求池，按规则判定优先级，组织排期评审 | 优先级判定结果、评审记录 |
| 研发负责人 | 拆解工作项、估算工作量、提出产能口径与缓冲建议 | 工作项清单、初版排期表 |
| 排期决策人 | 对范围与时间的取舍做最终决定 | 确认版排期表 |
| 需求负责人 | 执行期间更新状态、上报阻塞、发起重排 | 状态更新记录、偏差说明 |
确认方式建议采用评审会加书面记录：会上逐项过排期表，异议当场记录处理结论，会后由决策人确认版本生效。跟踪责任人通常由需求负责人担任，产品负责人按周汇总偏差。角色可以由同一人兼任，但职责要写清楚，避免出现“都以为对方在跟”的空档。
交付跟踪与偏差处理：排期之后的日常动作
排期确认只是起点，交付跟踪解决的是“计划与现实出现差距时怎么办”。跟踪节奏建议按日看状态、按周看趋势：每日站会检查进行中工作项的状态和阻塞，每周汇总一次进度偏差和依赖变化。
检查内容集中在三项：状态是否按计划推进、是否有阻塞未解除、依赖方是否按期交付。偏差判定可以用简单规则，例如工作项实际进度落后计划超过约定天数、关键依赖延期、或阻塞超过约定时长未解决，即视为偏差。偏差出现后，由需求负责人先评估影响范围，影响限于本需求内部的在周内调整；影响跨需求或跨团队的，升级给产品负责人与研发负责人共同处理。
重排的触发条件建议明确写下来：关键依赖失效、产能发生较大变化、优先级被更高项替换、或偏差累计超出缓冲额度。触发重排时，更新排期表对应字段并记录重排原因，保留原计划与新计划的对照，便于后续复盘估算准确度。ONES 中团队成员可通过看板管理任务状态，在站会中对齐进度与风险，需求与缺陷的处理进度对相关方可见，这些能力可以承接上述跟踪动作。
示例：一个需求从入池到排期确认的完整走查
以下为演示情景，用于说明字段填写与判断过程，不代表真实客户案例。
某团队收到需求“订单列表支持按客户名称筛选”。入池时，提出方补充了描述（客服在核对订单时需要逐页翻找）、价值说明（减少客服单次查询耗时）和验收口径（输入客户名称可返回对应订单，空结果有提示）。三项齐备，进入排期候选。
优先级判定：价值为中（影响客服效率，不影响交易），紧急度低（无明确时间约束），无前置依赖，综合定为中优先级。拆解为三个工作项：后端查询接口改造、前端筛选组件、联调与回归测试，估算合计若干人天。依赖标注为“前端组件依赖后端接口字段确定”，交接点为测试环境部署。
填充时间窗口：后端接口排入周期前半段，前端组件在其后开始，联调测试排在周期末并预留缓冲。评审会上测试人员提出回归范围需包含历史订单数据，该异议记录后补充进验收口径，决策人确认排期表生效。跟踪记录样例：第3日后端接口状态更新为进行中，第6日标注“等待测试环境”，需求负责人上报阻塞并协调环境，第8日解除。
完成检查：排期是否可执行的核对清单
排期表确认前，用以下清单逐项核对。每项都有通过标准，未通过的项在确认前补齐。
| 检查项 | 通过标准 |
|---|---|
| 字段完整性 | 每个需求的需求标识、优先级、负责人、计划起止时间、依赖、状态均已填写，无空项 |
| 责任人明确性 | 每个工作项有唯一负责人，交接点有接收方 |
| 依赖覆盖 | 所有前置依赖已指名到具体需求、团队或环境，无“待定”依赖 |
| 缓冲设置 | 周期内预留缓冲且有明确额度，关键风险点有对应余量 |
| 产能匹配 | 排入工作量不超过可用产能，超出部分已移入待排区 |
| 跟踪机制 | 跟踪节奏、偏差判定规则、重排触发条件已确定，跟踪责任人有名有姓 |
| 确认记录 | 决策人已确认，评审异议有处理结论并留档 |
七项全部通过，排期结果即可进入执行。执行中按跟踪机制运行，偏差按规则处理，重排留记录，下一周期的估算和缓冲比例就有了校准依据。
常见问题
需求排期和迭代计划是什么关系，两者会不会重复做一遍？
两者处理的对象不同。排期解决的是需求在什么时间窗口做、由谁负责、依赖什么；迭代计划解决的是某个周期内团队整体做什么、节奏怎么安排。采用迭代方式的团队，排期结果通常体现为需求被规划进某个迭代，排期表与迭代计划共用同一套需求标识，不需要重复录入。
如果团队不按迭代运作，排期表可以独立存在，按时间窗口直接分配工作项即可。迭代整体节奏的设计不在排期环节展开，排期只负责把需求落到具体窗口并明确责任。
优先级规则定下来之后，遇到紧急插入的需求怎么处理？
紧急插入的需求同样要走准入检查和优先级判定，不能因为“急”就跳过字段填写。处理方式有两种：一是替换当前周期内优先级较低的工作项，被替换项移入待排区并记录原因；二是占用缓冲额度，前提是缓冲还有余量且不影响关键依赖链。
无论哪种方式，都要更新排期表对应字段并留下记录，让后续复盘能看清插入需求对原计划的影响。频繁插入说明优先级规则或产能口径需要重新校准，可以在周度汇总时一并评估。
跨团队依赖的交接点怎么跟踪，出了问题找谁？
交接点在排期阶段就要写明接收方、交付物和确认方式，只写“等待某团队支持”不算合格。跟踪时把交接点当作独立检查项：交付方是否按期提供、接收方是否确认可用。任一方未按期完成，即视为偏差，由需求负责人先评估影响范围。
影响限于本需求内部的，在周内调整；影响跨需求或跨团队的，升级给产品负责人与研发负责人共同处理。交接点的确认记录建议留在工作项上，避免口头承诺事后无从对照。
团队历史数据很少，缓冲比例第一次怎么定？
没有历史偏差数据时，可以先按经验设定一个初始比例，并在排期表中明确标注这是待校准值。运行一到两个周期后，用实际偏差情况回看：估算普遍偏低还是偏高、临时插入占用了多少产能、阻塞平均持续多久，据此调整下一周期的比例。
缓冲的作用是吸收估算偏差和临时插入，比例过高会掩盖估算问题，过低则频繁触发重排。关键是每次重排都记录原因，让校准有据可依，而不是凭感觉反复调整。
排期表用文档维护还是放到工作项字段上，怎么选？
判断标准是跟踪频率和协作人数。需求数量少、更新不频繁、参与方集中在一个团队时，文档形式的排期表可以满足需要；需求量大、状态每日变化、涉及多个角色查看时，把字段落到工作项上更合适，状态变化和时间调整都有记录，减少人工同步。
ONES 的统一需求池与任务、工单体系可以承载需求字段和状态流转，团队成员可通过看板管理任务状态并在站会中对齐进度与风险。具体字段如何配置，需结合团队实际在试用中确认。
