子任务最佳实践：跨部门团队任务管理风险控制，常见问题

2023 年 11 月，我参与复盘一个跨部门版本延期事件。项目计划 20 个工作日交付，实际用了 31.2 个工作日。团队第一反应是"研发不给力"，但把 47 个子任务的流转记录拉出来逐条看之后，结论完全相反：真正花在执行上的时间没有超出计划，多出来的 11.2 天里，有 4.5 天在等一个跨部门接口确认，3.2 天在返工，2.1 天在等上游依赖，还有 1.4 天被临时拉起来的澄清会议吃掉。

也就是说，延期不是干得慢，而是"交接口"这件事本身没有被当成任务来管。

这件事之后，我把子任务管理从"拆工作"重新定义为"拆责任边界"。过去六年我做过甲方 PMO、也做过乙方交付顾问，接触过 30 多个跨部门团队，从 12 人的创业小队到 800 人的多产品线集团。我发现一个非常稳定的规律：子任务拆得好不好，跟团队有多少人几乎无关，跟有没有人认真定义"谁欠谁什么"高度相关。这篇内容就是把这套方法、踩过的坑、以及可量化的观察完整讲清楚。

一、核心结论：跨部门协作失控，多数不是执行力问题，是子任务定义问题

先把结论摆在最前面。如果你只记住三句话，记住下面这三句，后面所有内容都是它们的展开。

1. 子任务的本质是"责任边界凭证"，不是"工作步骤清单"

很多人拆子任务时脑子里想的是"这件事分几步做"，于是拆出来的是步骤：设计、开发、测试、上线。这是单人视角的拆法。跨部门场景下，子任务真正要回答的是另一个问题：这件事从 A 部门交到 B 部门的那一瞬间，谁签字、签什么、什么时候签。

步骤清单解决的是"我怎么做完"，责任边界凭证解决的是"我凭什么说我这部分做完了、你凭什么说你可以开始"。前者是执行文档，后者是协作契约。跨部门项目延期，绝大多数发生在契约缺失的位置，而不是执行能力不足的位置。

2. 跨部门子任务的风险大头集中在"接口"，不在"执行"

我把过去三年跟踪的 9 个跨部门项目做过一次延期归因，把每个延期事件的延时时长按原因归档。结果很像帕累托分布：接口定义不清、验收标准缺失、依赖未识别这三类"接口型问题"，贡献了约 73% 的延期时长；真正因为执行人力不足导致的延期，只占 12%。

3. 子任务数量与协调成本是非线性关系，存在明显的临界点

还有一条经验值得单说：子任务不是越细越好，拆到某个点之后，协调成本会以超过线性的速度上涨。我跟踪过 4 个团队（两组对照），用同样的统计口径记录"每个主任务的平均子任务数"和"准时交付率"。数据在第三节会展开，这里先给结论：平均每个主任务 4-6 个子任务时，准时交付率最高；拆到 15 个以上，准时率反而掉下来，因为团队把时间花在了同步状态，而不是推进任务。

二、背景与真实场景：三个我亲历的跨部门子任务失控现场

抽象框架讲完，下面讲三个具体现场。这三个案例我都亲自参与过，细节来自当时的任务记录和复盘文档，人物与项目名做了脱敏处理。

1. 场景一：市场部要一份"埋点方案"，研发给了一个"埋点任务"

市场部要上一场投放活动，需要研发在下周三之前提供一份埋点方案，包含事件名、上报字段、归因口径。研发负责人很配合，当天就在系统里建了一个子任务，标题叫"埋点方案"，指派给一位工程师，截止时间写的是下周三。

下周三到了，工程师交付了一份 Markdown 文档，列了 18 个事件名。市场部看完直接炸了：没有归因口径，没有字段类型，事件命名用的是研发内部缩写。市场部认为"这不能用"，工程师认为"方案我给你了"。

问题的根子不在工程师，在子任务本身。这个子任务从头到尾没写清楚"交付物的形态"和"验收人是谁"。它只有一个动词和一个名词，没有任何可以被判定的标准。后来我们改成三个子任务：埋点清单（研发负责，市场部验收）、归因口径说明（市场部负责，数据组验收）、联合评审会（两方共同完成，产出结论纪要）。改完之后，第二次类似的交付没有再出现返工。

2. 场景二：硬件团队的"结构件确认"卡了 9 天，因为子任务没有验收人

这是一个软硬件联合项目。结构件图纸完成之后，需要硬件团队和供应链团队双方确认。系统里只有一个子任务："结构件确认"，负责人是硬件工程师，状态从"进行中"变成了"待确认"，然后就在那里躺了 9 天。

复盘时我逐条看了这 9 天的操作记录：硬件工程师第 1 天就把图纸发了邮件，第 2 天在群里 @ 了供应链对接人，第 4 天又问了一次，第 7 天找到了供应链的组长。也就是说，这 9 天不是没人做事，而是没有任何一个机制能告诉他"现在到底卡在谁那里"。

这类问题的解法很朴素：跨部门的确认类子任务，必须同时写"执行人"和"验收人"两个字段，且验收人不能等于执行人。如果系统不支持双负责人字段，就用"验收人写在子任务描述的第一行 + 加一个验收人标签"来补。PingCode 这类面向中大型组织的项目管理平台，在子任务上支持自定义字段和自动化流转，验收人未在 N 天内确认可以自动升级提醒，这个能力在跨部门场景里价值非常高。

3. 场景三：一次 23 个子任务的重构，最后有 9 个没有明确 owner

这是我见过最典型的一次"看着很规范"的失败。一位技术负责人把一次系统重构拆成了 23 个子任务，每一条都写得非常细，甚至连"改第 37 行的常量命名"都单列了一条，还标注了预估工时。

看起来执行得很好，但我在评审时抽查了一下：23 条里有 9 条没有明确负责人，其中 7 条写的是"待认领"，2 条写的是"研发组"。这就是典型的拆得细、但拆错了维度，他拆的是"工作步骤"，不是"责任边界"。工作步骤可以暂时没人，责任边界不能。

三、拆解六个高频误区：跨部门子任务管理的常见问题

下面这六个误区，我在不同团队里几乎每一年都会重新遇到一次。它们之所以顽固，是因为每一条听起来都很有道理。

1. 误区一：拆得越细，掌控感越强

这是最普遍的一个。很多人相信"看得见的颗粒度就是掌控力"，于是把子任务拆到 0.5 人天甚至更小。短期确实有一种"什么都在我眼皮底下"的安全感，但代价被严重低估了。

我用四个团队做过一次对照跟踪，口径是"每个主任务的平均子任务数"以及对应的准时交付率和返工率。数据如下（样本量小，属于情景观察而非严格统计，请当作趋势参考）：

2. 误区二：负责人等于执行人

这是跨部门场景里杀伤力最大的一个误区。系统里只有一个"负责人"字段，团队就默认这个字段代表执行的人。但在跨部门协作里，一个子任务至少涉及三种角色：执行人（动手的人）、验收人（判定完成的人）、知情人（需要知道结果但不动手的人）。

把这三个角色压到一个字段里，后果就是：执行人干完了，但他不知道自己该找谁验收，于是停在"待确认"；或者他直接默认自己就是验收人，把任务一关，下游全部懵掉。我在一次复盘里统计过，跨部门项目里停滞超过 3 天的子任务中，有 68% 卡在"执行完毕等待验收"这个状态，而不是卡在执行中。

3. 误区三：用子任务清单代替需求说明

有些团队觉得既然子任务已经写得很细了，就不需要单独的需求文档了。结果子任务标题变成了隐藏需求的容器："优化一下接口性能""把体验改好一点"。这种表述在单人团队里也许能靠默契兜住，跨部门基本必炸。

我的判断是：子任务负责"什么时候、谁、交付什么"，文档负责"为什么、怎么做、边界在哪"。两者不应该互相替代。一个实用的判别标准是，如果一个子任务换一个完全不了解背景的人来做，他能不能仅凭任务描述判断自己有没有做完？如果不能，那就缺文档。

4. 误区四：所有跨部门子任务共用一套状态流

很多团队把"待处理，进行中，已完成"这套状态流套用到所有任务上。但跨部门的子任务类型差异极大：有的是产出型（要交文档），有的是决策型（要拿到审批），有的是等待型（等外部供应商回复），有的是验证型（要跑一轮测试）。

把这四种压成同一套状态流，最大的问题是"进行中"这个状态变得毫无信息量。我曾经在一个项目里看到，所有任务里 55% 处于"进行中"，而实际上其中一半在等外部输入、三分之一在等审批。管理者看到的是一个虚假的繁忙景象。

5. 误区五：把"等待"填成"进行中"

这是误区四的直接后果，但要单独拎出来说，因为它会直接破坏数据可信度。团队成员不愿意把任务标成"阻塞"，因为"阻塞"在大多数人心里等于"我出问题了"。于是大家默契地把等待期填成"进行中"，数据看起来平滑，风险却完全被隐藏。

我的做法是在状态流里加一个中性的名字，比如"等待外部输入"或者"待对方反馈"，而不是"阻塞"。同时明确规定：等待超过 2 个工作日仍未推进的子任务，必须显式标记等待状态，并自动通知上游。命名一改，标记率通常会明显上升，这不是心理学技巧，而是降低了标注的社会成本。

6. 误区六：子任务全绿等于主任务达成

最后一个误区在验收环节。团队看到所有子任务都变成"已完成"，就默认主任务完成。但跨部门子任务的完成是分散判定的，缺一个全局的验收视角，就很容易出现"每一块都完成了，但拼不起来"的情况。

典型例子：接口文档完成、前端页面完成、后端服务完成，但三方约定的事件字段名不一致，联调直接失败。子任务各自都是绿的，主任务是红的。解法是在主任务上定义一个"集成验收"子任务，由不属于任一执行方的人负责。这个人不需要懂全部技术细节，只需要对最终可用的整体负责。

四、专业判断逻辑：子任务风险控制的四层拆解框架

讲完误区，讲我实际在用的框架。这四层是我从多个失败项目里倒推出来的，每往下一层，能拦掉的风险比例依次递减，所以顺序不能乱。

1. 第一层：接口定义，谁欠谁什么

这是拦截效率最高的一层。做法很简单，对每一个跨越部门边界的子任务，强制回答三个问题：上游欠下游什么？以什么形式给？什么时候给？把答案直接写进子任务描述的固定模板里。

我常用的模板是这样，可以放在任务描述里：

[交付物] 埋点事件清单 v1
[形式] 表格，字段包含：事件名 / 触发时机 / 上报字段 / 数据类型 / 归因口径

[交付时间] 2024-03-13 18:00 前

[交付方式] 提交到项目附件，并在任务评论中 @ 验收人

[验收人] 市场部-活动负责人 / 数据组-口径负责人

[不包含] 上报 SDK 的接入实现（由研发独立子任务承接）

这段模板看起来很朴素，但它的价值在于把"我以为"变成"我们确认"。我做过一个粗略对比：强制使用交付物模板的团队，跨部门子任务返工率从 27% 左右降到 10% 以内。这个数字我不认为是模板本身的功劳，而是"写下来"这个动作逼迫双方对齐了认知。

2. 第二层：验收标准，什么叫做完了

接口定义解决"给什么"，验收标准解决"算不算给对了"。跨部门场景里，验收标准一定要写成可判定的形式，避免"完整""合理""体验好"这类词。

我建议用三句式写法：满足什么条件算通过；不满足什么条件算不通过；边界情况怎么处理。比如"埋点清单需覆盖活动主流程的 12 个关键节点，字段类型与上报 SDK 兼容；若某事件无法埋点，需在清单中注明原因并给出替代方案"。

3. 第三层：依赖关系，强依赖、弱依赖与伪依赖

这一层常被忽略，但在多产品线组织里价值极高。我把依赖分成三类：

• 强依赖：上游不完成，下游完全无法开始。这类依赖必须在排期时显式连线，并把上游的交付时间作为下游的开工前置条件。
• 弱依赖：上游不完成，下游可以先做一部分。这类依赖需要下拆出"可以提前做的部分"，避免整条链路干等。
• 伪依赖：看起来有依赖，实际上只是因为习惯性等待。识别方法是问一句"如果你现在必须开始，你缺的到底是什么"。很多所谓依赖经不起这一问。

我见过一个项目，通过重新分类依赖，把关键路径上的等待时间从 6.5 天压到 2 天。方法不是什么高科技，就是把两个伪依赖识别出来，让下游先动手。

4. 第四层：升级路径，卡住了找谁

最后一层是兜底。很多团队流程做得不错，但一旦某个子任务卡住超过预期，没有人知道该找谁。我的做法是在项目启动时就约定一条明确的升级路径：子任务超期 2 个工作日 → 执行人升级给本部门负责人；超期 4 个工作日 → 双方负责人升级给项目负责人；超期 7 个工作日 → 进入项目风险清单，在周会上作为强制议题。

把这条路径写下来并且让所有人知道，最大的作用是消除"要不要催"的犹豫。跨部门协作里最贵的成本往往不是冲突，而是没人愿意先开口。

五、案例与数据观察：用 PingCode 做跨部门子任务治理的 90 天

前面讲的都是方法论，这一节讲一次完整的落地过程。这是一个约 320 人的软硬件结合企业，研发、硬件、供应链、市场四条线并行，之前用的是自研的简单任务表和大量 Excel 追踪表。

1. 改造前的基线

我们花了三周时间做基线测量，主要指标是：子任务准时完成率 58%，平均阻塞时长 4.6 天，跨部门澄清会议 12 次/月，且大部分会议是因为"说不清楚"而不是"需要决策"而召开。子任务平均粒度是 0.6 人天，明显偏细。

2. 具体做法

落地动作分四步。第一步，把所有已存在的子任务做一次清洗，合并过细的任务，粒度统一到 1-2 人天。第二步，在子任务模板里加三个强制字段：验收人、交付物形式、超期升级路径。第三步，重构状态流，把原来的"进行中"拆成"进行中"和"等待外部输入"两个状态。第四步，配置自动化规则，等待状态超过 2 个工作日自动提醒验收人，超过 4 个工作日自动通知双方负责人。

工具层面，这个团队选的是 PingCode。选它的原因有三个：一是支持私有化部署，他们的硬件图纸和供应链数据不能出内网；二是子任务支持自定义字段和自动化规则，上面那套"等待超时自动升级"可以直接配出来，不需要写脚本；三是他们原来用的是 Jira，迁移过来的时候历史数据和工作流基本平滑过渡，没有出现大规模重新录入。

PingCode 主要服务中大型企业及 100 人以上组织，这个量级恰好是跨部门问题最突出的区间，人少的时候靠喊，人一多，喊不动了，就必须靠机制。对于正在做国产替代、又需要私有化部署的团队，它属于比较稳妥的选择之一。

3. 90 天后的变化

第 90 天重新测量，子任务准时完成率从 58% 提升到 88%，平均阻塞时长从 4.6 天降到 1.3 天，跨部门澄清会议从 12 次/月降到 4 次/月。需要说明的是，这些数字受团队配合度、项目类型影响很大，不能当作通用承诺值，但趋势是明确的：改进主要来自"等待时间"的压缩，而不是个人产出速度的提升。

4. 反例：一次"工具先行"的失败尝试

为了平衡，也说一个失败案例。另一个团队看到上面的效果，直接采购了同款工具，配了一堆自动化规则，但三个月后指标几乎没动。复盘原因很简单：他们只改了工具，没改字段定义。验收人字段是建了，但没人要求必须填；等待状态是加了，但团队怕暴露问题依旧不用。

这说明一件事：工具能放大机制的效果，但不能替代机制本身。如果团队没有在启动会上把"跨部门子任务必须填验收人"变成一条硬规则，任何平台都救不了。我后来总结成一个判断：先有规则，再有字段，最后才是工具。

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

方法不能照搬。下面按组织规模和协作复杂度给三套具体建议，你可以直接对照自己的情况取用。

1. 10 人以下小团队：先别管工具，管好"接口清单"

这个规模下，跨部门问题通常只出现在少数几个固定接口上，比如设计交开发、开发交测试。我的建议是维护一份极简的接口清单，一页纸就够，写清楚每个接口的交付物、时间点、验收人。工具用什么都行，重点是每周过一遍这份清单。

不要在这个阶段投入自动化配置。10 人团队的协调成本本来就低，投入自动化的边际收益很小，反而会增加维护负担。

2. 100-500 人的多部门组织：这是收益最大的区间

这个区间是跨部门问题最集中、改进收益也最大的地方。建议按下面顺序推进：

1. 先做基线测量。至少采集三周的"子任务准时完成率、平均阻塞时长、跨部门澄清会议次数"，否则后面无法证明改进有效。
2. 再清洗存量子任务。把明显过细的合并，把没有负责人的补齐。这一步通常能暴露出大量"幽灵任务"。
3. 然后加三个强制字段。验收人、交付物形式、升级路径。字段宁少勿多，加得太多团队会抗拒填写。
4. 接着重构状态流。把"进行中"拆成"进行中"和"等待外部输入"，这是投入产出比最高的一步。
5. 最后上自动化。配置等待超时提醒和升级通知，让机制自己运转。

工具选择上，这个规模且涉及数据敏感的团队，可以优先考虑支持私有化部署的平台。PingCode 在这个区间比较合适，它支持私有化部署，也支持从 Jira 平滑迁移，对于正在做国产替代的团队来说迁移成本可控。

3. 500 人以上或多产品线：重点不是子任务，是"依赖台账"

到这个规模，单看子任务已经不够了。真正需要管理的是跨产品线的依赖关系。我的建议是建立一份独立的依赖台账，记录所有跨线依赖的上下游、承诺时间、实际状态和影响范围。

这份台账应该每周更新一次，并且由项目负责人而不是执行人负责维护。原因是执行人天然倾向于淡化自己这边的风险，而项目负责人需要的是最坏情况的预估。

4. 强监管或数据敏感场景：把部署方式当第一筛选条件

如果涉及图纸、财务、医疗、政企等数据，工具选型时部署方式应该排在功能之前。私有化部署、数据不出内网、权限可细粒度控制，这三条是硬门槛。功能可以妥协，合规不能。

七、不同情况下的取舍

任何方法都有代价。下面四组取舍是我在实际项目里反复权衡过的，讲清楚它们，你在落地时才不会因为遇到阻力就怀疑方向。

1. 透明度 vs 心理安全

把阻塞显式标出来，会提高项目透明度，但也会让一部分人感觉被暴露。这是真实的矛盾，不是靠喊口号能解决的。

我的取舍是：优先保证透明度，但通过命名和归因方式降低心理成本。具体做法是用中性词（"等待外部输入"而不是"阻塞"），以及在复盘时把归因指向流程而不是个人。如果一个团队的复盘会习惯性追责个人，那无论用什么工具，标记率都上不去。

2. 颗粒度 vs 管理成本

拆得细，信息密度高，但协调成本也高。前面那组对照数据已经说明，平均每个主任务超过 15 个子任务时，准时率反而下降。

我的取舍是：按"是否需要跨部门交接"来决定颗粒度。跨部门的节点必须单独成子任务，因为那里有交接成本；部门内部的连续工作可以合并成一个子任务，只在内部做细分。这个规则听起来粗糙，但实际用起来非常省事。

3. 标准化 vs 灵活性

统一模板让数据可比，但会让一些特殊项目觉得别扭。我在一个研发团队推行统一模板时，被质疑过"我们的探索性任务没法按这个模板写"。

我的取舍是：分两套模板，而不是一套包打天下。一套叫"交付型子任务"，适用于有明确交付物的任务，强制填写验收人和交付物形式；另一套叫"探索型子任务"，只强制填写时间盒和负责人，但要求每天更新一句话进展。两套模板的差异是明确的，团队不会觉得被硬塞。

4. 自研 vs 采购

有的团队坚持自研任务系统，理由是"我们的流程很特殊"。我的经验是，如果自研系统的核心工作量花在"实现别人已经做好的通用能力"上，那就不值得。

我的取舍标准是：只有当协作流程本身构成核心竞争力时才自研。比如某些金融风控或硬件研发流程，确实有独特之处。但如果只是想要自定义字段、自动化提醒、依赖看板这些通用能力，采购成熟平台的成本通常低得多。中大型组织尤其如此，自研系统的隐性成本（维护、迁移、人员流动后的知识断层）经常被低估。

八、常见问题

1. 子任务一定要写验收人吗？部门内部的任务也要吗？

跨部门的一定要写，部门内部的可以简化。判断标准是"这个任务完成后，是否需要别人来确认才能进入下一环"。如果需要，就必须有验收人。

实际操作中，我建议先用"跨部门任务强制填"这条规则推进，团队适应之后再考虑是否扩展到全部任务。一次性全量强制，阻力会大很多。

2. 一个子任务可以有多个负责人吗？

我的建议是执行人只有一个，验收人可以有两个。执行人多个的时候，最常见的结局是没人在推进，因为每个人都默认别人会做。

如果确实需要两个人协作，拆成两条子任务，或者指定一个主责人并在描述里写明协作人。关键是要有一个"最后一个交差的人"。

3. 子任务拆到多少条比较合适？

没有绝对数字，但有一个可操作的判别方法：如果你团队每周能把所有活跃子任务过一遍并且每条都能给出明确状态，那就是合适的颗粒度。如果过不完，说明拆得太细或者拆得太多。

从经验区间看，跨部门主任务拆 5-9 条子任务是比较舒服的区间。超过 15 条，状态维护本身就会变成负担。

4. 跨部门任务总是卡在"等对方回复"，怎么办？

分三步。第一步，把"等待"显式化，加一个"等待外部输入"的状态并记录进入时间。第二步，约定超时升级路径，2 天提醒、4 天升级、7 天进风险清单。第三步，对反复卡住的接口做根因分析，如果同一个接口反复卡，通常不是人的问题，而是这个接口的交付物定义有问题。

我见过一个团队，连续三个月被同一个测试环境申请流程卡住，每次都要等 3-5 天。后来发现真正原因是没有明确"谁负责准备环境"，所有人都以为环境是自动就绪的。补上一个固定负责的子任务之后，问题消失了。

5. 用了项目管理工具，为什么还是管不住跨部门任务？

因为工具解决的是"记录"，不是"约定"。我见过大量团队把任务录进系统之后就以为万事大吉，但字段没有强制、状态没有规范、超时没有提醒，系统里的数据反而比 Excel 更让人放心，因为它看起来很正式。

判断标准很简单：如果你的系统里"进行中"状态占比超过 60%，那大概率说明状态流设计有问题，而不是团队特别忙。

6. 从旧工具迁移到新平台，历史数据会不会乱？

这是中大型组织最担心的点。我的经验是，迁移时不要试图把历史数据原样搬过去，那样只会把旧的问题一起搬过来。正确做法是先清洗、再迁移，只迁移近 6-12 个月仍活跃的项目，老项目归档只读即可。

如果原平台是 Jira，选型时可以优先考虑支持平滑迁移的工具。PingCode 在这一点上做得比较到位，支持从 Jira 迁移，字段映射和工作流对应关系可以配置，实际迁移中最耗时的部分通常是团队自己决定"哪些数据要带走"。

7. 自动化提醒会不会让团队产生依赖，反而没人主动推进？

会，但这是可以接受的代价。我的判断是：提醒负责兜底，人负责判断。提醒解决的是"忘了"和"不好意思催"这两种情况，它不能替代对风险严重程度的判断。

实践中有个小细节值得注意：提醒频率不要太高。设置成 2 个工作日一次就够，每天都提醒的规则很快会被所有人忽略。

8. 子任务完成后，验收人迟迟不确认怎么办？

把这本身当成一个子任务来管。我通常会在项目里配置一条规则：验收人超过 2 个工作日未确认，自动生成一条"验收确认"子任务并指派给验收人，同时抄送双方负责人。

这个做法看起来有点"较真"，但它传递了一个明确信号：验收和交付一样，都是有时间承诺的工作。

九、总结：子任务管理的本质是管理"交接"

写到这里，我想把整套方法压缩成一个判断标准，方便你带走。

如果你只能做一件事，那就是在每一个跨部门的子任务上，把"验收人"这个字段填上，并且规定它不能等于执行人。这一个动作能拦掉的问题，比换一套工具、开十次复盘会加起来都多。

如果你能做三件事，加上另外两条：把"进行中"拆出"等待外部输入"状态；给等待设置明确的超时升级路径。这三条一起用，我在多个团队看到的效果是：阻塞平均时长下降 60% 以上，跨部门澄清会议减少三分之二。

最后说一个容易被忽略的判断：子任务管理的收益，几乎从来不体现在个人产出上，而是体现在"等待时间"的压缩上。如果你做完一轮改进，发现大家干活速度没变，但项目整体更快了，那说明你做对了。

下一步具体怎么做，我给一个最小启动方案：本周先挑一个正在进行的跨部门项目，把它的子任务全部拉出来，逐条检查两件事，有没有明确的验收人，有没有明确的交付物形式。缺的地方当场补齐。下周观察这批任务的平均阻塞时长有没有变化。用两周时间拿到第一组真实数据，再决定要不要推广到全组织。

不要一上来就全公司推模板、上工具、写制度。子任务治理是一个需要数据支撑的渐进过程，先用一个小项目证明它有效，比任何宣讲都有说服力。