任务推进不畅时，团队常把颗粒度、责任、估算三类原因混在一起讨论，结果改拆解没效果，换人也没起色。判断的关键是看症状落在哪一层：完成标准说不清，多半是颗粒度；任务清楚却无人认领，是责任；边界清楚、有人负责却反复延期，是估算。本文给出症状清单、对照证据和一套按顺序执行的验证方法，帮助把原因定位到具体一层。
要点总览（TL;DR）
- 颗粒度问题的核心信号是完成标准不可判定：任务描述写的是方向而非交付物，不同人对“做完”的理解不一致。
- 责任问题的信号是任务本身清楚却无人认领、负责人频繁变更或多人共同负责导致推诿，交接处反复退回。
- 估算问题的信号是任务边界清楚、负责人稳定、任务持续推进，但实际工时持续稳定地高于预估。
- 排除顺序固定为：先验证完成标准，再验证唯一负责人，最后用实际工时回填对比预估，哪一步修正后症状消失，原因就在哪一层。
- 修正后至少观察一个完整迭代，用停滞任务数、平均停留时长、交接退回次数和工时偏差率做前后对比，并把颗粒度标准、责任人规则、工时回填写进日常流程。
颗粒度不合理时会出现哪些典型症状
颗粒度问题指的是任务被切得过大或过粗，导致执行者无法在一次连续工作内完成，也无法判断做到什么程度算完成。这类问题在表面上常被误读为“执行不力”或“沟通不畅”，但症状有比较稳定的特征，可以先从以下清单逐项比对。
- 任务描述笼统，完成标准不可判定。例如“优化登录流程”“完善数据看板”，任务标题写的是方向而非交付物，不同人对“做完”的理解不一致，验收时容易产生争议。
- 单个任务跨多天或跨多个角色。一个工作项需要前端、后端、测试轮番介入，持续数天甚至数周，任何一个人都无法独立推进到完成状态。
- 任务长期停在进行中，进度只能靠口头汇报。状态字段停留在“进行中”超过预期周期，问进度时得到的回答是“还在做”“快好了”，缺少可核对的中间产物。
- 同一任务被反复拆开又合并。团队多次尝试细化，拆出来的子项仍然过大，或者拆完后发现彼此强耦合又合并回去，拆解动作本身消耗了大量讨论时间。
- 任务清单数量与工作量不匹配。一个迭代只有十几个工作项，但每个都对应一周以上的工作量，计划颗粒度无法支撑日常进度跟踪。
这份清单的作用是建立归因起点，而不是直接下结论。上述症状中，只有“完成标准不可判定”和“单人无法在一次连续工作内完成”这两条与颗粒度的关联最直接；其余几条可能由责任或估算问题引起，需要在下一节做对照排除。
三类原因的症状对照与排除证据
颗粒度、责任、估算三类原因会产生部分重叠的症状，比如“任务长期停滞”在三类原因下都可能出现。区分它们不能靠症状本身，而要靠各自独有的证据：完成标准是否可判定、是否存在唯一负责人、实际工时与预估的偏差是否稳定。下表按同一组观察维度做横向对照。
| 观察维度 | 颗粒度问题 | 责任问题 | 估算问题 |
|---|---|---|---|
| 任务描述与完成标准 | 描述笼统，完成标准模糊或缺失，验收靠口头确认 | 任务描述清楚，完成标准可判定 | 任务描述清楚，完成标准可判定 |
| 负责人 | 可能有多人参与，但无人对整体完成负责 | 无唯一负责人，或负责人频繁变更、多人共同负责导致推诿 | 负责人明确且稳定 |
| 流转表现 | 任务跨角色、跨天，交接点多 | 任务在交接处反复退回，或长期无人认领 | 任务持续推进，但完成时间一再后移 |
| 工时与预估 | 难以估算，因为任务本身边界不清 | 工时投入正常，但产出与交接不畅 | 实际工时持续显著高于预估，偏差方向一致 |
| 典型口头反馈 | “这个到底要做到什么程度？” | “这块不归我管”“我以为他在跟” | “比想的花时间多了”“没想到这么复杂” |
排除顺序建议固定为三步：先验证完成标准，再验证责任人，最后验证估算。原因是颗粒度问题会污染后两项判断——任务本身边界不清时，指定负责人也难以推进，工时估算也缺乏基准。先解决完成标准问题，后两项的验证才有意义。
有几类症状会同时出现在两类原因中，需要二次验证。“任务长期停在进行中”既可能是颗粒度过粗导致无人能推进，也可能是无唯一负责人导致无人推进；“反复延期”既可能是估算偏低，也可能是任务边界不清导致范围持续扩大。遇到这类重叠症状，不要凭印象归因，直接进入下一节的验证步骤，用修正后的变化来确认原因。
按顺序做三步验证，定位真正原因
验证的思路是：对同一批样本任务依次施加一项修正，观察症状是否消失。哪一步修正后症状明显改善，原因就在哪一层。样本建议选取近期停滞或延期的 5 至 10 个任务，覆盖不同角色，避免只挑极端案例。
第一步：检查完成标准是否可判定
逐个查看样本任务的描述，问两个问题：交付物是什么，做到什么程度算完成。操作上可以请任务执行者用自己的话复述完成标准，再与任务记录比对。判定标准是：如果超过半数样本任务无法给出可核对的完成标准，或不同人对标准的理解不一致，颗粒度问题成立。此时先不要急着改责任人或重估工时，把任务拆到“一个人在一次连续工作内可完成、完成标准可判定”的单元，再观察后续表现。
第二步：为样本任务指定唯一负责人
在完成标准已经清楚的前提下，为每个样本任务指定一名唯一负责人，明确其对整体完成负责，其他人作为协作方。观察一到两周，看任务流转是否改善：交接退回次数是否减少，停滞任务是否有人主动推进。判定标准是：如果指定负责人后任务明显流动起来，责任问题成立；如果任务仍然卡住，且卡点集中在“不知道做到什么程度”或“范围不断变大”，说明颗粒度仍未解决，需要回到第一步继续细化。
第三步：用实际工时回填对比预估
在完成标准清楚、负责人明确的任务上，记录实际投入工时，与最初预估做对比。判定标准是：如果实际工时持续、稳定地高于预估，且偏差方向一致（例如普遍高出五成以上），估算问题成立；如果偏差忽高忽低、没有规律，更可能是任务边界不稳定，应回到颗粒度层面检查。回填数据至少积累一个完整迭代，单次偏差不足以支撑结论。
调整任务结构前需要保留原记录：原任务描述、原负责人、原预估工时和历史状态变更。原因在于，修正后如果症状消失，需要靠原记录做前后对比才能确认归因；如果直接覆盖原数据，修正效果就无法验证。对于已经进入交付阶段的任务，拆解动作应选择在迭代边界或任务暂停点进行，避免在关键路径上中途重构任务结构造成交接混乱。
这套验证流程依赖任务记录本身可查：完成标准写在哪里、负责人是否唯一、工时是否有登记。在 ONES 中，这些信息可以随工作项一起记录和流转，验证时直接调取历史记录做前后对比，减少靠回忆和口头确认带来的偏差。
修正后如何验证恢复并防止复发
修正动作落地后，需要用一段观察周期确认症状确实消失，而不是碰巧被外部因素掩盖。建议观察周期覆盖至少一个完整迭代，对比指标包括：停滞任务数量、任务平均停留时长、交接退回次数、实际工时与预估的偏差率。修正前后的数据用同一口径统计，才能说明问题。
判断症状消失是否由修正带来，可以看两点：一是改善集中在被修正的那批任务上，未修正的同类任务没有同步改善；二是改善在修正动作之后出现，而非之前就已经发生。如果整体进度好转但被修正任务没有单独变化，更可能是外部因素（如需求减少、人员补充）在起作用，需要延长观察或补充样本。
防止复发要把三项规则写进日常流程，而不是停留在一次性的诊断结论上：
- 颗粒度标准：新建任务时检查是否满足“一个人在一次连续工作内可完成、完成标准可判定”，不满足则继续拆分。
- 责任人规则：每个任务有且只有一名负责人，协作方单独标注，交接时明确接收人。
- 估算回填：任务完成后登记实际工时，迭代回顾时对比预估偏差，偏差持续偏大的任务类型单独分析。
如果同类症状再次出现，复查顺序与诊断时一致：先看新任务是否满足完成标准，再看负责人是否唯一且稳定，最后看工时偏差是否重新扩大。按这个顺序复查，可以避免每次复发都从头争论原因，也能让颗粒度标准、责任规则和估算习惯在团队内逐步稳定下来。
常见问题
任务长期停在进行中，怎么判断是颗粒度太粗还是没人负责？
这两种原因都会表现为任务停滞，单看状态字段无法区分。可以先检查该任务的完成标准：如果执行者说不清交付物是什么、做到什么程度算完成，颗粒度问题的可能性更大；如果完成标准清楚，但任务记录里没有唯一负责人，或负责人一栏挂着多个人，责任问题的可能性更大。
更稳妥的做法是做一次小范围修正：先为停滞任务补上可判定的完成标准，观察一到两周。任务开始流动，说明此前是颗粒度问题；仍然卡住且卡点集中在交接环节，再指定唯一负责人继续观察。用修正后的变化确认原因，比在会议上争论更可靠。
预估工时普遍偏低，是不是说明任务颗粒度也有问题？
不一定，需要看偏差的形态。如果实际工时持续、稳定地高于预估，偏差方向一致，例如同类任务普遍高出五成以上，更可能是估算方法或经验基准的问题，任务本身的边界是清楚的。如果偏差忽高忽低、没有规律，或者任务范围在执行中不断扩大，则要回到颗粒度层面检查，因为边界不清的任务无法形成稳定的估算基准。
操作上建议先确认完成标准是否可判定，再回填实际工时做对比。完成标准清楚的任务，其工时偏差才有分析价值；标准模糊时，偏差数据本身就不稳定，直接归因为估算偏低容易改错方向。
团队已经指定了负责人，任务还是推不动，接下来查什么？
先确认“指定负责人”是否真正落地：负责人是否唯一、是否对整体完成负责、协作方是否单独标注。如果负责人一栏仍有多人，或负责人只负责其中一段工作，推诿的空间依然存在。
如果负责人确实唯一且稳定，任务仍推不动，回到完成标准检查。常见情形是任务跨多个角色、持续多天，负责人无法独立推进到完成状态，需要协调的对象超出其权限。这时应把任务拆到一个人在一次连续工作内可完成的单元，再观察流转是否改善。调整前保留原任务描述、原负责人和历史状态记录，便于修正后做前后对比。
在迭代中途调整任务结构，会不会影响正在进行的交付？
会有影响，主要风险是交接混乱和记录丢失。已经进入交付阶段的任务，中途重构拆解可能打断正在进行的工作，也可能覆盖原有的预估和状态记录，导致修正效果无法验证。
建议把拆解动作安排在迭代边界或任务暂停点，关键路径上的任务尽量等当前阶段交付完成后再调整。确需中途调整时，先留存原任务描述、原负责人、原预估工时和状态变更历史，再建立新任务并关联原记录。这样修正后既能对比前后差异，也不影响正在推进的工作。
修正之后指标好转了，怎么确认是修正起的作用？
看两点：改善是否集中在被修正的那批任务上，以及改善是否出现在修正动作之后。如果被修正任务的停滞数量、停留时长明显下降，而未修正的同类任务没有同步变化，修正与改善之间的关联就比较可信。
如果整体进度好转但被修正任务本身没有单独变化，更可能是需求减少、人员补充等外部因素在起作用。此时可以延长观察周期，或补充一批新的样本任务再做对比。观察周期建议覆盖至少一个完整迭代，指标口径在修正前后保持一致。
