任务跟踪要回答两个问题：任务现在处于什么状态，下一步由谁做什么。支撑这两个判断的可核查信息，就是跟踪依据。本文聚焦单项任务的执行闭环，给出四类依据的清单、建立步骤、角色分工、填写示例和完成检查，帮助你把“凭印象报进度”变成“凭依据定状态”。
要点总览（TL;DR）
- 任务跟踪依据分四类：任务定义（目标、范围、验收标准、责任人）、计划（里程碑、依赖、时间基线）、执行证据（进展记录、产出物、评审结论）、变更与风险（范围调整、阻塞原因、决策记录）。
- 建立依据按五步推进：启动固化、计划记录、执行采集、变更留痕、检查确认，每步明确输入、动作、输出与完成标志。
- 依据由最接近事实的人提供，状态由对结果负责的任务负责人判断，跟踪组织者负责核对完整性与推动结论。
- 状态结论前按完整性、时效性、可核查性逐项检查；验收标准模糊、证据不覆盖当前进展、变更无决策人时应暂缓结论并补正。
- 依据支撑判断、判断引出行动、行动产生新依据，单项任务的执行闭环由此形成。
任务跟踪要盯住哪四类依据
跟踪依据的作用是让状态判断可以被复核。判断一条信息是否算依据，可以问三个问题：它是否指向具体任务、是否能被他人查看或验证、是否与当前时点相关。按这个标准，单项任务的跟踪依据可以分为四类。
四类依据的定义与作用
| 依据类型 | 包含内容 | 解决什么问题 |
|---|---|---|
| 任务定义依据 | 目标、范围、验收标准、责任人 | 确定“做成什么样算完成”，避免状态判断主观化 |
| 计划依据 | 里程碑、依赖关系、时间基线 | 提供对照基准，识别进度偏差和外部等待 |
| 执行证据 | 进展记录、产出物、评审或验收结论 | 验证进展的真实性，支撑“已完成”“可交付”等结论 |
| 变更与风险依据 | 范围调整、阻塞原因、决策记录 | 解释计划与现状的差异，保留决策链条 |
每类依据的最低可用形态
依据不追求详尽，但必须达到可用的下限。任务定义依据至少要有可判定的完成标准和明确的责任人；计划依据至少要有可对照的时间点或依赖项；执行证据至少要有可核查的产出或记录；变更与风险依据至少要有变更内容、原因和决策人。低于这个下限，跟踪就会退化为口头汇报。
依据缺失时的具体问题
- 缺少验收标准：状态只能靠感觉判断，“基本完成”与“完成”无法区分。
- 缺少时间基线：无法识别偏差，延期往往在截止日当天才暴露。
- 缺少执行证据：进展真实性无法验证，汇报与实际产出脱节。
- 缺少变更记录：范围悄悄扩大或收缩，相关方按旧预期行事而无人察觉。
按步骤建立单项任务的跟踪依据
依据不是跟踪时才去收集，而是在任务推进过程中逐步沉淀。下面五个步骤按时间顺序展开，每一步都明确输入、动作、输出和完成标志，便于对照执行。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 启动固化 | 任务来源、背景说明、相关方诉求 | 写清目标、范围边界、验收标准和责任人，与相关方确认 | 任务定义记录 | 责任人确认，验收标准可被第三方判定 |
| 2. 计划记录 | 任务定义记录、上下游安排 | 设定里程碑与关键时间点，标注依赖项及提供方 | 计划基线 | 每个时间点有对应交付内容，依赖项有明确对接人 |
| 3. 执行采集 | 计划基线、实际工作产出 | 按固定节奏记录进展、附上产出物或链接，标注与计划的差异 | 进展记录与产出证据 | 最近一次记录覆盖当前时点，产出可被查看 |
| 4. 变更留痕 | 变更请求、阻塞情况 | 记录变更内容、原因、影响范围和决策人；阻塞项写明卡点与解除条件 | 变更与阻塞记录 | 每项变更都有决策人和生效时间 |
| 5. 检查确认 | 前四步的全部记录 | 按检查清单核对完整性与时效性，形成状态结论 | 状态判断与下一步行动 | 结论有对应依据支撑，下一步行动有责任人和时间 |
第3步的采集节奏需要与任务周期匹配：周期短的任务按天或按完成节点记录，周期长的任务按周记录，并在关键里程碑前增加一次。记录内容以“做了什么、产出在哪、与计划差多少”为主，避免只写“进行中”。
第4步容易被忽略。变更发生时，除了改计划，还要保留原计划与调整原因，否则后续复盘无法解释偏差来源。阻塞项同样如此，写明卡在谁那里、解除条件是什么，跟踪时才能推动而不是重复询问。
第5步是闭环的收口。状态结论应当能追溯到具体依据，例如“已完成”对应验收结论，“延期”对应时间基线与当前进展的差距。下一步行动要落到具体的人和日期，否则闭环在判断之后就断了。
谁提供依据、谁判断状态：角色与交付物
跟踪变成单人汇总，通常是因为依据产生和状态判断的职责没有分开。合理的分工是：依据由最接近事实的人提供，状态由对结果负责的人判断，跟踪组织者负责核对与推动。
| 角色 | 职责 | 提供的依据 | 交付物 |
|---|---|---|---|
| 任务负责人 | 对任务结果负责，确认目标与验收标准，做出状态判断 | 任务定义依据、变更决策 | 任务定义记录、变更决策记录、状态结论 |
| 执行人 | 推进具体工作，如实记录进展 | 执行证据、阻塞情况 | 进展记录、产出物、阻塞说明 |
| 评审人 | 按验收标准检查产出 | 评审或验收结论 | 评审意见、验收结论 |
| 跟踪组织者 | 汇总依据、核对完整性、推动状态判断 | 不直接提供业务依据 | 跟踪记录汇总、缺失项提醒、待决事项清单 |
状态判断的决策权应归属对结果负责的角色，通常是任务负责人。跟踪组织者提供依据支撑和缺失提示，不替代负责人下结论。评审人的结论是“已完成”状态的关键证据，但验收是否通过、任务是否关闭，仍由负责人结合范围与计划综合判断。
当任务涉及多个执行人时，每位执行人对自己那部分进展和产出负责，负责人汇总后判断整体状态。这样分工可以避免跟踪组织者逐人追问，也避免负责人在缺少证据的情况下被迫表态。
依据的采集与状态交接如果分散在聊天记录和口头同步中，核对成本会明显上升。把任务定义、进展记录、变更说明和验收结论放在同一个工作项下，负责人判断状态时可以直接引用对应记录。ONES 的工作项可以承载任务信息与过程记录，适合作为这类依据的归集位置；具体字段与状态配置以团队实际使用为准。
一个任务跟踪依据的填写示例
以下为演示情景，用于说明四类依据如何落到一条任务的跟踪记录上。
任务背景：为内部知识库上线“文档检索”功能，计划两周内交付测试版本，由产品、开发、测试三方参与。
四类依据的填写内容
- 任务定义依据：目标为支持按标题和正文关键词检索；范围为知识库现有文档，不含附件内容；验收标准为十条预设查询中至少九条返回正确结果，响应时间在两秒内；责任人为开发负责人张某。
- 计划依据：里程碑为第5个工作日完成检索接口、第8个工作日完成页面联调、第10个工作日提交测试；依赖项为知识库文档索引由数据组李某在第3个工作日前提供。
- 执行证据：第5个工作日记录接口自测通过并附测试截图；第8个工作日记录联调完成，附联调问题清单及关闭情况；第10个工作日提交测试版本并附测试环境地址。
- 变更与风险依据：第6个工作日数据组索引延迟一天，记录阻塞原因、影响为联调顺延一天、决策人为项目负责人王某，决定压缩联调后的缓冲时间，里程碑整体不变。
依据如何支撑状态判断与下一步行动
到第10个工作日，负责人依据验收标准核对测试结果：十条查询中九条正确、响应时间达标，评审人给出通过结论，执行证据齐全，变更记录解释了联调顺延的原因且已消化。据此判断任务状态为“已完成”，并附验收结论作为支撑。下一步行动为将检索功能纳入版本发布清单，由测试人员在第12个工作日前完成回归确认。整个判断过程中，每条结论都能对应到具体记录，第三方可以按同样路径复核。
跟踪依据的完成检查
在给出状态结论前，按以下清单逐项核对。检查的目的不是追求材料齐全，而是确认依据足以支撑结论。
| 检查项 | 通过标准 |
|---|---|
| 四类依据是否齐备 | 任务定义、计划、执行证据、变更与风险记录均有对应内容，无整类缺失 |
| 验收标准是否可判定 | 标准具体到可被第三方按同一口径判断通过与否 |
| 时间基线是否可对照 | 存在明确的计划时间点，当前进展可与之比较 |
| 证据是否覆盖当前时点 | 最近一次进展记录与产出证据对应本次状态判断，无长时间空档 |
| 证据是否可核查 | 产出物、评审结论、决策记录可被他人查看，非仅口头说明 |
| 变更是否留痕 | 每项范围或时间调整都有内容、原因和决策人 |
| 结论是否可追溯 | 状态结论能指向具体依据，下一步行动有责任人和时间 |
出现以下情况时应暂缓状态结论：验收标准缺失或模糊、执行证据无法覆盖当前进展、变更未记录决策人、依赖项状态不明。补正动作对应为：由任务负责人补充或确认验收标准；由执行人补齐进展记录与产出物；由变更发起人补记原因与决策；由跟踪组织者向依赖方确认状态并记录结果。补正完成后再进入状态判断，避免在依据不足时形成无法复核的结论。
当检查项全部通过，跟踪可以收口：状态结论连同依据一并留存，下一步行动转入新的跟踪周期。单项任务的闭环由此形成——依据支撑判断，判断引出行动，行动又产生新的依据。
常见问题
任务周期很短，还需要按五步建立全部依据吗？
步骤可以压缩，依据不能整类缺失。周期一两天的任务，启动固化与计划记录可以合并成一条简短的任务说明，写清目标、验收标准和完成时间；执行采集按完成节点记录一次即可；变更与风险记录只在发生调整或阻塞时填写。检查确认仍然保留，用来说明状态结论对应哪条记录。判断标准是：第三方能否依据现有记录复核你的状态结论，能复核就够用。
任务负责人和跟踪组织者由同一人担任时，怎样避免状态判断失去复核？
同一人担任时，把判断依据写出来比口头结论更重要。状态结论要附上对应的验收结论、进展记录或时间基线对比，让评审人或上级可以按同样路径核对。涉及验收的任务，评审结论应由评审人独立给出，负责人只做综合判断。这样即使角色合并，依据的产生与结论的形成仍然可以分开追溯。
执行过程中发现原验收标准不合理，应该改标准还是保留原标准？
按变更处理，保留原标准并记录调整原因。具体做法是：写明原验收标准、调整后的标准、调整原因和决策人，再按新标准判断状态。直接改掉原标准会让后续复盘无法解释偏差来源，也会让已经按旧标准开展的工作失去对照基准。如果调整影响范围或时间，同步更新计划基线并通知相关方。
依赖项迟迟没有交付，任务状态应该怎么判断？
把依赖项状态作为阻塞依据单独记录，写明卡在哪个提供方、已等待多久、解除条件是什么，任务状态按实际可推进的部分判断。依赖未解除期间，状态结论应体现“受阻”而非“进行中”，并明确下一步是推动依赖方还是调整计划。依赖方给出新的交付时间后，更新计划基线并记录变更，避免用旧时间点继续对照。
依据记录分散在聊天工具和文档里，核对成本很高，有什么简化办法？
把同一任务的四类依据归集到一处，是降低核对成本最直接的做法。任务定义、进展记录、变更说明和验收结论放在同一个工作项或同一条跟踪记录下，状态判断时直接引用，不必跨工具检索。ONES 的工作项可以承载任务信息与过程记录，可作为这类依据的归集位置；具体字段与状态配置以团队实际使用为准。归集位置确定后，团队约定只在该处更新进展，聊天工具中的讨论结论回填到记录里。
