一个时间管理小套路

  • 2017-01-24
  • 84
  • 0
  • 0

如果老板给你布置了一个项目,
让你预估完成它到底需要多长时间?
二周?一个月?二个月?
不不不,你估了没用,它实际只取决于老板给你多少时间。

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才是第一生产力。

拖延不是病,是人这个物种固有的劣根性,不到最后一刻,决不一拼。

对待拖延,还真是一场自我欺骗心理战。

评论

还没有任何评论,你来说两句吧

发表评论