任务进度记录要回答四件事：任务当前处于什么状态、已经完成到什么程度、下一步谁在什么时候做什么、有没有阻塞需要谁处理。本文给出一份从启动到验收退回再重开的完整填写示例，逐项解释每个字段的写法，并说明换一个任务如何套用。示例中的状态、进展和阻塞字段，可以对应到ONES工作项上做持续跟踪。
要点总览（TL;DR）
- 一份可用的任务进度记录要同时回答四件事：当前状态、完成程度、下一步谁在何时做什么、有无阻塞及需要谁处理。
- 示例覆盖启动、进行中、受阻、逾期提醒、提交验收、验收退回、重开七次更新，可直接对照填写。
- 进展写产出而非动作，下一步带责任人和时间点，阻塞写卡点、影响、支持方和期望时间，验收退回引用具体完成标准条目。
- 记录频率随任务周期和风险调整，出现阻塞或逾期时提高记录密度，保证记录可交接。
- 示例适用于单项任务执行闭环，组织级流程规则、会议决议跟踪和长期无进展的升级流程需另行约定。
示例目标：这份进度记录要解决什么问题
本文使用一个演示情景：某产品团队要开发“订单导出”功能，任务涉及后端接口、前端页面和测试三个角色，计划从3月3日做到3月21日。任务在提交验收后被退回，修改后重新提交。这个情景为演示用途，不是真实客户案例，其中的日期、人名和完成比例均为虚构。
这份记录要支撑三个用途。第一是同步进展，让负责人、协作人和需求方在同一份记录里看到任务走到哪一步。第二是暴露阻塞，把卡点、影响范围和需要谁支持写清楚，避免问题停留在个人手里。第三是支撑验收，让验收人对照启动时写下的完成标准逐条判断，退回时也有明确依据。
记录范围限定在单项任务的执行闭环：从任务启动、日常更新、遇阻、逾期、提交验收、验收退回，到重开后的再次提交。组织级的流程规则配置、会议决议跟踪不在本文范围内。
完整示例：一条任务从启动到重开的进度记录
先填写任务基本信息，作为后续每次更新的固定背景。
| 字段 | 填写内容 |
|---|---|
| 任务名称 | 订单导出功能开发 |
| 负责人 | 李然（后端） |
| 协作人 | 周敏（前端）、陈凯（测试）、王璐（需求方） |
| 计划起止时间 | 3月3日—3月21日 |
| 完成标准 | 1. 支持按日期范围和订单状态导出，单次上限5万条；2. 导出文件字段与订单列表一致；3. 测试通过，需求方确认导出结果可用于对账 |
以下是按时间顺序的七次进度记录。
| 日期 | 状态 | 完成比例 | 本次进展 | 下一步 | 阻塞与支持 |
|---|---|---|---|---|---|
| 3月3日 | 已启动 | 0% | 与需求方确认导出范围和字段清单，完成接口设计初稿 | 李然3月5日前完成接口设计评审；周敏3月6日前确认页面交互稿 | 无 |
| 3月10日 | 进行中 | 40% | 导出接口开发完成，支持按日期和状态筛选；前端页面完成筛选区 | 李然3月13日前完成5万条数据的性能验证；周敏3月14日前完成导出按钮与进度提示 | 无 |
| 3月14日 | 受阻 | 55% | 性能验证发现5万条导出耗时超过2分钟，未达到可接受范围 | 李然3月17日前改为分批查询并复测 | 需要运维赵鹏在3月15日前开通测试环境的大文件存储权限，否则无法验证分批写入 |
| 3月18日 | 受阻（逾期提醒） | 60% | 分批查询改造完成，3万条导出耗时45秒；5万条场景仍待存储权限开通后复测 | 赵鹏3月18日当天处理权限申请；李然3月19日完成复测 | 存储权限申请已提交两天未处理，影响性能验收，升级至技术负责人张衡协调 |
| 3月20日 | 待验收 | 100% | 5万条导出复测通过，耗时1分20秒；测试用例全部执行完毕，无阻断缺陷 | 王璐3月21日前按完成标准逐条验收 | 无 |
| 3月21日 | 验收退回 | 80% | 需求方验收发现导出文件的订单状态显示为代码值，与订单列表的中文名称不一致，不满足完成标准第2条 | 李然3月24日前补充状态名称映射；陈凯3月25日前回归验证 | 无 |
| 3月25日 | 重开并再次提交验收 | 100% | 状态名称映射已补充，导出文件字段与订单列表逐项比对一致；回归测试通过 | 王璐3月26日前完成二次验收 | 无 |
这份记录的关键在于每次更新都能独立读懂：读者不需要翻看聊天记录，就能知道当前状态、已完成什么、接下来谁做什么、哪里卡住了。验收退回那次记录保留了退回原因和对应完成标准条目，重开后的更新也说明了针对退回原因做了什么修改。
逐项解释：每个字段为什么这样写
状态和完成比例是两个不同口径。状态描述任务处在哪个阶段，比如已启动、进行中、受阻、待验收、验收退回；完成比例描述可交付成果的完成度。示例中3月14日状态为受阻、比例55%，说明任务仍在推进但有关键卡点，比例反映的是已完成的工作量，两者并不矛盾。常见错误是受阻时把比例改成0%，或者待验收时直接写100%却在验收退回后仍保留100%。
进展要写产出，不写动作。“在推进导出功能”没有信息量；“导出接口开发完成，支持按日期和状态筛选”说明完成了什么、产出了什么。判断标准是：这句话能否让接手的人知道现在有什么可用、还缺什么。
下一步必须带责任人和时间点。“继续优化性能”无法跟踪；“李然3月17日前改为分批查询并复测”可以核对。下一步与本次进展成对出现，进展说明走到了哪，下一步说明往哪走，两者合起来才构成可交接的记录。
阻塞项要写清三件事：卡点是什么、影响什么、需要谁在什么时候支持。示例中“存储权限申请已提交两天未处理，影响性能验收，升级至技术负责人张衡协调”，卡点、影响、支持方和时间都具备。只写“有阻塞”或“等待协调”，其他人无法判断严重程度，也无法接手推动。
验收退回要写退回原因和对应标准。示例中退回原因指向完成标准第2条“字段与订单列表一致”，这样修改范围明确，重开后的验证也有对照。退回原因写得笼统，比如“不符合要求”，重开后就容易再次被退回。
| 字段 | 推荐写法 | 常见问题写法 |
|---|---|---|
| 状态 | 进行中、受阻、待验收、验收退回 | 用“正常”“差不多”等无法判断阶段的词 |
| 完成比例 | 按可交付成果估算，如55% | 受阻时归零，或凭感觉每次加10% |
| 本次进展 | 写完成的功能、产出的文档、通过的测试 | 只写“在推进”“处理中” |
| 下一步 | 动作＋责任人＋时间点 | 只写动作，不写谁做、何时完成 |
| 阻塞 | 卡点＋影响＋支持方＋期望时间 | 只写“有阻塞”“等协调” |
| 验收退回 | 退回原因＋对应完成标准条目 | 只写“不符合要求” |
可迁移规律：换一个任务怎么套用
记录频率随任务周期和风险调整。周期两周以内的任务，可以在启动、中途、提交验收三个节点各记一次；周期更长或依赖外部资源的任务，按周更新，遇阻时当天补记。示例中3月14日和3月18日两次记录间隔较短，就是因为出现了阻塞和逾期，需要提高记录密度。
进展与下一步成对出现，是保证记录可交接的基本要求。任何一次更新，如果只写了进展没写下一步，接手人不知道后续安排；只写下一步没写进展，读者不知道当前基础是什么。两者都写，记录才完整。
阻塞和逾期要指向具体人和具体动作。“需要支持”不是有效记录，“需要运维赵鹏在3月15日前开通存储权限”才是。逾期提醒同样要写清楚逾期的是哪个交付物、影响哪个后续节点、由谁协调。
完成标准在启动时写清，验收时逐条对照。示例的完成标准有三条，验收退回时直接引用第2条，修改和回归都围绕这一条展开。如果启动时只写“完成导出功能”，验收时双方对“完成”的理解容易不一致。
- 启动时写清完成标准，条目化，可逐条判断
- 每次更新同时写进展和下一步
- 下一步带责任人和时间点
- 阻塞写卡点、影响、支持方和期望时间
- 出现阻塞或逾期时提高记录频率
- 验收退回引用具体标准条目，重开时说明调整内容
适用边界：哪些情况不适合照搬这份示例
这份示例适用于单项任务的执行跟踪，覆盖状态、进展、阻塞、逾期、验收和重开。组织级的流程规则配置，比如状态字典如何定义、哪些状态转换需要审批，属于流程设计范畴，示例不涉及。
会议决议与行动项的落实跟踪也不在示例范围内。会议行动项通常需要单独的清单管理参会人、决议内容和完成期限，与单项任务的进度记录结构不同。
长期无进展的任务需要升级机制。示例只给出了升级触发点——存储权限申请两天未处理即升级至技术负责人——但没有展开升级后的处理流程。团队如果存在多级升级路径，需要另行约定。
不同团队的状态命名可以不同，有的用“处理中”，有的用“开发中”，关键是同一团队内口径一致，且状态能区分阶段。照搬示例中的状态名称而不统一口径，记录的可读性会打折扣。
把示例落到工具里：记录字段如何变成可跟踪的工作项
示例中的字段可以在ONES工作项上承载。任务名称、负责人、协作人和计划起止时间对应工作项的基本信息；状态和完成比例对应工作项的状态字段与进度字段，状态流转记录任务从启动到验收退回再到重开的路径。
每次进展更新以评论或更新记录的形式留在工作项上，按时间排列，交接和回溯时可以直接查看历史。验收退回对应状态回退，退回原因写在记录里，重开后的修改说明也留在同一处，形成完整的处理链条。
下一步中的责任人和时间点，可以形成待办或提醒，让协作人在约定时间前看到自己的动作。阻塞项写在记录中并指定支持方，配合逾期提醒，让卡点在被发现后有人跟进。这样，示例中的填写口径就转化为可查询、可提醒、可回溯的跟踪方式。
常见问题
任务进行中遇到阻塞，完成比例应该怎么填？
完成比例反映可交付成果的完成度，与状态是两个口径。任务受阻时，已完成的工作量仍然存在，比例按实际产出估算即可，不必归零。示例中3月14日状态为受阻、比例55%，说明接口和部分页面已完成，卡点在性能验证环节。把比例归零会让读者误以为工作推倒重来，也无法判断距离完成还有多远。
任务逾期后，进度记录需要补写哪些内容？
逾期记录要写清三件事：逾期的是哪个交付物、影响哪个后续节点、由谁协调处理。示例中3月18日的记录写明存储权限申请两天未处理、影响性能验收、升级至技术负责人协调。补写逾期记录时，把原计划时间和实际状态并列写出来，后续复盘时能看清延误发生在哪个环节。
验收退回后重开，原来的进度记录要保留还是重写？
建议保留原记录，在退回时新增一条记录说明退回原因和对应完成标准条目，重开后的更新接着往下写。这样处理链条完整，二次验收时验收人能看到第一次为什么退回、修改了什么。如果直接覆盖原记录，退回依据和修改范围都会丢失，容易在同一个问题上反复退回。
周期很短的任务也需要每次都写完整字段吗？
可以按任务周期和风险简化。周期两三天、单人完成的任务，启动时写清完成标准，完成时写一条进展和验收结果即可。涉及多人协作、外部依赖或验收环节的任务，建议保留状态、进展、下一步和阻塞四个字段，因为交接和验收都需要这些信息。简化的是记录次数，不是关键字段的口径。
不同团队状态名称不一样，记录还能互相看懂吗？
状态名称可以不同，关键是同一团队内口径一致，且状态能区分阶段。有的团队用“处理中”，有的用“开发中”，只要成员理解一致就不影响跟踪。跨团队协作时，可以在记录里补充一句当前阶段说明，比如“开发中，接口已完成、页面待联调”，让外部读者不依赖状态名称也能判断进度。
