跟踪需求实现进度，关键依据要能回答三件事：需求当前处在哪个实现环节、这个状态由谁在什么时间确认、下一步交接给谁。可落地的依据分为四类：需求基线与范围确认记录、任务与工作项状态数据、代码与构建等交付物证据、评审与变更记录。下文给出依据清单、从需求拆分到状态汇总的操作步骤、角色分工、一条需求的跟踪记录示例，以及判断依据是否够用的检查表。
要点总览（TL;DR）
- 需求实现进度跟踪的依据分四类：需求基线与范围确认记录、任务与工作项状态数据、交付物证据、评审与变更记录，分别回答做什么、做到哪、凭什么说做到了、谁确认过。
- 跟踪按拆分需求、定义状态口径、按节奏采集状态、识别偏差、记录处置五步执行，状态汇总以需求为对象而非以个人任务列表为对象。
- 需求负责人维护基线与变更，开发与测试更新状态并附证据，项目经理或跟踪人汇总核对；交接时点与交付物绑定，依据在流转中自然积累。
- 判断依据是否够用，看四类是否齐全、状态是否在核对周期内更新、口径是否一致、完成状态是否有可定位的证据支撑。
- 不看口头说明，仅凭记录就能回答需求处于哪个环节、由谁何时确认、下一步交接给谁，依据才算充分。
跟踪需求实现进度要准备哪几类依据
需求实现进度反映的是“需求从确认到可交付”的过程状态，单看任务完成百分比容易失真。把四类依据放在一起，才能同时回答状态是否真实、状态由谁确认、证据是否支撑结论。下表列出每类依据的用途、维护责任人与更新时点。
| 依据类别 | 回答的跟踪问题 | 典型内容 | 维护责任人 | 更新时点 |
|---|---|---|---|---|
| 需求基线与范围确认记录 | 要做的到底是什么，范围有没有变 | 需求描述、验收标准、优先级、范围变更说明 | 需求负责人 | 需求确认时建立；范围调整时同步更新 |
| 任务与工作项状态数据 | 需求拆成了哪些工作，各自进行到哪一步 | 子工作项、开发任务、测试任务及其状态、负责人、计划完成时间 | 开发、测试等任务执行人 | 任务开始、状态流转、完成时更新 |
| 交付物证据 | 状态声明有没有实物支撑 | 代码提交记录、构建与部署结果、测试执行记录、缺陷清单 | 开发、测试 | 提交代码、构建完成、测试执行后更新 |
| 评审与变更记录 | 关键节点是否经过确认，变更是否被批准 | 需求评审结论、设计评审意见、变更申请与审批记录、遗留问题 | 需求负责人牵头，评审参与人共同确认 | 每次评审或变更发生时记录 |
四类依据各有分工：基线与范围回答“做什么”，状态数据回答“做到哪”，交付物证据回答“凭什么说做到了”，评审与变更记录回答“谁确认过、改过什么”。缺少任何一类，进度判断都会出现盲区。例如只有状态数据而没有交付物证据，任务被标记完成但代码未合入的情况就无法识别；只有交付物而没有基线，也无法判断交付内容是否覆盖了确认过的范围。
维护责任要落到具体角色而不是“团队”。需求负责人对基线与变更记录负责，执行人对状态与证据的及时性负责，跟踪人负责汇总与核对。更新时点与动作绑定：状态变化即更新，评审结束即记录，构建或测试完成即附证据，避免集中补录导致记录失真。
从需求拆分到状态汇总的操作步骤
依据齐备之后，跟踪本身是一套固定动作：拆分、定口径、按节奏采集、识别偏差并处置。下表给出每个步骤的输入、动作、输出和完成标志，可按顺序执行。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 拆分需求 | 已确认的需求描述与验收标准 | 把需求拆成可独立跟踪的开发、测试等工作项，建立与需求的父子关联，明确每个工作项的负责人 | 需求下的工作项清单及关联关系 | 每个工作项都有负责人和计划完成时间，且能回溯到所属需求 |
| 2. 定义状态口径 | 团队现有的工作流程 | 约定状态名称、进入条件与流转规则，例如“开发中”指已开始编码，“已完成”指代码合入并通过自测 | 状态定义与流转规则说明 | 团队成员对每个状态的含义理解一致，状态变更条件可核对 |
| 3. 按节奏采集状态 | 工作项状态、交付物证据 | 按固定节奏（如每日或每周）收集各工作项状态，核对状态变化是否附有对应证据 | 需求层级的状态汇总视图 | 汇总结果能按需求查看各工作项当前状态与最近更新时间 |
| 4. 识别偏差 | 状态汇总、计划完成时间、基线 | 对比计划与实际，标记延期、停滞、范围外新增等工作项，判断对需求整体交付的影响 | 偏差清单 | 每项偏差都有明确描述、影响判断和责任人 |
| 5. 记录处置动作 | 偏差清单 | 与责任人确认处置方案（调整计划、补充资源、缩小范围等），记录决定与后续跟进时点 | 偏差处置记录 | 处置动作有负责人和复查时间，下次核对时可验证是否关闭 |
拆分环节要注意粒度：工作项应小到能在较短时间内完成并确认状态，过大则状态长期停留在“进行中”，跟踪失去意义；过细则增加维护成本。状态口径要在拆分之后、执行之前确定，否则同一状态在不同人手里含义不同，汇总数据无法比较。
状态汇总以需求为对象，而不是以个人或任务列表为对象。汇总时把需求下所有工作项的状态、证据和偏差放在同一视图里，才能判断需求整体处于设计、开发、测试还是待交付阶段。ONES 支持用子工作项拆解复杂需求并关联研发和测试任务，团队成员通过看板管理任务状态，需求、研发、测试各环节可以在同一体系内串联，便于按需求层级汇总进度。
各角色在跟踪中的分工与交付物
跟踪能否持续，取决于每个角色是否清楚自己产出什么记录、在什么时点交接。下表按角色列出职责、交付物和交接时点。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 需求负责人 | 维护需求基线与验收标准，受理并记录范围变更，确认需求是否具备进入实现的条件 | 需求说明、验收标准、变更记录 | 需求确认后交给开发与测试；范围变更批准后同步给跟踪人 |
| 开发 | 领取或拆分开发工作项，按口径更新状态，提交代码并附构建结果 | 开发工作项状态、代码提交记录、构建与自测结果 | 开发完成、提测时把工作项与证据交接给测试 |
| 测试 | 执行测试任务，更新测试状态，登记缺陷并跟踪修复验证 | 测试执行记录、缺陷清单、测试结论 | 测试完成后向需求负责人和跟踪人提交测试结果 |
| 项目经理或跟踪人 | 组织状态核对，汇总需求层级进度，记录偏差与处置动作，维护跟踪节奏 | 状态汇总、偏差清单、处置记录、跟踪例会结论 | 每次核对后向相关角色反馈偏差与待办，下次核对时复查 |
角色之间最容易断开的环节是交接：开发标记完成但未附构建或自测证据，测试无法判断能否开始；测试发现缺陷但未登记到需求关联的工作项，跟踪人汇总时看不到风险。把交接时点与交付物绑定，例如“提测时必须附构建结果和自测记录”，可以让跟踪依据在流转中自然积累，而不是事后追补。
在 ONES 中，需求、任务、测试与缺陷可以在同一流程内关联，业务与研发团队能跟踪需求和缺陷的处理进度，形成从需求到任务、测试、缺陷的闭环记录。跟踪人据此汇总状态时，依据来自同一套工作项数据，减少多头核对。
示例：一个需求的进度跟踪记录长什么样
以下为演示情景，用于说明依据如何组合使用，不对应真实项目数据。
基线与拆分。需求“订单导出支持按时间范围筛选”，验收标准为“导出文件包含所选时间范围内的全部订单，且单次导出不超过十万条时有明确提示”。需求负责人确认后，拆分为三个工作项：后端导出接口开发、前端筛选条件与提示、导出功能测试，分别指定负责人和计划完成时间。
状态更新与证据。开发工作项从“待开始”流转到“开发中”，完成后附代码提交记录与构建结果，状态改为“待测试”；前端工作项同步更新并附页面自测截图说明；测试工作项在提测后开始，执行记录登记了用例通过数与发现的缺陷。
偏差发现与处置。跟踪人按周核对时发现：测试工作项计划完成时间已过，状态仍为“测试中”，且缺陷清单中有一条“导出超时”缺陷未关闭。核对记录写明偏差描述、影响（需求整体交付延后）、责任人（后端开发）和处置动作（优化查询后重新提测），并约定下次核对时复查该缺陷状态。
跟踪结论写法。结论按“当前阶段—依据—风险—下一步”组织，例如：“需求处于测试阶段；开发与前端工作项已完成并附构建与自测记录；测试执行中，剩余一条超时缺陷待修复；预计交付时间顺延，待缺陷关闭后由需求负责人确认是否满足验收标准。”这样的结论每句都能对应到具体依据，便于复核。
完成检查：跟踪依据是否足够支撑判断
在依据用于进度汇报或决策之前，按下表逐项核对。任一项不通过，先补正再使用结论。
| 检查维度 | 检查项 | 不通过时的补正动作 |
|---|---|---|
| 完整性 | 四类依据是否都有：基线、状态数据、交付物证据、评审与变更记录 | 缺哪类补哪类；基线缺失先与需求负责人确认范围，证据缺失要求执行人补充 |
| 完整性 | 需求下每个工作项是否都有负责人和计划完成时间 | 补指派负责人，补齐计划时间或说明不设时间的原因 |
| 时效性 | 状态最近更新时间是否在约定的核对周期内 | 联系负责人确认实际状态并更新，长期未更新的工作项列为偏差 |
| 口径一致性 | 同一状态在不同工作项中的含义是否一致，是否符合约定的流转规则 | 按状态定义纠正错误状态，必要时在核对会上重申口径 |
| 可追溯性 | 每个“已完成”状态是否附有对应证据，证据能否定位到具体提交、构建或测试记录 | 要求补充证据；无法补充的，将状态回退为实际所处环节 |
| 可追溯性 | 范围变更和评审结论是否有记录、有确认人 | 补记变更内容与确认人；无法确认的变更暂不纳入基线，单独标注 |
| 判断支撑 | 偏差是否都有描述、影响判断、责任人和处置动作 | 逐条补齐；无法判断影响的，提交需求负责人评估后再记录 |
检查通过的标准是：不看口头说明，仅凭记录就能回答需求当前处于哪个环节、状态由谁在何时确认、下一步交接给谁。达到这个标准，跟踪依据才足以支撑进度判断和后续决策。
常见问题
需求实现进度跟踪和迭代进度跟踪有什么区别，依据能共用吗？
两者关注对象不同。需求实现进度跟踪以单条需求为对象，判断它从确认到可交付走到哪一步；迭代进度跟踪关注一个迭代周期内的整体安排与容量。依据可以部分共用：工作项状态、交付物证据、变更记录既服务于需求层级汇总，也服务于迭代视图。区别在于汇总口径，需求跟踪要求每条需求下所有工作项的状态与证据能合并成一条结论，迭代视图则按周期聚合多条需求。迭代整体排期不在本文范围内，可另按迭代管理的方法处理。
团队规模小、没有专职项目经理时，跟踪人角色怎么安排？
跟踪人不必是独立岗位，可以由需求负责人兼任，但要区分两种动作：维护需求基线属于需求负责人的职责，汇总状态、组织核对、记录偏差属于跟踪职责。兼任时建议把核对节奏固定下来，例如每周固定时间核对一次，并把偏差与处置写进同一条记录，避免自己跟踪自己时只报结论不报依据。团队规模扩大后再考虑把跟踪职责拆出，判断标准是需求数量是否已多到一个人无法在固定节奏内完成核对。
工作项状态更新不及时，汇总出来的进度还可信吗？
可信度会下降，但可以通过检查识别。核对时先看状态最近更新时间是否落在约定周期内，长期未更新的工作项直接列为偏差，联系负责人确认实际状态后再更新。若多个工作项集中补录，说明更新动作没有和状态变化绑定，需要重申“状态变化即更新”的规则。对关键节点，可以要求状态变更必须附证据，例如标记完成时附构建或测试记录，用证据倒推状态真实性。
需求范围中途变更，之前的跟踪记录要作废重来吗？
不需要作废，但要把变更单独记录并关联到原需求。做法是保留原基线与已有跟踪记录，新增一条变更记录，写明变更内容、提出人、确认人和对计划的影响，再把变更后的范围作为后续核对的基线。这样历史状态与证据仍可追溯，也能看出进度偏差是执行问题还是范围变化造成的。未经确认的变更暂不纳入基线，单独标注，避免范围悄悄扩大。
用工具承载跟踪记录时，重点看哪些能力？
重点看三件事：需求能否拆成子工作项并保持父子关联，状态流转是否有明确口径，变更与评审能否留痕。ONES 支持用子工作项拆解复杂需求并关联研发和测试任务，团队成员通过看板管理任务状态，需求、任务、测试与缺陷可在同一流程内关联，便于按需求层级汇总进度。选型时结合团队实际流程验证配置方式，具体版本与套餐能力以实际部署环境为准。
