在和朋友闲聊时，聊到一个很有意思的话题：什么时候觉得自己潜力巨大？他说在Deadline面前。虽然我有时候也会有拖延症，但还是会尽量避免踩着Deadline交作业，因为那是非常危险的事。
01
Deadline的存在，虽然会让人感到压力巨大，但它是提高一个人生产力的关键所在。想象下，如果一份工作，有明确的交付时间和没有明确的交付时间，多数人会选择后者，那样好像会更轻松，但效率不一定会高。没有Deadline，时间看上去更充裕，但你执行的动力也会变小。
很多人，尤其是拖延症患者，坚信Deadline 是第一生产力。尽管结果可能是以低分飘过，Bug和问题频出，但最后期限的存在确实帮助我们建立起了秩序感，让事情可以按照计划一步步顺利执行。简言之就是有条不紊，一切尽在掌握中。
人们普遍认为在Deadline的压力面前会更有动力，从而有效地赶进度过关。这种不到“死”不做事，做了事又不用“死”的经历，让人觉得刺激，“胆大者”虽往往能“得逞”，却也面临风险，计划赶不上变化。如果有Deadline前发生了其他事件，那你将没有冗余的时间，相信我，墨菲定律多数情况下，还是会生效的。
02
对于我个人而言，我是不太信任在Deadline前做突击的。在明确了Deadline后，我更希望事情按计划一步步去做，每日都有进展，进度在可控的范围内。如果可能，会透明信息给到对应的领导或者同事，来确保最后交付的，不是惊吓，或者半成品。
延伸下，对于软件研发，测试活动何尝不是研发活动的Deadline？把产品质量依托于最后的测试活动，期待测试人员发现更多的BUG，进而“提升”产品质量。虽然敏捷研发和敏捷测试已经比较普遍了，但是还有很多同行的认知还是停留在此。对于测试左移，他们是不屑的，感觉那是测试手伸得太长伸得太长了，测试只要做好自己的事，产品的质量就会得到保障，如果漏测了，那就是测试的责任。整天想的不是如何改进和提升，而是抱怨研发团队太垃圾。除了发泄，于事无补。
在研发过程中，我们需要避免这类Deadline思维。面对研发过程，作为测试人员，我们需 有目的、有步骤地推进测试工作。做好需求实例化，提供可靠的测试用例供研发做冒烟测试，尝试自动化先行，积极推进探索性测试，把事情坐在前面，避免Deadline思维。
03
其次，并不是所有的事都有Deadline。如果你过于依赖Deadline，那么对于这类问题，将会不知所措。比如看书、学习、照顾家人，等等。
这些事情没有人给你设定一个必须完成的时间，此时Deadline 是第一生产力的人生信条也就不起作用了。
但这类事务的拖延，造成的影响可能比「未完成的作业」和「搞砸的项目」更加严重。
因为我们不做，也没有任何人来指责我们，所以可以无限地拖延它，甚至一度把它忘掉。但突然某一天，我们发现自己已经错失机会或者没有时间了，于是陷入漫长的内疚之中。
想自学一门新技术，却在入门就选择放弃，而心仪的工作正好需要这个技能，最后擦肩而过失之交臂；
看了一部讲述亲情的电影，下定决心要和家人多联系，结果隔天就忘了，等亲人离去才后悔陪伴太少……
人生就是一场倒计时，每天都有可能成为 Deadline，也许在某个猝不及防的日子里，许多事情就仓促地到此为止了。
到那时，你才发现，那些来不及做的事，没开口的话，再也没有机会补救。
04
把大事拆成小事，每天就是Deadline，通过可视化的方法来透明自己的进度。不管是工作还是其他事，其实都是一样的。管理好自己，管理好每天的进展，而不是迷信Deadline是第一生产力。
