接手团队后的第一个月，我先通过观察和约定建立基本工作方式。五一前后，上级同步了团队这个季度要交付的结果，目标拆解随之从培训笔记变成了手头的工作（待确认：补上当时季度目标的原文表述）。
我一开始的做法很顺：把团队目标按模块切成几份，每人分一块，各自写成任务清单。这个做法来自我以前带小团队的经验。三四个人背景整齐、都能独立交付，方向本身就是共识，谁做什么在日常协作里随时能对上，目标写出来更多是备忘，拆分这个动作从来不需要专门做。
接手现在这支十几人的业务团队，我把同一套做法照搬过来，拆完没两周就发现不对。有同学把自己那份清单上的任务都做完了，但目标本身没有动；也有的事没人认领，因为它不天然属于任何一个人的模块。这两类问题在小团队里几乎不会出现：人少，目标和任务之间的距离一眼就能看到，有缺口当场就补上了。团队一大，按模块切块分下去，恰好会撞上它们。这让我回头去想，拆目标到底在拆什么。这篇把当时的理解整理下来：三个层次的区分、拆之前要补全的要素、个人目标怎么写、几种常见偏差，最后说 SWOT 在其中的位置。
结果目标、过程指标和任务是三层东西
培训里有一节专门讲这个区分，我结合自己的情况整理成这样。
结果目标描述要交付的变化：到某个时间点，什么事情和今天不一样了。判断标准是结束时能否验证它发生了没有。
过程指标用来判断路径是否还朝着结果走。它出现在结果之前，数值动了，说明路径可能在起作用；一直不动，就要提前调整，而不是等到季度末才发现。
具体任务是路径上的一段执行动作，用来安排每天的工作。
三层各自的用途不同：结果目标用来对齐方向和验收，过程指标用来在中途判断要不要调整，任务用来排期。混在一起用的典型后果，是把任务完成度当成目标达成度。任务全部完成、结果原地不动的情况，以前在小团队里出不来：目标就在眼前，任务有没有推动结果随时能看到。十几个人各负责一段之后，任务完成度成了最容易统计的数字，它代替结果达成度几乎会自然发生。
拆之前，团队目标先要补全几个要素
上级给的目标通常只有一句话。小团队里一句话也够用，因为听到这句话的几个人会在每天的协作里把理解对齐。拆给十几个人，每个人都按自己的理解往下走，最后根本对不上。所以动手之前，先要把团队目标本身补全。
先是可验证的结果。这句话要能回答”季度末凭什么判断做到了”。我拿到的目标里有一条大意是”提升某块业务的系统质量”（待确认：补上原话），这种描述没法拆，先和上级对齐到可验证的程度再往下走。
再是关键约束。人力不变、某个项目不能延期、某套系统这个阶段不能大改。约束不明说，成员会在不知情的情况下替你做了取舍，取舍的方向未必是你想要的。
然后是依赖关系。结果依赖哪些团队、哪些前置条件。凡是写着”需要某某配合”的部分，在依赖方确认之前，都不能算成自己团队已经承诺的东西。
最后是阶段性检查点。一个季度太长，拆成几个能看到中间结果的时间点。检查点看的是过程指标和结果的差距，不是任务清单完成了几成。
个人目标写成”负责推动的结果与边界”
个人目标有两种常见写法，我都见过问题。“完成某功能”是任务不是目标，功能做完和目标达成之间没有必然联系。“协助某项目”更糟，既没说负什么责，也没说做到什么程度，等于把判断留给了事后。
我现在倾向的写法是：每个人负责推动一个可验证的结果，同时写清边界。边界包括哪些决策可以自己定、哪些要升级，以及结果依赖别人的部分，自己负责到哪一环。写边界的目的是让两个人负责的区域之间不留空白、也不重叠。空白表现为没人认领的事，重叠表现为两个人都以为自己能拍板。这种写法我以前用不上，三四个人的边界靠日常协作就划清了。现在边界只能靠写出来才能对齐，没写的地方默认就会有空白。
这个写法有一个前提：结果得是这个人的动作能影响的。影响不了的结果压到个人头上，写完就变成听天由命。这正是下面要说的第一类偏差。
拆解中的几种常见偏差
这一段从自己踩过的和观察到的情况里整理。
指标不可控。把成员影响不了的结果直接挂给他，典型的是依赖外部团队排期的部分。不可控的指标只有两种下场：要么不再使劲，要么把精力花在推动不了的事情上。
任务与结果脱节。任务清单写得很细，但没有任何一条线指回结果。识别方法很简单：问一句”这些任务全部做完，结果会动吗”，答不上来就是脱节。
多人共同负责、无人做最终判断。为了表示”这是大家的事”，把一个结果同时挂给几个人。挂的人越多，越没有人觉得需要自己做判断。执行可以多人参与，对结果负责和最终拍板的人应该明确到一个。我接手不久就遇到过一次，一个跨模块的事两个人都写了”参与”，出了问题谁也不觉得该自己先动（待确认：补充当时的具体情况和处理过程）。
忽略跨团队依赖。拆解只在团队内部做，依赖外部的那部分默认”到时候再说”。到时候通常就晚了。
这几种偏差有个共同点：它们都发生在纸面阶段，不走到执行就暴露不出来。所以拆完之后，需要有人拿上面那几句检查的话挨个过一遍。这个人一般是管理者自己。
SWOT 放在规划阶段，不替你做选择
2 月写过 SWOT 分析法的基本定义，这里不重复。放回团队目标拆解的场景，我用它的位置在拆目标之前：定路径和检查点时，先盘一遍团队当前的条件。
内部的优势和劣势，影响路径怎么选。某块系统只有一个人熟，这条劣势决定了相关目标的路径要留缓冲，或者干脆把”降低单人依赖”本身列为一个结果。外部的机会和威胁，影响约束怎么定。比如听到协作方下个季度要调整的消息，进了威胁这一格，对应目标里就要写清依赖的退路。
团队场景和个人使用有一个不同的条件：输入不能只来自管理者一个人。带三四个人时，我对每个人的状态有日常观察，判断多少有依据；十几个人之后，判断里想象的成分变多了。我对团队劣势的判断，和成员自己的体感经常不一致，我认为的短板在做事的人看来可能根本不是瓶颈。所以这一步我放在团队会议上做，各人往里填，我来归并。
另一个边界更重要：SWOT 只负责把条件摆出来，不替你做目标选择。四个格子填满了，选哪个目标、放弃哪个，还是得和上级对齐之后拍板。填格子这件事本身不产生判断，把它当成目标制定的替代品，是很多规划讨论开了半天没有结论的原因。
小结
拆目标这件事，我现在的理解是：先补全团队目标的结果、约束、依赖和检查点，再把个人目标写成可验证的结果加边界，最后用几个问题把不可控、脱节、多头负责、外部依赖这几类偏差筛一遍。它解决的是”任务做完了目标没动”的问题，边界是：目标本身的取舍仍然要管理者来定，工具和方法只保证拆得清楚，不保证选得正确。
目标和个人边界写清后，涉及多个角色的工作还要进一步明确执行、决策、咨询和知会的责任。目标描述本身无法替代这层协作接口的约定。
