如何把项目拆分成任务

为什么分解才是真正的规划工作

每个项目开始时都是一句话。重做网站。启动通讯邮件。搬迁办公室。那句话是目标，不是计划，而一句话是无法排期的。分解就是把那一行字变成一份任务清单的工作，这些任务小到可以估算、可以分配、可以跟踪。做对了，时间表几乎会自己搭起来。做错了，再聪明的排期也救不了，因为你管理的是错误的单元。

大多数看起来像排期问题的规划麻烦，其实是乔装打扮的分解问题。任务太大，无法估算；太含糊，无法分配；或者太琐碎，以至于跟踪本身成了一份全职工作。本指南将带你走一遍如何把目标拆到合适的层级：先想交付物、用于定大小的8/80规则、把任务命名为动作，以及与正式工作分解结构的联系。

从交付物入手，而不是从活动入手

最常见的分解错误是去头脑风暴各种活动。你坐下来列出大家要做的事：调研、开会、撰写、评审。这份清单感觉很有成效，却没有主心骨，事情会从缝隙里漏掉，因为没有任何东西告诉你这份清单什么时候算完整。先想交付物把这一点翻转过来。你先问项目必须产出什么，也就是干系人能够指着看的有形成果，然后才问是什么工作创造出每一个成果。名词先于动词。

一个网站项目产出站点地图、页面设计、撰写好的文案和一个上线的网站。其中每一项都是一个交付物。在设计和文案之下，你就找到了任务。好处在于完整性：如果你命名了每一个交付物，而每个交付物又都有产出它的任务，你就可以有把握没有遗漏任何重要的东西。活动清单给不了这样的保证，所以它们总是在项目后期漏水。

合适的大小：8/80规则

多小才算足够小？最常被引用的答案是8/80规则：一个工作包所需的工作量应不少于8小时、不多于80小时，大约是一到十个工作日。低于8小时，你是在跟踪琐事。超过80小时，这个任务就大到无法有把握地估算，也大到察觉不出它在滑坡。确切数字不如原则重要：一个任务应当小到可以诚实地估算、可以分配给单一负责人，同时又大到值得在计划里占一行。

另有两个检验可以让8/80的区间更精准。汇报周期检验说，没有哪个任务应当长于一个状态周期，所以如果你按周汇报，就把任务控制在一周或更短，否则延误会一直藏着，直到为时已晚。单一负责人检验说，一个任务应当恰好有一个人负责。如果你叫不出那个人的名字，这个任务就还是太大。

大小信号	它发出的警告	该怎么做
工作量超过80小时	太大，无法估算或跟踪	拆成多个工作包
长于一个汇报周期	延误会藏到截止日	拆到一周或更短
没有单一负责人	责任变得模糊	一直拆到只需一个名字
工作量不足8小时	跟踪的成本高过去做	合并进更大的工作包

把任务命名为清晰的动作

一个任务的名称就是一条指令，所以就该这样写。以动词开头，并点出具体的产出：撰写首页文案，而不是首页。测试结账流程，而不是测试。像网站或营销这样含糊的名词是一个筐，不是一个任务，而筐是无法完成的，只能被放弃。动词逼着你说出完成是什么样子。当有人读到这个名称，他应该确切地知道要做什么，以及怎样判断它何时算完成。

好的名称还能让计划一眼就读得懂，这比听起来更重要，因为一份没人扫一眼就能看明白的计划，就是一份没人更新的计划。避免那些描述状态而非动作的名称，比如进行中或持续中，也避免那些通用到可以安在任何项目上的名称。如果两个不同的任务可能共用一个名称，那这两个名称都含糊到没有用处。

太大的任务会藏住风险

一个超大的任务是风险的藏身之处。开发应用是一个没人能估算的任务，因为它把上百个更小的未知量卷进了一根看起来很省心的条里。当一个任务横跨数周，你无法判断它是否按计划推进，直到它快要到期，而那时延误已经没有余地被吸收。大任务还抗拒分配，因为这种规模的真实工作几乎总需要不止一个人，而共担的责任会悄悄变成无人负责。

更深层的问题在于，一根大条会不诚实地汇报进度。它在半个月里一直停在百分之五十完成，而底下的真相却在没问题和很危险之间来回摆动。把它拆成工作包就会揭开这个真相。十根小条，每一根要么完成要么没完成，告诉你的远比一根大条瞎猜一个百分比要多。如果你说不出一个任务百分之五十完成意味着什么，那它就太大了。

太小的任务会制造额外开销

相反的错误同样真实。分解得过头，你就会淹没在行政事务里。像打开文档或发一封邮件这样的任务，跟踪它的成本高过去做它，而一份有三百行琐碎条目的计划会变成一桩录入数据的苦差，没人会去保持它更新。每个任务都带着额外开销：它要被估算、排序、分配、更新和汇报。当管理一个任务的开销逼近去做它的工作量时，你就拆得过细了。

8小时的下限正是为此而存在。把琐碎的步骤按它们共同的成果归入单个工作包。十二处微小的格式修正变成润色报告格式，一个任务，一个负责人，一份诚实的估算。目标不是尽可能小的碎片，而是你仍能有把握地估算和跟踪的尽可能大的块。当再拆一刀所增加的管理成本多过带来的清晰度时，分解就该停下。

任务定大小的好与坏对照

把好的和坏的定大小并排来看会很有帮助。下表对照了一个网站项目里常见的任务条目。左栏展示陷阱，中栏解释它为何失败，右栏展示一个大小得当的版本。注意，这些修正不只是更短或更长，它们改变了条目的形态：一个含糊的筐变成一个有负责人的、命名清楚的交付物，而一个琐碎的步骤被折进某个值得跟踪的东西里。

大小不当的任务	它为何失败	更好的版本
网站	一个筐，不是任务，无法完成	撰写并发布五个服务页面
搭建网站	长达数周，藏住风险，没有单一负责人	搭建首页、搭建联系表单、搭建博客
保存logo文件	几分钟的活，纯粹是跟踪的额外开销	折入准备品牌素材
测试	一个状态，不是动作，完成没有定义	在移动端和桌面端测试结账流程

与工作分解结构的联系

工作分解结构就是把分解做得正式且可视化。一张WBS把整个项目排成一个层级结构：目标在最上，主要交付物在其下，工作包在最底层。它是项目将要产出的一切的家谱。你放到甘特图上的任务，就是一张WBS的最底层，也就是工作包，在时间上铺开。

先搭好WBS、再给它的叶子排期，能让你的图表保持诚实，因为在你开始考虑日期之前，这个结构就已经保证了覆盖面。我们关于工作分解结构的完整指南详细讲了层级与编号。对分解而言的关键思想是百分之百规则：任何一个方框下的子项加起来必须恰好等于其父项的整体，不多也不少。如果加起来少了，就是有工作漏掉了。如果加起来多了，就是重复计算了，会有人把同一件活儿做两遍。

一个做过的分解示例：公司通讯邮件

让我们分解一个真实的项目：启动一份每月一期的公司通讯邮件。从目标开始，命名交付物，然后把每一个拆成工作包。自上而下地做能让你始终以交付物为先，不至于漂移成一份松散的活动清单。

1. 命名目标：一份发给客户名单的月度通讯邮件。
2. 列出交付物：内容计划、撰写好的文章、邮件模板、订阅者名单，以及发送流程。
3. 把模板这个交付物拆成工作包：设计版式、搭建HTML模板、在各类邮件客户端测试渲染。
4. 把内容这个交付物拆开：起草文章提纲、撰写文案、编辑与校对、寻找配图。
5. 按8/80规则给每个工作包定大小，哪里不对就调整。
6. 给每个工作包一个负责人和一个清晰的动作式名称。
7. 估算每个工作包的工作量，然后把它们排成依赖关系。

先横向拆，再纵向拆

一个常见的失误是把你最先想到的那个交付物彻底分解，在网站文案上往下钻了五层，而上线和测试这两个交付物却各自还是含糊的一行。结果是一份一头沉的计划，看起来很详细，却把它最大的风险藏在了那些浅薄的分支里。要先横向分解。先把最上层的所有交付物都列出来，再去拆其中任何一个，然后做第二遍把每一个拆开，必要时再做第三遍。

这能让详细程度在整份计划里保持均匀，于是不会出现一部分被过度规划、另一部分却是黑箱的情况。它还能及早让缺失的交付物浮出水面，趁补上它们还很便宜的时候。均匀的覆盖比深入的覆盖更重要，因为时间表的可靠程度只取决于它最含糊的那一行，而那一行含糊的，永远是你没有分解的那一行。给每片叶子定大小仍然要依靠诚实的工期估算，所以也要为这一遍留出余地。

从工作包到甘特条

一旦你有了大小合适的工作包，甘特图就只差一步了。每个工作包成为一根条，它的工作量估算决定长度，而工作的先后顺序成为条与条之间的依赖关系。因为现在每一根条都小到可以诚实地估算，又由一个人负责，所以浮现出来的时间表是你可以站得住脚去捍卫的，而不是只能寄望它成真。

把你真实的工作包建好模型，你就能在几分钟内在gantts.app里搭出这张图，并随着画面越来越清晰来调整估算与依赖关系。

常见的分解错误

少数几个分解习惯造成了大部分的损害。列活动而不是交付物，于是计划漏水。凭直觉而不是用8/80规则来定大小，于是条太大，跟踪不了。把任务命名为名词，于是没人知道它们什么时候算完。把一条分支分解得很深，而其他分支还含糊着。还有忘了单一负责人检验，于是责任稀释进一个始终没能真正行动起来的小组里。

一旦你能叫出它们的名字，这些错误都不难纠正。把里程碑与任务分开也有帮助，这样检查点就不会冒充成工作。能预防其余错误的那个习惯很简单：从项目必须产出什么出发，均匀地往下拆，直到每一块都可估算、都有归属，然后就此打住。一张甘特图若只搭一次、此后再不触碰，那它不是计划，而是一个愿望，而诚实的分解正是让它值得你再去触碰的东西。

常见问题

延伸阅读

• 什么是WBS？
• 如何估算任务工期
• 里程碑与任务
• 返回指南列表

本文也提供英文版本。