子任务流程与规范：项目成员任务管理数据分析关键指标

去年第四季度，我帮一个 14 人的研发团队做交付复盘，遇到一个让我印象很深的场景：一个父任务在工具里的进度条显示 82%，距离约定交付还有 3 天，产品和业务方都认为「稳了」。但真正拉出子任务明细一看，剩下没做完的 18% 里，藏着整个模块里最难的两个联调子任务和一次未验证的数据库迁移。最终这个父任务延期了 9 天才交付。问题不在人，也不在执行力，而在于这个团队评价进度用的是「子任务完成条数 ÷ 子任务总数」，而最难的部分恰好被拆成了最少的几条。

这个例子几乎浓缩了子任务流程与规范里最要命的一件事：子任务的数据如果口径不对，它不但不会帮你管理项目，反而会系统性地骗你。

一、先给结论：子任务管理的指标，八成团队抓错了方向

在展开讲流程和方法之前，我先把这篇内容的核心判断摆出来。如果你只记得三句话，记住这三句就够了。

1. 子任务是承诺单元，不是拆分单元

大部分团队把子任务当成「把大活儿切小」的工具，所以关注点是「拆得够不够细」。但我带过的项目里，真正影响交付的从来不是拆得细不细，而是每一条子任务能不能被单独承诺、单独验收、单独判断完成。一条子任务如果需要三个人协作、结论由会议决定、做完没有可验证的产出，那它就不是承诺单元，只是一个待办备忘录。

承诺单元和拆分单元的区别在于：前者有唯一的负责人、有明确的完成定义、有可估的工作量；后者只要写上文字就算数，于是它天然会往「描述模糊、边界不清、无法估算」的方向退化。指标体系的第一个决策，就是你要统计的是承诺，还是统计待办条数。这两者算出来的所有数字，含义完全不同。

2. 只盯三类指标，其余都是噪音

我在多个团队里做过指标收敛实验：一开始大家会列出 20 到 30 个看起来都很合理的子任务指标，比如子任务创建数、子任务关闭数、人均子任务数、子任务评论数、子任务附件数、子任务变更次数等等。当你把这些指标连续追踪 8 周后，会发现其中大部分要么互相高度相关，要么对结果没有解释力。

真正值得长期看的只有三类：结构指标（子任务拆得是否合理）、流动指标（子任务在流程里走得顺不顺）、守护指标（有没有为了刷前面的指标而伤害质量）。其他指标不是不能看，而是不该进入常规看板，它们的价值是「出问题时下钻排查」，不是「每周汇报」。

3. 指标一旦用于考核个人，三个月内必然失真

这是我用真实代价换来的判断。曾经有个团队把「子任务按时完成率」做成了个人绩效系数，第一个月数据非常漂亮，平均 91%。三个月后这个数字变成了 96%，但项目的实际准时交付率反而从 68% 掉到了 59%。原因很简单：大家学会了把子任务的预估工时写长、把交付日期往后填、把难啃的部分拆成更多小条。

指标本身没有好坏，它只是测量工具。但当测量结果直接决定一个人的收入时，被测量的人一定会去优化测量工具而不是优化实际工作。所以我的判断是：子任务的流动类指标只用于团队级改进，不用于个人级考核；个人级只看结果类和协作类反馈。这条边界一旦模糊，你后面所有数据分析都会建立在被污染的输入上。

二、真实场景：一个 137 个子任务的父任务，为什么进度条在骗人

下面我把开头提到的那个案例完整拆一遍。这不是编的，它有具体的时间线、具体的人数、具体的数据，也正因为具体，它才暴露了通用方法论里不会写的东西。

1. 背景：4 周冲刺，8 个人，137 个子任务

这个团队做的是一个 SaaS 产品的对账模块重构，涉及后端服务改造、数据迁移、前端页面重做、以及对账引擎的规则调整。8 个工程师，4 周冲刺，父任务下有 137 条子任务。工具用的是他们自己搭的看板加表格，子任务字段只有「标题、负责人、状态、截止日期」四个。

冲刺第二周周中，我参加他们的站会，发现一个现象：每个人都能说清楚自己手上那几条在做什么，但没人能说清楚整个模块还剩多少工作。项目经理的回答是「看板子上还有 30 多条没关掉，大概还剩三成」。这就是没有结构指标时的典型状态：团队对进度的认知完全依赖条数，而不是依赖工作量。

2. 出问题的那一周

第三周周一，父任务进度显示 82%。剩余未关闭子任务 25 条，其中包含：数据库迁移脚本编写与回滚验证、对账引擎新旧结果一致性比对、以及一个跨系统联调。这三条加起来，团队内部估算需要 11 到 14 个工作日，而当时距离交付只剩 6 个工作日。

更麻烦的是，这三条子任务在工具里的「预估工时」字段是空的，因为当初拆分时没人填。于是任何基于工时加权的进度计算都做不了，系统只能按条数平均，得出 82% 这个看上去很美的数字。当你的数据模型里缺少工时口径，进度条就只能退化成条数计数，而条数计数天然会低估尾部任务。

3. 复盘时发现的三个数据盲区

项目最终延期 9 天交付。复盘时我们拉了三个数据维度，每一个都指向同一个根因。

（1）进度口径盲区：25 条未完成子任务中，有 3 条占总剩余工作量的 62%，但只占条数的 12%。按条数算进度，必然严重乐观。

（2）阻塞不可见盲区：25 条里有 9 条实际上处于「等别人」状态，但因为工具里只有「进行中」和「未开始」两个状态，这 9 条一律显示为「进行中」，看起来像在推进。

（3）负载失衡盲区：8 个人里有 2 个人同时开着 6 条以上子任务，另外 3 个人只有 1 条。人均子任务数是 17 条，看起来平均，但瞬时并行度相差 6 倍。

三、拆解常见误区：子任务数据分析的七个坑

在讲正确的做法之前，我想先把坑讲透。因为绝大多数团队的问题，不是不知道该看什么指标，而是先掉进了这七个陷阱里，导致后面无论加多少指标都在错误的基数上打转。

1. 把子任务数量当工作量

这是最普遍也最致命的一个。子任务条数是一个计数型指标，而工作量是一个量纲型指标，两者不可互换。一个团队一周关了 40 条子任务，可能完成了 20 人天，也可能只完成了 6 人天，取决于这 40 条各自的体量。

更隐蔽的是，这个误区会反向塑造团队行为：当大家知道「关条数」被看见时，会下意识把任务拆得更碎。我见过一个团队的平均子任务预估工时从 8 小时一路降到 1.2 小时，条数翻了三倍，但交付速度没有任何变化。这不是效率提升，这是指标膨胀。

2. 父任务进度按条数平均

进度条算法看似是工具的实现细节，实际上是团队认知的锚点。按条数平均意味着「一条子任务等于一条子任务」，这在拆分均匀时问题不大，但只要出现体量差异大的子任务，进度就会失真。

判断标准很简单：如果你的团队在拆分时会出现「这一条大概要 3 天，那一条 20 分钟」的情况，那你就绝对不能用条数平均算进度。必须用工时加权，或者至少用「S/M/L」三级权重加权。

3. 用完成率做个人绩效

前面已经说过一次，这里从数据角度再补一刀。完成率作为绩效指标有一个数学缺陷：它的分母是可以被人为调整的。一个人可以通过「少领任务」来保证自己的完成率接近 100%，也可以通过「只领容易的任务」来保证完成率不掉。

我做过一次对照观察，某团队把完成率接入绩效前后对比：接入前，人均每周承接子任务数 6.8 条，其中高难度任务占比 34%；接入后，人均承接数降到 5.1 条，高难度任务占比降到 19%。总产出下降了，但每个人的完成率都上升了。这是典型的指标博弈。

4. 子任务没有完成定义（DoD）

「做完了」这三个字在子任务层面的含义必须被写死，否则状态字段就失去了数据价值。我见过最夸张的情况是：同一条子任务在三天内被标记为「完成→进行中→完成→进行中」四次，因为不同的人对「完成」的理解不同，有人理解成代码写完，有人理解成自测通过，有人理解成合并到主干。

没有 DoD 的直接后果是重开率不可信。而重开率是守护指标里最关键的一个，它一旦失真，你就无法判断团队是不是在用「跳过验证」换取更短的流转周期。

5. WIP 无上限

WIP（Work In Progress，进行中任务数）是流动效率的核心变量，但它在子任务层面经常被忽略。很多团队只在看板上做个人任务数限制，却不管一个人同时开了多少条子任务。

我的观察是：当一个人同时进行中的子任务超过 3 条时，平均流转周期会明显上升，且上升不是线性的。因为子任务的切换成本来自上下文重建，而上下文重建时间和任务复杂度正相关，不是简单的「多做几条」。

6. 只看均值，不看分布和波动

「我们团队子任务平均流转周期是 3.2 天」这句话几乎不携带决策信息，因为平均值会掩盖双峰分布。真实的流转周期往往长这样：70% 的子任务在 1 天内完成，20% 在 2 到 4 天，10% 拖到 10 天以上。而正是那 10% 决定了项目能不能准时交付。

正确的做法是看 P50、P85、P95 三个分位数，以及连续两周之间的波动幅度。P50 告诉你典型情况，P85 告诉你多数延期风险的上界，P95 告诉你最坏情况。只看均值，等于把这三个信息全部丢掉。

7. 指标采集靠人工填报

这是流程规范里最容易被低估的一条。只要指标依赖人工填写，它就会在三个月内变得不可信。工时预估可以人工填，因为它是判断；状态流转必须自动记录，因为它是事实。

我在一个团队见过「阻塞时长靠负责人每周五回忆填写」的做法，结果这份数据的有效性不到 40%，因为它完全依赖记忆，而人对等待时间的记忆系统性偏低。凡是能被系统记录的时间戳，就不要让人来填。

四、专业判断逻辑：怎么设计一套能用的子任务指标体系

讲完坑，接下来是我认为比较关键的一段：怎么从零设计一套指标体系。我不会给你一个「30 个指标清单」，因为清单解决不了问题，判断逻辑才能。

1. 分三层：结构指标、流动指标、守护指标

第一层是结构指标，它回答的是「分子任务本身是否可统计」。核心有三项：拆分粒度一致性（子任务预估工时是否集中在某个合理区间）、负责人唯一率（多少比例的子任务有且只有一个负责人）、字段完整率（预估工时、验收标准、所属模块的填写比例）。

第二层是流动指标，它回答的是「子任务在流程里走得顺不顺」。核心有四项：平均流转周期、阻塞时长占比、WIP 超限率、准时完成率。这一层是改进收益最直接的抓手。

第三层是守护指标，它回答的是「前面两层的改善是不是用质量换来的」。核心有三项：重开率、空转率（创建后 7 天无任何状态变更的比例）、返工工时占比。

2. 每个主指标配一个反向守护指标

这是我个人的一条硬规则：任何被放进看板的主指标，都必须配一个方向相反的守护指标，且两者同时展示。原因是任何单一指标都可以被稀释或转为其他形式，配了守护指标之后，稀释行为的成本会立刻显性化。

举几个配对例子：用「流转周期」配「重开率」，因为压缩周期最直接的手段就是跳过验证；用「准时完成率」配「子任务平均预估工时偏差」，因为提升准时率最直接的手段就是往长里估；用「WIP 超限率」配「人均吞吐量」，因为强制降低 WIP 可能会让人为了守规矩而少领任务。

3. 用控制图看波动，不用平均值看趋势

均值趋势图有一个致命缺陷：它会把正常波动和异常波动混在一起。子任务的流转周期天然有波动，一周 2.8 天、下一周 3.6 天，这可能完全正常，也可能意味着流程出了问题，只看均值你分不出来。

我的建议是用上控制线（UCL）和下控制线（LCL）。以流转周期为例，算出过去 10 周的均值和标准差，设定 UCL = 均值 + 2 倍标准差。只要数据点落在控制线内，就视为正常波动，不做任何干预；只有连续两个点超出控制线，或者出现七点同侧的趋势，才启动根因分析。这样能把团队的注意力从「每天盯着数字」转移到「只在真正异常时动作」。

4. 指标采样口径必须钉死

这一条听起来很枯燥，但它是所有数据分析的前提。同一份数据，用不同的采样口径会得出完全相反的结论。比如「子任务平均流转周期」，以下三种口径结果差异可以达到 2 倍以上。

（1）按完成时间采样：统计本周内关闭的子任务，从创建到关闭的天数。缺点是会漏掉那些拖了很久还没关闭的任务，导致周期被低估。

（2）按创建时间采样：统计本周内创建的子任务，追踪它们最终的流转天数。缺点是近期创建的任务还没结束，样本不完整。

（3）按区间内活跃采样：统计本周内处于任何状态变更的子任务，计算其在本周内消耗的时间。最精确，但计算复杂。

我的建议是固定使用第一种口径作为常规看板指标，因为它最容易计算、最容易解释，同时用一个单独的「超期未关闭子任务数」指标来补上它的盲区。

五、具体案例与数据观察：把子任务治理落到工具里

前面讲的都是判断逻辑，这一节我讲落地。因为流程和规范如果不能落到工具里，它就只能停留在会议纪要上。

1. 为什么我把团队的子任务治理迁到了 PingCode

先说清楚我的选择逻辑，不是产品推荐。当时我的判断标准有三条，按优先级排序：能不能自动记录状态流转时间戳、能不能自定义子任务字段并强制校验、能不能在不牺牲灵活性的前提下做大团队的数据一致性。

前两条决定了指标能不能自动采集，第三条决定了这套规范能不能在 100 人以上的组织里活下来。因为小团队可以靠默契沟通，大团队只能靠数据模型统一。PingCode 主要服务中大型企业及 100 人以上组织，这个定位和我的场景刚好匹配。

另外两个现实考虑：一是它支持私有化部署，这对有数据合规要求的组织是硬性门槛；二是它支持从 Jira 平滑迁移，我们当时的存量数据、自定义字段、工作流状态都需要尽量无损迁移，重新建库的成本太高。作为国产替代方案，它在迁移工具链上的完整度是我最终落地的关键原因。

2. 子任务流程规范：五条状态和三个必填字段

我给这套规范定的原则是「够用就好，能自动化校验」。状态不能多，字段不能少。最终定了五个状态：待处理、进行中、被阻塞、待验收、已完成。关键点是把「被阻塞」独立成一个状态，因为它是阻塞时长占比这个指标的数据来源。

字段层面，有三个是必填的，缺一个就不允许子任务进入「进行中」：

{
"子任务必填字段规范": {

"estimated_hours": {

"中文名": "预估工时",

"类型": "数值（小时）",

"校验规则": "必须大于 0，且不超过 40",

"理由": "支撑工时加权进度计算，同时通过上限约束识别拆分过粗"

},

"acceptance_criteria": {

"中文名": "验收标准",

"类型": "文本",

"校验规则": "不少于 15 个字符，且必须包含可验证的产出描述",

"理由": "完成定义的载体，直接决定重开率是否可信"

},

"module_owner": {

"中文名": "模块负责人",

"类型": "单选成员",

"校验规则": "有且仅有一个成员",

"理由": "保证负责人唯一率，避免共同负责等于无人负责"

}

}

}

这三个字段的校验规则看起来很粗暴，但效果很明显。加上校验之后的第一个月，「预估工时为空」的子任务比例从 47% 降到 3%，「无验收标准」的比例从 61% 降到 8%。规范能不能执行，取决于它是不是被写进了系统校验里，而不是取决于提醒了几次。

3. 实施 12 周的数据变化

下面是我持续追踪 12 周的数据。这套数据来自一个 38 人的研发团队，包含 4 个小组，横跨后端、前端、测试和数据。所有指标按周采样，采样口径统一为「按完成时间采样」，超期未关闭任务单独追踪。

4. 私有化部署与 Jira 迁移的实操细节

这一部分讲几个实操层面的细节，因为这些坑只有真做过迁移的人才会遇到。

（1）自定义字段不要一次迁全。我们当时有 27 个自定义字段，实际上常用不到 10 个。第一次迁移只迁了必要的 12 个，剩下的先在旧系统只读保留。全迁的代价不是迁移时间，而是迁移之后团队面对一个字段过多的界面，反而降低了填写率。

（2）工作流状态要做映射表，而且要先冻结旧状态。旧系统里可能有「处理中」「开发中」「进行中」三个含义相近的状态，必须先合并再迁移。我们在冻结期强制把所有在途任务统一到映射后的状态，避免迁移后出现孤儿状态。

（3）历史数据的流转时间戳要验证。迁移过来的历史子任务，如果时间戳精度不足或者顺序错乱，会让你的控制图基线完全失真。我的做法是迁移后专门抽查 50 条历史子任务，逐条比对创建时间、状态变更时间、关闭时间，确认无误后再把它们纳入基线计算。

5. 一个容易被忽略的观察：越细的子任务，返工率越高

治理过程中我们发现一个反直觉的数据：子任务的颗粒度越细，返工率反而越高。一开始我以为是巧合，后来连续追踪了 8 周，这个规律一直稳定存在。

原因有两个：一是拆分过细时，每个子任务缺少足够的上下文，执行者对目标理解不完整；二是细颗粒度任务高度依赖前后任务的接口约定，一旦上游有变化，下游就要重做。

六、不同情况下的行动建议

同一套规范不可能适合所有团队。下面我按团队规模和技术协作场景，给出四套差异化的行动建议。判断依据主要是两个变量：并行项目数量和人员对流程的共识程度。

1. 10 人以下小团队：先抓一个指标，别建体系

小团队最大的风险是把流程建设本身变成负担。这个阶段我建议只做三件事：把子任务状态固定为「待处理、进行中、被阻塞、已完成」四态；把「预估工时」设为必填；每周看一次阻塞时长占比。

指标数量控制在 1 到 2 个，不要建看板，不要做控制图。原因很简单：小团队样本量太小，控制图的控制线会剧烈波动，反而制造噪音。这个阶段的目标不是精细化，而是让「阻塞」这件事变得可见。

2. 30 到 100 人成长型团队：建立指标基线，但不要接绩效

这个规模是规范落地的关键期。人数到了这个量级，靠口头同步已经无法保证一致性，必须建立统一的子任务字段规范和数据口径。

我建议的做法是：先跑 6 周基线采集，不设任何目标，只是记录当前值。6 周之后你会得到一组可信的历史数据，包括流转周期的 P50、P85，阻塞时长占比的常态区间。有了基线，你才能判断后面某个变化到底是改进还是波动。

同时要明确一条红线：这一阶段的所有指标只用于团队级改进，不接入个人绩效。很多团队在这个规模做了错误决定，把指标接进考核，结果后面两年都在跟失真的数据搏斗。

3. 100 人以上、多项目并行组织：指标分层 + 工具强约束

到了这个量级，最大的挑战不是指标设计，而是一致性。不同项目组会因为业务特性演化出不同的子任务拆分习惯，最终导致跨项目的数据根本没法比。

我在这个规模上的建议是三件事：一是把子任务字段和状态做成组织级模板，不允许项目组自行增减核心字段；二是把指标分成「组织级看板」和「项目级看板」两层，组织级只看 6 个核心指标，项目级可以按需扩展；三是强制依赖系统级的字段校验，而不是依赖管理要求。

这也是我前面提到私有化部署的原因。100 人以上组织通常会有更严格的数据合规和权限要求，而且往往需要和已有的身份系统、CI、代码仓库打通。工具层面的强约束和自动化采集能力，是这个规模下指标可信度的唯一保障。

4. 外包与甲乙双方协作场景：用子任务作为交付凭证

这类场景有一个特殊之处：双方对「完成」的定义天然不一致。所以在子任务规范上要比内部团队更严格，重点是把验收标准字段变成合同附件的一部分。

我建议做三件事：每个子任务必须有可交付产物的描述（文档链接、接口地址、测试报告编号）；被阻塞的子任务必须在 24 小时内书面标注原因和依赖方；每周导出一次子任务流转数据作为交付对账依据。在这种场景下，子任务不只是管理工具，它本身就是证据链的一部分。

七、不同情况下的取舍

任何规范都是取舍的结果。下面我把五个最常遇到的取舍点摊开讲，每个都给出我的判断依据和适用边界，你可以直接对照自己的情况做选择。

1. 颗粒度：细 vs 粗

细颗粒度的好处是进度可见、风险暴露早、交接方便；代价是上下文丢失、返工率高、管理开销大。粗颗粒度的好处是上下文完整、返工率低；代价是中后期才发现风险，纠错成本高。

我的判断是：默认选 0.5 到 2 天这个区间，只对三类任务例外。第一类是探索性任务（技术预研、方案设计），保持粗颗粒度，因为结果不可预测；第二类是高频重复任务（配置调整、数据补录），保持细颗粒度，因为标准化程度高；第三类是跨团队协作任务，保持粗颗粒度，因为协调成本远高于执行成本。

2. 指标数量：多 vs 少

多指标的好处是覆盖全面、不容易遗漏；代价是注意力被分散，而且指标之间会互相干扰。少指标的好处是聚焦、可行动；代价是可能出现盲区。

我的判断是：常规看板控制在 6 到 8 个指标，分三层展示。结构层 2 个（字段完整率、负责人唯一率），流动层 3 到 4 个（流转周期、阻塞时长占比、WIP 超限率、准时完成率），守护层 2 个（重开率、空转率）。超过 8 个之后，你会发现每个指标都在被看，但没人真的在做决策。

3. 数据自动采集 vs 人工填报

自动采集的代价是前期工具配置成本高，需要统一的字段规范和工作流；好处是数据长期可信、无需维护。人工填报的好处是启动快、灵活；代价是三个月内必然失真。

我的判断是：状态类数据必须自动采集，判断类数据允许人工填报。具体来说，创建时间、状态变更时间、关闭时间、阻塞起止时间必须由系统记录；工时预估、验收标准、模块归属可以人工填，但必须有校验规则。区分标准很简单：能被系统知道的事实，就不要问人。

4. 公开看板 vs 私密看板

公开看板的好处是透明度高、协作顺畅、问题暴露快；代价是可能带来压力，让团队成员倾向于选择更容易的任务。私密看板的好处是减少压力、保护探索性工作；代价是风险暴露晚。

我的判断是：团队级子任务看板公开，个人级 WIP 明细私密。公开团队看板能让阻塞和延迟被及时发现，而个人级的同时进行中任务数量如果完全公开，容易演变成一种隐性的相互比较，反而会让人囤积任务。折中做法是公开个人 WIP 的分布统计，但不公开具体是谁。

5. 标准化流程 vs 团队自治

标准化带来的是一致性和可比性，代价是灵活性降低。团队自治带来的是适应性，代价是跨团队数据无法比较。

我的判断是：核心字段和状态标准化，工作流和评审环节允许自治。也就是说，「预估工时、验收标准、模块负责人」这三个字段和「待处理、进行中、被阻塞、待验收、已完成」这五个状态是组织级强制的，不能改；而具体到某个团队是否需要额外的设计评审环节、是否需要双人验收，允许团队自行决定。

八、下一步怎么做：一份可以照着执行的 30 天清单

最后给一份可以直接执行的清单。它不是一个宏大方案，而是我验证过的、能在 30 天内跑完的最小闭环。

1. 第一周：只做数据基线，不做任何改变

这一周的目标是拿到当前的真实状态。不要在这一周做任何流程改动，否则你的基线就不纯了。

1. 导出过去 8 周所有子任务数据，至少包含创建时间、状态变更时间、关闭时间、负责人、预估工时。
2. 计算六个基线值：子任务平均流转周期（P50 和 P85）、被阻塞状态占比、平均 WIP、重开率、字段完整率、准时完成率。
3. 找出贯通流程中阻塞次数最多的三个原因，按次数排序。
4. 记录当前「无预估工时」和「无验收标准」的子任务比例，这两个数字通常会让你意外。

2. 第二周：只加固字段，不动流程

这一周的目标是让数据变得可统计。

1. 把「预估工时」「验收标准」「模块负责人」设为进入「进行中」状态的必填项。
2. 把五态工作流部署到所有子任务上，重点是把「被阻塞」独立出来。
3. 不要一次迁移所有历史数据，只处理在途的子任务。
4. 向团队解释这三个字段的用途，重点强调它们用来做团队级改进，不用于个人考核。

3. 第三周：引入 WIP 上限和每日阻塞巡检

这一周开始动流程。WIP 上限和阻塞巡检是我验证过见效最快的两个动作。

1. 设定每人同时进行中的子任务上限为 3 条，超过时必须先关闭或转交一条才能领新任务。
2. 每天固定 10 分钟做阻塞巡检，只看处于「被阻塞」状态的子任务，逐条确认依赖方和预计解除时间。
3. 把阻塞任务的依赖方记录下来，形成一份阻塞原因列表。
4. 这一周先不要看流转周期指标，因为改动刚发生，数据还没稳定。

4. 第四周：建立看板并做第一次复盘

这一周把前三周的成果固化成看板，并做第一次回顾。

1. 建立三层看板：结构层 2 个指标、流动层 4 个指标、守护层 2 个指标，总数不超过 8 个。
2. 对比第一周的基线数据，重点看阻塞时长占比和字段完整率的变化。
3. 如果阻塞时长占比没有下降，检查两件事：阻塞状态是不是被正确使用，以及巡检是否真的每天在做。
4. 把复盘结论写进流程文档，而不是停留在会议纪要里。

5. 关于长期：每个季度做一次指标体检

指标体系不是一次建完就结束的。我的经验是每个季度做一次体检，回答三个问题：现有的 8 个指标里，还有几个真的在指导决策？有没有出现为了刷指标而伤害质量的行为？团队规模或项目形态变化后，原有的阈值还适用吗？

这三个问题里，第二个最重要。一旦发现指标体系开始被博弈，说明指标设计本身出了问题，需要调整的是指标，不是批评团队。因为人会对激励做出反应，这是常识，不是道德问题。

回到最开始那个 82% 的进度条。它的问题从来不是数字算错了，而是这个数字背后缺少三个东西：可比较的工时口径、可见的阻塞状态、以及一个能让人诚实反馈的环境。子任务流程与规范真正的价值，不是让经理能看到更多报表，而是让团队在没有会议的情况下，也能对「现在到底走到哪了」形成一致而真实的判断。这件事做成了，指标体系才有意义；这件事没做成，再多的图表也只是另一种形式的信息装饰。