任务跟踪要回答“进展如何、是否受阻、能否按期、是否完成”，靠的是可核查的记录。最小依据集包括任务定义、进展记录、阻塞与升级记录、逾期与催办记录、验收与退回记录五类，它们应在执行过程中同步产生，并与任务状态一一对应。
要点总览（TL;DR）
- 任务跟踪的最小依据集是五类记录：任务定义、进展记录、阻塞与升级记录、逾期与催办记录、验收与退回记录，每类对应一个具体判断。
- 依据要在任务生命周期中同步产生：创建时写清完成标准与验收人，执行中状态变更附说明，受阻时登记原因与解除条件，逾期时留下催办与处理结论。
- 任务负责人维护状态与进展，协作人提供分项交付物，验收人按完成标准给出结论，项目管理者核验依据完整性并处理升级。
- 验收退回要对应完成标准的具体条款，重开时保留原记录并衔接新一轮执行，形成可追溯的依据链。
- 用检查清单核对依据是否够用：四类判断均有记录、阻塞与逾期有处理结论、验收可回溯到完成标准，关键依据缺失时阻断关闭或升级处理。
任务跟踪依据的最小集合：五类记录对应五个判断
跟踪依据的价值在于支撑判断。记录本身不构成依据，只有当它能回答一个具体问题、并且可以被他人核查时，才算有效依据。以下五类记录构成任务跟踪的最小集合，缺少任何一类，都会让某一类判断失去事实基础。
| 依据类别 | 包含内容 | 支撑的判断 | 产生时点与责任人 |
|---|---|---|---|
| 任务定义 | 目标、负责人、截止时间、完成标准、验收人 | 这项任务要交付什么，什么算完成 | 创建任务时，由任务发起人或项目管理者填写 |
| 进展记录 | 状态变更时间、变更前后状态、变更说明 | 当前做到哪一步，进展是否符合预期 | 每次状态变化时，由任务负责人更新 |
| 阻塞与升级记录 | 阻塞原因、影响范围、解除条件、升级对象与时间 | 是否受阻，卡在哪里，谁来处理 | 发现阻塞时登记，升级时补充记录 |
| 逾期与催办记录 | 约定时间、提醒时间与方式、升级记录、逾期说明 | 能否按期完成，偏差是否已被处理 | 临期提醒与逾期处理时，由项目管理者或系统记录 |
| 验收与退回记录 | 验收人、验收结论、退回原因、重开记录 | 是否真正完成，未通过的原因是什么 | 提交验收与给出结论时，由验收人记录 |
五类记录之间存在依赖关系。完成标准是验收结论的比对基准，没有前者，后者只能凭主观判断；阻塞记录中的解除条件是判断任务能否恢复推进的前提；逾期说明则要引用原定截止时间才有意义。因此，依据不是孤立字段的堆叠，而是一组相互引用的记录。
需要区分事实记录与处理结论。阻塞登记中的“原因、影响范围”是事实，“升级给谁、何时解除”是处理动作；逾期记录中的“已超过约定时间三天”是事实，“调整计划或追加资源”是结论。两类内容都要保留，只记结论会让后续复盘失去线索。
按任务生命周期建立跟踪依据：从创建到关闭的操作步骤
依据要在任务执行过程中自然产生，事后补写会削弱可信度。把记录动作嵌入任务生命周期的各个阶段，可以让跟踪依据成为执行流程的副产品，而不是额外负担。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 创建 | 任务来源、交付要求 | 写清目标、负责人、截止时间、完成标准，指定验收人 | 完整的任务定义 | 负责人与验收人确认接受任务 |
| 执行 | 任务定义、工作计划 | 状态变更时附说明，按约定频率更新进展 | 带时间戳的进展记录 | 每次状态变化都有对应说明 |
| 受阻 | 执行中的问题信息 | 登记阻塞原因、影响范围、解除条件，明确升级路径 | 阻塞记录与升级记录 | 阻塞有明确责任人和预期解除时间 |
| 临期与逾期 | 截止时间、当前进展 | 临期提醒留痕，逾期后记录催办与升级 | 催办记录、逾期说明 | 逾期任务有处理结论或新的时间约定 |
| 完成 | 交付物、完成标准 | 提交验收，记录验收结论；退回时写明原因并重开 | 验收记录、退回与重开记录 | 验收通过并关闭，或退回后进入新一轮执行 |
创建阶段决定后续所有判断的基准。完成标准要写成可核对的条件，例如“接口文档覆盖全部字段并通过评审”，而不是“完成文档编写”。验收人应在创建时指定，避免任务做完才临时找人签字。
执行阶段的关键是状态变更必须附说明。只把状态从“进行中”改为“已完成”，无法说明完成了什么；附上交付物位置和自检结果，验收人才能据此判断。进展更新频率按任务周期约定，周期长的任务可以按周更新，临期任务适当加密。
受阻阶段要区分“登记阻塞”和“升级处理”两个动作。登记时写清原因、影响范围和解除条件；当阻塞超出负责人可处理的范围，按预设路径升级，并记录升级对象与时间。升级路径在任务创建时或团队规则中约定，避免临时找人。
临期与逾期阶段的催办要留痕。提醒的时间、方式、对象，以及被提醒方的回应，都是判断“偏差是否已被处理”的依据。逾期后应补充逾期说明，写明原因和后续安排，而不是只把截止时间往后改。
完成阶段以验收结论收尾。验收未通过时，退回原因要对应完成标准中的具体条款；重开任务时保留原记录，新增一轮执行记录，形成前后衔接而非覆盖。这样，一条任务的全部依据可以按时间顺序还原。
在工具层面，这些记录需要有承载位置。以 ONES 为例，任务或工作项可以记录负责人、截止时间与状态，状态流转和评论留下带时间的操作记录，验收环节可以通过工作项状态与评审意见记录结论。团队可以把阻塞原因、解除条件写成固定字段或评论模板，让登记动作有统一入口。具体字段配置和流转规则需结合团队实际设置确定。
角色与交付物分工：谁提供依据、谁核验依据
依据缺失往往不是没人记录，而是没人清楚自己该记什么。把五类记录分配到具体角色，并明确核验责任，才能让跟踪依据持续可用。
| 角色 | 主要动作 | 交付物 | 核验责任 |
|---|---|---|---|
| 任务负责人 | 维护任务状态，更新进展说明，发现阻塞时及时登记 | 状态变更记录、进展说明、阻塞登记 | 对记录的真实性和及时性负责 |
| 协作人 | 提供所负责部分的进展与交付物 | 分项进展说明、交付物 | 对提交内容与任务定义的对应关系负责 |
| 验收人 | 按完成标准给出验收结论，退回时写明原因 | 验收结论、退回原因 | 对结论与完成标准的一致性负责 |
| 项目管理者 | 核验依据完整性，处理催办与升级，维护跟踪节奏 | 催办记录、升级记录、跟踪检查结果 | 对跟踪依据的整体可用性负责 |
任务负责人是依据的主要生产者，但不应独自承担全部记录。协作人提交的分项进展，是负责人汇总状态的基础；验收人的结论，是任务能否关闭的最终依据。项目管理者不替代负责人记录，而是检查记录是否齐全、阻塞与逾期是否已有处理结论。
依据缺失时需要明确的处理规则。一般性缺失，例如进展说明过于简略，由项目管理者提醒负责人在约定时间内补充，并标注补录时间与原因。关键依据缺失，例如没有完成标准或没有验收结论，应阻断任务关闭，或提交升级处理，待补齐后再继续。补录记录要与原始记录区分，避免把事后补写的内容当作当时发生的事实。
示例：一条逾期任务的跟踪依据链
以下为演示情景，用于说明依据如何串成可追溯的链条。
任务创建。任务目标为“完成订单模块接口联调”，负责人为后端工程师，截止时间为某月20日，完成标准为“联调用例全部通过并输出联调报告”，验收人为测试负责人。任务定义记录完整，作为后续判断基准。
执行进展。12日状态由“待开始”改为“进行中”，说明为“完成接口定义核对”；16日更新进展“完成三个接口联调，剩余两个接口等待下游环境”，状态保持“进行中”。每次变更均带时间和责任人。
阻塞登记与升级。17日登记阻塞：原因为“下游环境未就绪”，影响范围为“剩余两个接口无法联调”，解除条件为“下游环境18日前可用”，升级对象为环境管理员。18日环境仍未就绪，记录升级：项目管理者将问题提交至周会协调，并记录协调结论。
催办与逾期说明。19日系统提醒临期，项目管理者发出催办并记录回应；20日任务未完成，登记逾期说明：原因引用阻塞记录，后续安排为“环境就绪后两日内完成联调”，新的时间约定同步更新至任务。
验收退回与重开。23日负责人提交验收，附联调报告；验收人核对完成标准后给出退回结论，原因为“两个接口的异常分支用例未覆盖”。任务重开，保留原验收记录，新增一轮执行记录；25日补充用例后再次提交，验收通过并关闭。
这条链条中，每个判断都能找到对应记录：是否受阻看阻塞登记，能否按期看催办与逾期说明，是否完成看验收结论，退回原因又能回溯到创建时的完成标准。记录之间通过时间和任务标识衔接，形成完整证据链。
完成检查：任务跟踪依据是否够用
判断依据是否够用，可以用一组检查项逐条核对。检查的对象是“能否支撑决策”，而不是“记录数量是否足够多”。
- 判断覆盖：当前进展、是否受阻、能否按期、是否完成四类判断，是否都能找到至少一条对应记录。
- 时间与责任人：每条记录是否带有产生时间和责任人，状态变更是否有变更前后对照。
- 阻塞闭环：阻塞记录是否写明原因、影响范围和解除条件，升级后是否有处理结论。
- 逾期闭环：逾期任务是否有催办记录和逾期说明，是否形成新的时间约定或处理决定。
- 验收可追溯：验收结论是否能对应创建时的完成标准，退回原因是否指向具体条款，重开是否保留原记录。
- 补录标注：事后补录的内容是否标注补录时间与原因，是否与原始记录区分。
- 缺失处理：关键依据缺失时，是否执行了阻断关闭或升级处理的规则。
通过标准可以设为：四类判断均有记录支撑，阻塞与逾期均有处理结论，验收结论可回溯到完成标准。任何一项不满足，都应先补齐依据再做出关闭、延期或升级决定。对于周期较长或跨团队的任务，可以在每周跟踪检查中抽取部分任务核对上述条目，及时发现记录断点。
依据体系不需要一开始就覆盖所有细节。先从五类记录的最小集合做起，在任务创建时把完成标准写清楚，在执行中坚持状态变更附说明，在阻塞和逾期时留下处理结论，跟踪就有了可靠的事实基础。随着团队对记录口径形成共识，再逐步细化字段和检查频率。
常见问题
任务周期很长，进展记录按什么频率更新才够用？
更新频率按任务周期和风险程度约定，没有统一标准。周期在一个月以上的任务可以按周更新，临期两周内适当加密；跨团队协作或依赖外部环境的任务，可以在关键节点前后各增加一次更新。判断频率是否够用的标准是：两次更新之间，跟踪者能否据此判断任务仍在推进、是否出现偏差。如果更新间隔内发生了状态变化却没有记录，说明频率偏低。
任务负责人自己登记阻塞，又由自己判断能否解除，这样合理吗？
负责人登记阻塞事实是合理的，因为他最先发现问题；但阻塞是否解除、是否需要升级，通常需要更高一层或相关方确认。可以把动作拆开：负责人记录阻塞原因、影响范围和预期解除条件，项目管理者或升级对象确认解除条件是否成立。这样既保留了第一手事实，也避免负责人单方面判断导致风险被低估。团队规模较小时，可以由项目管理者兼任确认角色。
验收退回后重开任务，原来的记录要保留还是新建一条任务？
两种做法都可以，关键是不覆盖原记录。保留原任务并重开，可以在同一任务下看到完整的退回原因、补充动作和再次验收结论，追溯链条更连续；新建任务则需要在两条任务之间建立关联，说明前一次退回的原因。选择哪种方式取决于团队的任务管理习惯和工具支持，但退回原因、重开时间和新一轮执行记录都应完整保留。
事后补录的进展记录还有参考价值吗？
有参考价值，但要与原始记录区分。补录时应标注补录时间和补录原因，说明内容对应的是哪个时间点发生的事实。补录记录可以帮助还原过程，但在判断“当时是否及时发现问题”时，不能把补录时间当作原始发生时间。对于关键决策，例如延期、升级或关闭，应优先依据当时产生的记录；补录内容作为补充说明使用。
小团队任务不多，五类依据都要完整记录吗？
可以从最小集合起步，但不宜省略完成标准和验收结论这两项。任务定义中的完成标准决定了后续判断基准，验收结论决定任务能否关闭，缺少这两项，跟踪容易变成凭印象判断。进展记录、阻塞记录和催办记录可以先采用简化的评论或说明形式，随着任务数量和协作复杂度增加，再逐步细化字段和检查频率。
