需求排期表把每条需求的负责人、计划时间和当前状态放在同一张表里，让团队能直接判断哪些需求按期推进、哪些已经受阻。本文提供一张可直接复制的空白表，并逐字段说明填写口径、必填与选填的划分，再用一条含延期的需求演示完整填法，最后给出按团队情况裁剪字段和长期维护的做法。
要点总览（TL;DR）
- 需求排期表以需求为行，按需求基本信息、排期信息、交付跟踪信息三组列组织，复制后即可逐条填写。
- 必填字段以“可唯一识别、可追踪、可判断是否按期”为标准，包括需求编号、名称、来源、优先级、负责人、计划时间、状态、交付里程碑和阻塞原因。
- 计划时间与实际时间分列记录，排期变动时保留原计划并标注调整后日期与原因，避免覆盖历史承诺。
- 团队十人左右、需求数量少时先用六列最小可用版本，出现跨团队依赖或对外承诺交付时再补齐完整字段。
- 需求数量增加、多人同时更新后，可把需求池、任务看板与状态流转交给协作工具承接，表格保留汇总与对外沟通用途。
可直接复制的需求排期表空白模板
下表按三组列组织：需求基本信息用于识别需求，排期信息用于记录承诺时间，交付跟踪信息用于反映当前进展。复制到表格软件后，按行填写每条需求即可。
| 需求基本信息 | 排期信息 | 交付跟踪信息 | 选填字段 | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 需求编号 | 需求名称 | 来源 | 优先级 | 负责人 | 计划开始 | 计划完成 | 当前状态 | 实际开始 | 实际完成 | 交付里程碑 | 阻塞原因 | 工作量估算 | 依赖项 | 验收人 |
表格范围限定在需求实现过程的排期与交付跟踪。迭代整体安排、需求验收结论分别属于其他管理环节，本表只保留与单条需求排期相关的信息，避免列过多导致填写负担。
每个字段的含义与填写口径
字段填写的一致性决定了表格能否被信任。同一列在不同人手里出现不同写法，后续筛选和汇总就会失真。下表给出每个字段的含义、取值方式和常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 需求编号 | 需求的唯一标识 | 沿用团队现有编号规则，如“REQ-2024-018”，一条需求一个编号，不复用 | 同一需求出现两个编号；编号中途更换导致追溯断链 |
| 需求名称 | 一句话说明需求要解决的问题 | 写成“对象＋动作＋结果”，控制在20字左右，避免只写“优化”“改版” | 名称过于笼统，评审时无法判断范围 |
| 来源 | 需求由谁或哪个渠道提出 | 写具体来源，如“客户A”“销售团队”“内部运营”，便于回溯沟通记录 | 统一写“业务方”，无法定位提出人 |
| 优先级 | 需求相对其他需求的紧急与重要程度 | 固定取值，如P0/P1/P2/P3，并在表头注明含义；P0仅用于影响线上可用性的需求 | 同一张表混用“高”“紧急”“P1”多种写法 |
| 负责人 | 对需求推进结果负责的人 | 写一个人名，不写团队名；协作者放在依赖项或备注中 | 填部门名称，出现问题时无人对应 |
| 计划开始 / 计划完成 | 团队对外承诺的时间 | 填写具体日期；计划完成日期应与评审时确认的交付时间一致 | 只填月份；计划时间随实际进度反复改写 |
| 当前状态 | 需求所处的推进阶段 | 固定取值，如待评审、已排期、开发中、待验收、已交付、已阻塞 | 状态名称随意新增，无法统计 |
| 实际开始 / 实际完成 | 实际发生的时间 | 进入开发当天填实际开始，交付确认后填实际完成；未发生则留空 | 用实际时间覆盖计划时间，丢失原承诺 |
| 交付里程碑 | 需求对应的交付节点 | 写版本号或节点名称，如“V2.3发布”，与发布计划对应 | 填写模糊的“本季度”，无法与发布对齐 |
| 阻塞原因 | 当前阻碍交付的具体事项 | 写明对象与影响，如“等待客户A确认接口字段，影响联调”，解除后清空并记录解除日期 | 写“资源不足”“沟通中”等无法行动的描述 |
| 工作量估算 | 完成需求所需投入的规模 | 统一单位，如人天或故事点，全表只用一种 | 部分行填人天、部分行填点数 |
| 依赖项 | 交付前必须满足的前置条件 | 写依赖对象和需求编号，如“依赖REQ-2024-012的接口上线” | 只写“依赖其他团队”，无法跟进 |
| 验收人 | 确认需求交付结果的人 | 写具体人名，通常为提出方或产品负责人 | 留空，交付时无人确认 |
计划时间与实际时间分列是这张表的关键设计。排期变动时修改计划完成日期，同时在变更记录中保留原日期和调整原因，这样既能反映当前承诺，也能看出承诺调整过几次。
哪些字段必填、哪些可以选填
必填字段的判断标准是：缺了它，这条需求就无法被唯一识别、无法被追踪，或者无法判断是否按期。按这个标准，需求编号、需求名称、来源、优先级、负责人、计划开始、计划完成、当前状态、交付里程碑、阻塞原因属于必填；工作量估算、依赖项、验收人、实际开始、实际完成属于选填或按阶段填写。
| 类别 | 字段 | 必填理由或适用场景 |
|---|---|---|
| 必填 | 需求编号、需求名称、来源 | 保证每条需求可被唯一识别并回溯提出方 |
| 必填 | 优先级、负责人 | 决定排序和责任人，缺一项就无法安排工作 |
| 必填 | 计划开始、计划完成 | 排期表的核心信息，缺了无法判断是否按期 |
| 必填 | 当前状态、交付里程碑 | 反映进展并与发布节点对齐 |
| 必填（无阻塞时填“无”） | 阻塞原因 | 强制填写可让阻塞在表内可见，避免口头传递 |
| 选填 | 工作量估算 | 需要做容量评估或排期取舍时填写 |
| 选填 | 依赖项 | 存在跨团队或跨需求前置条件时填写 |
| 选填 | 验收人 | 交付需要明确确认人时填写 |
| 按阶段填写 | 实际开始、实际完成 | 需求进入开发或交付后填写，用于对比计划偏差 |
最小可用版本只保留需求编号、需求名称、优先级、负责人、计划完成、当前状态六列，适合需求数量少、团队人数在十人以内的情况。完整版本在此基础上补齐来源、计划开始、交付里程碑、阻塞原因和实际时间，适合多团队协作、需要对外承诺交付时间的场景。两种版本的字段名称保持一致，便于后续扩展时直接加列。
一张填好的需求排期表示例
以下示例为演示情景，团队和需求均为虚构，用于说明字段如何填写。表中包含一条因外部确认延迟而延期的需求，展示阻塞原因和计划时间调整的记录方式。
| 需求编号 | 需求名称 | 来源 | 优先级 | 负责人 | 计划开始 | 计划完成 | 当前状态 | 实际开始 | 实际完成 | 交付里程碑 | 阻塞原因 | 工作量估算 | 依赖项 | 验收人 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| REQ-2024-018 | 订单列表支持按客户筛选 | 客户A | P1 | 张明 | 2024-06-03 | 2024-06-21 | 开发中 | 2024-06-03 | V2.3发布 | 无 | 5人天 | 无 | 李婷 | |
| REQ-2024-021 | 对接客户B的物流查询接口 | 客户B | P0 | 王磊 | 2024-06-10 | 2024-07-05（原计划2024-06-28） | 已阻塞 | 2024-06-10 | V2.3发布 | 等待客户B提供接口文档与测试账号，影响联调，6月17日提出，6月24日仍未提供 | 8人天 | 依赖REQ-2024-018的筛选组件 | 陈静 | |
| REQ-2024-025 | 导出报表增加汇总行 | 内部运营 | P2 | 赵倩 | 2024-06-17 | 2024-06-28 | 已交付 | 2024-06-17 | 2024-06-27 | V2.3发布 | 无 | 2人天 | 无 | 周涛 |
REQ-2024-021这一行演示了三个要点：计划完成日期保留原计划并用括号标注调整后日期；阻塞原因写明等待对象、缺失材料和影响范围；状态改为“已阻塞”而非继续停留在“开发中”。这样在周会上查看表格时，阻塞项会直接暴露出来，而不需要逐条询问。
模板的调整与日常维护方法
模板拿到手后需要按团队情况裁剪，并在使用中保持更新，否则表格很快会变成过期信息的堆积。以下清单覆盖字段调整、排期变更、清理归档和工具衔接四类动作。
按团队与项目类型增删字段
- 需求数量在几十条以内、团队十人左右时，先用最小可用版本，减少填写负担。
- 存在跨团队依赖时增加依赖项列，并在每周排期会上逐条核对依赖是否解除。
- 需要做容量评估时增加工作量估算列，全表统一单位，避免人天与故事点混用。
- 对外承诺交付时间的项目增加交付里程碑列，与发布计划保持同一套节点名称。
- 删除长期空白的列。连续两个迭代无人填写的选填列，说明当前阶段不需要，先移除再按需加回。
排期变更的更新时机与记录方式
- 计划完成日期发生变化时，当天更新表格，在原日期后标注新日期，并在变更记录中写明原因，如“客户确认延迟”。
- 状态变化当天更新，尤其是转为“已阻塞”时，同步填写阻塞原因和提出日期。
- 阻塞解除后清空阻塞原因，在变更记录中补一条解除说明，保留问题持续时长。
- 每周固定一次排期核对，逐条确认负责人、计划时间和状态三项是否仍然准确。
定期清理与归档
- 已交付的需求在交付确认后保留一个迭代，随后移入归档表，主表只保留进行中的需求。
- 归档表保留原编号和实际完成时间，便于后续追溯交付记录。
- 每季度检查一次字段使用情况，合并重复列、删除无人维护的列。
与协作工具衔接
当需求数量增加、多人同时更新时，单张表格容易出现版本冲突和状态滞后。这时可以把需求池、任务看板和状态流转交给协作工具承接，表格保留汇总和对外沟通的用途。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，业务团队可跟踪需求和缺陷处理进度，研发团队通过任务和工单完成开发、测试与修复，形成需求—任务—测试—缺陷的流程闭环；其业务、产品经理与研发团队三视角分别聚焦需求来源、产品规划及落地交付，统一的需求池、工单与任务看板可实时同步状态与信息。产品负责人可按优先级将需求规划至对应迭代，在迭代计划会议上与团队评审需求，设计、研发、测试人员再用子任务拆分需求以便跟踪。这些能力承接的是排期确定之后的执行与状态同步，迭代整体安排和验收结论仍由对应环节管理。
常见问题
需求排期表和迭代计划是什么关系，应该先做哪一个？
两者关注的对象不同。需求排期表管理单条需求的负责人、计划时间和当前状态；迭代计划决定一个迭代内做哪些需求、按什么顺序做。常见顺序是先在需求池中确定优先级，再在迭代计划会议上把选中的需求排入迭代，随后把每条需求的计划开始与完成时间落到排期表中。
如果团队还没有稳定的迭代节奏，可以先只维护排期表，等需求数量和协作人数上升后再引入迭代安排。本文的模板只覆盖单条需求的排期与交付跟踪，迭代整体安排属于另一个管理环节。
需求在开发中途被阻塞，排期表应该怎么改？
当天更新三处：把当前状态改为“已阻塞”，在阻塞原因中写明等待对象、缺失材料和影响范围，并在计划完成日期后标注调整后的日期，原日期保留。阻塞解除后清空阻塞原因，并在变更记录中补一条解除说明，保留问题持续时长。
不建议把状态继续停留在“开发中”再口头同步，这样周会查看表格时阻塞项不会暴露，容易拖到临近交付才被发现。
团队人数很少，能不能只用最简的几列？
可以。需求数量在几十条以内、团队十人左右时，只保留需求编号、需求名称、优先级、负责人、计划完成、当前状态六列即可满足识别、排序和按期判断。字段名称与完整版本保持一致，后续需要增加来源、计划开始、交付里程碑或阻塞原因时直接加列，不需要重建表格。
需要留意的例外是：一旦出现对外承诺交付时间或跨团队依赖，就应补上交付里程碑和依赖项，否则延期和等待关系无法在表内体现。
排期表用表格软件维护，什么时候该换成协作工具？
出现以下信号时可以考虑迁移：多人同时编辑同一张表导致版本冲突；状态更新依赖人工汇总，周会上看到的信息已经滞后；需求与任务、测试、缺陷之间的对应关系需要手工维护。这时可把需求池、任务看板和状态流转交给协作工具承接，表格保留汇总和对外沟通用途。
ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，业务团队可跟踪需求和缺陷处理进度，研发团队通过任务和工单完成开发、测试与修复；统一的需求池、工单与任务看板可同步状态与信息。迁移后仍需保留每周一次的排期核对动作，工具不会替代对承诺时间的确认。
已交付的需求要留在主表里吗？
建议交付确认后保留一个迭代，随后移入归档表，主表只保留进行中的需求。归档表保留原需求编号和实际完成时间，便于后续追溯交付记录和对比计划偏差。
如果团队需要按季度统计交付情况，可以在归档表中增加一列记录计划完成与实际完成的差值，主表不必为此增加字段。每季度同时检查一次字段使用情况，合并重复列、删除连续两个迭代无人填写的列。
