任务分解表把一项交付拆成可执行、可指派、可验收的工作项，适合项目启动、迭代规划或跨角色协作前使用。本文直接给出一份可复制的空白表格，并逐列说明填写口径、区分必填与选填、用一个完整案例示范拆解粒度，最后说明模板如何随项目调整和长期维护。表格聚焦可执行工作项，项目交付范围的 WBS 编制与需求层级分解不在本文展开。
要点总览（TL;DR）
- 空白任务分解表含14列：工作项名称、所属父项、层级、交付物、负责人、协作人、计划起止、工作量估算、验收标准、依赖关系、优先级、状态、备注与变更记录，可直接复制到文档或表格工具。
- 小团队或两周内迭代可用七项最小字段集：名称、父项、交付物、负责人、计划起止、验收标准、状态；跨团队或外包项目再补协作人、依赖、优先级和变更记录。
- 拆解粒度以“有独立交付物、有唯一负责人、能单独验收”为准，单项工作量控制在一至两周内；父项不重复估算工作量。
- 维护时固定状态流转顺序，计划或验收口径变化写入备注与变更记录；迁移到任务管理工具时按名称、父项、负责人、起止、状态、依赖逐项映射。
可复制空白任务分解表
下面的表格可以直接复制到文档、在线表格或任务管理工具中。表头保留，空白行按实际工作项逐行填写；父项与子项放在同一张表里，通过“层级”和“所属父项”两列体现从属关系，不需要拆成多张表。
| 工作项名称 | 所属父项 | 层级 | 交付物 | 负责人 | 协作人 | 计划开始 | 计划结束 | 工作量估算 | 验收标准 | 依赖关系 | 优先级 | 状态 | 备注与变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
拆解层级建议控制在两到三层：第一层是交付目标，第二层是可独立验收的工作项，第三层只在工作项仍然偏大时继续细分。父项行填写名称、层级和交付物，子项行在“所属父项”中填写父项名称，层级填 2 或 3。这样同一张表既能看整体结构，也能按负责人筛选出个人待办。
复制到文档工具时，保留表头作为固定行，按项目周期新建一张表或一个页面；复制到在线表格时，可对“负责人”“状态”“优先级”设置下拉选项，减少填写口径不一致。若复制到任务管理工具，通常把每一行映射为一个工作项，把“所属父项”映射为父任务或分组，把负责人、起止时间、状态映射为对应字段。
字段说明：每一列填什么
字段的价值在于让不同角色对同一行工作项形成一致理解。名称回答“做什么”，交付物和验收标准回答“做到什么程度算完成”，负责人和协作人回答“谁来做”，计划时间与估算回答“什么时候做、大概多大”，依赖和优先级回答“先后与轻重”，状态与备注回答“现在到哪了、发生过什么变化”。
| 字段名 | 含义 | 填写口径 |
|---|---|---|
| 工作项名称 | 这一行要完成的具体工作 | 用“动词+对象”描述，如“完成登录页接口联调”，避免只写“登录页”或“开发” |
| 所属父项 | 该工作项从属的上一级交付 | 填写父项名称，与父项行保持一致；顶层交付可留空或填项目名 |
| 层级 | 该行在拆解结构中的位置 | 顶层填 1，其下依次填 2、3；同一父项下的子项层级相同 |
| 交付物 | 完成后可被查看或使用的结果 | 写具体产物，如接口文档、测试报告、上线清单；避免写“完成开发”这类过程描述 |
| 负责人 | 对该工作项结果负责的一人 | 每行只填一个负责人，便于追责和排期；多人参与写入协作人 |
| 协作人 | 参与或需要配合的角色 | 填写需要评审、提供输入或联调的人员，可多人 |
| 计划开始 | 预计开始日期 | 填日期，不填“下周”等相对表述；跨月项目建议统一格式 |
| 计划结束 | 预计完成日期 | 与验收节点对应，不把缓冲时间混入结束日期 |
| 工作量估算 | 完成所需投入的规模 | 统一单位，如人天或小时；团队内保持同一口径，不混用 |
| 验收标准 | 判断完成的客观条件 | 写成可核验的条目，如“接口返回符合文档、联调用例全部通过” |
| 依赖关系 | 开始或完成前必须满足的前置工作项 | 填写前置工作项名称；无依赖填“无”，避免留空造成歧义 |
| 优先级 | 相对重要与紧急程度 | 用统一档位，如高/中/低，并说明档位含义 |
| 状态 | 当前推进阶段 | 使用固定状态集，如未开始、进行中、待验收、已完成、已阻塞 |
| 备注与变更记录 | 补充说明和调整痕迹 | 记录范围变化、延期原因、验收口径调整，注明日期和调整人 |
填写时有两个常见口径需要提前约定。工作量估算只表示投入规模，不直接等同于日历工期，排期时还要考虑人员并行和等待时间。验收标准要写到第三方可以独立判断，例如“文档评审通过并归档”比“文档写好”更容易核对。
必填与选填：最小可用字段集
字段并非越多越好。小团队或短周期任务可以先使用最小可用字段集，保证每行工作项能被指派、排期和验收；当项目涉及多团队协作、外部依赖或较长的交付周期时，再补充协作人、依赖、优先级和变更记录。
| 字段 | 精简版 | 完整版 | 说明 |
|---|---|---|---|
| 工作项名称 | 必填 | 必填 | 没有名称无法识别工作项 |
| 所属父项 | 必填 | 必填 | 维持拆解结构，避免工作项散落 |
| 层级 | 选填 | 必填 | 层级简单时可从父项关系推断 |
| 交付物 | 必填 | 必填 | 明确产出，便于验收 |
| 负责人 | 必填 | 必填 | 每行必须有唯一负责人 |
| 协作人 | 选填 | 必填 | 跨角色配合多时建议填写 |
| 计划开始/结束 | 必填 | 必填 | 用于排期和识别冲突 |
| 工作量估算 | 选填 | 必填 | 需要容量规划或报价时填写 |
| 验收标准 | 必填 | 必填 | 完成的判断依据 |
| 依赖关系 | 选填 | 必填 | 存在前后置关系时不可省略 |
| 优先级 | 选填 | 必填 | 资源紧张或多项目并行时需要 |
| 状态 | 必填 | 必填 | 日常跟踪的基本依据 |
| 备注与变更记录 | 选填 | 必填 | 范围或口径变化时记录 |
精简版适合两周以内的迭代或人数较少的团队，保留名称、父项、交付物、负责人、计划时间、验收标准和状态七项即可运转。完整版适合跨团队交付、有外部供应商或验收环节较多的项目。取舍的判断标准是：缺少该字段是否会导致无法指派、无法排期或无法验收；如果不会，可以先不填，等出现争议时再补。
填写示例：一个完整拆解案例
以下示例为演示情景：某团队需要上线一个“用户登录改版”功能，父项为整体交付，下面拆成四个子项。示例重点展示字段之间如何配合，以及拆到什么粒度适合进入执行。
| 工作项名称 | 所属父项 | 层级 | 交付物 | 负责人 | 协作人 | 计划开始 | 计划结束 | 工作量估算 | 验收标准 | 依赖关系 | 优先级 | 状态 | 备注与变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 用户登录改版 | — | 1 | 新版登录功能上线 | 张明 | 产品、测试 | 3月3日 | 3月21日 | — | 新版登录在预发环境通过验收并上线 | 无 | 高 | 进行中 | 父项，不单独估算 |
| 完成登录交互稿评审 | 用户登录改版 | 2 | 评审通过的交互稿 | 李华 | 张明、测试负责人 | 3月3日 | 3月5日 | 2人天 | 评审意见关闭，交互稿归档 | 无 | 高 | 已完成 | 3月5日评审通过 |
| 完成登录接口开发与联调 | 用户登录改版 | 2 | 接口文档、联调记录 | 王强 | 李华 | 3月6日 | 3月12日 | 5人天 | 接口返回符合文档，联调用例全部通过 | 完成登录交互稿评审 | 高 | 进行中 | 依赖交互稿定稿 |
| 完成登录页前端开发 | 用户登录改版 | 2 | 可运行的前端页面 | 赵敏 | 王强 | 3月6日 | 3月14日 | 6人天 | 页面在测试环境可完成登录流程，无阻断缺陷 | 完成登录交互稿评审 | 高 | 进行中 | 与接口联调同步推进 |
| 完成登录功能测试 | 用户登录改版 | 2 | 测试报告 | 陈静 | 王强、赵敏 | 3月15日 | 3月19日 | 3人天 | 主流程用例全部通过，遗留缺陷有明确处理结论 | 完成登录接口开发与联调；完成登录页前端开发 | 高 | 未开始 | 依赖前后端完成 |
这个示例的拆解粒度依据有三条：每个子项都有独立交付物，能单独验收；每项工作量在二到六人天之间，大致落在一至两周内可完成的区间；每项都有唯一负责人，依赖关系能指向具体前置工作项。父项本身不填工作量，避免与子项重复计算。
如果某个子项仍然偏大，例如“完成登录页前端开发”实际包含多个页面和多种登录方式，可以继续拆到第三层，但拆出的工作项仍应满足“有交付物、有负责人、可验收”。反过来，如果两个子项总是由同一人同一天完成、验收标准也无法分开，就应合并，减少表格行数带来的管理成本。
调整与维护：让表格持续可用
模板需要随项目类型调整，而不是一次定好后长期不变。判断是否增减字段，可以看它是否影响指派、排期、验收或交接：研发迭代通常需要依赖关系和状态；市场活动更关注交付物和协作人；外包项目则需要更完整的验收标准和变更记录。调整时保留字段含义不变，只增减列，避免同一名称在不同项目里指代不同内容。
状态更新和变更记录要有固定规则。建议约定状态流转顺序，例如未开始→进行中→待验收→已完成，出现外部阻塞时标记为已阻塞并写明原因。计划时间、验收标准或范围发生变化时，在备注与变更记录中注明日期、调整人和调整原因，原计划可保留在记录中，便于复盘时区分“计划变更”和“执行偏差”。
定期维护可以按周或按迭代进行：检查是否有长期停留在进行中却没有更新的工作项，清理重复或已合并的行，确认父项与子项的层级关系仍然成立。迭代结束或项目收尾时做一次复盘，统计延期工作项、依赖阻塞和验收返工的情况，据此决定下一轮模板保留哪些字段。
当表格迁移到任务管理工具时，字段映射思路是：工作项名称对应任务标题，所属父项对应父任务或分组，负责人对应任务负责人，计划起止对应起止时间，状态对应任务状态，验收标准写入任务描述或验收字段，依赖关系对应任务关联。ONES Wiki 支持文档关联项目任务，页面组可关联项目，文档中可嵌入任务进度和报表，适合把填写规范、空白模板与项目工作项放在同一页面体系中维护；文档实时同步并记录页面版本，支持查看与回滚，模板调整后可以保留历史版本。若团队同时使用 ONES 的项目与任务相关产品，表格中的工作项、负责人和状态可以在任务管理中继续流转，文档与项目工作保持关联。具体字段配置以实际使用的产品版本为准。
常见问题
任务分解表拆到第几层就该停？
常见做法是拆到“能在一至两周内完成、有独立交付物、能单独验收”这一层就停。层级本身不是目标，判断依据是这一行能否被单独指派和验收。若某个子项仍包含多个可分别验收的产物，可以继续拆到第三层；若两个子项总是同一人同一天完成、验收标准也分不开，就合并成一行，减少维护成本。
父项要不要填负责人和工作量？
父项建议填一个对整体交付结果负责的人，便于跨子项协调；工作量估算通常留空或标“—”，由子项估算汇总得出，避免父子重复计算导致总量虚高。父项的计划起止可以填整体交付窗口，子项时间应落在该窗口内，出现超出时及时调整父项排期或在备注中说明。
任务分解表和 WBS 有什么区别，什么时候用哪个？
任务分解表侧重可执行工作项的指派、排期和验收，字段围绕负责人、时间、状态和验收标准组织；WBS 侧重项目交付范围的结构化拆解，强调范围完整性和交付物层级。做项目范围确认和合同交付清单时用 WBS，进入执行排期和日常跟踪时用任务分解表。两者可以衔接：WBS 的工作包作为任务分解表的父项，再往下拆成可执行工作项。
表格里的状态和依赖怎么更新才不流于形式？
先约定固定状态集和流转顺序，例如未开始→进行中→待验收→已完成，外部阻塞单独标记为已阻塞并写明原因。更新责任落在每行负责人，按周或按迭代检查一次：长期停留在进行中且无更新的工作项要追问，依赖已满足的子项及时启动。状态变化与计划调整分开记录，计划变更写入备注与变更记录并注明日期和调整人，复盘时才能区分计划变更和执行偏差。
把表格搬进任务管理工具时，哪些字段需要保留？
建议保留能支撑指派、排期、验收和追踪的字段：工作项名称对应任务标题，所属父项对应父任务或分组，负责人对应任务负责人，计划起止对应起止时间，状态对应任务状态，验收标准写入任务描述或验收字段，依赖关系对应任务关联。协作人、优先级和备注按团队需要保留。迁移前先统一状态集和优先级档位，避免工具里的选项与表格口径不一致。若使用 ONES，表格中的工作项、负责人和状态可以在项目与任务管理中继续流转，文档与项目工作保持关联，具体字段配置以实际使用的产品版本为准。
