项目一再跳票？试试这一招：用 Deadline 倒逼生产力
我想也许你早就听说过“Deadline 是第一生产力”这句话，哪怕以前没听说过，我相信看完本文后，再也不会忘记这句话，甚至时不时还要感慨一句：“Deadline 是第一生产力！”。
在日常生活中，Deadline 倒逼生产力的例子比比皆是，比如说：
- 上学时，临近到要交作业的 Deadline 了，游戏都顾不上玩了，急急忙忙赶作业。
- 工作中，项目发布的 Deadline 临近了，大家加班加点，热火朝天赶着开发功能和修复 bug。
- 生活中，快到了要报税的 Deadline 了，每个人都急急忙忙赶在 Deadline 前把税给报了。 不管多拖延的人，快到了 Deadline 的时候，总能爆发出惊人的生产力。这就是为什么我们总是说：Deadline 是第一生产力。
与之相反的例子也很多，一些没有 Deadline 的事情，总会能拖则拖，直到不能拖为止，或者干脆不了了之。比如说：
- 程序员常有一些绝妙的想法，比如写一个开源项目，做一个 App 或者网站，结果因为没有 Deadline，结果总是开了个头，就再没结果了。
- 工作中很多项目，虽然有计划，但是没有强 Deadline，结果需求一改再改，计划总是在跟着调整延迟，一直不能上线。
- 比如说我这篇文章，打算写很久了，但因为没有 Deadline 一直拖着，最近终于给自己定了一个 Deadline 是这周末要写出来，这才开始动笔。 这些失败的例子，归根结底，一个很重要的原因就是没有 Deadline，导致不能发挥出生产力，或者生产力没有用在正确的地方。
Deadline 为什么能创造出巨大的生产力？
为什么 Deadline 这么神奇，能创造出巨大的生产力？
无论是个人的事情还是项目，生产力低下，不能按时完成的原因，总结下来不外乎三种：
- 想太多
- 过于追求完美、关注细节
- 不够专注
想太多
回想一下你做过的事或者项目，是不是会有“想太多”的情况。这并不是说在动手做之前先思考不好，而是有时候，因为停留在想的时间太长，迟迟没有动手，导致想的太多对于做成一件事反而会成为一种阻碍。
比如说想写一篇文章，打腹稿打的太久，最后都模糊了当初要写的观点，真下笔的时候，很多思考完全用不上；想写一个程序，设计了太久，不仅花了太多的时间在不必要的设计上，最后留给写程序的时间就不多了；做一个项目，在需求上想太多，迟迟不能确定，最后留给后面设计和开发的时间很短。
当有了明确的 Deadline，想太多的问题就会有明显的改善，该写的文章就动手写起来了，程序差不多时间也就动手编码起来了，需求也能早点明确下来。
过于追求完美、关注细节
追求完美、关注细节不是坏事，像乔布斯就以关注细节而闻名，但对一个项目来说，有时候过于追求完美、关注细节反而会导致项目失败。
比如说想打造“完美”的产品，导致产品一改再改，迟迟无法上线；程序设计时考虑各种未来可能的需求，导致设计非常复杂，很难实现。
想象一下，如果你本来想做一个完美的产品、设计一个完美的架构设计，但是有个很严格的 Deadline，必须要保证在 Deadline 前交付，那么你是不是就不会那么追求完美和细节，而是抓住最核心最主要的功能和设计，先保证能交付。
不够专注
当一件事没有明确的 deadline 时，就很容易被其他事情分心，比如说上上网、玩玩游戏，只有在 deadline 临近时，才能专注在要做的事情上，不再被那些无关紧要的事所分心。
借用时间四象限的理论，有了 Deadline，你要做的事情就变成了“重要并且紧急”，否则就会变成“重要不紧急”甚至是“不重要不紧急”，以至于一拖再拖。
结合项目管理金三角来分析
我曾经在《怎样平衡软件质量与时间成本范围的关系？》一文中提到了项目管理金三角的理论，也就是软件质量和时间成本范围三者之间是相互制约的关系。
结合前面的分析：
- “想太多”的问题本质上是在压缩了你的有效时间和扩大了范围，导致失控；
- “过于追求完美、关注细节”的问题本质上是扩大了范围，导致失控；
- “不够专注”则是一些不重要的事情挤压了你的时间。
而当你的项目有强 Deadline 的时候，说明金三角的三条边中，时间这条边是固定住的，只能少不能多，那你就只能去调整范围和成本另两条边。而成本很多时候也是不能动的，最终结果就是缩小范围和有效利用时间。
所以说，Deadline 之所以能提升生产力，归根结底，是由于利用 Deadline，倒逼着你缩小“范围”，做当前最重要最有价值的事情；利用 Deadline，让你专注，不浪费时间在不重要的事情上。从而可以把 Deadline，变成第一生产力。
如何在项目中应用好“Deadline 是第一生产力”？
既然 Deadline 是第一生产力，那是不是只要凡事设置一个 Deadline，就万事大吉，自然就可以把事情做好？把项目完成好？
显然也不是那么简单的事情！并不是随便把一个时间点设成 Deadline，就可以马上激发生产力。
首先你的 Deadline 是否有一定的强制性？
Deadline 之所以能成为 Deadline，就是因为它具有一定的强制性，Deadline 到了之后没能完成会有一定后果。比如说你作业没能按时交，那么分数就会受影响；项目没能按时交付，绩效就会受影响。
很多优秀的程序员，在公司的项目中能高效的完成任务，相反自己在做 Side Project 的时候却各种拖延，难以交付，就是因为无法给自己定一个 Deadline，就算定了时间点，到时间没能完成也不用承担什么后果，自然就难以将 Deadline 变成生产力。
有时候如果自己真的难以执行，可以让家人朋友帮助监督，或者可以学学亚马逊的逆向工作法（Working backwards），在打造一个新产品前，不是按传统的需求、设计、开发、测试和发布流程，而是先写新闻稿，然后开新闻发布会告诉大众要打造一个什么样的产品，以及什么时间发布，再去设计开发。这样在写新闻稿的时候就想清楚你的产品要交付的最核心的功能是什么，以及你的 Deadline 是什么。
当你把要做的事情和 Deadline 当作牛逼吹出去了，要想不被人笑话，就要考虑为你吹过的牛逼奋斗，保证在 Deadline 之前有所交付了。
然后你的 Deadline 是否具有可操作性？
成功的 Deadline 一定都是以科学的计划为基础的，否则不切实际的 Deadline 就会闹出像“两个女人 5 个月生孩子”这样的笑话。
怎么样的 Deadline 才算具有可操作性呢？
首先 Deadline 的时间点不宜太遥远。
当你的 Deadline 定的太过遥远，只有在 Deadline 临近的时候，才能发挥出作用，但可能已经太迟了。
传统的瀑布模型开发软件就是典型的例子。使用瀑布模型开发软件项目，也会有一个项目发布的 Deadline，但是这个 Deadline 通常在几个月甚至一年之后，结果通常就是开发过程前松后紧，刚开始不忙，临到上线时加班加点。
后来针对这种情况，一个改善的方案就是设置里程碑，里程碑本质上就是把一个长的 Deadline 拆分成几个短的 Deadline，比如说需求分析完成是一个里程碑、开发完成是一个里程碑。这样的借助一个个里程碑，让 Deadline 贯穿项目始终，持续的激发生产力。
然后 Deadline 到了必须要有交付。
很多人有追求完美的情结，即使 Deadline 到了，因为觉得产品不完美而不愿意交付，所以宁可将 Deadline 不断调整，一直延期，最终导致 Deadline 形同虚设。
完美是没有止境的，在你眼里不完美的东西也许在其他人而言，已经可以满足需求了。Deadline 的一个意义也在于通过 Deadline，让你在有限的时间内必须要有交付，倒逼着你放弃完美清洁，想清楚什么是你应该交付的最重要的东西。
交付，也不意味之交付一个漏洞百出半成品给大众，而是通过缩小范围，交付一个完成的最小可用的版本。
另外软件的交付也分两种，一种是内部的可供测试的版本，一种是外部的正式发布的版本。比如像 Chrome (Chrome Release Cycle) 的开发，会交付不同的版本给不同的用户，比如每天交付的开发版本，但是只是内部人员使用。还有 Beta 版本，只是给一部分测试用户，最终交付给用户的，已经是一个经过反复测试完善的稳定版本了。
再有就是 Deadline 到了必须要有完整的交付。
前面说的里程碑的方案可以很好的解决 Deadline 太长的问题，但也有问题，那就是在里程碑的 Deadline 到了的时候，虽然有交付，但交付的产物并不是十分清晰。比如说需求设计里程碑到了，只是一些模糊不清的需求文档。结果就只能是基于这种模糊不清的需求文档，边开发边修改，导致后续因为需求修改而产生很多不必要的浪费。
所以 Deadline 到了的时候，不能交付一个半成品或者模棱两可的结果，而必须是一个完整的结果，否则这样的 Deadline，生产力是大打折扣的。
最后再给你看一个在软件项目中，应用好“Deadline 是第一生产力”的经典例子。
敏捷开发的时间盒子
可能你已经知道敏捷开发，每天都在用敏捷开发管理软件项目，也许你还不知道什么是敏捷开发，在这里我不展开多讲，只讲其中的时间盒子（Time Boxing）概念。
在敏捷开发中，一个软件项目的开发，是采用的迭代开发的模式，并不是一次交付完整的产品，而是通过一个个的迭代，每次交付一部分可以运行的产品，最终交付完整的交付。
每一个迭代都是一个固定时长的时间盒子，时间通常不会太长，1-4 周左右，但每个迭代结束，都要求要交付可执行的产品。
这个时间盒子本质上就是一个个的 Deadline，每次时间盒子的结束点就是一个 Deadline。那这样做有什么意义呢？
首先，每次迭代前，你要计划好：当前迭代要做哪些事情？deadline 到了的时候能交付什么？
因为有 Deadline 的压力，每次迭代时间是有限的，而你又必须要交付，那么就会倒逼着你在计划的时候，会优先选择当前优先级最高的任务，专注在重要的事情上。
然后，在迭代的过程中，你要尽可能的提升效率，保证在 Deadline 之前能交付。
如果你想要在 Deadline 之前尽可能的交付更多的东西，那就会倒逼着你去提升效率。
所以你在设计的时候，只会做刚刚好的设计；所以你会写自动化测试，从而提升测试的效率；所以你会采用像 CI/CD 这样的工具，帮助你将很多工作自动化，提升效率。
最后，在迭代完成的时候，Deadline 到了，你一定要有完整的交付。
前面说到了：在 Deadline 到了后，有交付、有完整的交付非常重要。这也会倒逼着你去思考如果提升发布版本的质量。
要保证你有一个稳定的可交付的版本，在敏捷开发中有很多很好的实践：
- 首先是要有充分的测试，完全人工测试显然是跟不上快速迭代的节奏的，所以要有大量自动化测试来辅助，保证可以同自动化的方式覆盖各种测试用例；
- 然后需求不能频繁变更，这就意味着在一个迭代中，通常不会接受需求的变更；
- 还有就是采用分支的方式来开发新功能或开发 bug，只有代码审查和测试通过才能合并，这样你就有一个稳定的随时可以发布的分支。
敏捷开发的时间盒子，就是一个借助 Deadline 来提升生产力的经典应用。借助 Deadline，倒逼着你专注于重要的事，倒逼着你提升效率，倒逼着你按时交付可执行的内容。
即使你不是采用的敏捷开发的时间盒子来开发项目，其中很多借助 Deadline 激发生产力的思想和方法，都可以借鉴到你的项目开发甚至是日常生活中。
Deadline 就是第一生产力，希望你能理解和应用好 Deadline，帮助你提升生产力。