有人总结，从外部来看，拖延症引起的原因有几个：
- 需要做到事情（以下简称为任务）不够明确。
- 任务太难，超出能力范围。
- 任务太枯燥，没有乐趣。
从这几个原因可以反映出，人们讨厌不确定性，讨厌无聊。
在开发任务中，也会出现拖延问题，造成拖延的原因，我自己遇到的有几种：
- 开发任务不够明确，大家不知道具体要做什么，代码要怎么写。
- 开发任务涉及到的系统比较多，前期准备工作量大。
- 调研任务，无法预估具体耗时。
- 不着急上线的需求。
- 枯燥的需求，体会不了乐趣的开发任务。
如果这些原因是准确的，那么就能使用一种方法来解决，核心目的是把开发任务变成可控，确定性高，且有趣的任务。
这里介绍一种方法，就是把一个整体的开发任务，拆解成足够小的任务，这些小的任务就可以做到非常具体和明确，再给这些小任务设定完成它们需要的时间，这些任务就会变成确定性任务。而且拆解任务的过程中，如果能加入一些有趣的学习类，挑战类，优化类任务，会让这些小任务做起来充满乐趣。
拆解任务的目标是：
- 让任务变的可控，充满确定性。
- 把枯燥的任务变成有趣的任务。
- 给每个任务设置完成时间，增加确定性的同时，训练自己的能力。
为了让拆解任务的目标能顺利达成，我们需要把任务拆分的足够小，就像做微分一样，小到足够简单，简单到2个小时以内就完成。
但是拆分任务的过程，往往会低估一些开发任务，导致任务实际开发的时间过长。
又或者高估一些开发任务，导致实际开发时间非常短。
而且一些任务可能自己没有做过，根本不知道如何做，需要进行一些调研和学习，在这之前，没法预估需要花多少时间。
对于低估和高估，我们可以采用协作的方式解决，就是多人对同一个拆分任务进行评估，得出一个平均值，或者大家都满意的值，往往会得到一个比较平衡的耗时。
对于自己没做过的任务，除了自己去实践一次得出一个基准值以外，就需要团队里有比较厉害的人，或者有前瞻性的人之前做过，给到一些经验性的评估，这样能帮助自己在一开始能设定一个比较合理的耗时和任务拆分。
但是实际任务拆分过程中，大家往往会忽略了拆分的目标，只是简单罗列任务涉及的几个模块，把模块的实现当作子任务，把拆解任务当作了todo list来使用，在开发过程中，一些工作可能不会出现在拆解的任务里，因为总有意外发生。
为了能让拆分任务完成自己的目的，我们应该时刻提醒自己拆分任务的目标，并且每天更新自己的任务拆分，因为总有意外会发生，任务实际开发可能是在变动中完成的。
更新需要数据，这就需要我们记录好自己开发每个功能，每个函数，每个接口，每个页面所花费的时间，有一些工具可以帮忙，当真的去记录才是最重要的。
记得电影《伸冤人》里，主角每次行动都给自己设置一个倒计时，以此来检查自己是否退步，或者是否有提高的空间。在行动之前，就在脑海里播放了一遍所有的行动细节，这就像是在做需求之前，就已经把所有的业务逻辑都在脑海里实现了一遍，下一步只是设定时间打印出来而已。
可军事行动会进行非常多的演练和模拟，做需求却没有那么多时间进行演练和模拟，可能接到的需求任务是做过的，或者没做过，或者要边做边填补以前的坑。
如果我们足够了解业务，熟悉业务，或许我们能做到把每一次迭代，都拆分和演练的非常好，实现代码如同打印文件那么简单。
最后复习一下，拆分任务和执行的目标：
- 把开发任务变成确定性，可控的任务
- 每个子任务都有明确的时间，这样才能可控和确定性
- 拆分的任务要有趣，如何有趣，可能需要因人而异
- 每天根据实际情况，更新任务拆分，记录每项任务的真实耗时
而为什么是这样的目标，是为了避免拖延症。
拖延症会让我们焦虑，心情不好，会让我们赶工，偷工减料，让我们的开发的应用摇摇欲坠，会挫败我们自信心。