需求排期表的设计核心，是把需求条目、排期依据、责任角色和交付状态放进同一张可维护的表里。字段要能回答“做什么、为什么先做、谁来做、何时完成、现在到哪一步”；运行时要按收集、评估、排序、排期、跟踪、调整的顺序推进；维护上要分清产品、研发、测试和项目负责人的填写与确认职责。本文围绕字段结构、排期步骤、角色分工、填写示例和上线前检查展开，帮助你把表设计到可以直接使用。
要点总览（TL;DR）
- 需求排期表用五组字段固定结构：标识与来源、优先级与价值、工作量与时间、责任人与依赖、状态与更新；缺少就无法判断或跟踪的设为必填，只在特定场景使用的设为选填。
- 排期表按需求收集与去重、工作量评估与拆分、优先级排序与排期确定、状态更新与交付跟踪、排期变更与调整五步运转，每步都有明确输入、输出和完成标志。
- 产品经理负责需求信息与优先级，研发负责人负责工作量与排期承诺，测试角色负责验证节点，项目负责人负责整体排期与变更确认，更新频率与团队节奏对齐。
- 上线前从字段完整性、排期依据可追溯、责任人与更新机制、状态口径统一、边界划分清晰五个方面逐项核对，全部通过再正式推行。
- 排期表只承载需求实现过程的排期与交付状态，迭代整体安排和验收结论由对应机制承载，通过状态或关联字段衔接。
需求排期表先定哪些字段
字段设计的目标是让一张表同时承担三件事：记录需求本身、说明排期依据、支撑交付跟踪。字段过多会增加填写负担，字段过少会让排期变成没有依据的时间承诺。建议先按“标识与来源、优先级与价值、工作量与时间、责任人与依赖、状态与更新”五组建立字段，再区分必填和选填。
必填与选填的划分原则可以归纳为三条：缺少该字段就无法判断需求是否应该进入排期，设为必填；缺少该字段会影响交付跟踪或责任追溯，设为必填；只在特定场景使用、对常规排期不构成判断依据的信息，设为选填。必填项应在需求进入排期前补齐，选填项允许在评估过程中逐步完善。
| 字段名 | 用途 | 填写角色 | 必填/选填 |
|---|---|---|---|
| 需求编号 | 唯一标识需求，便于引用、去重和跨表关联 | 产品经理 | 必填 |
| 需求名称 | 用一句话说明需求内容，便于快速识别 | 产品经理 | 必填 |
| 需求来源 | 记录来自客户、业务部门、内部改进或线上问题，支撑价值判断 | 产品经理 | 必填 |
| 需求描述 | 说明使用场景、目标用户和期望结果 | 产品经理 | 必填 |
| 优先级 | 标明高、中、低或排序序号，作为排期先后依据 | 产品经理 | 必填 |
| 价值说明 | 记录业务收益、影响范围或风险规避理由 | 产品经理 | 必填 |
| 预估工作量 | 以人天或故事点表示实现成本，支撑排期容量判断 | 研发负责人 | 必填 |
| 计划开始时间 | 需求进入开发的计划日期 | 项目负责人 | 必填 |
| 计划完成时间 | 需求达到可交付状态的计划日期 | 项目负责人 | 必填 |
| 负责人 | 对需求交付结果负责的人，通常为研发负责人 | 项目负责人 | 必填 |
| 依赖项 | 记录前置需求、外部接口、环境或资源依赖 | 研发负责人 | 选填，存在依赖时必填 |
| 当前状态 | 标明需求处于待评估、已排期、开发中、测试中、已交付等阶段 | 负责人按阶段更新 | 必填 |
| 最近更新时间 | 记录状态或排期变更时间，便于识别长期未更新的条目 | 系统或更新人 | 必填 |
| 备注 | 记录变更原因、风险说明或临时约定 | 更新人 | 选填 |
这张字段清单可以直接作为表头使用。实际落地时，需求编号和需求名称用于识别，优先级和价值说明用于回答“为什么先做”，工作量和计划时间用于回答“什么时候做”，负责人和依赖项用于回答“谁来做、受什么限制”，状态和更新时间用于回答“现在到哪一步”。五组字段各司其职，避免把排期表做成只有时间列的计划表。
从需求进入到交付的排期步骤
排期表建立之后，需要一套固定动作让它持续运转。下面五个步骤按顺序衔接，每一步都明确输入、动作、输出和完成标志，便于团队照着执行。
第一步：需求收集与去重
输入是来自客户、业务部门、内部团队和线上问题的各类反馈。产品经理将反馈整理为需求条目，分配需求编号，合并重复或高度相似的需求，并补齐来源和描述。输出是一份编号唯一、描述清晰的需求清单。完成标志是每条需求都能追溯到来源，且不存在同一诉求重复建条。
第二步：工作量评估与拆分
输入是已去重的需求清单。研发负责人组织评估，对功能复杂、跨模块或周期较长的需求拆分为可独立交付的子项，分别给出预估工作量，并标注子项之间的先后关系。输出是带有工作量估算和拆分结构的排期候选需求。完成标志是每条进入排期的需求都有明确的工作量数值，拆分后的子项能够对应到具体负责人。
第三步：优先级排序与排期确定
输入是带工作量的需求清单和团队可用容量。产品经理依据价值说明、紧急程度和依赖关系给出优先级，项目负责人结合容量确定计划开始与完成时间，并指定负责人。输出是完成排期填写的需求条目。完成标志是每条已排期需求都具备优先级、计划时间、负责人三项信息，且排期总量与团队容量基本匹配。
第四步：状态更新与交付跟踪
输入是已排期的需求条目。负责人按实际进展更新状态，从待评估、已排期推进到开发中、测试中、已交付；出现阻塞时在依赖项或备注中说明。项目负责人定期检查状态是否与实际一致，重点关注计划完成时间临近但仍未进入测试的条目。输出是状态准确、可随时查看的排期表。完成标志是表中不存在超过约定周期未更新的条目，且每条需求的当前状态都有对应的更新记录。
第五步：排期变更与调整
输入是跟踪过程中发现的延期、需求变更或资源调整。变更由提出人说明原因，项目负责人评估对关联需求的影响，更新计划时间和依赖项，并在备注中记录变更依据。输出是调整后的排期表和变更记录。完成标志是变更后的排期仍满足优先级顺序，受影响的关联需求已同步调整，变更原因可追溯。
谁填表、谁更新、谁确认
排期表建好后无人维护，通常源于职责没有落到具体角色。建议按“信息谁最清楚、结果谁负责”的原则划分：产品经理负责需求信息与优先级，研发负责人负责工作量与排期承诺，测试角色负责验证节点，项目负责人负责整体排期与变更确认。
| 角色 | 主要职责 | 交付物 | 更新时机 |
|---|---|---|---|
| 产品经理 | 录入需求编号、名称、来源、描述，给出优先级和价值说明，合并重复需求 | 完整的需求条目与优先级排序 | 需求进入排期前；优先级调整时 |
| 研发负责人 | 评估工作量，拆分复杂需求，确认计划时间是否可承诺，标注依赖项 | 工作量估算、拆分结构与依赖说明 | 排期评估时；开发过程中发现偏差时 |
| 测试角色 | 确认测试介入时间与验证节点，反馈测试中发现的问题对排期的影响 | 测试节点安排与验证反馈 | 需求进入测试前；测试结论变化时 |
| 项目负责人 | 汇总排期、平衡容量、确认变更，检查状态更新是否及时 | 整体排期表与变更记录 | 排期确定时；每次变更确认时；定期检查时 |
更新频率建议与团队节奏对齐：需求信息和优先级在需求进入排期前完成填写，状态在每次进展变化时更新，项目负责人按固定周期检查一次全表。交接规则上，负责人变更时由原负责人更新负责人字段并在备注中说明交接原因，避免出现无人认领的条目。状态口径也需要统一，例如“已交付”指需求通过验证并可对外提供，而非开发完成，具体口径由团队在表头说明中约定。
当排期表从文档迁移到可维护的工作项体系时，需求条目、负责人和状态流转需要有对应的承载方式。ONES 提供统一的业务需求池与产品需求池，可将来自各方的反馈收集为工单并转化为需求，整理成产品待办列表；对于功能复杂的需求，可用子工作项拆解并关联研发和测试任务，团队成员通过看板管理任务状态。这样，排期表中的字段和状态更新就落到具体工作项上，产品经理、研发和测试在同一体系中完成各自负责的更新动作。
一张填好的需求排期表示例
下面用四条示例需求展示字段如何填写、状态如何流转。示例数据为演示情景，团队可按自身业务替换。
| 需求编号 | 需求名称 | 来源 | 优先级 | 预估工作量 | 计划开始 | 计划完成 | 负责人 | 依赖项 | 当前状态 |
|---|---|---|---|---|---|---|---|---|---|
| REQ-101 | 订单列表支持按状态筛选 | 客户反馈 | 高 | 3人天 | 3月4日 | 3月8日 | 研发A | 无 | 已交付 |
| REQ-102 | 导出报表增加汇总行 | 业务部门 | 中 | 2人天 | 3月6日 | 3月11日 | 研发B | REQ-101 | 测试中 |
| REQ-103 | 消息通知支持批量已读 | 内部改进 | 中 | 5人天 | 3月11日 | 3月18日 | 研发A | 无 | 开发中 |
| REQ-104 | 权限配置页交互优化 | 线上问题 | 低 | 待评估 | 待定 | 待定 | 待定 | 无 | 待评估 |
逐项说明：REQ-101 优先级高、工作量明确，计划时间已过且状态为已交付，说明该条目完成了从排期到交付的完整流转。REQ-102 的依赖项填写为 REQ-101，表示需在前置需求交付后推进，其计划开始时间晚于 REQ-101 的计划完成时间，依赖关系与时间安排一致。REQ-103 处于开发中，负责人和计划时间齐全，可直接用于跟踪。REQ-104 尚未评估，工作量和负责人留待补充，状态停留在待评估，符合“未完成评估不进入排期”的规则。
示例中也能看到常见填写误区：一是把依赖项写成“无”却在实际执行中等待外部接口，导致排期失真；二是计划完成时间只按开发完成填写，未给测试留出时间；三是状态长期停留在“开发中”而备注中没有阻塞说明。设计排期表时，可以在表头或填写说明中明确这几点，减少后续返工。
上线前如何检查排期表是否可用
排期表设计完成后，建议在正式推行前逐项核对。以下检查清单覆盖字段、依据、责任、状态和边界五个方面，通过标准可作为验收口径。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 字段完整性 | 必填字段全部定义，表头含字段说明；任取一条已排期需求，必填项无空缺 | 项目负责人 |
| 排期依据可追溯 | 每条已排期需求都能看到优先级理由和工作量估算，计划时间有对应容量依据 | 产品经理与研发负责人 |
| 责任人与更新机制 | 每条需求都有明确负责人；更新频率和交接规则已写入填写说明并被团队确认 | 项目负责人 |
| 状态口径统一 | 状态取值有明确定义，团队成员对“已交付”“测试中”等含义理解一致 | 项目负责人与测试角色 |
| 边界划分清晰 | 排期表只记录需求实现过程的排期与交付状态；迭代整体安排、验收结论和闭环管理由对应机制承载，表中通过状态或关联字段体现衔接 | 项目负责人 |
五项检查全部通过，说明排期表具备了基本可用性：字段能支撑判断，排期有依据，责任有人承担，状态可比较，边界不混淆。推行一段时间后，还可以结合状态更新是否及时、变更记录是否完整做一次复盘，据此调整字段和更新频率。排期表的价值在于持续维护，设计阶段的检查只是起点。
常见问题
需求排期表里的“计划完成时间”应该按开发完成算，还是按可交付算？
建议按“需求达到可交付状态”来填，也就是包含测试验证通过的时间。如果只按开发完成填写，测试阶段的时间会被挤到计划之外，排期表看起来准时、实际交付却延后。具体做法是把测试介入时间作为排期评估的一部分，由测试角色在需求进入测试前确认验证节点，研发负责人据此给出可承诺的完成时间。团队也可以在表头说明中写明“已交付”的口径，避免不同角色理解不一致。
需求还没评估完，能不能先放进排期表？
可以放进表里，但状态应停留在“待评估”，工作量和计划时间留待补充，不占用具体排期。这样既保留了需求记录，又不会让未评估的需求挤占团队容量。判断标准是：只有优先级、计划时间和负责人三项齐全的条目才算完成排期。示例中的 REQ-104 就是这种处理方式，工作量和负责人待定，状态为待评估。
排期表由一个人统一维护，还是各角色分别更新？
建议按“信息谁最清楚、结果谁负责”分工更新，项目负责人负责整体排期和变更确认，并定期检查全表。集中由一人维护的问题是信息经过转述容易失真，状态更新也会滞后。分工更新时需要用统一的字段说明和状态口径约束，否则各角色填写标准不一致。负责人变更时，由原负责人在备注中说明交接原因，避免出现无人认领的条目。
排期表要不要记录迭代信息？和迭代计划怎么衔接？
排期表聚焦需求实现过程的排期与交付跟踪，迭代整体安排由迭代管理机制承载。两者衔接的方式是在排期表中保留状态或关联字段，让已排期需求能够对应到所属迭代，而不在排期表里展开迭代目标、容量分配和迭代评审等内容。这样排期表保持轻量，迭代层面的安排也不会被拆散到两张表里重复维护。
排期表推行一段时间后，怎么判断需不需要调整字段？
可以从两个观察点入手：一是状态更新是否及时，是否存在长期停留在同一状态且备注无说明的条目；二是变更记录是否完整，延期和调整能否追溯到原因。如果发现某类信息反复被写进备注，说明它值得独立成字段；如果某些字段长期为空且不影响判断，可以考虑改为选填或删除。调整后同步更新填写说明，并让团队确认新的口径。
