如果老板给你布置了一个项目，
让你预估完成它到底需要多长时间？
二周？一个月？二个月？
不不不，你估了没用，它实际只取决于老板给你多少时间。
Deadline总是会给你造成时间充足的幻觉。
很多时候，80%的任务量都是最后几天，甚至最后那几刻完成的。
而前面的时间都在干嘛呢？
一直处于准备的状态。
前天，Xdite给我们分享了她获得Facebook Hackthon冠军的经历。
Hackthon需要一个团队在9个小时内完成一个项目。
9个小时你需要制定idea, 完成功能，排bug, 做PPT，上台展示。
这还包含吃饭上厕所的时间。
时间很紧，这9个小时得怎么安排？
实际上，Xdite团队只有两个人，她说，人多了容易吵架，很多项目没做好都是因为人多很难达成意见一致，从而很多时间都花在争吵上面了。
要在超短的时间内做好一个完整度高的产品，获得比赛的成功，你得想明白，到底哪些事情是最重要的，毕竟你把最重要的事情最好事半功倍。
它也许是：
最好的idea？
最好的code?
最好的PPT？
回答这个为题前，首先你要定义“成功”。
成功并不是证明你或者你的产品有多么牛逼。
在这个Facebook Hackthon大赛里，成功的定义就是让评审认可你产品的价值。
那在评委眼中，什么是好的产品？
- 投影片牛逼
- 演示感人
- 有意义的产品
- 没有BUG
- 明天就可以上市
这么说的话，我们甚至得出这样的一个公式
好的产品=有价值的功能+好的PPT
比赛嘛，打动评委才是硬道理。
于是上面的问题里，参加这么个比赛，做什么事最重要，答案居然是做好PPT！
三件事要按重要程度来排，是这样的：
1，牛逼的PPT。
2，其次idea好。
3，代码还行。
难怪搞创业的，搞融资的都是PPT高手。
Xdite虽然是写code的高手，但写code却不是最重要的。
如果你能搞定PPT的话，那还要在最短的时间，打造出牛逼的产品，那要怎么做？
1，不要太多idea, 只做一个关键功能。
2，尽快做出最小可行性产品。
大型的项目都是有很多的User Story(用户故事)，一开始把项目规划得很大，事先定义很多功能，其实，复杂的系统，风险是很大的。
越多的功能 => 越多的bug => 越多的风险
墨菲定律说的就是：该出错的事，总是会出错的。你越怕它出错，它越会出错。
项目越复杂，bug几乎难以避免。
好吧，想通了，那就只做核心的功能，短时间内，尽快做最小可行性的产品。
那在做项目时，我们要分析一个项目的用户需求，怎么样可以提炼核心功能呢？
写User Story有个非常有用的方法，你把用户需求按照以下4个重要级别列出来：
- Must have
- Should have
- Could have
- Nice to have
必须有什么功能？应该有什么功能？可以有什么功能，又有什么功能是可有可无的？
当你可以理清什么是重要的需求，什么是不重要的需求，请砍掉不必要的，只做Must have 和 Should have 部分。
Xdite在这场比赛里，居然只做一个功能，她的项目只是做了一个facebook的分享收藏的功能，她认为，这样的一个idea应该是主办方的确需要的。
好吧，也许是吧。
那明确了要做什么，Xdite是怎么分配这9个小时的呢？
- 她花半个小时跟队友讨论，决定做什么。
- 花半个小时的时间做最基础的东西，比如deploy(部署)，通常一个编程项目都是最后一步才deploy的，但是在编程项目中，最后这个deploy环节经常莫名其妙地掉链子，部署到服务器上的过程也许会有意想不到的事故。就好比你考试，所有的题目都会，但就是忘记了写名字，填涂答题卡，还是等于白忙活。把整个流程的最重要、最可能出意外的事情，预先处理好可以省掉很多不必要的麻烦。
- 然后又两小时的时间搭好框架，做主线，做好主要功能。
- 其他时间填补点细节，留下大量时间来测试，修补bug.
- 还预留大量的时间（2小时）来排练demo演示。
实际上，9个小时的编程项目大赛，Xdite给自己的预设时间只有6个小时。
剩下的3个小时都用来“挥霍”了，或者说看起来是挥霍，但其实还是用在很重要的事情上，比如做PPT，和上台演示的排练，这样就几乎没有心理压力了。
就靠这种奇淫技巧居然拿到了Facebook Hackthon的冠军。
有人表示不服，但也不得不服。
因为：
- 她的PPT确实好看，评委看得懂，看得舒服。
- 主办方Facebook 也确实需要这样的功能。
- 展示过程中，评委没发现任何bug。
- 这个产品可以立即上市。
而其他团队落选，要么花了太多时间与队友争吵需要实现哪些idea, 要么因为功能太多导致bug太多出现问题。
整个故事说起来很简单，就是挑重要的事做，并提前做好。
预留了三分之一的时间，是一个很好的心理战略，甚至可以放到任何事情上。
明明老板告诉你一个月内完成某个项目，你欺骗自己说要20天，也许20天你真的完成了，还留下大量时间来修补小问题。
明明允许预期30天完成的一个项目，老板欺骗员工说必须要在20天内完成，可能20天这个团队就真的完成了，老板于是偷偷暗喜。
不管是写文章，还是写报告，还是做任何项目，都可以尝试设置个提前的deadline。
当时间不充裕的时候，效率特别高。
毕竟，Deadline才是第一生产力。
拖延不是病，是人这个物种固有的劣根性，不到最后一刻，决不一拼。
对待拖延，还真是一场自我欺骗心理战。