这份通用任务拆解记录表按“父任务—子任务—可执行工作项”三层组织，包含任务编号、上级编号、任务名称、层级、负责人、协作人、交付物、完成标准、日期、依赖关系、状态和备注等字段。你可以先复制空白表，再对照字段说明逐项填写，最后用文末的完整示例检查记录是否清晰、可执行，从而在团队内统一任务拆解记录格式。
要点总览（TL;DR）
- 通用任务拆解记录表按“父任务—子任务—可执行工作项”三层组织，核心字段包括任务编号、上级编号、任务名称、层级、负责人、交付物、完成标准、截止日期、依赖关系和状态。
- 任务编号建议用层级前缀加顺序号，上级编号体现拆解关系；工作项必须具体到一个人能直接动手完成，并写清可检查的交付物和完成标准。
- 最小可用记录只填必填字段，适合小团队快速起步；多人协作或跨团队交接时补齐协作人、开始日期、依赖关系和备注。
- 模板长期可用依赖编号与状态口径稳定、指定维护人、保留版本说明；旧记录不强制回填新字段，按原口径保留。
- 记录表迁移到协作工具时，可把字段和层级对应到工作项属性，让编号、负责人、状态在工具内保持一致。
可复制空白任务拆解记录表
下面的空白表可以直接复制到文档或表格工具中使用。表头字段与后文说明、示例保持一致，复制后不需要再调整列名。建议保留“任务编号”作为第一列，便于按编号排序和追溯上下级关系。
| 任务编号 | 上级编号 | 任务名称 | 层级 | 负责人 | 协作人 | 交付物 | 完成标准 | 开始日期 | 截止日期 | 依赖关系 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果团队习惯在表格工具中维护，可以把“层级”列设置为下拉选项，取值固定为“父任务”“子任务”“工作项”；“状态”列同样建议用下拉选项，避免同一状态出现多种写法。空白行数量按一次拆解的规模增减，表头保持不变。
字段说明：每个字段记录什么、怎么填
字段说明解决的是“同一个人填得对、不同的人填得一样”的问题。下面逐项说明每个字段的含义和填写口径，团队可以据此形成自己的填写约定。
编号类字段：任务编号与上级编号
任务编号是每条记录的唯一标识，建议采用“层级前缀＋顺序号”的规则，例如父任务用 P01、P02，子任务用 P01-01、P01-02，工作项用 P01-01-01。上级编号填写本条记录所属的上一层编号：父任务的上级编号留空，子任务填所属父任务编号，工作项填所属子任务编号。编号一经使用不再复用，任务取消时保留编号并在状态中标注。
名称与层级：任务名称、层级
任务名称用动宾结构描述要完成的事情，例如“完成登录模块接口联调”，避免只写“登录模块”这类名词。层级只有三个取值：父任务表示一个阶段性目标，子任务表示父任务下的可管理模块，工作项表示一个人可以在一个时间段内直接动手完成的事情。层级决定这条记录需要拆到多细：父任务和子任务允许保留一定概括性，工作项必须具体到能直接开始执行。
人员与产出：负责人、协作人、交付物
负责人填写对这条记录结果负责的一个人，不填团队或部门名称。协作人填写需要参与但不承担最终责任的人员，多人用顿号分隔。交付物写这条记录完成后留下的具体产物，例如文档、原型、代码分支、测试报告或会议结论；工作项的交付物应当可以直接检查。
验收与时间：完成标准、开始与截止日期
完成标准描述“做到什么程度算完成”，用可判断的条件表述，例如“接口在测试环境返回预期结果并通过冒烟测试”。日期填写计划口径，开始日期和截止日期都要落到具体日期；工作项的截止日期不应晚于其所属子任务的截止日期。
关系与过程：依赖关系、状态、备注
依赖关系填写本任务开始或完成前必须先完成的其他任务编号，没有依赖时留空或写“无”。状态建议统一为“未开始、进行中、已完成、已取消”四类，团队可按需要增加“阻塞”状态。备注用于记录范围变化、风险、决策依据等不适合放进其他字段的信息，保持简短。
必填与选填：哪些字段不能空
必填字段保证记录可被追溯和执行，选填字段补充过程信息。团队可以先按最小可用记录起步，运行一段时间后再提高填写强度。
| 字段 | 填写要求 | 理由或适用场景 |
|---|---|---|
| 任务编号 | 必填 | 唯一标识，支撑排序、引用和依赖填写 |
| 上级编号 | 必填（父任务留空） | 体现三层结构，缺少则无法还原拆解关系 |
| 任务名称 | 必填 | 记录的主体内容 |
| 层级 | 必填 | 决定拆解深度和填写要求 |
| 负责人 | 必填 | 没有责任人的任务无法推进 |
| 交付物 | 必填（工作项） | 工作项需要可检查的产出；父任务、子任务可先概括 |
| 完成标准 | 必填（工作项） | 避免“做完了”口径不一致 |
| 截止日期 | 必填 | 支撑排期和依赖判断 |
| 状态 | 必填 | 反映当前进展，便于汇总 |
| 协作人 | 选填 | 需要多人参与时填写 |
| 开始日期 | 选填 | 排期明确后补充，或用于跨周期任务 |
| 依赖关系 | 选填 | 存在前后置关系时填写 |
| 备注 | 选填 | 记录风险、变更和决策信息 |
最小可用记录只填必填字段，适合任务量小、成员熟悉的团队快速起步；完整记录补齐协作人、开始日期、依赖关系和备注，适合多人协作、跨团队交接或需要复盘的项目。两种强度使用同一张表，区别只在填写完整度，不改变字段定义。
填写示例：一个完整的三层拆解记录
下面是一份演示情景下的完整记录，任务背景为一次内部活动报名系统的上线准备，人员、日期均为示例，使用时替换为团队真实信息。三行记录分别对应父任务、子任务和工作项，字段与空白表一一对应。
| 任务编号 | 上级编号 | 任务名称 | 层级 | 负责人 | 协作人 | 交付物 | 完成标准 | 开始日期 | 截止日期 | 依赖关系 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| P01 | 完成活动报名系统上线 | 父任务 | 张明 | 李华、王芳 | 可对外使用的报名系统 | 报名页面开放，提交与通知流程验证通过 | 2025-03-03 | 2025-03-28 | 无 | 进行中 | 上线时间受活动宣传排期约束 | |
| P01-01 | P01 | 完成报名表单与后台配置 | 子任务 | 李华 | 王芳 | 表单配置说明与后台截图 | 表单字段与后台数据项一致，测试环境可正常提交 | 2025-03-03 | 2025-03-14 | 无 | 进行中 | 字段调整需同步通知宣传物料制作 |
| P01-01-01 | P01-01 | 配置报名表单字段并完成提交测试 | 工作项 | 王芳 | 李华 | 表单配置记录与测试结果 | 姓名、部门、联系方式等字段在测试环境提交成功，后台可查看 | 2025-03-04 | 2025-03-07 | 无 | 已完成 | 测试中发现手机号校验需调整，已修复 |
对照检查时看三点：编号是否体现上下级关系，工作项的交付物和完成标准是否可以直接判断，日期是否与上级任务的时间范围相容。三项都满足，这条拆解记录就可以进入执行和跟踪。
调整与维护方法：让模板适配团队并长期可用
模板能否长期使用，取决于字段是否随团队变化调整、编号和状态口径是否稳定、版本更新是否照顾旧记录。下面给出可操作的维护要点。
按团队规模和任务类型增删字段
小团队任务量少、沟通频繁，可以只保留必填字段，减少填写负担；跨团队协作或交接频繁时，补充协作人、依赖关系和备注。任务类型差异明显时，可以增加“任务类型”列区分开发、设计、运营等工作，或为不同类型约定不同的完成标准写法。新增字段应说明填写口径，并明确是否必填，避免出现填了但没人看的列。删除字段前先确认历史记录中该字段没有仍在使用的信息。
维护编号与状态口径
编号规则一旦确定就写入团队填写约定，新增任务按顺序续号，任务取消保留编号。状态取值保持固定集合，需要新增状态时同步更新下拉选项和汇总口径，例如把“阻塞”纳入统计时要说明它与“进行中”的区别。建议指定一名模板维护人，负责解释字段口径和处理争议填写。
处理模板版本更新与旧记录兼容
模板调整时保留版本说明，记录本次新增、删除或修改了哪些字段及原因。旧记录不强制回填新字段，可以在汇总时把空值视为“未填写”，并在需要时对仍在执行的任务补充信息。涉及编号规则或状态口径变更时，先在新周期任务中启用，旧记录按原口径保留，避免同一批数据出现两套解释。
当记录表从个人文档迁移到协作工具中统一管理时，需要把字段和层级对应到工作项上。ONES Project 提供敏捷、瀑布、通用任务协同等项目模板，支持自定义需求状态与多种属性，并可将需求和相关任务规划至迭代、分配负责人；其产品、项目、任务多层级权限可按组织架构、用户组、项目角色分配。团队可以把本文的字段约定落到工作项属性中，让编号、负责人、状态在工具内保持一致。若希望模板说明与任务记录放在一起，ONES Wiki 支持页面模板库创建制式化文档，支持文档关联任务并插入 ONES Project 的工作项列表，也记录页面版本，便于查看和回滚模板的历史修改。具体可配置的字段范围和层级深度，以实际使用时的产品界面为准。
常见问题
父任务、子任务和工作项三层一定要都建吗？
不一定。三层结构是记录表的组织方式，实际拆解深度按任务复杂度决定。任务简单时，可以只建父任务和工作项两层，把子任务省略；任务跨多个模块、需要分组管理时，再补上子任务层。无论用几层，编号规则和上级编号的填写方式保持一致，后续汇总和追溯才不会乱。
工作项的完成标准写到什么程度算够用？
判断标准是：另一个人拿到这条记录，能独立判断它是否完成。例如“接口在测试环境返回预期结果并通过冒烟测试”可以直接检查，“接口开发完成”则依赖个人理解。完成标准尽量写可观察的结果，避免使用“基本完成”“大致可用”这类模糊表述。父任务和子任务的完成标准可以概括一些，工作项需要具体。
团队已经在协作工具里管理任务，还需要这张记录表吗？
两者可以配合使用。记录表适合在拆解讨论阶段集中梳理层级、负责人和依赖关系，形成共识后再落到工具的工作项上。迁移时把任务编号、层级、负责人、状态等字段对应到工作项属性，减少重复录入。ONES Project 支持自定义需求状态与多种属性，可将需求和相关任务规划至迭代、分配负责人，团队可以把本文的字段约定落到工作项属性中；具体可配置范围以实际产品界面为准。
模板调整后，旧记录里的空字段要不要补填？
不强制回填。旧记录按原口径保留，汇总时把空值视为“未填写”即可。仍在执行的任务，可以在下次更新时补充新字段信息；已经完成或取消的记录保持原样，避免为了格式统一而改写历史数据。涉及编号规则或状态口径变更时，先在新周期任务中启用新规则，旧记录继续按原口径解释。
多人协作时，负责人和协作人怎么区分？
负责人填写对这条记录结果负责的一个人，不填团队或部门名称；协作人填写需要参与但不承担最终责任的人员。一条记录只设一个负责人，避免出现问题时无人拍板。协作人较多时，可以在备注中说明各自分工，或把参与部分拆成独立工作项并分别指定负责人。
