需求排期要把已确认进入实现的需求，转成一份可执行、可跟踪的计划：明确优先级、工作量、依赖、负责人和时间窗口，并约定发布后的更新方式。本文按“确定范围—拆解估算—识别依赖—分配时间窗口—评审发布—跟踪变更”的顺序展开，适用于单个需求集合或一个交付批次的排期；迭代整体安排和需求验收结论不在本文范围。
要点总览（TL;DR）
- 需求排期针对已确认进入实现的需求，把优先级、工作量、依赖、负责人和时间窗口落到一张可跟踪的表上。
- 制定过程分五步：确定范围与需求清单、拆解并估算工作量、识别依赖与约束、按优先级与产能分配时间窗口、评审确认并发布排期基线。
- 需求负责人确认优先级，研发负责人组织估算与识别技术依赖，项目或交付负责人汇总协调并发布，测试与相关方确认测试与联调时间点。
- 排期发布后按检查点跟踪状态、依赖与风险，需求变更和插入需求先评估影响，再决定替换、顺延或另排窗口，并更新排期版本。
- 发布前用检查清单核对范围、优先级、估算依据、依赖风险、资源匹配、发布确认和变更规则，全部通过再发布。
需求排期要回答哪几个问题
排期的核心任务，是回答“哪些需求在什么时间、由谁、按什么顺序做完”。它针对的是已经确认进入实现的需求，尚未澄清或未通过评审的需求不进入排期表，否则日期会建立在不确定的范围上。一份可用的排期至少要回答四个问题：需求之间的先后顺序是什么，每项工作需要多少工作量，工作之间有哪些依赖和外部约束，以及由谁在哪个时间窗口内完成。
这四个问题对应排期表的基本信息：优先级、估算、依赖关系、负责人和时间窗口。缺少任何一项，排期都容易退化成一张只有日期的清单。优先级决定先做什么，估算决定能不能装得下，依赖决定顺序是否可行，负责人和时间窗口决定计划能否被跟踪。
排期结果需要能被持续跟踪和调整。需求在实现过程中会出现澄清、插入、延期等情况，排期表要保留状态字段和变更记录，让相关方看到当前进展与偏差。排期发布后，需求实现过程中的进度更新、阻塞上报和调整决策，都应以这张表为共同参照。
需要区分的是，本文讨论的是需求实现过程的排期。迭代周期怎么划分、迭代目标如何设定，属于迭代整体安排；需求做完后是否通过验收、验收结论如何闭环，属于需求验收管理。这两部分会与排期发生衔接，但不作为本文的操作内容。
制定需求排期的操作步骤
下面五步构成一次完整的排期过程。每一步都说明输入、动作、输出和完成标志，可以按顺序执行一遍，形成首版排期基线。
第一步：确定排期范围与需求清单
输入是已确认进入实现的需求及其优先级依据。动作是逐条核对需求是否具备进入排期的条件：需求描述是否清楚、优先级是否已由需求负责人确认、是否明确本期要做的范围。输出是一份待排期需求列表，包含需求名称、优先级、提出方和期望时间。完成标志是列表中的每条需求都有明确优先级，且没有处于“待澄清”状态的需求混入。
第二步：拆解工作项并估算工作量
输入是待排期需求列表。动作是把每条需求拆成可估算、可分配的工作项，例如设计、开发、测试准备等，再由对应执行人给出工作量估算。拆解粒度以“一个人能在较短时间内完成并判断是否做完”为宜。输出是带估算的任务清单，每条任务有负责人和估算值。完成标志是所有进入排期的需求都已拆解，且每项任务都有估算和负责人，没有无人认领的任务。
第三步：识别依赖与约束
输入是带估算的任务清单。动作是逐项检查任务之间的前后依赖，以及外部约束，例如接口联调时间、第三方资源到位时间、关键人员可用性。输出是依赖关系与风险清单，标明依赖对象、影响的任务和风险等级。完成标志是每条依赖都有明确的上下游任务和责任人，高风险项有初步应对方案。
第四步：按优先级与产能分配时间窗口
输入是任务清单、依赖清单和团队可用产能。动作是先按优先级排序，再结合依赖顺序和人员可用时间，把任务放入具体时间窗口，检查同一负责人的任务是否重叠、关键路径是否留有缓冲。输出是排期表，包含需求、任务、负责人、起止时间、依赖和状态字段。完成标志是排期表中没有资源冲突，高优先级需求的时间窗口已确定，关键依赖的前后顺序一致。
第五步：评审确认并发布排期
输入是排期表初稿。动作是组织需求负责人、研发负责人、测试和相关方共同评审，确认时间窗口、依赖假设和风险应对，记录评审中的调整意见并更新排期表。输出是经确认的排期基线。完成标志是相关方对排期表无未决异议，排期表已发布到团队共同可见的位置，并注明了版本或发布日期。
角色分工与各环节交付物
排期涉及多个角色的判断，由一个人填表容易遗漏依赖和验收时间。下表按角色列出主要职责和交付物，实际执行时可由同一人兼任多个角色，但职责要明确到人。
| 角色 | 主要职责 | 输入 | 输出交付物 |
|---|---|---|---|
| 需求负责人 | 澄清需求内容，确认优先级和本期范围 | 业务反馈、需求背景 | 已确认优先级的需求清单 |
| 研发负责人 | 组织工作项拆解与工作量估算，识别技术依赖 | 需求清单 | 带估算的任务清单、技术依赖说明 |
| 项目或交付负责人 | 汇总排期、协调资源冲突、组织评审并发布 | 任务清单、依赖清单、产能信息 | 排期表、评审记录、排期基线 |
| 测试与相关方 | 确认测试准备、联调和验收时间点 | 排期表初稿 | 测试与联调时间确认、评审意见 |
需求负责人的关键动作发生在排期之前：把需求讲到研发能估算的程度，并给出可解释的优先级。研发负责人对估算的准确性负责，估算依据可以是历史同类任务、技术方案复杂度或团队经验，估算结果要记录在任务上，便于后续复盘。项目或交付负责人不替代各角色做判断，而是把各方输入汇总成一张一致的排期表，并在冲突时推动取舍。测试与相关方需要在评审阶段确认测试窗口和联调时间，避免排期表发布后才发现测试资源已被占用。
一个需求排期的示例
以下为演示情景，用于说明排期表的形成过程，不对应任何真实项目。
某团队本期有四项已确认需求：A 订单列表增加筛选条件，优先级高；B 导出报表格式调整，优先级中；C 消息通知增加模板配置，优先级中；D 历史数据清理工具，优先级低。团队可用开发人员两名，测试人员一名，本期时间窗口为两周。
拆解后，A 拆为接口调整、前端筛选组件、联调三项，合计约五天；B 拆为导出逻辑修改和格式校验两项，约三天；C 拆为模板配置界面和通知发送逻辑两项，约四天；D 拆为脚本编写和数据校验两项，约三天。依赖方面，A 的前端筛选依赖接口字段确定，C 的通知发送逻辑依赖消息服务配置到位，B 的格式校验需要测试提供样例数据。
按优先级和产能分配后，A 排在第一周完成开发、第二周初联调；B 与 C 并行安排在第二周，C 的发送逻辑排在消息服务配置确认之后；D 因优先级低且依赖较少，安排在第二周后半段，若时间不足则顺延。风险清单记录两项：消息服务配置时间未确认，可能影响 C；测试样例数据未提供，可能影响 B 的校验进度。
排期表可按以下字段呈现：需求编号、需求名称、优先级、工作项、负责人、开始时间、结束时间、前置依赖、当前状态、风险说明。这张表的关键在于每行都能对应到人和时间，依赖列能看出顺序，状态列能支持后续更新。示例的适用边界是需求数量较少、团队规模较小的场景；需求更多或跨团队协作时，需要增加按团队分组的视图和更细的依赖管理。
排期发布后的跟踪与变更处理
排期发布后进入执行跟踪阶段。跟踪节奏可以与团队现有会议结合，例如每日同步阻塞和当天计划，每周检查整体进度与风险。检查点关注三类信息：任务状态是否按计划推进，依赖是否按期解除，风险是否已经发生。状态字段至少包含未开始、进行中、阻塞、完成，更新责任人是各任务的负责人，项目或交付负责人负责汇总偏差。
需求变更和插入需求需要规则。建议约定：变更需求先进入待评估状态，由需求负责人说明优先级和期望时间，研发负责人评估对当前排期的影响，项目或交付负责人决定是替换、顺延还是另排窗口，并将决定记录在排期表或变更记录中。插入高优先级需求时，明确被调整的需求和新的时间窗口，避免只加不减导致排期失真。
延期识别以检查点为准：任务超过计划结束时间仍未完成，或依赖未按期解除，即标记为偏差。调整方式包括重新分配负责人、压缩非关键任务、调整后续需求时间窗口。每次调整后更新排期表版本，并在下一次检查点确认调整是否有效。
在工具层面，排期涉及的需求拆解、任务状态和进度对齐需要有共同的承载位置。ONES 支持通过业务需求池、产品需求池与工单系统联动业务反馈与产品开发，业务团队可跟踪需求和缺陷处理进度，研发团队通过任务和工单完成开发、测试与修复，形成需求—任务—测试—缺陷的流转；对于功能复杂的需求，可用子工作项拆解并关联研发和测试任务；迭代过程中可通过敏捷看板管理任务状态，在每日站立会议中对齐进度与风险。这些能力对应的是排期发布后的拆解承载和状态跟踪环节，排期表本身仍需团队按上述字段约定维护。
排期完成检查清单
发布排期前，可逐项核对以下检查项。全部通过，说明本次排期达到了可用标准；存在未通过项，先补齐再发布。
- 需求范围已确认：进入排期的需求均为已确认进入实现的需求，没有待澄清项混入。
- 优先级已确认：每条需求都有需求负责人确认的优先级，排序依据可解释。
- 估算有依据：每项任务都有工作量和负责人，估算依据已记录。
- 依赖与风险已记录：依赖关系标明上下游和责任人，高风险项有应对方案。
- 时间窗口与资源匹配：同一负责人的任务无重叠，关键路径留有缓冲。
- 排期表已发布：排期表包含需求、任务、负责人、时间、依赖和状态字段，并已发布到相关方可查看的位置。
- 相关方已确认：需求负责人、研发负责人、测试与相关方对排期无未决异议，评审意见已处理。
- 跟踪与变更规则已约定：明确了检查节奏、状态更新责任人和需求变更的处理方式。
常见问题
需求还没完全澄清，可以先放进排期表占一个时间窗口吗？
不建议把待澄清需求直接排进时间窗口。排期表里的日期代表团队对交付顺序的承诺，需求描述不清或优先级未确认时，估算缺少依据，后续澄清很可能推翻时间安排。更稳妥的做法是先把这类需求留在待评估清单，由需求负责人补齐描述和优先级后再进入排期。如果业务方希望预留时间，可以标注为“待评估占位”，并明确它不构成交付承诺。
团队同时有多个高优先级需求，产能装不下时怎么排？
先确认这些需求的优先级是否真的同级。让需求负责人给出排序依据，例如业务影响、时间敏感度或依赖关系，把“都重要”拆成可比较的顺序。排序后按产能装入时间窗口，装不下的需求明确顺延到下一个窗口，并告知提出方。如果确实无法取舍，由项目或交付负责人组织决策，记录取舍结论和被调整的需求，避免排期表上出现超出产能的安排。
排期发布后插入紧急需求，原排期怎么处理？
插入需求先进入待评估状态，由需求负责人说明优先级和期望时间，研发负责人评估对当前任务的影响，项目或交付负责人决定处理方式：替换掉同等或更低优先级的需求、把受影响需求顺延，或另排时间窗口。决定后同步更新排期表并记录变更，明确被调整的需求和新的时间窗口。只加不减会让排期逐渐失真，因此每次插入都应伴随一次取舍。
需求排期和迭代计划是什么关系，需要各做一份吗？
两者关注的范围不同。需求排期针对需求实现过程，回答哪些需求在什么时间、由谁、按什么顺序做完；迭代计划关注迭代周期如何划分、迭代目标如何设定。实际执行中，排期结果可以作为迭代计划的输入，迭代计划确定后再回到排期表细化任务时间窗口。团队规模较小时可以合并在一张表里维护，但要保留需求层面的优先级、依赖和状态字段，避免只剩迭代层面的安排。
排期表用表格维护还是放到研发管理工具里？
取决于团队规模和跟踪频率。需求数量少、协作方少时，一张字段完整的表格就能满足排期和状态更新。需求多、跨角色协作频繁时，把需求拆解、任务状态和进度对齐放到共同可见的工具里更便于跟踪。ONES 支持通过业务需求池、产品需求池与工单系统联动业务反馈与产品开发，业务团队可跟踪需求和缺陷处理进度，研发团队通过任务和工单完成开发、测试与修复；功能复杂的需求可用子工作项拆解并关联研发和测试任务，迭代过程中可通过敏捷看板管理任务状态。无论用哪种承载方式，排期表本身的字段约定和变更规则仍需团队维护。
