需求交付进度表要回答四个问题：谁在做、做到哪、何时交付、卡在哪。设计时先定字段和状态口径，再规定更新节奏与责任人，最后用一条真实需求走通全流程。这张表只覆盖需求实现过程，迭代整体排期由迭代管理承接，验收结论由验收闭环环节承接，边界要在表头写清。
要点总览（TL;DR）
- 进度表以“一条需求一行”组织，字段按需求标识与来源、责任角色、计划节点、状态与阻塞、交付证据五类裁剪，每个字段都要对应一个使用动作。
- 状态口径要写明进入条件、离开条件与唯一更新责任人，延期按计划日期与实际完成日期比较判定，阻塞须写清依赖对象。
- 设计按五步落地：明确表要回答的问题、确定字段与状态口径、选定承载方式建表、导入在途需求试填一周、固定更新节奏与评审时点。
- 更新责任按环节分配：开发与测试更新各自节点，需求负责人核对整行一致性，交付负责人汇总延期与阻塞清单并推动解决。
- 用一条真实需求走通状态流转后再正式使用，并逐项核对字段覆盖、状态唯一性、更新节奏、延期可导出与边界清晰。
进度表先定字段：一条需求一行要写什么
进度表以“一条需求一行”为基本结构，字段按五类组织：需求标识与来源、责任角色、计划节点、状态与阻塞、交付证据。字段不是越多越好，每一列都应当对应一个使用动作——有人填、有人看、有人据此做判断。填了没人用的字段应删掉，否则只会增加维护负担并降低更新意愿。
下表给出可直接套用的字段清单。填写人一栏写角色而非姓名，人员变动时只需换人，不必改表结构。
| 字段名 | 填写人 | 取值规则 | 是否必填 |
|---|---|---|---|
| 需求编号 | 需求负责人 | 沿用需求池或工单系统的唯一编号，不另起编号 | 必填 |
| 需求名称 | 需求负责人 | 一句话说明交付内容，避免只写模块名 | 必填 |
| 提出方 | 需求负责人 | 业务方、客户或内部团队，写具体部门或角色 | 必填 |
| 优先级 | 需求负责人 | 按团队既有分级填写，如P0/P1/P2，并注明分级依据 | 必填 |
| 产品负责人 | 需求负责人 | 对需求范围与验收标准负责的人 | 必填 |
| 开发负责人 | 开发负责人 | 对开发完成与提测质量负责的人 | 必填 |
| 测试负责人 | 测试负责人 | 对测试执行与测试结论负责的人 | 必填 |
| 计划开始 | 需求负责人 | 与迭代排期对齐的日期，精确到日 | 必填 |
| 计划提测 | 开发负责人 | 开发自测通过、可交付测试的日期 | 必填 |
| 计划上线 | 需求负责人 | 对外可用的日期，含发布窗口约束 | 必填 |
| 当前阶段 | 当前环节负责人 | 从统一状态清单中取值，不允许自由填写 | 必填 |
| 阻塞原因 | 当前环节负责人 | 仅在阻塞时填写，写清依赖对象与等待事项 | 阻塞时必填 |
| 下一步动作 | 当前环节负责人 | 一句话写明下一个动作与责任人 | 必填 |
| 提测记录 | 开发负责人 | 提测单或测试环境部署记录链接 | 提测后必填 |
| 上线记录 | 开发负责人 | 发布单或变更记录链接 | 上线后必填 |
| 验收结论 | 产品负责人 | 验收单链接，结论本身在验收环节维护 | 上线后必填 |
交付证据字段只放链接，不复制内容。进度表的价值在于指向证据，验收结论的正文留在验收记录里，避免同一结论在两处维护、两处不一致。
状态口径怎么统一：从待排期到已上线的阶段划分
同一状态在不同角色手里含义不同，是进度表失效最常见的原因。开发认为“快提测了”，测试认为“还没收到”，表上却都写着“开发中”。解决办法是给每个状态写明进入条件和离开条件，并指定唯一更新人。
| 状态 | 进入条件 | 离开条件 | 更新责任人 |
|---|---|---|---|
| 待评估 | 需求已登记，尚未确认范围与价值 | 完成评估并给出优先级 | 需求负责人 |
| 已排期 | 优先级确认，已进入某个迭代或交付批次 | 开发开始动工 | 需求负责人 |
| 开发中 | 开发已领取任务并开始编码 | 开发自测通过并提交提测 | 开发负责人 |
| 待提测 | 开发完成，等待提测材料或环境就绪 | 提测记录已登记 | 开发负责人 |
| 测试中 | 测试已接收提测版本并开始执行用例 | 测试结论给出，缺陷处理完毕 | 测试负责人 |
| 待上线 | 测试通过，等待发布窗口 | 上线记录已登记 | 开发负责人 |
| 已上线 | 版本已发布到目标环境 | 验收结论登记后归档 | 需求负责人 |
状态更新遵循“谁交付、谁更新”的原则：开发提交提测时把状态改为待提测并附提测记录，测试接收后改为测试中。需求负责人对整行状态的一致性负责，发现状态与证据不符时要求对应角色更正。
延期与阻塞要分开判定。延期指当前日期已超过某个计划节点而该节点未达成，判定依据是计划日期与实际完成日期的比较，不需要人工判断。阻塞指需求无法按计划推进且原因在当前责任角色之外，例如等待外部接口、等待环境或等待决策，必须在阻塞原因中写明依赖对象。只有阻塞原因填写完整，进度表才能支撑推动动作，否则“卡住了”只是一句无法跟进的话。
设计步骤：从字段到可用表格的落地顺序
设计进度表按五步推进，每步都有明确产出，避免一开始就陷入工具配置。
- 明确表要回答的问题与使用场景。输入是当前交付跟踪中的具体困扰，例如“周会上说不清哪些需求会延期”。动作是列出表需要支撑的判断，如识别延期、定位阻塞、核对交付证据。输出是一页问题清单。完成标志是每个字段都能对应到清单中的至少一个问题。
- 确定字段与状态口径。输入是上一步的问题清单。动作是按五类字段裁剪出字段表，并逐条写明状态的进入、离开条件与更新人。输出是字段定义表与状态流转规则。完成标志是团队能对同一条需求给出相同的状态判断。
- 选定承载方式并建表。输入是字段表与状态规则。动作是选择表格工具或研发管理工具建表。选型看三点：状态能否按规则流转、权限能否区分填写与查看、能否按责任人或计划日期汇总视图。输出是可录入的空表。完成标志是字段、取值选项与状态清单配置完毕，且与规则文档一致。
- 导入在途需求并试填一周。输入是当前正在交付的需求清单。动作是逐条补全字段，按真实节奏更新状态，记录试填中出现的口径分歧。输出是一周的实际数据与问题记录。完成标志是至少一条需求走完一个状态流转，且分歧点已形成修订意见。
- 固定更新节奏与评审时点。输入是试填记录。动作是确定日常更新责任与固定评审安排，把评审中要看的视图固化下来。输出是更新与评审约定。完成标志是下一次评审能直接使用表中的数据，无需会前临时收集。
承载方式的选择直接影响维护成本。表格工具上手快，适合需求数量少、角色集中的团队，但状态靠人工填写，容易出现口径漂移。研发管理工具把需求、任务、测试与缺陷放在同一体系内流转，状态随工作项推进而变化，汇总视图也可按责任人、计划日期直接生成。以ONES为例，其统一的需求池、工单与任务看板可实时同步状态与信息，并支持按实际场景自定义工作流，团队把前面定好的状态口径配置进去后，需求从排期到上线的流转就有了一致的承载；对于功能复杂的需求，还可以用子工作项拆解并关联研发与测试任务，把各环节串在同一条需求下。选型时以状态流转、权限与汇总视图三项需求为准，不必追求功能数量。
角色与交付物：谁填、谁看、谁负责推进
进度表无人维护，通常不是态度问题，而是职责没有落到具体动作上。下表把每个角色的动作、频率与产出写清楚，可以直接作为团队约定。
| 角色 | 动作 | 更新频率 | 交付物 |
|---|---|---|---|
| 需求负责人 | 维护需求标识、优先级与计划节点；核对整行状态与证据一致；登记验收结论链接 | 状态变化时即时更新，每周复核一次 | 准确的需求行与计划日期 |
| 开发负责人 | 更新开发中、待提测、待上线状态；登记提测记录与上线记录；填写开发侧阻塞原因 | 每次提测、上线时更新 | 提测记录、上线记录 |
| 测试负责人 | 接收提测后更新为测试中；测试完成后给出结论并推动缺陷处理 | 每日更新测试进展 | 测试结论与缺陷处理情况 |
| 项目经理或交付负责人 | 汇总延期与阻塞清单；组织阻塞问题的协调；在评审中对照计划与实际 | 每周汇总一次，评审前复核 | 延期清单、阻塞清单与协调结论 |
| 管理层 | 按固定节奏查看汇总视图，关注整体交付风险与资源冲突 | 按周或按迭代 | 风险判断与资源调整决定 |
更新频率要与评审时点对齐。若每周一次交付评审，则关键状态应在评审前一日完成更新，评审中只看表、不临时补数据。日常更新由各环节负责人完成，汇总与推动由交付负责人承担，两者分开，避免一个人既填表又催表。
示例：一条需求在进度表里的完整记录
以下为演示情景，用于说明字段填写与状态推进方式，不代表真实项目数据。
需求“订单列表支持按交付状态筛选”，编号REQ-1042，提出方为客服部，优先级P1，产品负责人为产品经理A，开发负责人为开发B，测试负责人为测试C。计划开始3月3日，计划提测3月10日，计划上线3月17日。
- 3月3日，状态由已排期改为开发中，开发B更新，下一步动作为完成接口开发。
- 3月10日，开发B提交提测并登记提测记录，状态改为待提测，随后测试C接收，状态改为测试中。
- 3月12日，测试C填写阻塞原因：“筛选字段依赖订单服务新接口，对方排期未确认”，下一步动作为交付负责人协调接口排期。状态保持测试中，阻塞标记生效。
- 3月13日，接口排期确认，阻塞原因关闭并记录解除说明，测试继续执行。
- 3月16日，测试通过，状态改为待上线；3月17日发布，开发B登记上线记录，状态改为已上线。
- 3月18日，产品经理A完成验收，登记验收结论链接，该行归档。
这条记录体现了三个要点：状态每次变化都有对应角色和证据；阻塞原因写清了依赖对象而非笼统描述；验收结论只放链接，结论正文留在验收记录中。计划上线3月17日与实际一致，若实际晚于计划，该行会自动进入延期清单，无需额外标注。
完成检查：这张表能不能支撑交付跟踪
表格设计完成后，用下表逐项核对。任一项不通过，先修订再投入使用。
| 检查项 | 通过标准 |
|---|---|
| 字段覆盖度 | 责任、计划、状态、阻塞、证据五类信息均有对应字段，且每个字段都有明确填写人 |
| 状态唯一性 | 状态取值来自固定清单，每个状态有进入与离开条件，且有唯一更新责任人 |
| 更新节奏 | 日常更新责任已分配到角色，关键状态在评审前一日完成更新，评审中不临时补数 |
| 延期可导出 | 能按计划日期与实际完成情况筛出延期需求，形成可直接用于评审的清单 |
| 边界清晰 | 表头或说明中写明本表只覆盖需求实现过程，迭代整体排期与验收结论分别由对应环节承接 |
| 试填验证 | 至少一条真实需求完整走过一次状态流转，试填中发现的口径分歧已修订 |
最后一项常被忽略。没有经过真实需求验证的表，字段和状态往往停留在设想层面，投入正式使用后才发现口径冲突。用一条在途需求试填一周，比在会议上讨论字段更有效。
常见问题
需求数量不多、团队规模小，还需要专门做这张进度表吗？
需求数量少、角色集中的团队，用一张结构清晰的表格就够用，重点是把字段和状态口径定下来，不必追求工具复杂度。表格工具上手快，但状态靠人工填写，需要有人定期核对，否则容易出现同一需求在不同人手里状态不一致。团队规模扩大、需求与测试缺陷需要联动时，再考虑把进度表迁到研发管理工具中承载。
需求中途变更范围或计划日期，进度表怎么记录才不混乱？
计划日期变更时，直接更新计划字段，并在评审记录或备注中写明变更原因与确认人，保留变更痕迹即可，不必在表内另设多列历史日期。范围变更影响交付内容时，同步修改需求名称与验收标准链接，并重新确认计划提测与计划上线日期。关键是变更后由需求负责人复核整行状态与证据是否仍然一致，避免计划已改、状态还停在旧节点。
进度表和迭代看板同时存在，状态以哪个为准？
两者服务的问题不同：进度表跟踪单条需求从排期到上线的实现过程，迭代看板服务于迭代内的任务推进与每日对齐。可行的做法是明确单一数据源，若在研发管理工具中承载，需求状态随工作项推进自动变化，进度表视图直接读取，不再手工二次维护；若用独立表格，则约定以进度表为交付跟踪口径，看板状态变化后由对应角色同步到表中。无论哪种方式，都要避免两处各自更新、结论不一致。
阻塞解除后，原来的阻塞原因要删掉吗？
建议保留阻塞记录并补充解除说明与解除日期，而不是直接清空。保留记录便于复盘哪些依赖最常造成等待，也便于在评审中说明延期原因。若表内只设一列阻塞原因，可在解除时改为“已解除：原依赖事项＋解除日期”，或把历史阻塞移入备注字段。关键是当前是否仍阻塞要一眼可辨，历史信息不干扰当前判断。
验收结论为什么只放链接，不直接写进进度表？
验收结论的正文属于验收与闭环环节，涉及验收标准、遗留问题和闭环处理，内容会持续更新。进度表只承担指向作用，放链接可以避免同一结论在两处维护、两处不一致。若团队希望快速浏览结论，可在表中增加一列简短结论状态（如通过、有条件通过、未通过），详细内容仍以验收记录为准。
