任务拆分最佳实践：管理层任务管理入门指南，常见问题

去年 Q3，我帮一家 180 人的 SaaS 公司做年中复盘，看到一组让我后背发凉的数字：CEO 在 1 月全员会上宣布的“今年把客户成功体系建起来”，在公司任务系统里被拆成了 47 个任务，分布在 6 个部门，挂着 3 个不同的负责人名头。到 9 月底，47 个任务里有 28 个状态是“进行中”，其中 19 个的最后更新时间停留在 6 月之前。

更麻烦的是，当我逐个问“这个任务做完意味着什么”时，18 个负责人里有 11 个给出的是动作描述而不是结果描述，“每周和客户开一次会”“整理一份文档”“推动产品侧优化”。没有人能说清“做完”的判定标准是什么。

这不是执行力问题，也不是工具问题，这是任务拆分的维度选错了。管理层任务拆分的失败，绝大多数时候不是拆得不够细，而是拆到了“谁在忙”而不是“什么会变”。这篇文章我会把手上的复盘数据、踩过的坑和一套可落地的判断方法全部摊开，帮你把任务拆分这件事从“会上分活”变成“可管理的交付结构”。

一、先说结论：管理层任务拆分的四条硬规则

在展开细节之前，我先把结论放在前面。这四条规则是我在 60 多个跨部门任务复盘里反复验证过的，它们不依赖于你用什么工具，也不依赖于团队规模。

1. 拆到“一个人、一个交付物、一个验收标准”

一个任务只能有一个负责人，不能是“XX 团队牵头、YY 团队配合”这种写法。配合关系要表达在依赖字段里，而不是塞进负责人字段。

同时，每个任务必须能回答“交付物是什么”，而且这个交付物必须是名词，不是动词。“推进数据打通”不是交付物，“一张包含 12 个客户字段、每日 8 点更新的客户健康度看板”才是。

验收标准是管理层任务最容易缺失、也最致命的字段。一线任务可以不写验收标准，因为代码能不能跑、测试能不能过本身就是标准；管理层任务没有天然标准，所以必须显式写出来。

2. 拆到“能被估算”，而不是“能被描述”

我见过太多团队把任务拆得很漂亮，但每个任务都估不出工时。判断标准很简单：让一个不参与这个任务的人，在只看任务描述的情况下，能给出一个误差在 ±50% 以内的工时区间。如果做不到，说明这个任务里还藏着未拆解的决策点。

管理层任务的合理工时区间，比一线任务大得多。一线开发任务通常落在 4 小时到 3 人天之间，而管理层任务我建议控制在 2 到 10 人天。低于 2 人天的管理层任务，管理成本会超过它的价值；高于 10 人天，你就失去了通过进度反推风险的机会。

3. 拆到“依赖可见”，而不是拆到“人人有活干”

管理层任务的最大风险从来不是工作量，而是依赖。市场等产品、产品等数据、数据等 IT 开权限，这些依赖如果不显式建模，就会在真正卡住的时候才被发现。

我建议用有向无环图（DAG）的思维去组织依赖关系，而不是用列表。列表只能表达顺序，不能表达“A 和 B 同时等 C，而 D 只等 B”这种结构。在项目管理系统里，依赖关系应该是字段，不是备注里的一句话。

4. 管理层要先拆自己的任务，再拆别人的

这是我最坚持的一条。当一个管理者要求团队“把任务拆细一点”时，如果他自己那一条“完成组织架构调整”还挂在那里半年没动，团队很快就会学会表演式拆分。

管理层的任务往往才是真正的关键路径。你的“决策是否拍板”，可能决定下游 30 个任务能不能启动。先拆自己，是一种管理信号，也是一种风险排查。

二、为什么管理层的任务拆分和一线执行层不是一回事

把一线任务的拆分方法直接套用到管理层任务上，是很多团队翻车的起点。两者的输入、约束和失败模式都不一样。

1. 管理层的输入是“模糊目标 + 政治约束”

一线任务的输入通常是明确的需求文档或缺陷单，边界相对清晰。管理层的输入往往是一句话：“把交付效率提上去”“今年要做出海”“客户成功体系要建起来”。

这些目标的问题不在于模糊，而在于它们天然携带多个利益相关方的不同解读。CEO 说的“出海”可能是收入结构，销售总监理解的“出海”可能是渠道铺设，产品负责人以为的“出海”可能是多语言版本。任务拆分的第一价值，不是分配工作，而是把不同人的解读逼到同一个桌面上对齐。

所以我在做管理层任务拆分时，第一步从来不是写任务，而是写“这句话在三个不同角色眼里的含义”，把分歧显性化。

2. 我三次踩坑的完整记录

（1）2019 年，我主导一个 45 人的增长项目，把目标拆成 30 个任务分给 6 个小组。三个月后复盘，30 个任务完成 22 个，但核心指标只涨了 4%。原因是所有任务都是“活动型任务”，发多少篇内容、跑多少场活动，没有任何一个任务对结果负责。

（2）2021 年，我把任务拆到极细，一个战略项目拆出 120 个子任务。结果是团队每天在更新状态上花掉 40 分钟，项目经理变成了状态收集员，而真正的风险，第三方数据接口的授权审批，因为被拆散在 5 个任务里，反而没有人看到全貌。

（3）2023 年，我尝试只拆到“季度目标 + 月度检查点”的粒度，把执行细节完全交给团队。结果是跨团队的接口全部错位：A 团队 7 月才需要的数据，B 团队 5 月才刚开始采集，中间两个月的空窗没有任何人管。

三次踩坑的共同结论是：拆分的粒度不是问题，拆分的“维度”才是问题。按活动拆、按动作拆、按部门拆，都会失败；按交付物和依赖拆，才可能成功。

3. 管理层任务的三分法：承诺型、探索型、运营型

这是我觉得最实用、也是最少被讨论的一个区分。管理层手里的任务根本不是同一种东西，用同一套拆分方法处理它们必然出错。

承诺型任务：有明确对外交付时间和对象，比如“6 月 30 日前完成 ISO 27001 认证”。这类任务必须拆到可验收、可倒排期，任何不确定性都要显式列为风险。

探索型任务：目标是获取信息而不是交付成果，比如“验证东南亚市场是否值得投入”。这类任务不要拆成执行步骤，而要拆成“假设，验证方式，判断标准”三件套，并且明确“什么结果会导致我们放弃”。

运营型任务：周期性重复发生，比如月度经营分析会、季度绩效校准。这类任务的关键不是拆解，而是固化模板和责任人轮转机制。

把探索型任务当承诺型拆，团队会为了交付而交付，做出一个漂亮但没人用的报告；把承诺型任务当探索型管，到了截止日期才发现根本没有交付物。先给任务分类，再决定拆分方式，这一步不能省。

三、拆解常见误区：七个我复盘过的坑

下面七个误区，几乎每一个我都在真实项目里见过，其中四个我自己也犯过。它们的共同特点是：在拆分的那一刻看起来都很合理，代价要到两三个月后才显现。

1. 按“人”拆而不是按“交付物”拆

这是最高频的问题。“张三负责数据部分，李四负责前端部分”，看起来分工明确，实际上把交付物切碎了。数据部分什么时候算做完？前端部分依赖数据到什么程度？没有交付物定义，这两个问题永远没有答案。

正确的顺序是：先确定交付物，再匹配人。如果某个交付物找不到合适的负责人，那是一个组织能力问题，不应该通过模糊任务描述来掩盖。

2. 把“沟通协调”当成一个任务

“与相关部门沟通对齐方案”这类任务，我建议直接删掉。它不是交付物，它是所有任务都必须附带的行为。真正需要被管理的是“对齐后产出的那份共识文档”，而不是“沟通”这个动作。

如果一件事的核心产出确实就是共识，那也要写清楚：谁签字、签在哪份文档上、什么时候签。

3. 拆到 8 小时以下就停下

有些团队走向另一个极端，把管理层任务拆成 4 小时的颗粒度。结果是三层子任务嵌套，每周要花大量时间维护状态。

我的经验值是：管理层任务的拆分深度以“能识别出独立风险”为界，不以“能填满一天”为界。一个任务如果它的主要风险和其他任务完全一样，就不需要再拆。

4. 只拆执行，不拆验收

这是我在第一节就强调过的问题，但值得在这里再说一次，因为它造成的损失最大。一个没有验收标准的任务，本质上是一个无限期的开放任务。

我在项目里推过一个硬性规则：没有验收标准的任务不允许进入“进行中”状态。这条规则刚开始被抱怨最多，但也是被保留下来最多的一条。

5. 认为“拆分粒度越细，控制力越强”

这是个反常识的判断：拆分粒度和控制力之间不是线性关系，而是一条先升后降的曲线。拆得太粗，你失去可视性；拆得太细，你失去判断力，因为噪音淹没了信号。

当任务数超过团队人数的 3 到 5 倍时，我通常建议先停下来做一次合并，而不是继续往下拆。

6. 拆完就冻结，不允许变更

拆分结果是假设，不是事实。项目进行到 40% 时发现某个依赖不存在，正确的做法是修改任务结构，而不是硬着头皮执行原计划。

我的做法是设一个“结构变更窗口”：每个迭代或每个双周，允许集中调整一次任务结构，其余时间不允许随意改动。这既保护了稳定性，也保留了修正空间。

7. 用工具能力代替管理判断

见过一些团队，上了功能很强的项目管理平台，就把拆分工作完全交给工具模板。工具能给你工作项层级、能给你自定义字段，但它不知道你的业务里哪个依赖最危险。

工具解决的是“拆分结果能不能被看见”，管理判断解决的是“应该按什么维度拆”。顺序搞反了，再贵的工具也只是把错误的结构记录得更整齐。

四、专业判断逻辑：粒度是否合适的五个检验

很多人问我“到底该拆多细”，这个问题没有绝对答案，但有一组可执行的检验。任何一个任务只要不能同时通过下面五项检验，就说明它还不到位。

1. 交付物检验

问一个问题：“这个任务完成后，我会拿到什么东西？”如果答案里出现的是动词（推进、优化、支持、协调），而不是名词（一份文档、一个看板、一个已签署的合同、一套已上线的流程），说明交付物不明确。

更严格一点：交付物最好能被一个第三人独立检查。如果不能，说明它还是一个主观判断。

2. 估算检验

找一个不参与该任务的人，让他只看描述给出工时区间。如果他的区间跨度超过 3 倍（比如 3 天到 10 天），说明任务里还有未拆解的决策点或者隐藏依赖。

这个方法我在无数次评审里用过，效果比让负责人自己解释要好得多，因为外部人没有“我知道大概怎么回事”的错觉。

3. 依赖检验

每个任务要能回答三个问题：我依赖谁？谁依赖我？如果我延迟 5 天，谁会受影响？三个问题里有任何一个答不上来，就说明依赖关系没有被完整建模。

依赖检验的价值在于提前暴露关键路径，而不是在项目延期后追责。我通常会把依赖关系画成一张图，然后找那些“入度为零且出度很高”的节点，它们是最容易成为瓶颈的地方。

4. 验收检验

验收标准要满足两个条件：可观察、可争议。可观察意味着有明确的观察方式（数据、文档、签字、上线），可争议意味着存在“没达到”的可能性。

“提升客户满意度”不是验收标准，因为它不可观察；“客户满意度调研分数从 7.2 提升到 8.0，调研样本不少于 200 份”是可观察的，而且存在没达到的可能，这才是合格的验收标准。

5. 复盘检验

最后一个检验是：这个任务在结束后，能不能用来回答“我们当初的假设对不对”。如果一个任务做完之后，除了“做完了”之外学不到任何东西，它对组织能力的积累价值就很低。

我倾向于在每个任务里加一个“复盘问题”字段，只写一句：如果重来一次，我们最应该改变什么？这个字段在任务完成时才填，成本很低，但积累了组织记忆。

6. 一个可直接套用的任务描述模板

下面这个结构我用了三年，覆盖过研发、市场、供应链、职能等多种场景。写成结构化格式是为了说明字段之间的关系，你在实际工具里把它落成字段即可。

task:
name: 客户成功体系第一阶段上线

五、案例与数据观察：在 PingCode 上重构一个 300 人研发组织的任务树

前面讲的都是方法，这一节我把一个完整的落地过程摊开讲。案例主体是一家 300 人规模的研发组织，5 条产品线、12 个 Scrum 团队，业务横跨金融和制造两个行业，对数据不出内网有硬性要求。

1. 改造前的状态：三层结构混用，字段形同虚设

他们当时已经在用项目管理平台，结构上其实是四层：史诗、需求、任务、子任务。但实际使用中，团队的划线方式是“大需求叫史诗，小需求叫任务”，层级之间没有稳定的语义差别。

更关键的是两个缺失：一是没有“验收标准”字段，完成判定靠负责人自己说；二是依赖关系全靠备注，评审会上用口头方式确认。我抽查了 60 个跨团队任务，其中 23 个存在未被记录的依赖，占比接近 38%。

还有一个隐性成本：因为结构不稳定，他们的迭代承诺达成率长期在 60% 上下浮动，团队形成了“反正估不准”的心理预期，估算这件事本身被放弃了。

2. 具体做法：把维度固定下来，把字段变成纪律

（1）重定义工作项类型语义。史诗层只放跨季度、跨产品线的战略主题；需求层只放可验收的用户价值单元；任务层只放单人可完成的交付切片；子任务层只用于技术实现拆解，不用于管理层可见范围。

（2）把“验收标准”设为需求层和任务层的必填字段。这一条阻力最大，我们花了两周时间做培训，并且给出了 12 个写得好的范例和 6 个反例。

（3）把依赖关系从备注迁移到结构化字段，并且配置了关键路径视图。项目经理每周一只看两张图：本周新增依赖、本周阻塞依赖。

（4）区分迭代与里程碑的用途。迭代用于团队节奏，里程碑用于跨团队对齐，避免用同一个时间容器承载两种完全不同的管理意图。

（5）明确升级路径。当依赖阻塞超过 3 个工作日，自动升级到产品线负责人；超过 5 个工作日，升级到项目管理办公室。这条规则让很多原本会烂在群聊里的问题被显性化。

顺便说一句，他们选择 PingCode 的一个重要原因是私有化部署，代码、需求文档和客户数据必须全部留在内网，这对金融和制造客户是硬约束。另外他们此前长期使用 Jira，历史项目、附件、字段和权限关系需要平滑迁移，迁移过程的完整性直接决定了这次改造能不能被团队接受。对中大型组织来说，工具选型的核心不是功能多少，而是能不能承接你已有的管理资产。

3. 三个季度的数据变化

下面这组数据来自我为他们做的前后对比记录，口径统一为“改造前 3 个月”与“改造后第 2 到第 4 个月”，已做脱敏处理。这是单案例样本，不能直接当成行业基准，但趋势值得参考。

有两个结果超出了我的预期。第一是人均状态维护耗时反而减半，我原以为增加字段会加重负担，实际是因为结构稳定之后，重复沟通和返工减少带来的净收益。第二是交付周期的改善主要来自依赖漏检下降，而不是单个任务执行变快。

这印证了我在第一节的判断：管理层任务的效率瓶颈在接口，不在个体。你花在处理依赖上的每一分钟，回报都高于花在催促个体上的十分钟。

4. 私有化部署与历史迁移的取舍点

如果你所在的组织也在考虑类似改造，有两个决策点需要提前想清楚。

第一是部署形态。涉及客户数据、源代码、财务信息的组织，私有化部署基本是硬需求，代价是运维成本和升级节奏由自己承担。如果你的业务不涉及敏感数据，SaaS 形态的迭代速度和运维负担会友好得多。

第二是历史数据迁移。我的建议是迁移结构，慎重迁移状态。历史项目的工作项、字段、附件、权限关系应该完整迁移，因为它们是组织记忆；但已经关闭的历史迭代里的状态流转，不必强行还原成新流程，否则你会把旧流程的混乱一起带进新体系。

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

方法是一样的，但落地节奏必须跟组织规模匹配。下面是按团队规模分档的建议，你可以直接对号入座。

1. 10 人以下团队：不要建体系，建习惯

这个规模下，任何流程都会被沟通成本抵消。你唯一需要养成的习惯是：每个任务写清楚交付物和负责人，两句话就够。

不要引入多层工作项，不要设置复杂的自定义字段，不要做依赖图。你们的依赖关系靠每天站会就能覆盖。这个阶段的目标是让“交付物”这个概念成为团队默认语言。

2. 10 到 50 人团队：建立任务层的最小标准

开始需要结构了。建议设两层：需求层和任务层，任务层强制两个字段，交付物、验收标准。依赖关系可以先用简单的“阻塞”标记，不必上关键路径视图。

这个阶段最容易犯的错是过早引入史诗层，导致大家为了“看起来完整”而把中等需求塞进战略层。等你有超过 3 条独立产品线时再考虑加这一层。

3. 50 到 200 人团队：把依赖当成一等公民

这是管理复杂度快速上升的区间，跨团队接口开始成为主要风险来源。建议做三件事：一是依赖关系结构化成字段；二是设立每周一次的依赖评审，只看阻塞项；三是把验收标准的完备率作为流程健康度指标之一。

这个规模下，工具的选择开始有实际影响。如果你需要私有化部署、需要从既有平台平滑迁移历史项目，那要提前评估迁移方案，因为迁移失败会让整个改造失去团队信任。PingCode 在这类场景里是比较常见的选择，它面向中大型企业、支持私有化部署，同时提供从 Jira 迁移的路径，对 100 人以上组织的历史资产承接比较友好。

4. 200 人以上或集团型组织：先统一语言，再统一工具

这个规模下的失败往往不是工具问题，而是各业务单元对“任务”“需求”“史诗”的定义各不相同。上来就统一工具的后果是，所有人在同一个系统里用不同的语言说话。

我的建议是先做一轮“术语对齐工作坊”，把四层工作项的定义、边界和典型例子写成文档，各方签字确认，再去做工具配置。这一步会多花两到三周，但能省掉后面半年的扯皮。

同时建议配置升级路径和度量看板：依赖阻塞超时自动升级、验收标准缺失率周报、任务数与团队人数比值监控。这三个指标能提前预警大部分结构性问题。

七、不同情况下的取舍

讲完建议，必须讲取舍。任何管理动作都有代价，只说好处的方法论是不负责任的。下面五组取舍是我在实际项目里反复遇到的。

1. 粒度精细度 vs 管理带宽成本

拆得越细，可视性越强，但维护成本上升。我的经验拐点在“任务数 = 团队人数 × 3 到 5 倍”。低于这个区间，你可以放心增加粒度；高于这个区间，每增加一个任务，带来的噪音多于信息。

如果组织正处在高压交付期，我建议主动放宽粒度，把管理带宽留给风险处理。如果处在复盘改进期，可以适当收紧粒度，换取更清晰的度量。

2. 标准化 vs 业务灵活性

统一的任务结构便于横向比较和资源调配，代价是某些业务单元的个性化需求被压制。我的判断原则是：涉及跨团队协作的部分必须标准化，团队内部的执行拆解可以自由。

具体做法是划定一条线，需求层及以上强制统一，任务层及以下允许团队自定义字段。这条线让跨团队对齐和团队自治可以共存。

3. 工具强度 vs 流程纪律

买一个功能强大的平台，和让团队真正按纪律使用它，是两件事。我见过太多组织花大价钱采购，最后只用到 20% 的功能，因为配套的纪律没有建立。

如果你的组织纪律基础较弱，建议先用最小功能集跑三个月，把“验收标准必填”这一条真正落地，再逐步增加依赖管理和度量看板。工具的价值是被流程纪律激活的，不是被功能清单激活的。

4. 私有化部署 vs SaaS 的运维负担

私有化部署解决了数据合规和内部审计问题，代价是版本升级、环境维护、备份恢复都需要自己承担人力。粗略估算，一套中等规模私有化环境，每月需要 0.3 到 0.5 个专职人力维护。

判断标准很直接：如果你的业务涉及客户隐私数据、源代码资产或行业监管要求，这项成本是必须付的；如果不涉及，把这部分人力投到流程建设上，回报可能更高。

5. 一次拆分的收益 vs 持续维护的成本

任务拆分不是一次性动作。结构会腐化，字段会空置，依赖会过期。你需要为“维护”预留时间预算。

我的建议是每两周安排一次 60 分钟的结构维护会，只做三件事：合并过细的任务、补齐缺失的验收标准、清理失效的依赖。不做维护的拆分成果，平均在 6 到 8 周后开始失效。

八、常见问题

1. 任务拆分应该由谁来做，管理者还是执行者？

我的答案是分层做。目标对齐和交付物定义由管理者主导，因为只有他们清楚业务意图和对外承诺；实现路径的拆解由执行者主导，因为只有他们知道技术约束。

两者之间需要一个交接点，我通常用一场 60 分钟的“拆分会”完成：管理者讲清交付物和验收标准，执行者当场提出依赖和风险，会议结束时任务结构定稿。

2. 管理层任务一天只有 2 小时可用，拆成 8 人天还有意义吗？

有意义，但要换算。8 人天的管理层任务不等于 8 个工作日，它可能要横跨 4 到 6 周。关键是把任务拆成可以“插入碎片时间”的片段，并明确哪些片段需要大块专注时间。

我通常会在任务里加一个“专注需求”标记，区分“需要半天不被打断”和“可以随时处理 30 分钟”。这个标记能显著提升时间利用效率。

3. 探索型任务怎么拆才不失控？

不要按步骤拆，按“假设，验证，判断”拆。一个探索型任务应该包含：我们相信什么、用什么方式验证、什么样的结果会让我们继续或放弃。

时间盒是必需的。我给探索型任务的默认上限是 4 周，超过 4 周必须给出中期结论并重新决策。没有时间盒的探索型任务，最后会变成没有截止日期的承诺型任务。

4. 验收标准写不出来怎么办？

大多数时候不是写不出来，而是这个任务本身还没想清楚。我的处理方式是反向提问：“如果这件事失败了，我们靠什么知道？”这个问题能逼出可观察的指标。

如果确实找不到可观察指标，那说明这个任务应该被降级为“探索型”，改用假设验证的方式管理。

5. 任务拆得越细，团队成员会不会觉得被过度管理？

会，而且这是真实的风险。区别在于你拆的是什么。如果你拆的是“怎么做事”，团队会抵触；如果你拆的是“交付什么、什么时候验收”，团队通常欢迎，因为这减少了返工。

我的做法是把拆分结果公开透明，并且允许团队在任务层以下完全自治。让团队看到结构化带来的好处，比任何宣讲都有效。

6. 现有工具不支持依赖字段和验收标准字段怎么办？

先做减法：如果工具只支持标签，就用标签体系承载“验收标准是否存在”的标记；用任务描述的固定模板承载验收标准内容。这不够优雅，但能先跑起来。

如果组织规模已经超过 100 人，且存在跨团队依赖管理、私有化部署或历史数据迁移需求，那么换一套能承载结构化字段的平台就值得考虑了。评估时重点看三件事：工作项层级是否可自定义、依赖关系是否是结构化字段、有没有完整的数据迁移方案。

7. 拆分之后任务数量暴涨，怎么处理？

先做一次合并。判断标准是：如果两个任务的负责人相同、验收标准相同、风险来源相同，就应该合并成一个。

同时检查是否有任务被拆到了“动作”层级。“准备会议材料”“发送邮件”这类任务不应该出现在管理层视图里，它们属于个人待办，可以用独立的清单管理。

8. 如何衡量任务拆分的改进效果？

我建议只用三个指标起步：验收标准缺失率、跨团队依赖漏检数、迭代或周期承诺达成率。前两个反映结构质量，第三个反映结构质量带来的结果。

不要一开始就上十几个指标，那会让改进动作失焦。跑三个月稳定之后，再补充交付周期和人均维护耗时这两个成本指标。

9. 远程或分布式团队在拆分上有什么额外注意点？

分布式团队对书面结构的依赖远高于同地团队，因为缺少走廊沟通这种非正式对齐渠道。所以任务描述的完整度要求要更高，依赖要更早显式化。

另外建议把“验收标准的时区归属”写清楚，跨时区的截止时间如果不标时区，会制造大量本可避免的争议。

10. 任务拆分和 OKR 是什么关系？

简单说，OKR 回答“为什么要做”，任务拆分回答“做什么、谁做、什么时候算做完”。两者不该混在一套结构里。

我见过把 KR 直接当成任务写给团队的组织，结果是 KPI 化的 KR 和碎片化的执行，两边都失真。更合理的做法是：OKR 独立管理，任务结构里通过字段关联到对应的 KR，保持松耦合。

九、下一步：这周可以做的三件事

写到这里，我想把整篇文章压缩成三个可以立刻执行的动作。方法论的价值的全部在于落地，不在于读起来是否顺畅。

第一件事：挑出你手上最让你焦虑的一个跨部门任务，重新写一遍它的交付物。不要改结构，只改描述。把动词改成名词，看看你能不能写出来。如果写不出来，你就找到了问题的真正位置。

第二件事：给这个任务补一条验收标准，并且找一个不参与该任务的人读一遍。如果他能说出“什么情况算没完成”，这条标准就合格了；如果他说不出来，继续改。

第三件事：把它的依赖关系列出来，问三个问题，我依赖谁、谁依赖我、我延迟五天会影响谁。把答案写下来，发给相关的人确认。这一个动作，往往就能暴露出你之前完全没意识到的关键路径。

最后我想强调一个在这篇文章里反复出现的判断：任务拆分的本质不是把工作切小，而是把不确定性提前暴露。拆得好的任务，会让你在项目开始时就感到不安，因为所有模糊的地方都被逼到了明面上。那种“拆完觉得一切尽在掌握”的顺畅感，往往才是真正的危险信号。

从下周一开始，试着把你最不确定的那件事，拆到你自己都不好意思再模糊为止。