任务管理如何做好子任务？项目经理最佳实践与操作步骤

去年我在一个 300 人规模的研发组织做交付复盘，遇到一件让我印象很深的事：一张显示"进度 78%"的父任务，在迭代结束前三天突然变成了 0。追下去发现，那张任务下面挂着 23 个子任务，其中 18 个的标题是"写接口代码""看设计文档""和前端对齐一下"，没有验收标准，没有独立负责人，也没有人真正去关闭它们。项目经理看到的是 18/23，真实的交付状态是核心联调还没开始。

这件事之后，我把过去几年经手和旁观的十几个项目拉出来做了一次子任务数据体检，覆盖 6 个团队、约 4200 条子任务记录。结论有点反常识：子任务数量最多的团队，往往不是进度最透明的团队，而是进度最不可信的团队。子任务本身没有错，错的是绝大多数团队把三种性质完全不同的东西塞进了同一个层级里。

下面这套内容，是我自己在带项目、帮团队做工具迁移和研发效能治理时反复打磨出来的判断框架和操作步骤。它不是"把任务拆小"这种正确但无用的话，而是一套可以直接套到你的项目里、今天下午就能开始调整的做法。

一、核心结论：子任务不是拆解动作，而是责任和验收的重新分配

先把最关键的判断放在前面：子任务管理做不好的根本原因，不是拆得不够细，而是把"交付拆解""个人待办""流程节点"三类东西混在了同一个层级上。

只要这三类东西混在一起，你的父任务进度就一定是失真的，你的迭代燃尽图就一定是装饰品，你的子任务列表就一定会长出一堆没人负责的僵尸卡片。反过来，一旦把它们分开，很多看起来很复杂的子任务治理问题会自动消失。

1. 三类子任务的本质区别

我在做数据体检时，把每一条子任务按"能否独立验收""是否由不同的人负责""是否会阻塞其他任务"三个维度分类，结果几乎每次都能分出清晰的三类。

第一类是交付层子任务。它有独立的交付物、独立的完成定义（DoD）、通常由不同的人负责，完成与否会直接影响父任务能否关闭。比如"支付网关对接联调"下面挂的"完成 3DS 鉴权接口联调并输出联调报告"，这是真正的交付层子任务。

第二类是执行层子任务。它是某个人为了完成自己的工作而拆出来的行动清单，比如"阅读风控文档""整理接口字段""约后端过一遍方案"。它有价值，但它不需要外部验收，也不应该出现在项目级的进度报表里。

第三类是流程层子任务。它由工作流驱动，比如"代码评审""安全扫描""UAT 签字"。它的完成条件是流程节点通过，而不是某个人说做完了。

这张表是我这几年用得最多的一个判断工具。每次有人问我"这个要不要建成子任务"，我就让他先对一下这张表。

2. 只有交付层子任务该进正式层级

这是我给团队定的第一条硬规则。项目管理平台里正式建立的子任务，必须满足"独立交付物 + 独立负责人 + 独立完成定义"三个条件。三个条件缺一个，就不要建卡。

执行层的内容放到个人的任务清单、日历或者干脆就是一张纸。流程层的内容应当在工具里用工作流状态、审批节点或独立的流程工作项来承载，而不是让执行人手建一张叫做"等待评审"的卡片。

为什么要分得这么清楚？因为工具里的每一个工作项都会被统计进报表、燃尽图、工时汇总和迭代容量计算。你往里塞了一张"参加每日站会"，这条数据就会污染后面所有的分析。

3. 拆解深度存在最优区间，不是越细越好

我在数据体检里发现了一条很稳定的曲线：单个父任务的子任务数量，和"进度更新的真实度"之间呈倒 U 型关系。4 到 7 个是最佳区间，低于 4 个进度颗粒度太粗，超过 8 个之后，进度更新的真实性开始快速下降。

原因是人的行为模式。当一个人面对 15 张待办卡片时，他的操作会从"逐条确认"退化成"批量勾选"。这不是态度问题，是认知负荷问题。我在两个团队里都观察到了同一个现象：子任务数超过 12 的父任务，其子任务的"关闭时间戳"高度集中，常常是同一分钟里关闭四五条。

4. 进度不能用子任务数量平均

这是最容易被忽视、破坏力却最大的一条。假设一个父任务下面有 10 个子任务，其中 9 个是半天能搞定的杂活，剩下 1 个是 5 天的硬骨头。当那 9 个做完时，工具会告诉你进度 90%。而按工作量算，真实进度是 47%。

这种偏差在项目后期尤其致命，因为最难的往往排在最后。我的做法是：父任务进度要么用工作量加权，要么干脆不显示百分比，只显示"剩余未关闭的关键子任务数量"和"卡点子任务列表"。后者在实战中比一个百分数有用得多。

二、背景与真实场景：为什么子任务在 20 人团队里好用，在 200 人团队里失控

子任务这个机制本身没有问题，问题在于它的适用边界会随着组织规模发生剧变。我经历过从 8 人小队到 400 人研发组织的不同阶段，同一个做法在不同规模下的效果完全相反。

1. 小团队的子任务是"共享上下文"

在 8 到 20 人的团队里，子任务主要解决的是"我知道你在干什么"这个问题。大家坐在一个房间里，子任务列表就是一份公开的进度看板。这时候子任务拆得细一点、杂一点，影响不大，因为信息通过日常沟通自动纠偏了。

我在一个 12 人的团队里见过最粗放的用法：所有子任务都挂在同一个人名下，没有截止日期，只有标题。这套做法在那个团队里奇迹般地运转了两年，因为所有人每天早上都站在一起，谁卡住了当场就知道了。

2. 中大型组织的子任务必须承担"接口契约"

当组织超过 100 人，跨团队协作成为常态时，子任务的角色发生了根本变化。它不再是你自己团队的进度记录，而是团队之间的交付契约。这时候一条模糊的子任务，代价不再是一句口头确认，而是一次跨部门的返工。

我在一个 300 人规模的支付系统改造项目里吃过这个亏。当时把"完成风控规则接入"拆成了 4 条子任务分给风控团队，但因为没定义清楚"接入完成"的标准，风控团队理解的是"规则配置上线"，我们理解的是"联调通过并给出压测报告"。结果两边都觉得自己做完了，在集成测试阶段才发现差了两个星期的活儿。

3. 一个真实场景：跨团队子任务的失败链条

我把上面那个支付项目的失败链条完整复盘了一遍，它非常典型，几乎每个中大型组织都能对上号。

1. 项目经理按模块拆出 38 个父任务，每个父任务下平均挂 8.2 个子任务。
2. 子任务标题普遍是动宾短语，没有完成定义，比如"完成风控规则接入"。
3. 62% 的子任务负责人与父任务负责人是同一人，跨团队节点没有落到具体人头上。
4. 父任务进度由工具自动按子任务数量汇总，项目经理每周只看这个数字。
5. 迭代进行到第 8 周，父任务整体显示 78%，但集成测试发现核心链路未打通。

最终这个迭代延期了 19 天，返工工时约 340 人时。事后我们统计，如果当初只做三件事，给子任务加完成定义、把跨团队节点指定到具体负责人、父任务进度改成关键路径加权，延期可以压缩到 5 天以内。

三、拆解常见误区：我见过最伤项目的七种做法

这一节我列的都是我在真实项目里反复见到的错误，每一条后面都附上我判断它有害的原因，以及我实际怎么改。

1. 把子任务当个人待办清单用

这是频率最高的一条。表现是：某个人的所有细碎工作都建成子任务挂在自己的父任务下面，"整理文档""回复邮件""准备周会材料"全都进去了。

危害在于报表污染。一个迭代下来，这个人的子任务可能有三四十条，工具的工时汇总、完成率统计、燃尽图全部被这些低价值条目稀释。我的处理方式是给子任务标题设一个过滤规则：凡是动词指向"沟通、准备、整理、了解、确认"的，一律不建卡。

2. 用子任务数量计算父任务进度

前面已经讲过这个陷阱，这里补充一个更隐蔽的变种：有些团队意识到了问题，改成按预估工时加权。这看起来对，但如果预估工时本身是在拆解时随手填的，加权后依然是错的。

我的建议是分阶段处理。拆解阶段允许粗估，但要求每个子任务的预估粒度误差不超过 2 倍；迭代执行到中期时，对剩余的关键子任务做一次重新估算，这次估算用于修正父任务进度。

3. 子任务没有负责人，或者负责人全部指向父任务负责人

我在数据体检里看到过一个很极端的案例：某团队 71% 的子任务负责人就是父任务负责人本人。这意味着这个团队建立了几百条子任务，但没有一条真正起到了"分派责任"的作用。

判断标准很简单：如果一个父任务下面所有子任务的负责人都是同一个人，那这些子任务大概率不该存在，它们只是这个人的待办清单。真正需要子任务的场景，一定涉及多人协作。

4. 允许子任务无限嵌套

有些工具支持多层级工作项，团队一旦发现这个能力就会忍不住用。我见过最深的嵌套是五层，到第四层的时候，已经没人能说清楚那条任务在整个项目里的位置了。

我的规则是最多两层。父任务下面一层子任务，如果子任务还需要拆，说明父任务定义得太大了，应该把父任务重新拆成两个父任务，而不是往下加层。

5. 子任务没有截止日期，或者日期全部等于父任务截止日期

把所有子任务的截止日期设成和父任务同一天，等于没有日期。这在工具上看起来整齐，实际上丢失了排期信息，也无法识别哪个子任务已经拖了太久。

我要求子任务的截止日期必须早于父任务，且相邻子任务之间要留出依赖缓冲。一个可用的经验值是：子任务的最晚完成时间应该比父任务提前至少 2 个工作日，给集成和验收留出空间。

6. 把跨团队依赖塞进子任务

跨团队依赖需要的是"提出方-接收方-交付物-时间点"四要素，而子任务只有"负责人-标题-状态"三个字段，信息结构根本不够用。

我的做法是把跨团队依赖单独建成一类工作项（有些平台叫"依赖"或"外部任务"），用专门的状态流转跟踪，而不是塞进子任务列表里。这样依赖的阻塞情况可以单独出报表，不会被自己团队的子任务淹没。

7. 只看完成率，不看关闭凭证

这是我最近两年才真正重视起来的一条。一个子任务被标记为"完成"，和它真的完成了，是两件事。

我在数据体检里统计过"关闭后无凭证率"，也就是关闭时既没有代码提交关联、也没有文档链接、也没有验收记录的子任务占比。在管理松散的团队里，这个比例可以到 50% 以上。

更麻烦的是，这个指标和返工率高度相关。无凭证率高的小组，其对应模块在集成测试阶段的缺陷密度平均高出 40% 左右。我的做法是在工具里配置一条规则：子任务关闭时如果没有关联提交或附件，就打上一个"待补证"标签，并在周报里单独列出。不强制阻止关闭，但要让它可见。

四、专业判断逻辑：子任务准入三问与粒度公式

前面讲了问题和误区，这一节给出我实际用的判断方法。它不是原则性的口号，而是可以在拆解会议上当场使用的提问清单。

1. 子任务准入三问

每当你准备为一条任务创建子任务时，先问三个问题。三个问题里至少有两个回答"是"，才建卡。

1. 它能被独立验收吗？如果不能说出"看到什么就算完成"，那它不是交付层子任务。
2. 它会由不同的人负责吗？如果负责人和父任务完全一致，先考虑它是不是应该直接作为父任务的执行步骤记录下来。
3. 它失败会阻塞其他任务吗？如果它延期不影响任何人，那它的管理价值很低，放在个人清单里更合适。

这三个问题看起来简单，但在拆解会上非常有效。我主持过的拆解会，平均能砍掉 30% 到 40% 的冗余子任务，而且被砍掉的都是对进度判断没有贡献的那些。

2. 粒度公式：一个可执行的经验值

我在实践中收敛出的粒度标准是：子任务预估工时应在 0.5 到 3 人天之间，最优区间是 1 到 2 人天。

低于 0.5 人天的工作，管理成本高于收益，一次站会就能同步完，不需要建卡。高于 3 人天的工作，说明它本身还是一个父任务级的交付物，应该继续往上归而不是往下拆。

这个区间不是随便定的。我在两个团队里做过对照：把子任务平均粒度从 0.8 人天调整到 1.7 人天后，子任务总数下降了 44%，而迭代延期率反而从 34% 降到了 19%。原因很直接，拆得粗一点，关键路径反而更清楚，执行人也不再被大量小卡片分散注意力。

3. 拆解顺序：骨架自上而下，肉自下而上

这是我认为最容易被搞错的一点。很多团队要么全由项目经理拆，要么全交给执行人拆，两种做法都会出问题。

我的做法是分两层：交付层骨架由项目经理自上而下拆，执行层细节由执行人自下而上填。项目经理负责定义"要交付什么"和"谁来验收"，执行人负责定义"我打算怎么做"。

这样一来，项目经理不会因为不了解技术细节而拆出错误的粒度，执行人也不会因为缺乏全局视角而漏掉关键交付物。责任边界清晰，两边都不越界。

4. 父子状态的自动联动规则

工具层面有一个配置项经常被忽略：父任务的关闭条件。默认配置通常是"所有子任务关闭后父任务才能关闭"，这看起来很合理，但会带来一个问题：如果存在流程层子任务（比如外部合规审批），父任务会被长期挂住。

我的建议是把关闭条件拆开配置：父任务的完成条件只看"交付层子任务"是否全部关闭，流程层节点用独立的状态标记来体现，不参与完成条件判断。这样既保证了交付完整性，又不会让父任务被流程卡住无法归档。

# 子任务关闭校验规则示例（伪配置）
subtask_closure_rules:

required_fields:

assignee # 必须指定负责人

due_date # 必须早于父任务截止日期

acceptance_criteria # 完成定义至少 1 条

close_validation:

require_evidence: true # 需要关联提交/文档/验收记录之一

on_missing: label("待补证") # 缺失时打标签，不阻止关闭

parent_completion:

count_layers: ["deliverable"] # 只统计交付层子任务

exclude_layers: ["process", "personal"]

progress_weight: "estimate" # 按预估工时加权，不用数量平均

这份配置的核心思想是：工具不应该只用来记录，还应该用来约束那些我们已经达成共识的规则。如果规则只写在文档里，两周之后就不会有人记得。

五、案例与数据观察：一次 300 人组织的子任务治理实操

下面这个案例来自我参与顾问的一个中大型研发组织，规模约 300 人，分 7 个研发小组，业务是金融风控系统。他们在做工具链替换的同时，顺带做了一次子任务治理。

1. 治理前的状态

这个组织当时使用的工具在子任务层级上限制较多：子任务只有一层，不能有自己的子任务；自定义字段在子任务上支持有限；跨项目的子任务关联比较麻烦。这些限制本身不是问题，问题是团队长期以来形成了把一切都塞进子任务的习惯。

治理前的基线数据是这样的：全组织约 2600 条活跃子任务，单个父任务的子任务数中位数是 11，平均粒度 0.8 人天，无凭证关闭率 53%，超过 14 天无任何状态变化的"僵尸子任务"占比 23%，迭代平均延期率 34%。

2. 工具替换与迁移的实操细节

他们选择迁移到一个支持多层级工作项、支持私有化部署的国产研发管理平台。在这个案例里，他们落地的是 PingCode，这个平台主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，对受监管行业的团队来说是比较典型的国产替代选择。

我参与的是迁移方案设计部分。Jira 的子任务在数据模型上是一种独立的工作项类型，迁移到新平台时需要做类型映射和层级重建。我们当时做的映射表大致是这样的。

我把这段经验写出来，是因为很多团队在评估迁移工具时只关注"能不能导数据"，而真正决定迁移成败的是层级关系、权限继承和子任务字段支持度这三件事。这三件事在演示环境里往往看不出问题，一到真实数据上就暴露了。

3. 迁移后同步实施的治理规则

工具迁移是个天然的窗口期。数据重新导入之后，原来的历史包袱被清掉了，这时候推行新规则阻力最小。他们当时落了五条规则。

1. 子任务准入三问写入拆解会检查清单，由项目经理在拆解评审时逐条确认。
2. 子任务必须填写完成定义字段，字段为空时无法进入"进行中"状态。
3. 父任务进度改为按预估工时加权，且只统计交付层子任务。
4. 建立僵尸子任务巡检：超过 10 天无状态变化、无评论、无提交记录的子任务自动打标并推送给负责人。
5. 关闭凭证校验：无关联提交或文档的子任务关闭时打上标签，纳入周报。

第五条规则在推行初期遇到了抵触，主要来自研发同事，觉得"打个标签像是被怀疑"。后来我们调整了措辞和呈现方式，把它从"合规检查"改成"知识沉淀提醒"，接受度明显提升。一条治理规则能不能落地，很多时候不取决于规则本身，而取决于它的叙事方式。

4. 六个月后的数据变化

治理满六个月时，我们做了一次数据回收。需要说明的是，这期间业务规模和团队人数基本稳定，所以指标变化可以在相当程度上归因到治理动作上。

有一点我想特别说明：延期率从 34% 降到 19% 是这组数据里最有价值的，但它并不是子任务治理单独带来的。同期他们还做了需求评审前移和测试环境自动化。如果要把功劳分配比例粗略估一下，我倾向于认为子任务治理贡献了其中的三分之一左右，主要是通过让风险更早可见、让跨团队依赖更早暴露。

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

子任务治理没有通用方案。团队规模、业务复杂度、监管要求、现有工具能力，都会影响你该从哪一步开始。下面按几种典型情况分别给出建议。

1. 20 人以下的小团队：不要治理，先保证一致性

如果你在 20 人以下的团队，我的建议是不要花时间做子任务规范。这个阶段沟通成本极低，任何制度都不如一次当面沟通有效。

你需要做的只有一件事：保证所有人用同一个地方记录任务。不要出现一部分人在工具里，一部分人在表格里，一部分人在聊天记录里。只要信息是集中的，粒度粗一点、格式乱一点都没关系。

2. 20 到 100 人的团队：从完成定义开始，不要一上来改粒度

这个规模是从"靠沟通"转向"靠流程"的过渡带。我的建议是先做最容易见效的一步：给所有子任务加完成定义字段。

具体做法是：在工具里加一个必填字段，内容格式要求写成"当 ____ 时，此任务视为完成"。不需要长篇大论，一句话就够。这一项做完之后，你会立刻发现一批没有存在必要的子任务自己消失了，因为负责人写不出完成条件。

粒度调整放在第二步。等完成定义稳定运行两三个迭代之后，再引入 0.5 到 3 人天的粒度标准，阻力会小很多。

3. 100 到 300 人的组织：需要工具层面的硬约束

到了这个规模，规范只写在文档里是无效的。跨团队协作的信息损耗会吃掉所有软性约定的效力。你必须把规则配置到工具里，让它成为不可绕过的流程。

这个阶段需要落地的硬约束包括：子任务完成定义必填、关闭凭证校验、僵尸任务自动巡检、父任务进度按工时加权、跨团队依赖单独建项。同时要考虑工具本身的能力边界，是否支持多层级工作项、是否支持精细的字段权限、是否能做自定义的自动化规则。

对于受监管行业或有数据主权要求的组织，还需要考虑部署方式。支持私有化部署的平台在这个阶段往往是硬性要求，而不是加分项，因为子任务里会沉淀大量业务细节和技术方案。

4. 300 人以上：把子任务纳入研发效能度量体系

到这个规模，子任务治理不再是一个项目管理动作，而应该是效能度量体系的一部分。你需要建立常态化的指标采集，包括子任务平均粒度、无凭证关闭率、僵尸任务占比、进度更新滞后天数这几项，按季度做趋势对比。

同时要警惕度量的反身性。一旦某个指标被用作考核依据，它就会失真。我的建议是这些指标只用于团队自检和改进，不做跨团队排名，也不与绩效挂钩。一旦挂上绩效，你就会看到所有子任务都被标记为"已完成"，然后凭证字段里塞满了无意义的截图。

七、不同情况下的取舍：没有全赢的方案

任何治理动作都有代价。这一节我想把几组真实的取舍摆出来，帮你在做决策时看到硬币的另一面。

1. 粒度粗一点还是细一点

粗粒度换来的是更低的管理开销和更清晰的关键路径，代价是进度可见性下降，风险暴露更晚。细粒度换来的是更早的预警，代价是执行人被大量卡片分散注意力，且进度更容易被批量勾选污染。

我的取舍原则是按风险等级分配粒度。关键路径上的任务用细粒度（1 人天左右），非关键路径用粗粒度（3 人天左右）。不要一刀切。

2. 强管控还是弱管控

强管控（必填字段、关闭校验、自动巡检）能保证数据质量，但会带来填写负担和抵触情绪。弱管控（只做提示、不做拦截）接受度高，但数据质量依赖团队自觉，容易随时间衰减。

我倾向于对"输入"强管控，对"输出"弱管控。也就是说，创建子任务时要求的字段（负责人、完成定义、截止日期）可以做成必填，这是低成本的；但关闭时的凭证校验只做提示和打标，不做拦截。这样做的好处是前期数据质量有保证，后期不会因为流程太重而被绕过。

3. 统一模板还是自由拆解

统一模板让数据可比、报表可用，但会抑制团队找到适合自己的拆解方式。自由拆解尊重团队差异，但跨团队汇总时会遇到口径不一致的问题。

我的做法是统一必填字段，不统一拆解结构。所有团队都必须填负责人、完成定义、截止日期这三个字段，但怎么拆、拆几层、用什么命名方式，交给团队自己决定。这样既保证了全局数据的可聚合性，又保留了局部灵活性。

4. 用工具强约束还是用规范软约束

这个问题和团队成熟度强相关。成熟团队用软约束就够了，因为他们能理解规则背后的原因，也会主动维护数据质量。不成熟或快速扩张的团队必须用硬约束，因为新成员快速涌入时，规范会被稀释得非常快。

我的判断信号是新人占比。如果团队里入职不满三个月的成员超过 30%，就应该把关键规则固化到工具里；低于 15% 时，可以用文档加评审的方式维护。

5. 私有化部署还是云端

对于 100 人以上、尤其是金融、政企、医疗等行业的中大型组织，子任务里沉淀的业务细节、接口定义、技术方案往往属于敏感信息。这类组织通常需要支持私有化部署的平台，因为数据出境和合规审计的要求往往不允许业务细节放在公有云上。

代价是运维成本和升级节奏。私有化部署意味着你需要自己维护环境，版本更新也不像云端那样自动。这个取舍没有标准答案，取决于你的合规约束有多硬。但如果合规是硬约束，那就不是取舍问题，而是前提条件。

八、总结与下一步

回到开头那个"进度 78% 突然变 0"的场景。如果当时团队做到了三件事，这个事故大概率不会发生：子任务有可验证的完成定义、跨团队节点落到了具体人头上、父任务进度按关键路径加权而不是按数量平均。

我把整篇文章的核心判断浓缩成四句话。

第一，子任务的本质是责任和验收的重新分配，不是拆解动作。把交付层、执行层、流程层三类东西分开，是解决大部分子任务问题的前提。

第二，拆解深度存在最优区间。单个父任务 4 到 7 个子任务是我观察到的最佳区间，超过 12 个之后进度更新的真实性会断崖式下降，因为人会开始批量勾选。

第三，进度不能按数量平均。按数量算的进度在项目后期会系统性高估，因为最难的活往往排在最后。用加权，或者干脆显示剩余关键子任务数量。

第四，规则要么配置到工具里，要么就不要指望它被执行。文档里的规范在两周之后就会失效，尤其是团队快速扩张的时候。

1. 下一步你可以做的三件事

如果你读到这里想立刻开始，我建议按这个顺序来，不要贪多。

1. 本周内：在你的工具里导出最近一个迭代的所有子任务，统计三个数，子任务总数、无凭证关闭率、超过 10 天无变化的占比。这三个数会告诉你问题有多严重。
2. 两周内：给子任务加一个"完成定义"必填字段，格式为"当 ____ 时视为完成"。只做这一件事，观察两个迭代后的变化。
3. 一个月内：把父任务进度从数量平均改成工作量加权，同时把跨团队依赖从子任务里拆出来单独建项。如果你的工具不支持这些配置，那就该考虑工具替换了，替换时优先验证子任务层级、字段权限和部署方式这三项能力。

2. 常见问题

子任务到底应该由项目经理拆，还是由执行人拆？分两层。交付层骨架由项目经理自上而下拆，负责定义"交付什么"和"谁验收"；执行层细节由执行人自下而上填，负责定义"怎么做"。两边都越界，就会分别出现粒度错误和全局遗漏。

我的工具不支持子任务自定义字段，怎么办？短期可以用命名约定兜底，比如在标题末尾用方括号标注完成定义。但这只是权宜之计，长期会带来检索和报表的困难。如果团队规模超过 100 人，建议把字段支持能力作为工具评估的硬性指标。

子任务需要记录工时吗？我的建议是只对交付层子任务记录工时，且只在需要做容量规划或成本核算时记录。执行层子任务如果也记工时，你会得到一份非常详细但完全没有决策价值的数据。

子任务长期不关闭，但确实还在做，该怎么处理？这种情况通常是子任务的定义太宽泛了。我的做法是强制拆分：如果一个子任务超过两周还在"进行中"，就要求负责人把它拆成两个更小的、各自能在 3 人天内完成的子任务。拆分本身就是一次重新思考。

治理会不会让团队觉得被微观管理？会有这个风险，关键在于你要求的是"信息"还是"动作"。要求填写完成定义是在收集信息，团队通常能接受；要求每天更新状态、要求工时精确到 0.5 小时，就是在干预动作，抵触会很大。保持在对信息的约束上，不要越界到动作层面。