任务进度记录要回答的是“谁在什么时候把任务推进到什么程度、依据是什么”。一份可用的记录至少保留六类信息：任务标识与目标、当前状态与完成比例、责任人与协作人、计划与实际时间、本次进展与下一步、阻塞与决策依据，并附上更新人和更新时间。记录以状态变化为主要触发点，每次更新写清变更内容，让执行轨迹可以追溯。
要点总览（TL;DR）
- 任务进度记录至少保留六类信息：任务标识与目标、当前状态与完成比例、责任人与协作人、计划与实际时间、本次进展与下一步、阻塞与决策依据，并附更新人和更新时间。
- 记录以状态变化为主要触发点，执行期间按任务周期补充进展；状态变化、阻塞出现、目标调整三类事件发生时即时更新，不受固定周期约束。
- 责任人维护整体状态与进展，协作人只补充自己承担的部分，验收人记录验收依据与结论，避免多人同时改动状态造成口径混乱。
- 进展说明写到产出物或可核对的事实上，阻塞记录包含上报对象与解除时间，关闭记录区分完成与验收并交代遗留事项去向。
- 关闭前用字段完整性、时间与状态一致性、进展可验证性、阻塞与决策可追溯、更新留痕、归档可查阅六项逐条核对。
一份合格的任务进度记录包含哪些字段
字段设计的目标是让一个不了解任务背景的人，读完记录就能判断任务当前处在什么位置、为什么停在这里、接下来由谁做什么。字段不必多，但每一条都要能支撑判断。下表给出可直接套用的字段清单，其中“必填”指任何任务都应保留，“选填”指按任务复杂度决定是否启用。
| 字段名 | 填写要求 | 是否必填 |
|---|---|---|
| 任务标识与目标 | 唯一编号或标题，加一句可判断完成与否的目标描述，写清交付物和验收对象 | 必填 |
| 当前状态 | 从团队约定的状态集合中选择，如未开始、进行中、阻塞、待验收、已完成、已关闭 | 必填 |
| 完成比例 | 按可核对的交付物估算，如“3 个模块完成 2 个”；不要求精确到百分比，但要能对应实际产出 | 选填 |
| 责任人 | 一名对结果负责的人，写姓名而非仅写岗位 | 必填 |
| 协作人 | 参与执行或需要知会的人，注明各自承担的部分 | 选填 |
| 计划时间 | 计划开始与计划完成日期，作为偏差判断的基准 | 必填 |
| 实际时间 | 实际开始、实际完成日期，以及最近一次更新的时间 | 必填 |
| 进展说明与下一步 | 本次完成了什么、产出了什么、下一步做什么、预计何时完成 | 必填 |
| 阻塞项 | 阻塞内容、影响范围、上报对象、预计解除时间、实际解除时间 | 选填（发生时必填） |
| 决策记录 | 影响任务走向的关键决定，写清决定内容、决定人和依据 | 选填（发生时必填） |
| 更新人与更新时间 | 每次更新自动或手动记录，不允许事后补填成他人 | 必填 |
几处容易写空的字段值得单独说明。目标描述要写成“完成什么、交给谁、达到什么标准”，避免只写“优化登录流程”这类无法判断结束的表述。进展说明要落到产出物或可观察的事实上，例如“接口联调完成 4 个，剩余 2 个待对方环境就绪”，比“进展顺利”更有判断价值。阻塞项一旦出现就转为必填，并且要记录解除时间，否则事后无法区分“卡了两天”和“当天就解决了”。
完成比例与状态存在重叠，实践中建议二者择一作为主口径：状态用于流转判断，完成比例用于汇报沟通。若两者同时保留，需要保证比例变化与状态切换不矛盾，例如状态已进入待验收，比例就不应停留在 50%。
按任务阶段记录：从开始到关闭的操作步骤
字段确定后，记录动作要落到任务执行闭环的各个节点上。每个节点都有明确的输入、动作、输出和完成标志，避免“想起来才补一句”。
| 节点 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 任务创建 | 需求说明、交付要求、排期约定 | 填写标识与目标、责任人、计划时间，状态置为未开始 | 初始记录 | 目标可判断完成与否，责任人已确认 |
| 开始执行 | 初始记录、启动条件 | 状态改为进行中，记录实际开始日期与首个下一步 | 首条进展记录 | 实际开始时间已填，下一步有明确动作 |
| 执行中更新 | 阶段性产出、进度变化 | 按节奏补充进展说明，产出物有变化时更新完成比例 | 若干条进展记录 | 每条记录含时间、更新人、可核对的事实 |
| 状态变更 | 阶段完成或条件变化 | 切换状态并写明变更原因，跨阶段时同步下一步 | 状态变更记录 | 状态与进展说明一致，无跳步 |
| 阻塞上报 | 无法自行解决的外部依赖 | 状态改为阻塞，填写阻塞内容、影响范围、上报对象与预计解除时间 | 阻塞记录 | 上报对象已知悉，解除条件明确 |
| 阻塞解除 | 依赖方反馈或问题解决 | 记录解除时间与解决方式，状态恢复为进行中 | 解除记录 | 阻塞时长可计算，后续计划已调整 |
| 完成与验收 | 交付物、验收标准 | 状态改为待验收，附交付物位置；验收人确认后改为已完成 | 完成记录与验收结论 | 验收人、验收时间、结论齐全 |
| 关闭归档 | 完成记录、遗留事项 | 状态改为已关闭，写明遗留问题与后续归属 | 归档记录 | 记录只读可查，遗留事项有承接人 |
创建阶段最容易被省略，但它决定了后续记录是否有基准。计划时间、责任人和目标描述三项在创建时就应确定，后续更新才有对照物。执行中的更新不必每次写长文，一条记录讲清“做了什么、结果如何、下一步”即可，关键是保持连续，避免出现两周空白后再补一段概括。
阻塞环节需要单独强调。上报时写清影响范围，是为了让接收方判断优先级；记录预计解除时间，是为了在超期时触发再次跟进。解除时补上解决方式，能让同类问题在后续任务中被提前识别。
完成与关闭是两个动作。完成指交付物已产出，关闭指验收结论已确认、遗留事项已安排。把两者合并会导致验收意见无处记录，也会让未处理的遗留问题随任务一起消失。归档后记录应保持可查阅，供复盘和交接使用。
在工具层面，这类记录通常由工作项承载：状态字段对应流转，进展说明以评论或更新日志形式累积，附件存放交付物，更新人和时间由系统自动留痕。以 ONES 为例，工作项的状态流转与操作记录可以保留每次变更的时间和操作人，任务相关的说明文档也能与工作项关联，便于在关闭后按任务回溯完整过程。具体字段配置需结合团队实际状态集合调整。
谁在什么时候更新：角色分工与更新节奏
记录流于形式，多半是因为职责不清：责任人在等协作人同步，协作人在等责任人汇总，最后谁都没写。把更新动作分配到具体角色，并给出频率下限，记录才能持续。
| 角色 | 记录职责 | 更新时点 |
|---|---|---|
| 任务责任人 | 维护状态、完成比例、进展说明与下一步；发起阻塞上报；提交完成记录 | 状态每次变化时立即更新；执行期间按约定周期补充进展 |
| 协作人 | 补充自己承担部分的进展与产出，回复与自身相关的阻塞信息 | 完成自己负责的环节时更新；被点名确认时回复 |
| 评审或验收人 | 确认验收结论，记录通过或不通过的理由与整改要求 | 收到待验收通知后一个工作周期内给出结论 |
| 任务发起人 | 确认目标与验收标准，对目标变更作出决定并留痕 | 创建时确认；目标调整时更新决策记录 |
协作人的更新边界需要明确：只写自己承担部分的进展，不改动整体状态和完成比例，避免多人同时改状态造成口径混乱。责任人负责汇总，把协作人的进展合并进整体说明。验收人的确认动作本身就是一条记录，写清验收依据和结论，比只把状态改成已完成更有价值。
更新频率按任务周期和风险确定，可以参照以下分档：周期在一周以内的任务，每日或每次有产出时更新；周期在一个月左右的任务，至少每周更新一次，关键节点当日更新；周期更长或跨团队依赖多的任务，每周更新并额外在里程碑节点做一次完整回顾。风险高的任务（对外交付、有硬性截止日期、依赖外部环境）应缩短间隔，并在阻塞出现时即时上报，不等到固定更新日。
频率是下限而非上限。状态变化、阻塞出现、目标调整这三类事件不受周期约束，发生时即更新，否则记录会与实际进度脱节。
填写示例：一条任务从创建到关闭的完整记录
以下为演示情景，用于说明字段如何逐次填写，不对应真实项目。
任务背景与目标：为内部报销系统增加发票批量导入功能，交付给财务团队使用，验收标准为支持一次导入 50 张发票且错误提示可定位到具体行。
创建时的初始记录：任务标识“报销系统-发票批量导入”；目标按上述验收标准填写；状态未开始；责任人张明；协作人李华负责导入模板设计；计划开始 3 月 3 日，计划完成 3 月 21 日；更新人张明，更新时间 3 月 1 日。
第一次执行中更新（3 月 5 日）：状态进行中；实际开始 3 月 3 日；完成比例按“解析、校验、错误提示三个模块完成 1 个”记录；进展说明“解析模块完成，支持 Excel 与 CSV 两种格式，已用 20 张样例发票验证”；下一步“完成校验模块，3 月 10 日前”；更新人张明。
阻塞与解除（3 月 11 日）：状态改为阻塞；阻塞内容“校验规则需财务确认金额精度与重复发票判定口径”；影响范围“校验模块无法定稿，可能影响 3 月 21 日完成日期”；上报对象财务王蕾；预计解除 3 月 13 日。3 月 12 日财务确认口径，记录解除时间 3 月 12 日、解决方式“按财务书面确认的规则执行”，状态恢复进行中，计划完成日期不变。
第二次执行中更新（3 月 17 日）：完成比例“三个模块完成 2 个，错误提示开发中”；进展说明“校验模块完成，覆盖金额精度与重复发票两类规则，测试用例 15 条通过 14 条，1 条待修复”；下一步“修复剩余用例并完成错误提示，3 月 20 日提交验收”；更新人张明。
关闭时的结论与证据（3 月 21 日）：状态已完成并关闭；实际完成 3 月 20 日；验收人王蕾，验收结论“通过，50 张批量导入测试成功，错误提示可定位到行”；交付物为功能说明文档与测试记录，存放于任务附件；遗留事项“CSV 大文件导入性能待优化，转由下季度技术优化任务承接”；更新人张明，更新时间 3 月 21 日。
这条示例体现了几个要点：每次更新都有时间和更新人；进展说明带具体数量和验证方式；阻塞记录包含上报对象与解除时间；关闭记录区分完成与验收，并交代遗留事项去向。
记录质量检查：完成前逐项核对
记录写完不等于合格。以下检查项用于任务关闭前逐项核对，也可在周度回顾时抽查进行中的任务。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 字段完整性 | 必填字段无空缺；阻塞与决策发生时对应字段已填写 | 任务责任人 |
| 时间与状态一致性 | 实际开始不晚于首次进行中记录；状态切换顺序合理；完成日期与验收时间不矛盾 | 任务责任人 |
| 进展描述可验证 | 每条进展含具体产出或数量，能对应到交付物、测试结果或文档 | 任务责任人，评审人抽查 |
| 阻塞与决策可追溯 | 阻塞有上报对象和解除时间；决策有决定人、依据和时间 | 任务责任人 |
| 更新留痕 | 每次更新有更新人和时间，无集中补填痕迹 | 任务责任人 |
| 归档与查阅 | 关闭后记录可被非参与者查阅，交付物位置有效，遗留事项有承接人 | 任务发起人或团队负责人 |
检查时可以用两个问题快速判断：一个没参与任务的人能否只读记录就说清当前进展和下一步；如果任务被交接给他人，接手者能否据此继续推进。两个问题都能回答“是”，记录基本合格。发现不合格时，优先补时间与状态的一致性，再补进展的可验证描述，最后处理归档与查阅。
常见问题
任务很小、当天就完成，还需要按完整字段记录吗？
需要保留核心字段，但可以精简。任务标识与目标、责任人、实际开始与完成时间、完成结论这几项建议保留，它们是后续复盘和交接的最小依据。完成比例、协作人、决策记录这类字段在任务简单时可以省略。
判断标准是：如果一周后有人问起这件事做了什么、谁做的、结果如何，记录能否直接回答。能回答就够用，不必为了字段齐全而补写没有信息量的内容。
任务执行到一半目标变了，原来的记录要改还是另起一条？
建议保留原记录，另起一条变更记录，写清变更内容、决定人、依据和时间，再更新任务的目标描述与计划时间。直接覆盖原目标会让前期进展失去对照基准，事后无法判断偏差来自执行还是目标调整。
如果目标变更幅度大到交付物完全不同，更稳妥的做法是关闭原任务并新建任务，在原任务中注明承接关系，避免一条记录里混着两套验收标准。
协作人可以直接改任务状态吗？
通常不建议。状态和完成比例由任务责任人统一维护，协作人补充自己承担部分的进展即可。多人同时改状态容易出现“协作人标了完成、责任人还在等验收”这类矛盾。
如果团队任务量大、责任人经常不在线，可以约定代更新规则：由指定代理人更新，并在记录中写明代更新原因。规则本身要简单，否则执行成本会超过记录带来的价值。
阻塞解除后，原计划完成日期要不要跟着改？
看阻塞是否实际影响了交付。如果通过调整内部排期消化了阻塞时长，原计划日期可以不变，在解除记录中说明调整方式；如果确实无法按期完成，就更新计划完成日期，并写明调整原因和新的承诺时间。
两种做法都要留下痕迹，避免出现计划日期悄悄变动、无人知道变更依据的情况。计划日期是偏差判断的基准，改动本身也是一条需要记录的信息。
用文档表格记录和用工具记录，怎么选？
任务数量少、参与人固定时，共享表格或文档就能满足记录需求，字段和格式自己定，上手成本低。任务多、跨团队协作、需要按状态筛选和统计时，用工作项承载记录更合适：状态字段对应流转，进展以评论或更新日志累积，更新人和时间由系统留痕，关闭后仍可按任务回溯。
以 ONES 为例，工作项的状态流转与操作记录可以保留每次变更的时间和操作人，任务相关说明文档也能与工作项关联。具体字段配置需结合团队实际状态集合调整。选择时优先看查阅和追溯是否方便，而不是记录形式本身。
