任务拆解评审模板的核心是一张可复制的评审表：字段覆盖工作项基本信息、产出物、责任人、完成标准、依赖关系五组，检查项围绕“拆得是否过细、产出是否可验收、责任是否唯一、完成标准是否可判定、依赖是否闭环”逐条打勾。本文提供空白表、字段填写口径、必填规则、检查项清单和一条完整填写示例，适用于可执行工作项的评审；项目交付范围的WBS编制与需求层级管理不在本文展开。
要点总览（TL;DR）
- 模板以一张空白评审表为核心，字段分为基本信息、产出物、责任人、完成标准、依赖关系五组，检查项与结论区由评审人填写。
- 字段完整性判定与质量检查分开：必填字段缺失直接退回补填，字段已填但内容不合格进入检查项判定。
- 检查项按产出、责任人、完成标准、依赖关系四组设置，采用全通过制，命中阻断项时结论只能在“修改后再审”与“合并或上提”之间选择。
- 拆解过细的典型信号包括单项工作量明显偏小、产出无法独立验收、责任人与父项重复、多个子项产出指向同一物件，出现时应先判断是否合并回父项。
- 模板可按工作项类型裁剪选填字段与附加检查项，基本信息与阻断项不裁剪；评审记录可用 ONES Wiki 的页面模板库承载并与工作项对应维护。
可复制空白评审表模板
下表为空白评审表，可直接粘贴到文档或表格工具中填写。字段区由被评审人填写，检查项区与结论区由评审人填写。表中不预填任何具体项目内容，编号规则由团队自定。
| 区域 | 字段/检查项 | 填写内容 | 评审打勾 |
|---|---|---|---|
| 基本信息 | 工作项编号 | — | |
| 工作项名称 | — | ||
| 所属父项 | — | ||
| 层级 | — | ||
| 类型 | — | ||
| 产出物 | 产出物名称 | — | |
| 验收方式 | — | ||
| 责任人 | 唯一负责人 | — | |
| 协作人 | — | ||
| 完成标准 | 完成定义 | — | |
| 判定依据 | — | ||
| 依赖关系 | 前置工作项 | — | |
| 外部依赖 | — | ||
| 检查项 | 产出物可独立验收 | — | □ |
| 责任人唯一且与父项不重复 | — | □ | |
| 完成标准可判定 | — | □ | |
| 依赖关系已闭环 | — | □ | |
| 工作量与粒度合理 | — | □ | |
| 名称以动词开头、指向明确 | — | □ | |
| 无重复或可合并项 | — | □ | |
| 类型与层级匹配 | — | □ | |
| 评审结论 | 结论 | 通过 / 修改后再审 / 合并或上提 | — |
| 修改意见 | — | ||
| 评审人与日期 | — |
使用时建议一次评审一组同层级工作项，逐行填写字段、逐条打勾，最后统一给结论。结论只保留三类处置：通过、修改后再审、合并或上提，避免评审会滑向逐条讨论细节。
字段说明：每个字段填什么、怎么判断合格
同一张表被不同角色使用时，分歧通常来自对字段口径的理解不同。下表给出每个字段的含义与合格填写要点，示例要点为示意，不针对具体项目。
| 字段 | 含义 | 合格填写要点 |
|---|---|---|
| 工作项编号 | 团队内唯一标识，便于引用与追溯 | 按团队规则生成，同一父项下不重复 |
| 工作项名称 | 一句话说明要完成的事 | 以动词开头，包含对象与结果，如“完成登录页接口联调” |
| 所属父项 | 该工作项从属的上一级事项 | 填写父项编号与名称，确保父子关系可追溯 |
| 层级 | 该工作项在拆解结构中的位置 | 与父项层级连续，不跳级 |
| 类型 | 工作项性质，如开发、设计、运营、测试 | 从团队既定类型中选择，决定后续必填差异 |
| 产出物名称 | 完成后可交付的具体物件 | 写具体物件，如文档、页面、接口、报告，避免写“相关工作” |
| 验收方式 | 如何确认产出物合格 | 写明评审、演示、测试通过或数据达标等可执行方式 |
| 唯一负责人 | 对结果负责的单一角色 | 只填一人，能对产出物和完成标准负责 |
| 协作人 | 参与但不承担结果责任的角色 | 列出参与方，与负责人明确区分 |
| 完成定义 | 什么状态算完成 | 用可观察的状态描述，如“接口上线并通过回归测试” |
| 判定依据 | 依据什么材料或数据判定完成 | 指向具体记录，如测试报告、验收单、数据截图 |
| 前置工作项 | 本项开始前必须完成的工作项 | 填写编号，确认前置项已排期或有明确完成时间 |
| 外部依赖 | 团队外部的输入或配合 | 写明依赖对象与需要的时间点，标注是否已确认 |
产出物字段的判断标准是“可交付、可验收”：拿到产出物的人能独立判断它是否合格。责任人字段的判断标准是“唯一且能负责”：出现两人共同负责时，通常意味着工作项还需继续拆分或明确主责。完成标准字段的判断标准是“可判定”：换一个不了解背景的人读完成定义，也能得出完成或未完成的结论。依赖关系字段的判断标准是“闭环”：每个前置项都能对应到已存在的工作项，外部依赖有明确的对接人和时间。
必填与选填：哪些字段缺失即退回
字段完整性判定与质量检查分开处理：字段缺失属于形式问题，直接退回补填；字段已填但内容不合格，进入检查项环节判定。下表给出必填与选填的划分及缺失处置。
| 字段 | 属性 | 缺失处置 | 适用说明 |
|---|---|---|---|
| 工作项编号 | 必填 | 退回补填 | 所有类型 |
| 工作项名称 | 必填 | 退回补填 | 所有类型 |
| 所属父项 | 必填 | 退回补填 | 顶层工作项填“无”并说明 |
| 层级 | 必填 | 退回补填 | 所有类型 |
| 类型 | 必填 | 退回补填 | 所有类型 |
| 产出物名称 | 必填 | 退回补填 | 所有类型 |
| 验收方式 | 必填 | 退回补填 | 开发、设计类必须写明；运营类可写数据或结果确认方式 |
| 唯一负责人 | 必填 | 退回补填 | 所有类型 |
| 完成定义 | 必填 | 退回补填 | 所有类型 |
| 判定依据 | 必填 | 退回补填 | 开发、测试类指向测试或验收记录；设计类指向评审记录 |
| 协作人 | 选填 | 不退回 | 存在跨角色配合时填写 |
| 前置工作项 | 选填 | 不退回 | 存在先后顺序时填写；无前置填“无” |
| 外部依赖 | 选填 | 不退回 | 依赖团队外部输入时填写，需注明对接人与时间 |
按工作项类型可做必填差异：开发类工作项必须填写验收方式与判定依据，因为其完成状态需要测试或验收记录支撑；设计类必须填写验收方式，通常为评审通过；运营类可将判定依据放宽为结果数据说明，但完成定义仍需可观察。差异只调整必填范围，不减少基本信息五字段。
字段缺失与检查项不通过的区别在于处置动作：字段缺失退回补填后重新提交，不进入评审讨论；检查项不通过则进入评审结论，可能给出“修改后再审”或“合并或上提”。把两者混在一起，会让评审会花大量时间处理本可提前补齐的信息。
检查项清单：防止拆解过细的判定标准
检查项回答的是“拆得对不对”，与字段是否填全无关。下表按产出、责任人、完成标准、依赖关系四组给出检查项、通过标准与阻断项，并单列拆解过细的识别信号。
| 分组 | 检查项 | 通过标准 | 阻断项 |
|---|---|---|---|
| 产出物 | 产出物是否具体可交付 | 能指出具体物件及其存放或交付位置 | 产出物写成“推进”“跟进”等动作 |
| 产出物 | 产出物能否独立验收 | 不依赖同批其他工作项即可判断合格 | 必须与父项合并后才能验收 |
| 责任人 | 负责人是否唯一 | 仅一名负责人，协作人单独列出 | 出现两名及以上共同负责人 |
| 责任人 | 负责人是否与父项重复 | 子项负责人与父项负责人可不同，且子项有独立责任范围 | 子项责任完全被父项覆盖 |
| 完成标准 | 完成定义是否可判定 | 第三方依据判定依据能得出完成结论 | 完成定义含“基本完成”“大致可用”等模糊表述 |
| 完成标准 | 判定依据是否可获取 | 依据材料在评审时已明确来源 | 判定依据指向不存在的记录 |
| 依赖关系 | 前置项是否已识别 | 每个前置项对应到已存在的工作项编号 | 存在未识别的隐性前置 |
| 依赖关系 | 外部依赖是否闭环 | 写明对接人、需要时间与确认状态 | 外部依赖仅写“待对方提供” |
| 粒度 | 工作量是否合理 | 与同层级工作项量级接近，可在一个评审周期内完成 | 单项工作量明显偏小，仅数小时且无独立产出 |
| 粒度 | 是否存在可合并项 | 同父项下无产出重叠、责任重叠的工作项 | 多个子项产出指向同一物件 |
| 粒度 | 名称是否指向明确 | 动词开头，包含对象与结果 | 名称为“其他”“杂项”或纯名词 |
| 粒度 | 类型与层级是否匹配 | 类型选择与工作内容一致，层级连续 | 层级跳级或类型与内容不符 |
拆解过细通常表现为几类信号同时出现：单项工作量明显小于同层级其他项，产出无法独立验收，责任人与父项重复，多个子项产出指向同一物件。出现任一信号时，评审人应先判断是否应合并回父项，再决定是否保留。阻断项一旦命中，结论不能为“通过”，只能在“修改后再审”与“合并或上提”之间选择。
检查项打勾采用全通过制：所有非阻断项通过、且无阻断项命中，才可给出“通过”。部分通过不设折算，避免评审结论被平均化。
填写示例：一条工作项的完整评审记录
以下为一条演示性质的工作项评审记录，用于说明字段与检查项如何对应，内容为示意，不代表真实项目。
| 字段/检查项 | 填写内容 | 说明 |
|---|---|---|
| 工作项编号 | DEMO-012 | 按团队规则生成 |
| 工作项名称 | 完成登录页接口联调并提交联调记录 | 动词开头，含对象与结果 |
| 所属父项 | DEMO-010 登录功能开发 | 父子关系可追溯 |
| 层级 | 第三层 | 与父项层级连续 |
| 类型 | 开发 | 决定验收方式与判定依据为必填 |
| 产出物名称 | 联调记录文档与接口可用环境 | 具体物件，可交付 |
| 验收方式 | 测试人员按联调记录复测通过 | 可执行 |
| 唯一负责人 | 后端开发A | 单一负责人 |
| 协作人 | 前端开发B、测试C | 与负责人区分 |
| 完成定义 | 登录接口在测试环境返回成功，联调记录归档 | 状态可观察 |
| 判定依据 | 测试复测记录与联调记录文档 | 来源明确 |
| 前置工作项 | DEMO-011 接口定义评审完成 | 对应已存在工作项 |
| 外部依赖 | 无 | 如实填写 |
| 检查项：产出物可独立验收 | □ 通过 | 联调记录可单独验收 |
| 检查项：责任人唯一且与父项不重复 | □ 通过 | 负责人独立承担本项结果 |
| 检查项：完成标准可判定 | □ 通过 | 依据测试复测记录判定 |
| 检查项：依赖关系已闭环 | □ 通过 | 前置项已存在 |
| 检查项：工作量与粒度合理 | □ 通过 | 与同层级项量级接近 |
| 检查项：名称指向明确 | □ 通过 | 动词开头 |
| 检查项：无重复或可合并项 | □ 通过 | 同父项下无产出重叠 |
| 检查项：类型与层级匹配 | □ 通过 | 开发类型，层级连续 |
| 评审结论 | 修改后再审 | 示例结论 |
| 修改意见 | 外部依赖栏补充“无”的确认说明；联调记录需注明归档位置 | 指向具体字段 |
| 评审人与日期 | 评审人D，示例日期 | 留痕 |
该示例中字段全部填写完整，检查项全部通过，结论仍为“修改后再审”，原因是修改意见指向了填写质量问题而非字段缺失。这一区分与上一节的退回规则一致：字段缺失退回补填，内容质量由检查项与结论处理。
模板调整与维护方法
模板需要随团队工作项类型变化做裁剪，但裁剪应有准入条件，避免每次评审都临时加字段。可按以下方法操作。
按类型裁剪字段与检查项。先保留基本信息五字段与四组核心检查项，再按类型增减：开发类保留验收方式与判定依据为必填；设计类将判定依据替换为评审记录；运营类可增加结果数据说明字段，同时保留完成定义。裁剪只针对选填字段与附加检查项，基本信息与阻断项不裁剪。
新增字段的准入条件。新增字段需同时满足三条：该字段在近几次评审中被反复口头追问；字段内容能被不同角色一致填写；字段能对应到明确的检查项或结论动作。只满足其中一条时，先写入评审说明，不进入模板。
评审结论的复盘与迭代节奏。建议按固定周期统计三类结论的分布：若“修改后再审”集中在同一字段，说明字段口径需要修订；若“合并或上提”频繁出现，说明拆解粒度标准需要收紧；若“通过”占比长期偏高而返工增多，说明检查项判定过松。复盘以结论分布为依据，不以个别评审人的感受为依据。
模板版本与变更记录。每次调整模板时记录版本号、变更字段、变更原因与生效日期，旧版本评审记录保留原样，不回溯修改。空白模板与字段说明表同步更新，确保模板、说明与示例三处字段一致。
评审通过后的工作项需要承载字段与状态流转时，可将评审表作为文档与工作项对应起来。ONES Wiki 支持页面模板库一键创建制式化文档模板，页面组可关联项目、需求与文档互相对应，文档还可嵌入任务进度与报表，并记录页面版本、支持查看与回滚，适合把评审记录与工作项放在同一处维护。具体字段配置与评审流转方式以团队实际使用的工具能力为准。
常见问题
评审会上发现字段填了但内容不合格，应该退回补填还是直接给结论？
按字段缺失与内容质量分开处理。字段为空或必填项未填，属于形式问题，退回补填后重新提交，不进入评审讨论。字段已填但内容不合格，例如产出物写成“推进”“跟进”、完成定义含“基本完成”等模糊表述，则进入检查项判定，由评审结论给出“修改后再审”或“合并或上提”。把两类问题混在一起，评审会容易花大量时间处理本可提前补齐的信息。
同一父项下多个子项由同一人负责，是否一定说明拆解过细？
不一定，需要结合责任范围判断。若子项负责人与父项负责人相同，但每个子项有独立产出物和独立验收方式，责任范围可以区分，属于正常拆解。若子项责任完全被父项覆盖、产出无法单独验收，则属于拆解过细的信号，应优先考虑合并回父项。评审时先看产出物能否独立验收，再看责任人是否重复，两项同时命中时合并的必要性更强。
外部依赖在评审时尚未确认，能否先给“通过”？
外部依赖属于选填字段，但一旦填写，检查项要求写明对接人、需要时间与确认状态。若仅写“待对方提供”而无对接人和时间，属于依赖未闭环，命中阻断项，结论不能为“通过”。此时可给出“修改后再审”，要求补充依赖信息；若该依赖短期内无法确认，也可评估是否将相关工作项上提，等待依赖明确后再拆解。
不同工作项类型的必填字段差异如何设定，会不会导致模板越来越复杂？
差异只调整必填范围，不减少基本信息五字段。开发类必须填写验收方式与判定依据；设计类必须填写验收方式，通常为评审通过；运营类可将判定依据放宽为结果数据说明，完成定义仍需可观察。新增字段需同时满足三条准入条件：近几次评审中被反复追问、能被不同角色一致填写、能对应到明确的检查项或结论动作。只满足其中一条时先写入评审说明，不进入模板，避免模板持续膨胀。
评审通过后的工作项和评审记录如何对应保存？
可将空白评审表做成文档模板，每次评审生成一份记录，与对应工作项建立关联。ONES Wiki 支持页面模板库一键创建制式化文档模板，页面组可关联项目，需求与文档互相对应，文档还可嵌入任务进度与报表，并记录页面版本、支持查看与回滚，适合把评审记录与工作项放在同一处维护。具体字段配置与评审流转方式以团队实际使用的工具能力为准。
