要吃掉一头大象，每次吃一口。
——克雷顿·艾布拉姆斯（Creighton Abrams）
造成拖延的首要原因之一，同时也是造成生产力低下的祸根，就是总是在感慨一个问题：好忙啊，问题好大啊……实际上，你并没有真正试着去解决问题。当我们从任务的全貌来审视任务的时候，它们看起来比真实情况都要大，并且更吓人。
在本文中，我会谈及一个能够帮助你克服拖延的提高生产力的窍门：分解任务。通过将大任务分解为小任务，你会发现自己更有动力去完成它们，也更加稳妥地向着目标前进。
“为什么更大并不总是更好”
任务越大，看起来就越吓人。编写一个完整的软件应用程序很困难，但是写一行代码就容易得多。遗憾的是，在软件开发领域，我们遇到的大项目、大任务往往要比小项目、小任务多得多。
这些大任务或大项目给我们带来了心理上的伤害，也削弱了我们的生产力——因为我们无法看清楚未来的前景。从宏观上审视一项大型任务的全貌时，它看起来几乎是不可能完成的。想想类似的壮举：盖一幢摩天大楼，修一座横跨几公里的大桥。
然而，很多摩天大楼和大桥已经被建成了，因此我们知道它们是可行的，但是如果从整体角度看待任何一个此类项目时，看起来好像任何人都不能完成它。
完成大型项目，像从头开始构建一个应用程序这样的，令我挣扎很久。我曾经动手开发过许多不同的应用程序，但最后都无疾而终，直到我学会如何分解任务。每当开始新项目的时候，我总是热情高涨，但是很快我就会被那些琐碎的事务搞得焦头烂额。我总在想还剩下多少工作要做，我从来就没有冲过终点线。项目越大，我越可能失败。
我发现有这方面困扰的不止我一个。在软件开发领域，我扮演过各种角色，我发现，当我给其他开发人员分配工作的时候，一个项目能否成功的最大标志就是我所分配的任务的规模。我要求他人完成的任务越大，他们完不成任务的可能性就越大。
关于这个问题，我们已经讨论过，原因之一就是：大型任务给人带来沉重的心理负担。面对大问题时，我们倾向于花更多的时间思考问题本身，而不是采取行动去解决问题。人类倾向于选择阻力最小的路径。当面对一项大任务的时候，检查电子邮件或者泡上一杯咖啡看起来就是更容易的路径，于是拖延随之而来。
但是拖延还不是我们不喜欢大型任务的唯一原因。任务越大，越难明确定义。如果我让你去商店买鸡蛋、牛奶和面包，这个任务就是非常明确的，你知道该做什么。完成这项任务很容易，你正确完成任务的概率也很高。
但是，如果我让你创建一个网站，这个任务很大，定义也不明确。你可能不知道要从哪里着手，也会有许多问题都悬而未决。你不太可能知道要完成这项任务该做些什么。我可以把我认为的、我期望的如何建立这个网站的内容详细记录下来，但是你得花一些时间才能读完并理解这么详细的说明，并且仍然有很高的出错概率。
大型任务往往也很难估算完成时间。如果我问你，写好一个找出列表中规模最大的项目的算法需要多长时间，你也许可以给我一个非常准确的估计值。但是，如果我让你告诉我，实现网站上的购物车功能需要多久，你的估计值不会比瞎猜好多少。
大型任务是一种智力挑战，与小任务相比，大任务更可能导致拖延，通常描述也更少，更容易出错，也更难估算完成时间。
“分解任务”
不要绝望，还有解决方案。事实证明，大多数大任务都可以被分解成更小的任务。实际上，几乎每个大型任务都可以分解为不计其数的更简单更小型的任务。
把大型任务分解为更小的任务，是我一直用来完成更多工作、更准确地估算要完成这项工作我需要多长时间的技巧之一。
事实上，写《软技能：代码之外的生存指南》这本书采用这样的结构并非巧合。你可能想知道为什么这本书有这么多章。在我开始着手写这本书的时候，我特意选择将每一篇拆分成很多小的章，而不是少数几个篇幅很长的章。原因有两个方面。
首先，小章内容更易于读者阅读消化。我知道，当我读章篇幅很长的书的时候，除非我有足够的时间读完一整章，否则我可能会避免捧起那些书来读。阅读每一章都很长的书的任务看起来会很吓人，所以我不太可能读完。希望你已经发现，与那些篇幅巨大、很少停顿的书相比，每章1000～2000字的篇幅更容易阅读，也不那么吓人。
其次，小章让我更易于完成写作。我知道，写书是一项挑战，大多数决心坐下来写书的人最终都不能完成它。曾经，我也有过这样的经历。如果每章的篇幅和一篇博客文章的长度差不多，那么写书这项任务就更可以管理了。所以，我给自己的不再是“写一本书”这样一个大任务，而是写大约80个小任务，每个小任务就是本书的一章。
当把任务分解成小块的时候，这些任务就变得更易于完成，对完成任务所需的时间的估算也更精确，你也更有可能正确地完成它们。即使有些小任务没有正确完成，你也有很多机会改正，而不至过多地影响大项目。我发现，把大任务分解成小任务真是一个好主意。
“如何分解任务”
事实证明，分解任务并没有那么困难。大多数任务都可以通过一次一步的方式分解为许多小任务。关于如何吃掉一头大象的引文非常正确。唯一可信的吃掉一头大象的方法就是一口一口地吃。这几乎同样适用于每项大型任务。即使你没有有意识地分解大任务，仍然会受制于时间的线性发展，即要想完成事项A，必须要先完成事项B，以此类推。
如果想承担一项大任务，又不想被它吓倒，你首先需要明确完成这项任务需要哪些步骤。如果我被分配了一项大任务，我要做的第一件事情就是弄清楚我能否将它分解为一连串的小任务。
我最近的一个项目是为我的一个客户建成持续集成系统，并完成代码部署的工作。这项任务非常庞大，看起来很吓人也很艰巨。但是，我没有试图一步登天地处理它，而是将其分解为一系列更小的文凭任务。
首先是要获得客户端代码，从命令行去构建和编译，因为这是创建自动构建环境的必需步骤。下一个任务是让构建服务器能够检出代码。然后，下一个任务是将这两者结合起来——让构建服务器能够检出代码，并使用命令行脚本来编译代码。
把大任务分解成小任务，这样更有意义
我把整个项目分解为这样的小任务后，原来的庞然大物瞬间变成了一只小老鼠。即使整个项目看起来仍然是难以解决的大问题，但每个小任务看起来却很简单。
你可能会发现一件事情，当你试图把大任务分解为许多小任务的时候，对于究竟需要做什么你其实并没有足够的信息。还记得我说过大任务通常并不明确吗？把大任务分解为小任务的关键步骤就是确定出因为缺失了哪些信息而导致你无法创建更小、更明确的任务。如果你在把大任务拆分成小任务的时候遇到问题，很可能是由于缺少信息。
但是这并不是坏事。在项目早期发现信息不足要比项目已经进展很多后才发现信息不足要好很多。把大任务分解为小任务的时候，务必确保每个小任务都有一个明确的目标。试着明确这些目标经常会发现之前用别的方法遗漏了的重要信息。
当我在敏捷团队工作的时候，我经常尝试使用这种方法从客户那里获得正确的信息。当客户要求你完成某项大任务的时候，例如，他们希望你能在他们的网站上增加购物车这样的大任务的时候，他们经常很难准确描述自己想要什么。如果你能将大任务分解为小任务，就可以让他们更容易地说出他们到底想要什么。
“分解问题”
分解任务的方法同样适用于编码和问题求解。许多新入行的开发人员总是会被自己要解决的问题压垮，他们认为自己的代码很难写，问题很难解决，原因在于他们总是试图一次性解决太大的问题。他们不知道如何分解问题。（我不得不承认，我自己偶尔也会犯这样的错误。）
当然，在管控代码的复杂程度问题上，我们也会做一些工作。这就是我们不会将所有的代码都写入一个方法中的原因。我们会将自己的代码分解为方法、函数、变量、类以及其他结构，从而简化代码。
不管编程问题有多难，它总是可以被分解为更小的单元。如果你想要写出一个难度很大的算法，在一头扎进去写代码之前，先把这个问题分解为能够依次独立解决的小模块会更有帮助。无论应用程序多么庞大、多么复杂，它都可以被分解成一行行的代码。单独一行代码的复杂度绝对不会超过任何一位程序员的理解能力和编码水平，所以，如果你愿意将问题分解得足够小，只凭借写出单行代码的能力你就能写好任何应用程序。
采取行动当前，你因为其规模惊人放弃了哪些大型任务？你会在打扫车库、写博客文章、解决复杂算法等事情上拖延吗？选出一个你当前面临的大问题，看看能否找到好办法将它分解为更小的任务。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
