任务管理任务拆分教程：产品经理实操方法，避坑指南

2023 年我参与过一个 B 端 SaaS 的「批量导入 + 校验回滚」需求，立项时评估 6 周上线，实际用了 9 周零 3 天。复盘会上大部分人的第一反应是「后端接口不稳定」，但把 43 张任务卡摊开后能看清楚：真正拖垮项目的不是技术难度，而是任务拆分方式本身，前 5 周所有人都在各拆各的，直到第 6 周联调，才发现三条关键路径互相咬死。

这不是孤例。过去四年里我复盘过 23 个出现明显延期的项目，其中 17 个的根因可以追溯到拆分阶段，而不是执行阶段。任务拆分是产品经理最不起眼、却最影响交付节奏的一项基本功。

这篇内容我会把拆分这件事拆开讲：先给结论和判断标准，再还原真实场景，然后逐条拆解高频误区，给出一套可以直接落地的五步拆分法，最后用中大型组织（以 PingCode 服务的企业场景为例）的实践数据，说明不同团队规模下应该怎么取舍。如果你现在手上正好有一个「感觉哪里不对但说不上来」的需求，可以直接跳到第五节。

一、先给结论：拆分质量决定大半延期风险

在展开方法论之前，我先把最重要的三句话放在最前面。这三句话如果你只记住一句，我建议记住第一句。

1. 拆分的目标不是「变小」，而是「变确定」

大多数产品经理对任务拆分的理解停留在「把大需求切成小任务」，于是拼命往细里切，一张卡切到半天工。但如果追问一句「切完以后，你对交付时间的预估准了吗」，答案往往是否定的。

拆分的真实目标，是把「不知道要多久」变成「知道大概多久、并且知道哪里可能出问题」。它是一次不确定性管理动作，不是一个排版动作。任务卡变小只是副产品，不确定性下降才是主产品。

我在做需求评审时会问一个很直接的问题：这个需求里，最不确定的一环是什么，它被单独拆成一张任务卡了吗？如果答案是否定的，这次拆分就算不上完成。

2. 我用三个数字判断一次拆分是否合格

经验多了以后，判断拆分好坏其实不需要看任务卡列表，看三个数字就够了。

• 任务卡数量与交付周期的比值：一个 6 周的需求，最终产生 15 到 35 张可独立验收的任务卡是健康区间。低于 10 张说明拆得太粗，高于 60 张说明拆得太碎。
• 跨度超过 3 天的任务卡占比：健康值低于 20%。超过这个比例，说明颗粒度不够，风险会在后期集中爆发。
• 被明确标注依赖关系的任务卡占比：健康值高于 60%。如果大量任务卡之间是「隐性依赖」，排期表基本等于装饰品。

这三个数字不需要精确统计，在项目管理工具里按字段过滤一下就能看出来。我通常会在评审前花 10 分钟扫一遍，几乎每次都能提前发现两三个坑。

3. 一个反直觉的结论：拆得越细，总工期可能越长

很多人默认「任务越细，进度越可控」，这在小范围内成立，但超过某个临界点后会反转。原因有三：任务卡之间的衔接成本随数量线性上升；每张卡都要写描述、验收标准、对齐人，管理开销叠加；团队会把注意力从「把事做完」转移到「把卡关掉」。

下面这组数据来自我对 23 个项目的样本推演（不是严谨的行业统计，而是我参与项目的复盘汇总，仅作趋势参考）。可以看到总交付周期是一条 U 型曲线，最优区间落在 2 到 3 人天。

二、真实场景：一个 6 周需求为什么拖成 9 周

抽象结论说完，我把开头那个案例完整还原一遍。它包含了产品经理在拆分环节能踩的几乎所有典型问题。

1. 项目背景与最初的拆分方式

需求是给一个客户数据平台加「批量导入 + 校验 + 失败回滚」。业务价值很清晰：客户从手工录入 2000 条数据变成上传 Excel 自动处理，单次操作时间从 4 小时降到 20 分钟以内。

立项会上，我们按技术模块把需求拆成了 6 大块：前端上传组件、后端解析服务、校验规则引擎、数据库事务处理、错误报告页面、日志与监控。每块下面再细分，最终生成 43 张任务卡，分配给 7 个人。

看起来非常完整。问题在于，这 43 张卡里，没有任何一张能让用户「看到东西」。所有人都在各自的技术层里工作，直到第 6 周才有第一条端到端链路跑通。

2. 延期原因拆解

复盘时我把 21 天延期拆成了具体的构成。结果很有意思：真正写代码的时间只多花了 4 天，剩下 17 天全部消耗在协作、等待和返工上。

3. 产品经理在这中间的三次失职

复盘之后我给自己列了三条「失职清单」，后来每次拆分前都会对照检查一遍。

第一次失职：没有定义「什么叫做完」。43 张卡里，只有 9 张写了验收标准，其余都是「完成上传组件开发」这类无法验证的描述。于是「开发完了」和「能用了」之间，出现了巨大的解释空间。

第二次失职：没有识别关键路径。校验规则引擎是所有模块的公共依赖，但它在排期里被排在第 4 周才启动。如果当时把它识别为关键路径上的第一个任务，至少能省掉 6 天返工。

第三次失职：把拆分当成一次性动作。拆完之后直到联调才第二次打开任务列表。而需求在 9 周里变了 4 次，拆分结构一次都没跟着调整。

三、六个高频误区：我见过最多的拆分错误

把 23 个项目的复盘结论归纳一下，产品经理在拆分环节反复踩的坑集中在六类。我按出现频率排序，并对每一类给出识别信号和修正方式。

1. 误区一：按页面或技术模块拆，而不是按用户价值拆

这是最常见的一类。按页面拆的典型表述是「登录页开发」「列表页开发」「详情页开发」；按技术模块拆是「前端」「后端」「数据库」。这两种拆法都符合直觉，因为它们和开发分工天然对齐。

问题在于，这样拆出来的每一块都无法独立交付价值。登录页做完，用户依然不能完成任何一件事。整个需求的价值只在最后一块完成时才出现，所有风险都被压缩到项目末端。

识别信号：如果你发现没有任何一张任务卡完成后能被演示给业务方看，那大概率是按技术层拆的。

2. 误区二：把工时当成颗粒度

「这个任务 8 小时，那个任务 16 小时」，很多团队用预估工时来定义拆分粒度，认为切到 4 小时以下就是足够细。这会带来一个隐藏问题：工时是执行视角，不是交付视角。

一个 4 小时的「修复列表排序逻辑」任务，虽然工时很小，但它可能依赖另一个 4 小时的数据接口任务，而那个接口又依赖后端的权限改造。从交付视角看，这一串 4 小时任务加起来是 3 天的不可验证黑洞。

正确的做法是把「能否在 3 天内被验证」作为颗粒度标准，工时只作为排期参考。

3. 误区三：拆完不管依赖，等于没拆

我在一个跨 4 个团队的项目里见过这样的排期表：任务卡写了、负责人标了、时间填了，唯独没有依赖关系。结果三个团队的开发在同一个星期内都完成了自己的任务，然后集体卡在等待对方提供接口。

依赖关系不是排期表的装饰，它是关键路径的计算输入。没有依赖标注，你根本无法判断哪个任务延迟会真正影响交付日期。

4. 误区四：用拆分掩盖需求本身没想清楚

有些时候，任务拆不清楚的真正原因不是拆分方法不对，而是需求本身是模糊的。产品经理这时候如果硬拆，就会把模糊性转嫁给开发团队。

典型表现是任务卡里出现「支持灵活配置」「处理异常情况」「优化性能」这类词。这些词看起来专业，实际上是需求方的思考缺口。遇到这种情况，正确的动作是回去补需求，而不是继续拆。

5. 误区五：把拆分责任全部压在产品经理身上

另一种极端是产品经理独自拆完所有任务，然后甩给开发执行。这样拆出来的任务往往忽略技术实现上的耦合，开发看到后第一反应是「这拆得不对」，然后私下重新拆一遍，两套结构并行。

我的做法是：产品经理负责「拆什么」（价值切片、验收标准、优先级），技术负责人负责「怎么拆」（技术子任务、依赖关系、实现顺序）。两者在一次 60 分钟的拆分工作坊里完成，而不是各自闷头干。

6. 误区六：工具里拆得很漂亮，线下没对齐

这是最容易被低估的一类。任务卡在系统里结构清晰、字段齐全，但团队成员从没一起看过这张图。每个人只看到自己那一张卡，看不到自己在整条路径上的位置。

我在一个 40 人团队里推行的做法是：每次拆完，用 15 分钟开一个「走图会」，把任务依赖图投屏，从第一个任务走到最后一个，每个负责人用一句话说明自己的输入和输出。这个动作的成本极低，但能提前发现大量理解偏差。

四、专业判断逻辑：一套可复用的拆分决策框架

讲完误区，接下来是我实际在用的一套判断逻辑。它不是教科书式的原则罗列，而是把几个经典方法改良成中文团队能直接用的版本。

1. INVEST 原则在中文研发团队里的三个水土不服

INVEST 原则（Independent、Negotiable、Valuable、Estimable、Small、Testable）是拆分领域的经典框架，方向没错，但直接套用会遇到三个问题。

第一，「Independent」在真实系统里几乎不存在。B 端系统里任何功能都会依赖权限、日志、配置中心等公共能力。强行追求独立，只会让任务卡变成虚假描述。

第二，「Small」没有给出量化标准。多小算小？半天还是一周？没有统一标准，团队里的理解就会千差万别。

第三，「Valuable」对内部系统不适用。很多技术任务（比如数据库分表）的价值用户感知不到，但必须做。

我的改良版本是：把 Independent 换成「依赖可见」，把 Small 换成「3 天内可验证」，把 Valuable 换成「有明确验收判据」。这三条对所有类型的任务都成立。

2. 纵向切片：按用户能感知的完整路径来切

纵向切片是解决「按模块拆」问题的核心手段。它的定义很简单：每一刀切下去，都要包含从入口到结果的一条完整路径，哪怕这条路径只覆盖部分场景。

比如前面那个批量导入需求，纵向切片的第一刀可以是：只支持 CSV 格式、只校验 3 条规则、失败时整体回滚、不提供错误报告页面。这一片完成后，用户已经能完成一次真实的导入操作，虽然能力有限。

纵向切片的好处是：最大的风险（端到端链路能否跑通）在第一周就被验证了。如果方案本身有问题，此时调整成本远低于第 6 周。

3. 拆分粒度的三档分级标准

我把粒度分成三档，团队里统一口径，避免每次都要争论「这个要不要再拆」。

需要说明的是，这三档不是固定规则，而是沟通语言。当有人说「这个要不要拆细一点」，团队能立刻对齐到具体的档位，而不是凭感觉争论。

4. 依赖识别：用轻量级依赖矩阵代替口头同步

依赖识别不需要复杂工具。我的做法是画一个二维矩阵：行是任务卡，列是负责人，交叉格子标记「输入依赖」和「输出交付」。

标记完成后，任何一行有两个以上输入依赖的任务，自动进入关键路径候选。这些任务需要在排期时优先启动，而不是等前面所有任务都做完。

这个动作在 20 张卡以内的项目里，用白板 15 分钟就能完成，比在系统里填字段还快。

5. 验收标准必须跟着任务一起拆

这是我最强调的一条。没有验收标准的任务卡，不是任务卡，是待办事项。

验收标准要满足三个条件：可观察（能演示或能测量）、可否定（存在明确的失败情形）、有边界（说明了不做什么）。比如「支持数据导入」不合格，「支持 CSV 文件导入，单文件不超过 5 万行，重复数据保留最早一条，失败时整体回滚」才是合格的。

五、五步拆分法：可以直接抄的实操流程

下面这套流程是我目前的标准动作，一个中等复杂度需求（4-8 周）大概需要 2 到 3 小时完成，分两次进行：前半段产品经理独立做，后半段和研发一起做。

1. 第一步：写一句话价值假设

在拆任何任务之前，先用一句话写清楚：这个需求上线后，谁会因为什么变化而受益，变化幅度大概是多少。

格式建议：「{角色} 在 {场景} 下，从 {现状} 变为 {目标}，衡量指标是 {指标}」。这句话写不出来，说明需求还没想清楚，回去补需求。

2. 第二步：做不确定性盘点

把所有「我不确定」的地方列出来，不区分是技术问题还是业务问题。常见的不确定来源有四类：外部接口是否可用、数据量级是否超预期、业务规则是否有例外、性能是否达标。

这一步的产出是一张风险清单。清单上的每一项，后面都必须对应至少一张任务卡，或者一个明确的验证动作。没有对应物的风险，就是项目里的定时炸弹。

3. 第三步：纵向切片，切成 3 天内可验证的单元

按照用户可感知的完整路径切片。第一刀通常切「最小可用闭环」：最主流的场景、最简单的规则、最少的异常处理。

每一片完成后要能满足两个条件：业务方能看到东西；团队能判断方案是否可行。如果某一片需要 5 天以上，说明切得还不够。

4. 第四步：标注依赖与关键路径

用前面说的依赖矩阵，标出每一项的输入和输出。然后找出最长依赖链，这就是关键路径。

关键路径上的任务有两个处理原则：优先启动（哪怕它排在第 5 个优先级）、粒度降一档（用细粒度拆分，缩短反馈周期）。

5. 第五步：为每个任务定义验收与回滚

最后一步是补齐任务卡的字段。我在 PingCode 里配置的任务卡模板大概是这样，字段不多但每个都有用：

任务卡模板字段（可直接在项目管理工具中配置）
title: 动词 + 对象 + 边界（例：实现 CSV 导入的重复数据保留最早一条规则）

value_slice: 属于哪个纵向切片（例：切片 2 – 校验规则扩展）

acceptance: 验收判据，3 条以内，必须可否定

上传含 100 条重复数据的 CSV，导入后保留最早一条，其余标记跳过

错误报告中重复数据条目数 = 100

单文件 5 万行导入耗时 < 90 秒

depends_on: 输入依赖的任务 ID

delivers_to: 输出交付给哪些任务

rollback: 失败时的回滚动作（数据层面 / 功能层面）

estimate: 预估人天（2-3 人天为默认档）

owner: 单一负责人

verify_by: 谁来验收，什么时间验收

这套模板的价值在于，它把「拆分」从一个抽象动作变成了一组必须填写的字段。字段填不满，任务卡就无法进入迭代。

六、案例与数据观察：中大型组织里的拆分实践

前面讲的方法在小团队里可以靠口头同步完成，但在 100 人以上的组织里会失效。这一节我用 PingCode 服务的中大型企业场景来讲讲差异，因为组织规模是拆分方法必须适配的关键变量。

1. 中大型组织的拆分复杂度来自哪里

PingCode 主要服务中大型企业及 100 人以上组织，这类客户的拆分复杂度和小团队完全不是一个量级。我观察到的差异主要有三点。

第一，任务卡不只是给自己团队看的。一张任务卡可能要经过产品、研发、测试、安全、运维、合规六个角色的流转，字段少了根本流转不下去。

第二，拆分层级从两层变成四层。小团队是「需求 → 任务」两层，中大型组织往往是「业务目标 → 需求 → 用户故事 → 技术任务」四层，每层都要有明确的收敛规则，否则信息在传递中失真。

第三，跨团队依赖成为常态。一个需求平均涉及 3 到 5 个团队，依赖管理的复杂度远超任务拆分本身。

2. 从 Jira 迁移时，拆分结构应该怎么重构

很多团队在用 PingCode 替代原有工具时（PingCode 支持 Jira 平滑迁移），会把注意力放在数据搬运上，忽略了一个更重要的动作：借迁移的机会重构成不合理的拆分结构。

我的建议是分三步走。第一步，先只迁移数据，保持原有结构不变，让团队适应新工具的操作习惯，这个阶段大概 2 周。

第二步，做一次拆分结构审计。随机抽取 30 张历史任务卡，检查三个指标：跨度超过 3 天的占比、有验收标准的占比、有明确依赖标注的占比。这三个数字会直接暴露历史遗留问题。

第三步，在新一轮迭代中按新的拆分标准执行，老数据保持原样不做追溯修改。追溯修改历史任务卡是纯粹的浪费，它不产生任何交付价值。

3. 一组可对比的拆分改造数据

下面是三家不同规模企业在调整拆分标准后，我跟踪到的指标变化。数据来自客户侧的迭代回顾记录，属于脱敏后的区间统计，不是精确的单一客户数据。

4. 私有化部署与合规约束对拆分的影响

还有一类特殊约束值得单独说。在金融、政企等对数据安全要求高的行业里，系统通常需要私有化部署，这意味着任务拆分必须额外考虑三件事：环境准备任务（独立环境搭建、网络策略开通）、数据脱敏任务（测试数据不能用生产数据）、发布流程任务（走内部审批而不是自动流水线）。

这三类任务如果不在拆分阶段列出来，后期会以「环境还没好」「审批还没过」的形式突然出现，平均每个迭代会吃掉 2 到 3 天。我在拆分时会把它们统一标记为「非功能前置任务」，并在排期时放在迭代最前面。

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

方法讲完，接下来是最实际的部分：不同团队规模、不同场景下，应该怎么落地。我把常见的五种情况分别列出来。

1. 十人以下小团队

不要建立复杂的拆分规范。你的目标是 20 分钟内拆完一个需求，而不是拆得完美。

• 只做两层拆分：需求 → 任务
• 每张任务卡必须写一句验收标准，不需要模板
• 用白板或工具的任务板做依赖标注，不做矩阵
• 每天站会用 5 分钟确认关键路径上的任务是否按时

小团队最大的风险是「流程过重」，我见过 8 人团队花两小时开拆分评审会，这是典型的资源错配。

2. 三十到一百人团队

这个规模是拆分规范收益最大的区间。团队已经跨过了口头同步的临界点，但还没形成顽固的流程惯性。

建议的动作是：把前面那套任务卡模板落到项目管理工具里，作为必填字段；每周固定一次 60 分钟的拆分工作坊，产品和研发一起参加；对关键路径上的任务强制使用细粒度拆分。

这个阶段最重要的不是方法本身，而是让团队形成统一的拆分语言。当有人说「这个要拆到细粒度」，所有人都知道是 0.5 到 1 人天，沟通成本会大幅下降。

3. 一百人以上中大型组织

这个规模的挑战从「怎么拆」变成了「怎么让 100 个人用同一种方式拆」。建议做三件事。

第一，建立四层拆分结构，并定义每层的收敛规则。比如业务目标层每个目标最多拆 5 个需求，需求层每个最多拆 8 个用户故事。

第二，把拆分质量指标纳入迭代回顾的固定议程。不要考核，只做观测。一旦变成考核，团队会开始刷数据。

第三，选择支持完整拆分链路的工具平台。像 PingCode 这类支持需求、任务、测试、缺陷一体化的平台，能让拆分结构在上下游之间保持一致；如果涉及原有工具的替换，支持从 Jira 平滑迁移会显著降低切换成本，这也是不少中大型团队做国产替代时的主要考量。

4. 跨团队、跨系统依赖场景

跨团队场景下，拆分的第一步不是切任务，而是先签接口契约。把输入输出的数据结构、字段含义、异常处理方式书面确定下来，再各自拆任务。

我通常会把接口契约本身作为一张前置任务卡，负责人是两个团队的技术负责人，验收标准是双方签字确认的接口文档。这张卡不完成，下游任务不开工。

5. 遗留系统改造场景

遗留系统的拆分逻辑要反过来：先拆「不动什么」，再拆「动什么」。

因为遗留系统最大的风险不是新功能做不出来，而是改坏了原有功能。我建议在拆分时明确圈定影响范围，对每一项改动都配一个回归测试任务，并且把回归测试的优先级排在新功能之上。

八、取舍：什么时候不拆、什么时候必须拆细

方法论的最后一部分是边界。任何方法都有不适用的场景，拆分也一样。

1. 不该继续拆细的四种情况

• 技术方案还在验证阶段：此时拆得越细，越容易锁死思路，应该先做一个时间盒的原型验证
• 需求本身还在讨论中：需求没定就拆任务，拆出来的都是废卡
• 任务已经短到无法独立验收：比如「修改一个字段名」，这种任务直接合并到父任务里
• 团队正处于紧急故障处理状态：此时优先恢复服务，事后补拆分记录而不是事前拆

2. 必须拆细的四种情况

• 关键路径上的任务：任何延迟都会直接影响交付日期，必须缩短反馈周期
• 多人协作的公共模块：边界不清会导致互相等待，拆细能明确责任
• 高风险的技术改造：比如数据库迁移、核心链路重构，需要每步可回滚
• 跨团队交付的任务：依赖关系复杂，粒度越细，协调越容易

3. 一张决策对照表

使用这张表的方式很简单：五个维度里如果「倾向拆细」的项达到 3 个以上，就按细粒度处理；只有 1 个或 0 个，就保持粗粒度。这样可以避免每次都要开会讨论。

九、常见问题

下面这几个问题是我在内部培训和客户沟通中被问得最多的，答案带有比较强的场景依赖，请结合自己团队的情况取用。

1. 拆分到多细才算合适，有没有一个通用数字？

没有通用数字，但有一个通用判据：任何一张任务卡，都应该能在 3 个工作日内被演示或被测量。这个 3 天不是拍脑袋定的，它大致等于「问题暴露后还有时间在本迭代内修复」的最大窗口期。超过 3 天，问题就会溢出到下一个迭代，成本翻倍。

2. 产品经理应该拆到任务层，还是只拆到需求层？

我的答案是拆到「用户故事」层，技术任务层交给研发负责人。产品经理的核心产出是价值切片和验收标准，这两项在用户故事层最清晰。继续往下拆到技术任务，产品经理既没有足够信息，也容易越界。

例外情况是团队没有专职技术负责人，或者需求涉及强合规要求，此时产品经理需要参与到技术任务层，但依然应该和研发一起拆，而不是单独拆。

3. 敏捷和瀑布两种模式下，拆分方法有什么不同？

核心逻辑是一样的，差异在于拆分的时机。敏捷模式下拆分是连续的，每个迭代开始前拆一次，随需求变化调整；瀑布模式下拆分是一次性的，需要在开发启动前完成全部拆分。

瀑布模式的固有风险是：拆分时信息最少，却要求拆得最全。所以我在瀑布项目里会额外做一件事，预留 15% 的工期作为「拆分修正缓冲」，专门应对拆分阶段没预见到的任务。

4. 需求频繁变更时，之前的拆分是不是白做了？

不是。拆分产生的最大资产不是任务卡列表，而是对需求结构的理解。需求变更时，你不需要重新理解整个需求，只需要定位到受影响的那几个切片。

我在处理频繁变更的需求时有个习惯：把变更记录在对应切片上，而不是重建整个拆分结构。这样迭代结束时能清楚看到哪个切片变更最多，进而判断是不是需求源头有问题。

5. 团队不愿意按新标准拆分，怎么办？

大部分情况下，抵触不是因为方法不好，而是因为团队没看到收益。我建议先在一个小范围做试点：选一个中等复杂度的需求，用新方法拆一遍，然后对比这个迭代和前几个迭代的返工情况。

数据出来之后再推广，阻力会小很多。另外要避免一件事：不要在试点阶段就把它做成强制规范，那样只会得到形式化的执行。

6. 拆分质量能不能量化考核？

可以量化，但不建议作为考核指标。我见过团队为了「任务卡跨度不超过 3 天」这个指标，把一张 4 天的任务硬拆成两张，结果两张卡之间还有强依赖，等于什么都没改变。

拆分质量适合作为回顾会的讨论素材，不适合作为个人绩效指标。一旦变成考核，团队优化的就是指标本身，而不是交付质量。

十、写在最后：拆分的本质是降低团队的认知负荷

回到开头那个 6 周拖成 9 周的项目。如果重来一次，我不会去优化排期表，也不会去催进度，我会做三件事：把需求纵向切成 4 个可演示的切片，把校验规则引擎提到第一周启动，给每张任务卡写上三条可否定的验收标准。

这三件事加起来花不了 3 个小时，但能省下至少 15 天的返工。这就是拆分这件事的杠杆率。

我在这篇文章里最想传递的独特观点是：任务拆分不是项目管理流程的一个环节，而是一次认知负荷的重新分配。拆分的目的是让每个人在任何时刻只需要理解自己那一小块，同时清楚自己那一块在整体中的位置。做不到后者，拆分就退化成了待办清单。

另一个常被忽略的判断是：拆分粒度存在明确的最优区间，小于 2 人天和大于 5 人天都会变差。不要迷信「越细越好」，也不要为了省事不拆。标准粒度是通用解，细粒度是特定场景的专项工具。

如果你准备从明天开始改，我建议按这个顺序动：

1. 先选一个正在做的中等复杂度需求，用五步拆分法重拆一遍，不要动其他需求
2. 把「3 天内可验证」和「三条可否定验收标准」作为两条硬性规则，加到任务卡模板里
3. 在下一个迭代回顾会上，观测三个数字：跨度超 3 天的任务占比、有验收标准的任务占比、有依赖标注的任务占比
4. 根据这三个数字决定要不要扩大范围，而不是一次性改掉所有流程

拆分能力的提升是渐进的，改两次之后你会发现，团队开会的时间变少了，因为大部分的「对齐」已经在拆分阶段完成了。