我曾经是个有完美主义倾向的拖延症患者：对于交待下来的工作，每项都恨不得全力以赴，每项都希望有完美的输出。正因为这种心态，接收到任务时，脑补一下预期的输出，天哪，需要多少时间才能做完！于是想：等我有大块时间了再做。或者：这个有点复杂，等我忙完手头这个静下心来想清楚再做。最后结果就是一拖再拖，迟迟无法开始。
然而项目不等人啊，客户不等人啊，我在这里“憋大招”，别的同事或者部门已经开始行动了。或者，我一直在评估如何取得最优解，别的项目已经迭代了一个周期了。经历过多次事件后，痛定思痛，发现拖延症的症结在于一颗追求完美的心。而克服拖延症，首先要从接受不完美开始——做完美不如做完！快速开始，现在就开始。
具体到操作上，如果接受到一个大任务/发现一个大难题，如何快速开始呢？第一：分解任务，第二，打造最小闭环。举个例子：
我喜欢码字，之前写公众号，形式正式，同事朋友都能看到，所以写一篇文章可费劲了，从构思到落笔到修改，没有两天下不来。有一天看到一位作者说可以半小时写一篇一千多字的文章，我就很希望自己也有这样的速度。于是暗暗立了个flag：我要周更！后来发现，太难了。以往那个速度，每周根本没时间写。所以后来调整思路：每天写一千字难，但每天写一百字还是很容易的吧？那就从每天一百字开始，写写总结感悟、生活片段，很快就一百字。在简书日更了十几天后，我发现我的码字速度明显快了。虽然大部分文字的质量无法和公众号文章相比，但产能提升了不止十倍。有了简书上的积累，我再写公众号时，就有很多素材可用，挑选、重新组织后就是一篇文章，这样单篇公众号文章的产出效率也高了很多。
再举一个工作中的例子：我们一个产品涉及从外部接口取数据然后拼接。某一天因为一个bug，发现因为前期设计缺陷，数据拼接算法少考虑了一种场景，导致拼接结果有问题、数据不准。经沟通，对方建议了一种新的拼接算法，可以覆盖所有业务场景，但是现有处理逻辑要全部推翻，并且底层架构都可能要变。项目经理有点被吓到了：不改吧，结果是错的，没法用；改吧，代价太大。我分析了一下：目前未考虑到的场景，出现概率是多少？验证后发现，大概不到1%。那么这种场景从数据上看是否有特征？经确认，有。好，既然这样，那在现有逻辑上，加入一个判断，筛选出之前被遗漏的场景，之后再针对处理。采用这种方式，开发哥哥一天就改完，第三天就修复上线了。
总的来说，遇到难题或者mission impossible时，尝试从不同角度去分解问题、拆解问题，将复杂的问题简单化——做全网调研花时间，那能不能先做业务最大省的调研？目标用户数一千万，能不能先做到十万？甚至一万？解决方案要覆盖几十个应用场景，能不能先覆盖概率最高的两个场景？
再来说“最小闭环”。闭环的意思就是从头到尾走完流程、贯通问题。比如，我要日更，那文章必须发布才算闭环，不然写个半截，不管这半截多么好，都是未完成。最小闭环的意思就是找一条最快的路径，然后走下去、走通。比如：做个产品，计划是全国覆盖，后来发现不同区域的用户有不同偏好。怎么办？做个大而全的？开发周期长，目标用户定位不准，结果多半不好。这种情况下，最好是找出种子用户，聚焦他们的需求，然后密集开发推出产品，然后根据反馈快速迭代。“天下武功，唯快不破”的意义就在这里。有进展、有结果、能迭代成长，小步快跑，往往比一步到位更容易实现。
