目标拆解落地方案：项目负责人开展项目目标的最佳实践案例解析

我带过一个跨部门的交付项目，立项会上所有人举手通过，三个月后复盘会，项目负责人对我说了一句话：「所有任务都完成了，但目标没达成。」

这句话我后来在很多项目里反复听到。任务清单打了满勾，甘特图没有延期，周报每周准时发出，但发起人问一句「所以我们现在到底做成了什么」，会议室里会安静五秒钟。这五秒钟，就是目标拆解失败的证据。

这篇文章不做名词科普。SMART、OKR、KPI、WBS、RACI 这些词谁都能搜到，我不想再复述一遍。我想讲的是我实际经手的项目里，项目负责人怎么把一个「正确但模糊」的目标，拆成能被执行、被追踪、被验收、被复盘的东西；在这个过程中，哪些动作是真正产生价值的，哪些动作只是让项目负责人自己感觉安全。

全文围绕一条主线：先澄清目标 → 再拆结果 → 再排依赖 → 再定责任 → 再控风险 → 最后复盘迭代。这条主线看起来平淡，但它是我在复盘了二十多个延期项目之后，唯一还愿意每次都用的框架。下面会拆开讲清每一层在做什么、容易错在哪、以及在不同项目规模下该怎么取舍。

一、先把结论说透：目标拆解的本质是三张翻译表

很多项目负责人对「拆解」的理解，是把一个大目标切成几十条任务，然后分给对应的人。这个动作看起来很像拆解，其实只是分发。真正的拆解，是把目标翻译三次，每次翻译都会丢失一些东西，项目负责人的工作就是确保丢失的东西被显式记录下来。

1. 第一张翻译表：把业务语言翻译成结果语言

发起人说「我们要提升客户满意度」，这是一个业务目标，不是项目目标。它没法验收，也没法排期。项目负责人要做的第一件事，是把它翻译成可判定真假的结果：「6 月底前，把 NPS 从 32 提到 45，样本量不低于 800 份，剔除内部测试账号」。

这个翻译过程有两个硬性要求。第一，必须有一个明确的判定时点，比如「6 月底前」；第二，必须有一个第三方能独立验证的口径，比如「样本量不低于 800 份」。没有这两条，目标就还是口号。

我见过最常见的错误，是项目负责人直接接受了发起人给的业务语言，然后在心里默默当成项目目标。三个月后发起人说「这不是我要的」，项目负责人拿不出任何书面澄清证据，只能认下这个锅。

2. 第二张翻译表：把结果语言翻译成依赖语言

结果一旦确定，接下来要问的不是「要做哪些任务」，而是「要达成这个结果，必须先有哪些条件成立」。这是依赖语言，也是大多数项目负责人跳过的环节。

举个例子，「6 月底前上线新结算模块」这个结果，前置依赖可能包括：财务口径确认、老系统数据迁移窗口、灰度环境的资源排期、合规审查周期。这些依赖不在项目负责人自己的团队里，但它们决定了项目能不能落地。把结果翻译成依赖，本质上是提前把「不由你控制的东西」摆到桌面上。

我做过一个粗略统计，在我经手的延期项目里，超过六成的延期不是执行慢，而是依赖识别太晚。团队按时完成了自己的部分，但因为某个外部依赖没到位，整体卡住。

3. 第三张翻译表：把依赖语言翻译成节奏语言

依赖识别出来之后，才会自然浮现出节奏问题：哪些依赖是关键路径，哪些可以并行，哪些必须在某个窗口内完成否则就要等下一个周期。这时候才轮到里程碑、例会、看板这些东西出场。

顺序一旦反过来，先建看板再想目标，就会出现「看板很漂亮，但没人知道为什么这些任务在这里」的局面。这是我最常看到的工具化误用。

把这三张翻译表连起来看，目标拆解的产出不是一张任务清单，而是三份互相咬合的文档：目标说明书、依赖清单、节奏计划。任务清单只是节奏计划的副产品。

二、真实场景：三个项目为什么在拆解阶段就埋了雷

抽象讲道理没意义，我讲三个具体场景。这三个项目分属不同行业，但失败逻辑高度相似，都是拆解阶段埋的雷在中后期引爆。

1. 场景一：一个「正确但模糊」的年度目标

某制造企业的数字化项目，年度目标是「实现生产数据全流程可视化」。听起来很正确，但没有人能回答「可视化到什么程度算实现」。项目负责人把它拆成了 42 条任务：接 6 个系统、建 3 个看板、做数据清洗、搭指标口径……

四个月后，看板做出来了，但车间主任看了一眼说：「这个数据跟我上个月报的不一样，我不敢用。」项目被迫回到数据口径阶段，前面两个月的工作有相当一部分要重做。

问题的根不在执行，在于「可视化」这个目标从来没有被翻译成可验证的结果语言。如果一开始就写清「车间主任每天早会使用该看板作为排产依据，连续 2 周无口径争议」，这个项目在第二个月就会暴露口径问题，而不是等到第四个月。

2. 场景二：跨部门依赖被当成「配合事项」

一个金融行业的系统迁移项目，项目负责人把所有跨部门需求写进了「配合事项」清单，发给了相关部门负责人。他以为这就算通知到了。

到了迁移窗口期，运维部门说这个窗口早就排给别的项目了，安全部门说合规审查需要三周，而项目计划里给合规留的时间是五天。整个项目卡了三周。

这里的关键区别是：「配合事项」是通知，「依赖」是有责任人和时间承诺的约束条件。前者是软的，后者是硬的。项目负责人如果没有把依赖转成后者，等于把项目的关键路径交给了别人的善意。

3. 场景三：目标中途变更，计划没跟着变

一个产品研发项目，中期公司战略调整，原本「服务中小客户」的目标改成了「优先服务大客户」。这个变更在战略会上只用了五分钟，但项目计划没有重排。

结果团队还在按中小客户的性能要求做优化，大客户最关心的权限体系和审计日志反而排在最后。项目最终交付了，但交付的东西跟公司真正想要的差了一截。

目标变更本身不是问题，变更之后不重排计划才是问题。而重排的前提是，你原本的计划是按「结果，依赖，节奏」三层拆出来的。如果你的计划只是一张任务清单，变更来的时候你根本不知道哪些任务该留、哪些该砍。

三、拆解环节的六个常见误区

下面这六个误区，我几乎在每个出问题的项目里都能找到至少三个。它们有一个共同特征：让项目负责人在当下感觉更安全，但把风险推到了未来。

1. 只拆任务，不拆结果

这是最普遍的一个。项目负责人拿到目标后，第一反应是列任务，因为任务是可以立刻动手的，而结果需要想清楚。但任务清单有一个致命缺陷：它无法回答「做完这些，目标就达成了吗」。

正确的做法是，在任务之前先写清「这一层要交付什么结果，谁来验收，验收标准是什么」。任务存在的唯一理由是产出这个结果，如果某个任务不指向任何结果，它就不该在计划里。

2. 责任稀释：多人负责等于无人负责

「这个模块由 A 团队和 B 团队共同负责」，这句话在跨部门项目里出现的频率极高，也是我最警惕的一句话。共同负责的实际含义是：谁都可以说自己配合了，但没人需要对最终结果负责。

我的做法是，任何一个结果都必须有一个唯一责任人，其他人可以有角色（执行、配合、审核、验收），但责任人只能有一个。这个人在结果没达成时，不能把责任推给「对方没配合」。

3. 里程碑没有验收标准

很多项目的里程碑写的是「完成需求设计」「完成开发」，但没有人能判断「完成」的定义是什么。是文档写完，还是评审通过？是代码提交，还是通过测试用例？

没有验收标准的里程碑，会变成一种仪式：到点了开个会，大家说差不多完成了，然后进入下一阶段。真正的问题被推迟到集成阶段才暴露，那时候修复成本已经翻了几倍。

4. 忽略资源冲突和跨部门依赖

项目负责人经常默认「我要的资源就能拿到」，但实际上中大型组织里，同一批人往往同时被三四个项目占用。如果你的计划里没有写清「谁在哪段时间投入多少比例」，那你拿到的很可能是别人排剩下的碎片时间。

依赖也是同理。跨部门依赖不能只写在文档里，必须落到对方的排期里，并且有明确的确认动作。

5. 目标变更后不重排计划

目标变更是常态，尤其在资源有限、市场变化快的组织里。问题不是变更本身，而是变更之后团队还在执行旧计划。

我建议的做法是：每次目标变更都强制触发一次「计划重排会议」，输出三个东西，哪些任务取消、哪些任务优先级下调、哪些依赖需要重新确认。没有这三个输出，变更就不算完成。

6. 复盘只写感受，不沉淀机制

「本次项目沟通不够及时」「下次要加强风险管理」，这类复盘结论我见过太多次，它们不产生任何行为改变，因为太空泛了，下次没人知道具体该做什么。

有价值的复盘结论必须是可执行的机制。比如「跨部门依赖必须在项目启动后 5 个工作日内进入对方排期系统并确认」，这是一条可以检查的规则，而不是一句感受。

四、专业判断逻辑：六层拆解法怎么用

讲完误区，我把自己的方法论完整摊开。这套方法我内部叫「六层拆解法」，它不是六个步骤，而是六个视角，每一层都要回答一个特定问题。顺序不能乱，但规模可以按项目大小伸缩。

1. 结果层：这个项目到底要交付什么

结果层的核心动作是把业务语言翻译成可判定的结果语言。我通常要求项目负责人写出一份《项目目标说明书》，一页纸，必须包含五个字段。

• 业务背景：为什么现在要做这件事，不做会怎样。
• 成功标准：什么情况算成功，口径是什么，谁来验证。
• 边界条件：范围、预算、人力、技术、合规上的硬约束。
• 关键干系人：谁决策、谁执行、谁配合、谁验收。
• 不做清单：明确排除什么，这一条最容易被忽略，但最能防止范围蔓延。

《项目目标说明书》的价值不在于写完，而在于让发起人在上面签字确认。没有签字的目标说明书，只是一份项目负责人自己的理解。

2. 里程碑层：阶段成果和决策点在哪

里程碑层的核心是把结果切成若干可验证的阶段成果。注意是「成果」不是「动作」：「完成需求设计」是动作，「需求评审通过并冻结」是成果。

我建议每个里程碑都配三样东西：交付物名称、验收标准、验收人。这三样缺一个，里程碑就会退化成进度汇报的装饰。

另外，里程碑里应该包含决策点。比如「是否进入下一阶段」「是否追加资源」，这类决策点如果不显式安排，就会在需要决策的时候找不到人拍板。

3. 工作包层：可分配、可估算、可验收的最小单元

工作包层的核心是把里程碑拆成能被一个人或一个小组独立完成的最小单元。判断标准有三条：能分配给单一责任人、工作量能估算、完成与否能验证。

关于颗粒度，我的经验是：单个工作包的工作量控制在 3 到 10 人天之间。小于 3 人天，管理成本超过执行成本；大于 10 人天，进度状态就没法准确反映，你只能在它完成或延期时才知道情况。

4. 依赖层：谁卡着谁

依赖层是六层里最容易被跳过、但回报最高的一层。做法是：对每个工作包问三个问题。

1. 它需要谁提供输入？这个输入什么时候必须到位？
2. 它的产出会被谁消费？下游什么时候需要？
3. 它需要什么资源（人、环境、预算、审批），这些资源在目标时间段内是否已被占用？

把答案整理成依赖清单，每条依赖必须有外部责任人、承诺时间和确认状态。未确认的依赖必须标红，并且进入周会的固定议题。

5. 责任与节奏层：谁在什么时候做什么，怎么同步

这一层决定项目的日常运行。责任用 RACI 表达：谁负责执行（R）、谁最终负责（A）、谁需要被咨询（C）、谁需要被告知（I）。注意 A 只能有一个。

节奏包括：同步频率、同步内容、异常升级路径。我的建议是，同步频率按项目风险等级定，不按团队习惯定。高风险项目周会不够就加日站会，低风险项目两周一次也够。

6. 风险与变更层：出问题怎么办，目标变了怎么办

风险层的核心是写清预警条件和升级路径。不是笼统地说「加强风险管理」，而是具体到「如果某个依赖在承诺时间后 2 个工作日仍未确认，由项目负责人升级到双方部门负责人」。

变更层的核心是建立变更触发机制：目标、范围、关键资源发生变动时，强制触发计划重排，输出「取消、降优先级、重新确认依赖」三份清单。

五、用工具承载拆解：以 PingCode 为例的落地观察

方法论讲完，必须落到工具上，否则还是一堆纸面文档。我的判断是：工具的价值不在于替代思考，而在于让拆解的产物可追踪、可追溯、可复用。如果工具只是把任务清单电子化，那它带来的价值非常有限。

1. 为什么中大型组织的拆解特别依赖工具承载

我在 100 人以下的团队里，用表格加周会也能跑通六层拆解。但组织一旦超过 100 人，问题会成倍放大：跨部门依赖变多、并行项目变多、人员流动变快、决策链条变长。

这时候靠文档和会议同步就会失效。一个依赖变更需要通知到的人可能有十几个，一份目标说明书可能在三个版本之间产生分歧，一个里程碑的验收标准可能被不同的人理解成不同意思。PingCode 主要服务中大型企业及 100 人以上组织，这个定位正好对应了我上面说的这个临界点。

2. 拆解链路怎么落到平台上

以 PingCode 为例，我看到比较健康的落地方式是这样一条链路：

1. 目标层：把《项目目标说明书》的关键结论沉淀为目标条目，成功标准和边界条件写进描述，发起人的确认动作留痕。
2. 里程碑层：用里程碑或版本承载阶段成果，验收标准写成可勾选的检查项，验收人显式指定。
3. 工作包层：用工作项承载，颗粒度按 3 到 10 人天控制，每个工作项关联到明确的里程碑。
4. 依赖层：跨部门依赖建立关联关系并指定外部责任人，未确认的依赖在视图中高亮，进入周会固定议题。
5. 责任与节奏层：用角色字段区分执行、配合、验收，用迭代或周期承载节奏。
6. 风险与变更层：用风险条目记录预警条件和升级路径，变更时通过关联关系快速识别受影响的工作项。

这条链路最关键的价值，是让「变更影响分析」从人工梳理变成一次筛选。目标变更时，你能顺着关联关系立刻看到哪些里程碑、哪些工作包、哪些外部依赖会受影响。这一步在纯文档模式下往往要花两三天。

3. 私有化部署与迁移：中大型组织的真实约束

我在金融、制造、政企类客户那里观察到一个共同点：工具选型的决定因素往往不是功能，而是部署方式和数据边界。这些组织有明确的合规要求，SaaS 模式在很多场景下走不通。

PingCode 支持私有化部署，这一点对上述行业是关键能力。同时它支持 Jira 平滑迁移，这对于已经在用 Jira 但需要做国产替代的组织来说，能显著降低切换成本，迁移的不只是数据，还包括工作流、字段体系和使用习惯。

我的判断是：国产替代不是把工具换掉就完事，而是要把方法论一起搬过去。如果原来的拆解方式就是一堆任务清单，换到新平台也还是一堆任务清单，只是界面变了。

4. 一个可量化的观察

我跟踪过一个约 200 人的研发组织从 Jira 迁移到 PingCode 的过程。迁移本身花了三周，其中数据和工作流迁移约两周，使用习惯调整约一周。

迁移之后半年，我记录了几个跟拆解和同步相关的指标变化：周会准备时间从平均 3.5 小时降到 1 小时左右；跨部门依赖的确认周期从平均 6 天降到 2 天；目标变更后的影响梳理从半天到一天降到 1 小时以内。

需要说明的是，这些改善不完全来自工具本身，也来自迁移过程中被迫重新梳理了一遍拆解逻辑。这恰恰说明一件事：工具迁移的最好时机，就是顺手把方法论升级一遍。

另外要提醒的是，私有化部署有额外成本，包括服务器资源、运维人力和升级维护。100 人以下的团队如果只是想要一个任务看板，未必需要走到这一步。

六、案例解析：一个跨部门交付项目的 90 天落地复盘

下面这个案例来自我参与复盘的一个真实项目，出于保密做了脱敏处理，部分数据是区间估算而非精确值，我会明确标注。案例的价值不在于结果多漂亮，而在于它完整经历了「第一次拆解失败→二次拆解→冲突调整→交付复盘」的全过程。

1. 背景与初始目标

某约 300 人的组织，要在一个季度内完成核心业务系统的结算模块重构。发起人给的目标是「提升结算准确率和处理效率，改善客户体验」。

项目负责人是一位有五年经验的技术经理，团队涉及研发、测试、财务、运维、客服五个方向。项目预算和人力在立项时基本确定，但合规审查周期和运维窗口没有明确。

2. 第一次拆解为什么失败

第一次拆解，项目负责人做了三件事：列了 68 条任务、排了甘特图、建了周会机制。看起来挺完整，但缺了三样东西。

• 没有可验证的成功标准：「提升准确率」没有基线，没有目标值，没有统计口径。
• 没有依赖清单：合规审查和运维窗口被写在「注意事项」里，没有责任人和承诺时间。
• 没有验收人：里程碑写的是「完成开发」「完成测试」，谁来判断合格没有说明。

项目进行到第 45 天，问题集中爆发。测试阶段发现财务口径和研发理解不一致，需要重新对齐；运维告知迁移窗口最早要等到第 70 天；客服的培训材料因为功能还在调整而无法定稿。项目整体延期约三周。

3. 二次拆解：六层法实操

延期之后，项目负责人重新做了一次拆解。这次他先花了两天时间，只做结果澄清。

第一版目标说明书把「提升准确率」翻译成了具体口径：结算差错率从基线 1.8% 降到 0.6% 以下，统计周期为上线后连续 30 天，由财务部门出具验证报告。同时明确「不做清单」：本次不涉及新的对账规则、不改造上游计费系统。

然后是里程碑重排。原来的四个里程碑被改成五个，每个都带验收人和验收标准。举两个例子：「结算引擎开发完成并冻结」的验收标准是核心用例通过率 100%、性能压测 P95 低于 300ms，验收人是技术负责人；「财务口径确认」的验收标准是财务出具书面口径文档并会签，验收人是财务负责人。

接着是依赖澄清。这一步产生了最实质的改变。项目负责人把依赖整理成清单，每条都有外部责任人和承诺时间，并且全部进入对方的排期。合规审查从「注意事项」变成了一个带责任人和时间的正式依赖，运维窗口也提前锁定。

最后是节奏调整。周会从「进度汇报」改成「依赖状态+风险预警」，进度数据从系统里自动取，会上只看红灯项。高风险依赖增加到每周两次的短同步。

下面是他使用的目标说明书结构，我做了简化，实际使用时字段可以按组织习惯调整。

project_goal:
name: 结算模块重构

business_context: 现有结算差错率 1.8%，客户投诉集中在账务不符

success_criteria:

metric: 结算差错率

baseline: 1.8%

target: 0.6%

measurement: 上线后连续 30 天，财务出具验证报告

metric: 结算处理时效

baseline: P95 4.2s

target: P95 1.5s

measurement: 生产环境监控数据

boundary:

budget: 已锁定

headcount: 研发 6 人、测试 2 人、财务 1 人（兼职）

compliance: 需通过合规审查

tech_constraints: 不改造上游计费系统

stakeholders:

decision_maker: 业务负责人

executor: 研发负责人

cooperator: [运维, 财务, 客服]

accepter: [财务负责人, 业务负责人]

not_doing:

新的对账规则

上游计费系统改造

历史数据全量重算

工作包层面，他把 68 条任务重新整理成 41 个工作包，颗粒度控制在 3 到 10 人天，每个工作包都关联到明确的里程碑和验收人。数量减少的原因不是工作变少，而是很多「任务」其实只是同一个工作包里的步骤。

4. 冲突处理与节奏调整

二次拆解之后并不是就顺了。第 60 天出现了新的冲突：运维给出的迁移窗口和另一个项目冲突，只能给到凌晨 1 点到 4 点，而测试团队原本计划在白天做验证。

因为依赖清单里已经写明了运维负责人和窗口时间，这个问题在三天内就被升级到双方部门负责人，最终调整方案是分两批迁移，第一批在小窗口验证，第二批在下一个可用窗口完成。如果没有依赖清单，这个问题大概会在迁移前一天才被发现。

另一个调整是节奏。原来周会 90 分钟，改成 40 分钟，因为进度数据自动汇总之后，会上只需要讨论红灯项。省下来的时间用在了两个高风险依赖的专项同步上。

5. 结果与复盘

项目最终在第 96 天交付，比二次拆解后的计划晚了 6 天，比最初计划晚了约 3 周。差错率上线 30 天后验证为 0.7%，接近但未完全达到 0.6% 的目标，团队据此又做了一轮参数调优。

复盘时最有价值的结论只有三条，但都是可检查的机制，而不是感受。

1. 跨部门依赖必须在项目启动后 5 个工作日内进入对方排期并确认，未确认的依赖在周会必须点名。
2. 所有里程碑必须带验收人和验收标准，缺少任一项的里程碑不允许进入计划。
3. 目标或范围变更时，强制触发计划重排，输出取消清单、降优先级清单、依赖重新确认清单。

这三条后来被写进了这个组织的项目管理规范。我认为这才是复盘真正的产出，不是解释这次为什么延期，而是让下次的延期概率下降。

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

六层拆解法不是每次都全用。根据项目规模、复杂度和风险等级，我给出下面几组差异化建议。

1. 一人负责多个小项目

这种情况下不要上全套流程，会把自己压死。建议只保留三样东西：一页纸的目标说明（重点是成功标准和口径）、一份依赖清单（只写跨出你控制范围的）、一份每周 15 分钟的自我检查（哪些红灯项、下周要推什么）。

里程碑可以合并，工作包可以不显式列，因为你自己心里有数。但成功标准和依赖这两样绝对不能省，它们是你向上沟通的唯一依据。

2. 跨部门项目，涉及三个以上部门

这类项目必须做完整的结果层、依赖层、责任层。特别提醒两点：第一，依赖清单必须由外部责任人确认，不能只是你单方面记录；第二，每个结果必须有唯一责任人，共同负责的表述要改成「A 负责，B 配合，C 验收」。

同步节奏建议按依赖数量定：依赖超过 10 条的项目，周会之外要加一次只谈依赖的短会。

3. 多项目并行、共享资源

多项目并行的最大风险是资源冲突在后期才暴露。建议在拆解时增加一步：把所有项目的关键资源需求拉到一个时间轴上，标出重叠区间，提前排序。

这一步如果不做，你会发现自己永远在救火，而且每次救火都在牺牲另一个项目的进度。

4. 目标可能频繁变更的项目

这类项目不要追求计划的稳定性，要追求变更响应的速度。建议把工作包的颗粒度调细一些（3 到 5 人天），这样变更时可以小步调整；同时把依赖清单做成可快速筛选的形态，变更发生时能在半天内输出影响范围。

如果团队规模在 100 人以上，这类快速筛选基本只能靠工具承载，纯文档模式下影响分析往往要花两三天。

八、不同情况下的取舍

拆解这件事，最难的不是知道方法，而是在有限的时间和精力下做取舍。下面四组取舍，我给的都是我自己的判断，不一定适用于所有组织。

1. 拆到什么颗粒度：细还是粗

颗粒度不是越细越好。细的代价是管理成本上升，团队会觉得被微观管理；粗的代价是进度状态失真，问题发现晚。

我的基准是 3 到 10 人天。低于 3 人天的工作包，合并到相邻工作包；高于 10 人天的，必须拆开或者加一个中间检查点。对高频变更的项目，可以下探到 3 到 5 人天。

2. 用不用重工具：文档、轻工具还是平台

我的判断标准有三个：人数、跨部门依赖数量、变更频率。100 人以下且依赖少，文档加表格就够；100 人以上、依赖超过 10 条、变更频繁，就需要平台承载。

需要注意的是，工具本身有引入成本。私有化部署适合对数据边界有明确要求的组织，但它带来服务器和运维成本；如果组织没有这类要求，过度选择反而增加负担。

3. 里程碑密度：密还是疏

里程碑太疏，问题发现晚；太密，团队疲于应付检查。我通常按项目周期来定：90 天的项目设 4 到 6 个里程碑，180 天的项目设 6 到 8 个，每个里程碑间隔不少于两周。

另外，高风险阶段可以加密，低风险阶段可以放宽，不必全程匀速。

4. 要不要引入 PMO 介入

PMO 的价值在于跨项目的资源协调和方法统一，但它也可能变成一层额外的汇报负担。我的看法是：当项目之间的资源冲突成为主要矛盾时，PMO 有明确价值；当问题主要出在单个项目的拆解质量上时，PMO 介入的收益有限，不如先把项目负责人的拆解能力提上来。

九、一页检查清单与下一步

最后我把整套方法压缩成一份可以直接用的检查清单。项目负责人在启动阶段对照检查一遍，能提前发现大部分拆解问题。

如果要把这套方法真正用起来，我建议下一步只做一件事：挑一个正在进行的项目，把《项目目标说明书》补出来，然后拿给发起人确认。不要一次改所有项目，也不要先换工具。等你把这一页纸跑通一次，你会对「目标拆解」这四个字有完全不同的理解。

我个人的一个判断是：目标拆解的能力差距，在项目前期几乎看不出来，因为大家都在开会、都在写文档；但到了第三、四个月，差距会以延期、返工、验收争议的形式集中显现。而那时候再回头补拆解，成本已经高出一个量级。

所以如果你现在手上正好有一个「正确但模糊」的目标，别急着列任务清单。先花两天，把它翻译清楚。