欧美舶来的Get Things Done，也即GTD，一种个人时间管理的方法论，其字面含义，就是把事做完，简单说——搞定。但是，本文却说得不是那个事情，是我自己顿悟出来的，关于工作的窍门。
唯结果论的公司文化
事实上，在各种公司，都弥漫着一种文化，就是唯结果论。就是不看苦劳看功劳。就是做得多没用，做成的多才有用。这也就是我顿悟出来的“把事情做完”才是工作真谛的事实依据。因为公司是唯结果论的，所以，从上到下，考察的就是每个部门的，每个团队的，每个人的工作业绩。而一件事情怎么看是不是业绩呢？衡量标准我们先不论，但是有一点是确定的，你必须把你做完的事情拿出来说事，做了一半的事情，哪怕再好也是未完成。
把事情做完，并不是人的天性
在实际工作过程中，我们发现，把一件事情尽快做完，并非一件符合天性的事情。人的脑门长在头的最前面，注定了人喜欢望向未来，所以，我们做事情的时候，总是喜欢从未来的角度来看待，于是，我们不愿意在做事情的时候，给未来带来什么麻烦，总会瞻前顾后，看看过去的经验，考量一下，我们现在的做法是不是会给将来带来什么麻烦。这种东西说得好听是总结经验，吸取教训。但是这样做的话，就势必会拖慢我们做事情的进度。
瞻前顾后是我们的天性，而且，这绝非什么恶劣天性，而是最优秀的天性，是人类之所以在百万物种中脱颖而出成为地球主宰的重要原因之一。但是，当你在做一件事情的时候，当你想要某个经验的时候，你发现没有，你会不由自主地去研究，去归纳，去总结。想想你的时间浪费在哪里了？就是这里。如果你每次做事情的时候，都忍不住去花上些时间瞻前顾后，势必让你的时间变得不够用。
做事不总结，总结不做事
专注才能有效率，所以你做事情的时候，要承认自己的经验不足，应该充分激活现有经验，完成任务，而不是现场学习，研究历史和未来。没有经验，就直接去问有经验的人要过来，没人给，就要容忍不完美。失败后迅速吸取教训。做到，做事情的时候，专注的做事，尽到了努力，那就够了，没做成的事情，就痛定思痛，学习整改。但是不是把两件事情混为一谈。
在你工作尚浅的时候，你就应该奉行这样的工作理念。因为那个时候，所有人都能容忍你的不完美，只要你每次切实吸取了教训，有了实质地进步，你就能赢得尊重，如果你现在才发现这件事情，总比没发现要好一点。痛苦是免不了的，但是你只需要相信。至少你还能获得一个人的喜爱，那就是项目经理，他首先喜欢把事情做完的团队成员，然后才是做得好的。
完成是个相对概念，你并不是总被要求尽善尽美
公司是多人协作，为共同愿景努力的群体。在奔向成功的路途之中，任何偏差都是可以容忍的，需要的只是偏差被纠正。害怕的却是止步不前。所以，上面说把事情做完，做完是个相对的概念，因为只要终极目标没有达成，那么就没有什么事情可以说是真正做完了的。当你判断任务太过庞大，或者太过超出自己的能力范围，应该做的事情是把问题摆到桌面上来，不是自己去吸收。
大任务应该被拆分成小任务，困难任务应该被拆分成简单任务。如果你是任务的负责人，就应该以自己在一个相对较短的时间内，能够“做完”为单位，对大任务和困难任务进行拆分，总是在自己约定的时间内给出阶段性成果。相信我，项目经理或者老大，都最喜欢这种人。甚至，连投资人也最喜欢这样的公司。
让人们看到你的成果，看到你前进的清晰脚印，远好过于一口气做完事情的惊喜。
敏捷是方法论，不只用在软件开发领域
最近，在软件领域中，有一种方法论，叫敏捷，是一种注重实践的方法论。作为一名工程师，从我的角度来看，这方法论，简直就是bullshit，但是如果从本文把事情做完这个工作的真谛来看，这简直就是这一理念的完美实践。确实不应该从工程角度来理解敏捷。而是从做事的一般原理来理解。
敏捷针对的是一个研发团队，提出让研发团队以两周为单位，快速迭代项目，不断抛出工作成果，让需求方，研发者，管理者，都能快速参与到工程实践中，不断修正研发的路线，使得最终的交付尽可能不要偏离需求方的愿景。因为需求方的愿望变化是很快的，小的时间单位能够充分兼容偏差。
回到本文的论点来看，敏捷同样是一个很好的方法，他让领导能快速看到你的阶段性成果，不至于蒙在鼓里，让他能够随时重新认识自己的想法。让任何事情，都能随时保持阶段性的成果。
将大任务切分成小任务后，你将获得更充分的时间
当你成功说服管理者，将一个大任务剖分成小任务的时候，每个小任务都会获得自己的单独的完成时间，又由于任务足够好，你可以充分安排你的时间，然后在合理的时间内将其做完，这样做，就更有希望从繁重的工作中解放出来。减少加班。