评估任务颗粒度，需要先收集三类证据：任务结构数据、执行过程数据、质量与验收记录。它们分别回答任务拆得够不够细、执行中是否顺畅、完成结果能否验收。把这三类数据按统一口径计算平均任务规模、完成周期中位数、返工率等指标，再结合团队反馈解读，才能判断颗粒度是否合适。下文给出指标、取数口径、计算步骤和一个可复算的示例。
要点总览（TL;DR）
- 评估任务颗粒度需要三类证据：任务结构数据（层级、子任务数、工时）、执行过程数据（完成周期、返工、阻塞）、质量验收记录（完成标准、验收结果）。
- 核心指标包括平均任务工时、平均子任务数、完成周期中位数、返工率、完成标准覆盖率和验收一次通过率，每项都要写清分子分母、时间窗和单位。
- 缺失工时和异常周期单独标记并记录处理规则，分母为零时该指标记为不适用，改为分组描述，不做强行比较。
- 指标只反映记录呈现的现象，需按团队和任务类型分组，结合估算讨论、验收退回意见等定性证据解读，不设通用达标线。
评估目标：颗粒度要回答什么问题
颗粒度评估的对象是可执行的工作项，也就是团队日常领取、推进和交付的任务与子任务。评估要回答三个问题：任务是否拆到一个人或一个小组能在较短时间内独立执行；任务的工作量是否足以支撑估算；任务完成时是否有明确标准可以验收。这三个问题对应可执行性、可估算性和可验收性，是判断颗粒度是否合适的核心依据。
评估边界需要提前说清。项目交付范围的WBS拆解关注交付物分解是否完整，需求层级管理关注需求从主题到子需求的归属关系，这两类问题各有独立的评估方法。颗粒度评估只看最末端的可执行任务：一个任务是否过大导致无法估算和验收，是否过小导致管理成本超过执行价值。把WBS完整性和需求层级纳入本文，会让指标口径混杂，结论也难以归因。
明确目标后，评估才有取舍标准。例如一个任务记录了两天工时、跨越三个角色、验收时无法逐项核对，这些现象指向的是同一个问题：任务边界不清。后续指标设计都围绕这类现象展开。
指标与范围：用哪些指标衡量颗粒度
颗粒度评估的指标分为三组，分别对应结构、过程和质量。单看任何一组都容易误判，三组结合才能形成较完整的证据链。
| 指标组 | 指标 | 含义与单位 | 回答的问题 |
|---|---|---|---|
| 任务结构 | 平均任务工时 | 统计期内任务实际工时之和除以任务数，单位为人时/任务 | 任务规模是否适合估算和领取 |
| 任务结构 | 平均子任务数 | 有子任务的任务所包含子任务数的平均值，单位为个 | 任务是否被进一步拆分到可执行层 |
| 任务结构 | 无子任务大任务占比 | 工时超过设定参考值且无子任务的任务数除以任务总数 | 是否存在未拆开的大块任务 |
| 执行过程 | 任务完成周期中位数 | 任务从进入执行状态到完成状态的天数中位数，单位为天 | 任务从开始到交付的典型时长 |
| 执行过程 | 返工率 | 发生返工的任务数除以完成任务数 | 任务边界或完成标准是否清晰 |
| 执行过程 | 阻塞任务占比 | 统计期内出现过阻塞状态的任务数除以任务总数 | 任务是否因依赖不清而停滞 |
| 质量验收 | 完成标准覆盖率 | 填写了明确完成标准的任务数除以任务总数 | 任务是否具备可验收条件 |
| 质量验收 | 验收一次通过率 | 首次验收通过的任务数除以提交验收的任务数 | 完成标准与实际交付是否一致 |
指标需要设定统计范围。建议以连续四到八个完整周为一个评估窗口，覆盖至少一个完整的交付周期，避免把假期或集中上线周的特殊情况当成常态。范围上按团队和任务类型分别统计，开发、测试、运营任务的工作量天然不同，混在一起算平均值会掩盖真实差异。指标本身不设通用达标线，判断依据来自团队自身的历史分布和当前执行反馈。
数据口径与证据来源：每项指标取什么数
指标能否复算，取决于口径是否写清。下表给出每项指标对应的数据字段、取数来源和计算口径，实际系统中的字段名称需要按所用工具核对后再落地。
| 指标 | 所需数据字段 | 取数来源 | 口径说明 |
|---|---|---|---|
| 平均任务工时 | 任务工时记录、任务标识 | 工作项工时字段或工时登记记录 | 分子为统计期内所有已登记工时之和，分母为有工时记录的任务数；不同单位先统一为人时 |
| 平均子任务数 | 父任务标识、子任务标识 | 工作项层级关系 | 只统计有子任务的父任务，分子为子任务总数，分母为父任务数 |
| 无子任务大任务占比 | 任务工时、子任务关系 | 工作项工时与层级字段 | 参考值由团队按历史数据自行设定，分子为超参考值且无子任务的任务数，分母为任务总数 |
| 完成周期中位数 | 进入执行状态时间、完成状态时间 | 工作项状态流转记录 | 周期等于完成时间减进入执行时间，按自然日计；取中位数降低极端值影响 |
| 返工率 | 返工标记或退回记录、完成状态 | 状态流转与评审记录 | 分子为统计期内出现返工或验收退回的任务数，分母为同期完成任务数 |
| 阻塞任务占比 | 阻塞状态记录、任务标识 | 状态流转记录 | 任务在统计期内至少进入过一次阻塞状态即计入分子，分母为统计期内活跃任务数 |
| 完成标准覆盖率 | 完成标准字段、任务标识 | 工作项描述或验收字段 | 完成标准需可逐项核对，空白或仅写“完成”不计入分子 |
| 验收一次通过率 | 验收结果、提交验收时间 | 验收或评审记录 | 分子为首次验收即通过的任务数，分母为统计期内提交验收的任务数 |
缺失值和异常值要单独处理并记录规则。工时字段为空的任务不参与平均工时计算，但在报告中注明缺失任务数；完成周期为负值或超过窗口上限的记录标记为异常，单独列出核查，不直接删除。分母为零时该指标记为“不适用”，不用零值参与汇总，避免把没有数据的团队误判为表现好或差。
计算与评估步骤：从取数到判断
评估按五步推进，每一步都留下可复核的中间结果。
- 数据准备。导出统计窗口内的任务清单，包含任务标识、父任务标识、任务类型、负责人、工时、状态流转时间戳、返工与阻塞记录、完成标准和验收结果。按任务类型和团队打标签，剔除已取消任务。
- 数据清洗。统一工时单位，标记缺失工时、异常周期和重复记录。对缺失值按前述规则处理，形成清洗日志，记录剔除了多少条、原因是什么。
- 指标计算。按表格口径逐项计算，每个指标同时输出分子、分母和结果值。例如返工率等于返工任务数除以完成任务数，两个数字都要保留，便于判断样本量是否足够。
- 分组对比。按团队和任务类型分组，比较各组指标分布，重点看中位数和分位数，而非只看平均值。样本量小于设定下限的组只做描述，不做组间比较。
- 形成结论。把指标结果与团队执行反馈对照，找出任务规模偏大、完成标准缺失或返工集中的具体任务类型，形成“哪类任务需要继续拆分、哪类任务拆分过度”的判断，并给出下一轮观察的改进点。
分母为零或数据不可比时，处理方式是改为分组描述。例如某团队统计期内没有验收记录，验收一次通过率不参与横向比较，改为说明该团队验收流程尚未建立。跨团队比较前先确认任务类型构成相近，构成差异大时只比较同一任务类型下的数据。
示例：一个团队的任务颗粒度评估
以下为演示情景，数值用于说明计算过程，不代表任何真实团队的表现。某研发团队以连续六周为窗口，统计期内完成任务120个，其中开发任务80个、测试任务40个。
| 指标 | 开发任务 | 测试任务 | 计算说明 |
|---|---|---|---|
| 平均任务工时 | 12人时 | 4人时 | 开发任务工时合计960人时除以80；测试任务160人时除以40 |
| 平均子任务数 | 2.5个 | 1.2个 | 仅统计有子任务的父任务 |
| 完成周期中位数 | 6天 | 2天 | 按状态流转时间戳计算 |
| 返工率 | 18% | 10% | 开发返工14个除以80；测试返工4个除以40 |
| 完成标准覆盖率 | 65% | 85% | 开发52个有标准除以80；测试34个除以40 |
| 验收一次通过率 | 72% | 90% | 按首次验收结果统计 |
解读时先看开发任务：平均工时12人时、周期中位数6天，说明单任务体量偏大；完成标准覆盖率只有65%，与18%的返工率相互印证，指向部分任务在开始执行时边界和验收条件不清。测试任务规模较小、标准覆盖率高，返工率低，颗粒度相对合适。结论是开发任务需要继续拆分并补齐完成标准，测试任务维持现状，下一轮重点观察开发任务拆分后的周期和返工变化。
这个示例的局限在于样本仅覆盖一个团队六周数据，任务类型划分较粗，且未纳入阻塞记录。迁移到其他团队时，参考值和分组方式需要按自身历史数据重新设定。
解读与限制：指标不能直接等同于颗粒度好坏
指标反映的是任务记录呈现出的现象，颗粒度好坏还需要结合执行场景判断。平均工时偏大可能说明任务没拆开，也可能说明该任务本身适合整块交付；返工率高可能源于颗粒度问题，也可能来自需求变更或技术风险。把单一指标当作颗粒度结论，容易把其他原因造成的结果归到拆分方式上。
不同任务类型之间的可比性有限。开发、测试、运营、设计任务的工作量和周期天然不同，跨类型比较平均值意义不大，应在同一任务类型内做纵向对比。团队之间比较时还要确认统计窗口、任务类型构成和工时登记习惯相近，否则差异可能来自记录方式而非颗粒度。
定性证据是必要的补充。建议在指标之外收集三类材料：任务领取时的估算讨论记录、验收评审中的退回意见、团队成员对任务是否“一天内能说清做什么”的反馈。这些材料能解释指标背后的原因，也能发现指标未覆盖的问题，例如任务描述含糊但工时记录正常的情况。
评估结论的使用边界要明确。结论适合用于识别需要调整拆分的任务类型和改进完成标准，不适合直接作为个人绩效评价依据，也不应据此设定统一的工时上限。颗粒度评估的价值在于形成可讨论的证据，推动团队在拆分方式和验收标准上达成一致。ONES 的工作项支持任务与子任务的层级关系、工时登记和状态流转记录，这些数据可以作为上述指标的取数来源；评估时仍需按本文口径核对字段含义和统计窗口，再计算和解读。
常见问题
团队没有登记工时的习惯，还能评估任务颗粒度吗？
可以，但需要换用替代证据。工时缺失时，平均任务工时这一项记为不适用，改用任务完成周期中位数、子任务数、完成标准覆盖率和返工率来判断。周期数据来自状态流转时间戳，通常比工时更容易获得。同时建议在报告中注明工时缺失的任务数，说明结论主要依据周期和验收数据，避免读者误以为工时已纳入计算。
统计窗口选多长比较合适？遇到集中上线周要不要剔除？
建议以连续四到八个完整周为窗口，覆盖至少一个完整交付周期。集中上线周、长假周的数据不建议直接删除，而是单独标记并在解读时说明。如果这类特殊周占比很高，可以同时给出含特殊周和剔除特殊周两组结果，对比后再下结论。窗口过短容易受个别大任务影响，过长则可能混入流程变更前后的数据，导致口径不一致。
评估发现某类任务平均工时偏大，应该直接要求全部拆细吗？
不建议一刀切。平均工时偏大只说明任务体量偏大，是否要拆开还要看这类任务能否独立估算、独立验收。可以先挑出工时超过参考值且完成标准缺失的任务，和负责人一起确认能否拆成可独立交付的子任务；对本身适合整块交付的任务，保留原样并补齐完成标准即可。拆分后下一轮观察周期和返工率是否改善，再决定是否扩大调整范围。
跨团队比较颗粒度指标时要注意什么？
先确认三个前提：统计窗口一致、任务类型构成相近、工时登记习惯可比。三个前提不满足时，跨团队平均值差异很可能来自记录方式而非颗粒度。较稳妥的做法是只比较同一任务类型下的数据，并同时看中位数和分位数；样本量过小的团队只做描述，不参与排名。比较的目的是发现需要讨论的任务类型，而非给团队排序。
颗粒度评估结果能直接用于个人绩效考核吗？
不适合。任务工时和返工率受任务类型、需求变更、技术风险等多种因素影响，把这些指标直接挂到个人考核上，容易促使成员把任务拆得过细或回避有风险的任务，反而扭曲数据。评估结论更适合用于识别需要调整拆分的任务类型、补齐完成标准、改进验收流程，作为团队讨论拆分方式的依据。
