任务拆解过细时，工作项数量会迅速膨胀，责任人、完成标准和依赖关系也随之变得难以维护。这份检查清单用于拆解完成、进入执行前的评审环节，围绕产出、责任人、完成标准和依赖关系四类维度逐项核验，并给出阻断项与退回处理方式，帮助团队在动手执行前把粒度过细的工作项合并或重新定义。
要点总览（TL;DR）
- 这份清单用于拆解完成、进入执行前的评审环节，由任务负责人自检、项目负责人或技术负责人复核。
- 检查项围绕四类维度展开：产出是否可验收、责任人是否唯一、完成标准是否可客观判定、依赖关系是否真实且已登记。
- 拆解前先确认父级目标、层级上限和最小粒度参考，可减少因目标模糊导致的过度拆分。
- 无产出条目、完成标准不可判定、责任人缺失、层级超过上限属于阻断项，须合并、上提层级或重新定义后再评审。
- 清单整体通过的条件是阻断项已处理并有记录、非阻断项已说明处理方式、复核人完成签署。
谁在什么时点使用这份清单
这份清单服务于拆解后的粒度评审，使用对象和时点需要先固定下来，否则检查容易流于形式。任务负责人负责自检，项目负责人或技术负责人负责复核，两者在同一份清单上留下判断记录。
| 角色 | 主要动作 | 检查时点 | 输出 |
|---|---|---|---|
| 任务负责人 | 对自己拆出的工作项逐项自检，标记不通过项并说明原因 | 拆解完成、提交评审前 | 自检记录与待调整项清单 |
| 项目负责人或技术负责人 | 复核自检结论，判断阻断项是否已处理，签署评审结果 | 执行开始前的评审环节 | 复核意见与通过或退回结论 |
触发检查的条件可以设为三类信号：工作项数量相比上一阶段明显增多；单个任务预计工时偏短，短到完成标准难以单独验收；出现大量只有动作描述、没有明确产出的条目。任一信号出现时，就应拿出清单逐项核对，而不是等到执行中发现问题再回头合并。
拆解前的准备检查项
拆得过细往往源于上游输入不清：目标模糊时，执行者只能靠不断细分来获得安全感。因此在动手拆解前，先确认以下四项，可以把因目标不清导致的过度拆分挡在前面。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 父级目标或需求是否已明确到可判断完成 | 能用一句话说明该目标完成后的状态，且该状态可被他人确认 | 父级工作项描述、需求说明或验收口径 | 任务负责人 |
| 是否已确定本次拆解的层级上限 | 明确本次拆解最多展开到第几层，超出层级的内容不再细分 | 拆解约定或评审记录中的层级说明 | 项目负责人 |
| 是否已约定工作项的最小粒度参考 | 给出可执行的参考口径，如预计工时下限或交付物形态要求 | 团队拆解规范或本次拆解的粒度约定 | 项目负责人与技术负责人 |
| 是否明确哪些内容不在本层展开 | 列出归项目范围或需求层级管理的内容，本层不重复拆分 | 范围说明或需求层级记录 | 任务负责人 |
层级上限和最小粒度参考没有统一数值，团队可按项目类型设定并在评审中调整。关键是把口径写下来，让拆解者有据可依，让复核者有据可查。
产出与完成标准的检查项
判断一个工作项是否值得独立存在，最直接的角度是看它能否交付可验收的成果。以下检查项用于识别只有动作、没有产出的条目。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 是否对应可识别、可验收的交付物或状态变化 | 能指出具体交付物，或说明某项状态从什么变成什么 | 工作项描述中的产出说明 | 任务负责人 |
| 完成标准是否可客观判定 | 完成标准可由第三方依据事实判断，避免“基本完成”“继续跟进”类表述 | 完成标准字段 | 任务负责人 |
| 产出是否可由单一角色在一次交付中完成 | 不需要多个角色交替接力才能形成可验收结果 | 工作项描述与责任人字段 | 任务负责人 |
| 是否存在只有动作描述、没有产出的条目 | 每个工作项都能回答“完成后留下什么”，无法回答的条目应合并或删除 | 工作项列表逐条核对记录 | 复核人 |
完成标准的写法直接影响判断。把“优化接口性能”改成“接口在约定数据量下响应时间达到约定值并留下测试记录”，条目就从动作变成了可验收的交付。拆解评审时，凡是完成标准无法被第三方判定的条目，都应视为需要重新定义。
责任人与依赖关系的检查项
职责不清是过度拆分的常见诱因：为了绕开跨角色协调，执行者会把一件事拆成多个碎片分给不同人。以下检查项从责任归属和依赖真实性两个角度识别这类问题。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 每个工作项是否有唯一责任人 | 责任人字段为单一人员，不存在多人共担或空缺 | 工作项责任人字段 | 任务负责人 |
| 是否存在同一责任人连续多个串行小项可以合并 | 同一责任人、同一产出目标下的连续小项，合并后仍可独立验收 | 工作项列表按责任人排序后的核对记录 | 复核人 |
| 依赖关系是否真实存在且已登记前置项 | 每条依赖都能指出具体前置工作项，且前置项状态可查 | 依赖登记记录 | 任务负责人 |
| 是否出现为规避跨角色协作而拆出的碎片任务 | 碎片任务能说明其独立交付价值，否则应合并回原工作项 | 工作项描述与协作记录 | 复核人 |
依赖登记要落到具体工作项，而不是笼统写“等待某团队支持”。前置项可查，才能在执行中判断阻塞是否解除，也才能避免用拆分来掩盖尚未协调清楚的协作关系。
每项检查的通过标准与证据
清单要能逐项核验，每一项都需要同时具备通过标准、证据形式、负责人和检查时点。下表把前述检查项汇总为统一口径，便于评审时直接勾选。
| 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|
| 父级目标可判断完成 | 完成状态可被他人确认 | 父级工作项描述或需求说明 | 任务负责人 | 拆解前 |
| 层级上限已确定 | 写明最多展开层级 | 拆解约定或评审记录 | 项目负责人 | 拆解前 |
| 最小粒度参考已约定 | 有可执行的工时或交付物口径 | 团队拆解规范 | 项目负责人 | 拆解前 |
| 本层不展开的内容已划出 | 列出归范围或需求层级管理的内容 | 范围说明 | 任务负责人 | 拆解前 |
| 工作项对应可验收产出 | 能指出交付物或状态变化 | 工作项描述 | 任务负责人 | 拆解后评审 |
| 完成标准可客观判定 | 第三方可依据事实判断 | 完成标准字段 | 任务负责人 | 拆解后评审 |
| 产出可由单一角色完成 | 无需多角色接力即可验收 | 工作项描述与责任人 | 任务负责人 | 拆解后评审 |
| 无纯动作条目 | 每条都能回答留下什么 | 逐条核对记录 | 复核人 | 拆解后评审 |
| 责任人唯一 | 责任人字段为单一人员 | 责任人字段 | 任务负责人 | 拆解后评审 |
| 串行小项已评估合并 | 合并后仍可独立验收 | 按责任人排序的核对记录 | 复核人 | 拆解后评审 |
| 依赖真实且已登记 | 每条依赖指向具体前置项 | 依赖登记记录 | 任务负责人 | 拆解后评审 |
| 无规避协作的碎片任务 | 碎片任务有独立交付价值 | 工作项描述与协作记录 | 复核人 | 拆解后评审 |
自检与复核分工明确：任务负责人完成自检并标注不通过项，复核人只对自检结论和阻断项处理情况进行确认，避免同一人既拆解又放行。证据以工作项描述、完成标准字段和依赖登记记录为主，评审时直接查看对应字段，不依赖口头说明。
在ONES中，工作项描述、完成标准与依赖关系可以作为工作项字段和关联记录保存，评审结论也能随工作项留痕，使自检与复核在同一处完成，减少清单与实际工作项脱节的情况。
阻断项与完成条件
清单中有一部分检查项一旦不通过，就不能进入执行，必须退回处理。明确阻断项，可以让评审结论清晰、可执行。
- 无产出条目：工作项只有动作描述，无法说明完成后留下什么，应合并到相邻工作项或删除。
- 完成标准不可判定：完成标准依赖主观判断，应重新定义，改为可被第三方确认的表述。
- 责任人缺失：工作项没有唯一责任人，应指定责任人，或与相邻工作项合并后统一归属。
- 层级超过上限：拆解层级超出事先约定，应上提层级，把超出部分收回父级工作项管理。
阻断项出现后的处理动作有三类：合并到相邻工作项、上提层级由父级统一管理、重新定义工作项使其具备可验收产出。处理完成后需重新走一遍对应检查项，确认问题消除。
清单整体通过的条件是：全部阻断项已处理并有记录，非阻断项的不通过项已说明处理方式或接受理由，复核人完成签署。签署方式可以是评审记录中的结论字段，也可以在工作项上留下评审备注，关键是能追溯到具体工作项和具体评审人。满足这些条件后，拆解结果方可进入执行。
常见问题
团队第一次使用这份清单，应该先从哪里入手？
建议先固定使用对象和时点，再逐项补充检查口径。可以先从阻断项入手：把无产出条目、完成标准不可判定、责任人缺失、层级超过上限这四类情况明确为退回条件，评审时先筛掉明显不合格的工作项，再核对非阻断项。层级上限和最小粒度参考不必一次定死，可在前几次评审中记录争议点，逐步形成团队自己的约定。
工作项数量不多，还需要逐项走完整清单吗？
可以按触发条件简化。清单设计的触发信号是工作项数量明显增多、单个任务预计工时偏短、出现大量只有动作没有产出的条目。如果本次拆解规模小、产出和责任人清晰，可只核对阻断项和产出类检查项，跳过部分准备项。简化不等于免检，阻断项在任何规模下都应保留，因为这些问题进入执行后修正成本更高。
同一责任人连续多个小项，什么情况下应该合并？
判断依据是合并后是否仍可独立验收。如果这些小项属于同一产出目标、由同一责任人在一次交付中完成，合并后完成标准依然可被第三方判定，就应合并为一个工作项。如果各小项对应不同交付物、验收时点或依赖前置项不同，则保留拆分。合并的目的是减少维护成本，不以数量少为目标。
依赖关系登记到什么程度才算合格？
合格的标准是每条依赖都能指向具体前置工作项，且前置项状态可查。笼统写“等待某团队支持”不满足要求，因为它无法在执行中判断阻塞是否解除。登记时应写明前置工作项、依赖内容和预期解除条件。如果依赖实际不存在，只是拆解时为规避协作而设，应合并回原工作项，而不是保留一条形式上的依赖记录。
评审结论如何留痕，才能追溯？
留痕的关键是结论能对应到具体工作项和具体评审人。可以在评审记录中写明通过或退回结论、不通过项及处理方式，也可以在工作项上留下评审备注。自检记录与复核签署分开保存，便于区分责任。使用 ONES 时，工作项描述、完成标准与依赖关系可作为工作项字段和关联记录保存，评审结论随工作项留痕，减少清单与实际工作项脱节。
