上一章我提到了，一个项目有高达 600 条细项，我们如何管理这么多细项。
## 我如何在全球 Hackathon 获胜
2012 年，我曾经与朋友双人组队，在 Facebook 举办的 Hackathon 获胜拿下大奖。
大概在六年前，我还没开始创业前，当时我个人搭项目的速度已经很牛逼。其实连在这次大赛获胜，也是预料中的事，只是我没想过会拿第一名而已。
很多人以为 Hackathon 获胜是凭运气与技术工底，但打 Hackathon 其实也是可以「准备的」。
这场比赛我是有十足战略的。
当时得奖的作品是一个书签收集服务。当初打算解决的痛点是：
- 当时每个人在 Facebook 每天都会 Like 很多页面
- 但是一 Like 过，隔几天就不知道去哪里了。
- 无法储存收藏觉得有价值的连结
我想开发一个网站，让一般使用者透过这个服务，可以自动收集整理自己曾经在 Facebook Like 过的书签，并且搜索整理。
这个功能 Facebook 已经有了。在 2014 年上线。我之所以能赢的理由很简单。我真的太想赢了，所以有备而来。
比赛前，总结了我以前在 Hackathon 落败的几个主要原因：
- 太贪心 - 想在比赛里面做尽可能多的 Feature，结果作不完
- 没有人懂价值 - 功能作不完，简报没时间做，上台乱讲导致上台时没有人懂这个产品的价值
- 不能用 - 写不完结果没有时间测试，
- 自HIGH - 自己做了一个觉得很炫，工艺很高的产品，但是完全不合主办单位举办这个比赛的期望
我以前认为要赢，只需要代码牛逼，IDEA 牛逼。没想到反而相反。
在黑客松落败的朋友，很多人在比赛结束批评得最凶的一件事是，赢下大奖的永远是 "PPT 组"。
虽然这件事很不公平，但我发现这却是真理。一般评审根本没有空可以看你的代码写的如何，他们只关心最终成品解决了什么问题。试用的时候是否真如同参赛者宣称的一致而已。至于有没有写真实代码，还得事后查核。
身为有一个有自尊的程序员，在 Hackathon 中纯用 PTT竞技，是绝对不可能的事。
但我觉得过去的打法的确是可以改进才是。
我归纳出了几条很简单的战略：
- 功能要单纯，最好只有一个主要功能，这样才做得完。
- 要做对主办单位有意义的项目
- 扣除开发时间外，要留足够多的时间写投影片与 DEBUG
下次这么做也许有可能赢。
我认为打 Hackathon 其实跟创业这件事其实是挺相像的。
- 需要牛逼幻灯片
- 正确的产品，适合主办方开新闻发布会
- 在最短时间，开发最小可行性产品
- 需要牛逼幻灯片
- 被市场认可并获利
- 在正确的时间点启动上线
打赢一场 Hackathon，本质上就是挑战在 10 小时之内创业。
那我们当时赢得关键是怎么样呢？第一个是说我们上台的时候，当然做了很牛逼的投影片，我本人也复习了很多遍。第二个是我们做出了一个对主办单位很有意义的项目。第三个是我在完整的要求了七个小时之内要做完，我在时限之内做出了一个完整的产品这样子之类的。这背后当然它的关键因素除了第一个是因为我(英文00:00:23)写得很快之外，第二个是我的时间管理很棒，在这边我就要解释为什么我可以做到这件事情，因为我刚刚前面有讲到我之前打(英文00:00:28)一直输，我那次就是因为太想赢了，因为我那时候想要创业，那创业希望有人吸引到我的产品跟我认识团队，你就觉得去打一个(英文00:00:28)，应该可以，如果有得名应该可以有助于我的产品曝光，说我就非常用心的准备，那我之前因为常常输，因为身为(听不清00:00:58)都会觉得我一定要有个牛逼的点子，然后或者是说很快写完技术很牛逼，我才可以(英文00:00:58)。
但是我就发现永远输，我有一次做了产品就非常的牛逼，美术也非常好，但是也却输了。后来我就发现为什么我做错了，做错是因为我做了一个产品，是讽刺时事的这个产品，那主办单位认为这不登大雅之堂，所以我连得名的机会都没有。而且我也输给投影片档。在更之前的我的(英文00:01:38)为什么都输呢？第一个我常有的问题，我可能写完我的项目，我才开始做投影片，结果就造成我的投影片写不完，接下来应该没有彩排，Demo就烂，按下去就直接爆炸，自然我也没有得名，所以我就想说我这是一定要赢，所以我就拟定了一些特殊的策略来让我保证绝对要赢。那我们当时是做什么产品呢？事实上我们是做了一个Facebook的动态珍藏连接的管理器。我们是在2012年的(英文00:02:16)赢的，我们还有Facebook在2014年的时候推出了这样的功能，我们是在七个小时里面做的。
那我讲一下我们当时比赛是怎么样进行，以及我尽我采用的策略，我们早上是早上9点开始比赛的，是下午的六点进行的(英文00:02:33)，总共有九个小时，那我为了一定要做出完美的比赛，我必须要花至少两个小时写投影片并且彩排，所以九个小时扣掉两个小时就是七个小时。那七个小时我们又扣掉吃饭的时间，还有上厕所的时间，大概一个半小时到两个小时，那真正我写作时间只有五个小时。各位猜猜看我这个当中我写了多少功能呢？给大家五秒钟的时间想看看，五个小时我能写多少功能？1、2、3、4、5，答案是一个功能。为什么呢？我到最后决定只写一个功能？是这样子的。
各位应该有这样的经验，每当你时间不够的时候，你会发现一件更囧的事情。你做这件事情的时候非常容易出错。平常比如说写代码可能会有五个Bug，那你很紧急的时候你就会发现你有15项的事情。土豆历史还没做，而且还会生出一大堆Bug，这就是所谓的墨菲定律。那为了怕墨菲定律干扰，我就发现我如果只有五个小时，依照我的功力应该可以写五个功能，但是因为会有墨菲定律，所以最保险的方法我只做一个主要的功能，如果这个功能做出来我就万幸了，所以这是我们第一个策略。我们的核心非常简单，就是一个网站增长器，去抓Facebook上面的动态，并且储存，就这样子就没了，也没有什么分析的这个功能。
那早上9点一到会场，我就只花了简短的时间跟我队的，我只有一个队友，我就跟他简短的沟通，我们今天早上要做什么？他虽然觉得这点子好像太单薄了，但是因为他比较菜，所以只能听我的意见，所以你打(听不清00:00:13)千万不要找太多队友，太多队友我们的意见就会分歧很多，像我知道有人打(听不清00:00:19)就喜欢找很多牛逼的队友，结果他们到最后的这个时间都花在吵架，那我只找一个队友跟我搭而已，那所以那时候我们就花了很简短的时间决定我们要做什么，所以我大概花了半个小时就决定我们到底要做哪一些方向，再花剩下的一个小时就是把我们的这个网站先部署上，部署到机器上面。那为什么要先做这件事情？是因为我以前发现等我把作品做好之后，然后要放到这个(英文00:00:54)或是说远端的机器里面，所以说我遇到一个最大的挫折，就是因为本地的环境跟远端的环境不一样，所以你要花很多时间调试，那时候一定会出非常的多的包，会导致你的投影片也没办法写完，所以我们第一件做的事情就是把最大风险抓出来，也就是(英文00:01:07)的风险抓出来，我们的第一次的时间，然后就把这件事情做完，那以后我们只要更新本地的代码再部署上去，那基本上你就可以很快的知道这个东西work不work？所以我们第一阶段是花了一两个小时做这件事情。
那我们第二部分是干什么？我们第二部分是再花了一个小时，把我们的主要功能赶快做好，做了一个简单雏形的框架，所以我们在12点左右就把我们的东西全部做完了，主干全部做完，12点做完有一个很大的战略意义，很多人不明白为什么要我在12点之前要做完？明明下午6点才是截止日。12点做完有个好处就是当中午大家在吃饭时间在讨论我们今天要做什么时候，我就拿着我的笔电就说我已经做完，你看多么厉害，世上只有一个可以，但是其他人不知道，他会觉得我操，叉代(人名00:01:58)实在太牛逼了，那怎么办？我已经赢不了。那我就是要这种效果，12点的时候我就把主要的功能就写完了。
第三阶段我做什么？我第三阶段就是把这个主干功能，所谓的这个上面可以微调的小部分的功能都慢慢的补完，然后接着就拿，就是到Facebook上面请我真实的朋友下面去测网站有没有什么样问题。那为什么要做这件事情？因为我以前做完的时候都没有测，结果评审测的时候就烂掉了，我就觉得不能再发生这件事情了，所以我那时候一做完就丢给外面的真实的用户去测，他们马上就帮我测到这些bug。为什么要这样测试？因为我这个东西是每个人在Facebook上面都有很多的珍藏，然后我们要时间去汇入，但是在三个人再用这个网站的时候汇入速度还是正常的，但是我一丢给50个人去测这个网站上面就非常的慢，而且使用者会进去了，但是却没有看到这个内容，它允许授权的，但是却没有看到网上有进度，他以为网是烂了，我就发现我的演算法其实是写错了，所以我就马上的这个修正，要是我没有做这件事情的时候，估计上线那个评审一按，然后就烂掉了，那我就很庆幸的我做了这个阶段的事情，大概是在下午的三四点，然后我就把所有的bug全部都修掉了。那最后一步骤是怎么样？最后一步骤的时候，突然间有一个朋友就问，说叉代你们到底是在做什么？我说不是明显吗？这个就是。你每次存了很多Facebook连接，你每次点了很多Facebook连接，过几天就会有人问，说你前几天分享了什么东西？好像很棒，但是我已经忘记了。FB它又不做一个收藏的功能，所以我们就做这个功能，这样你之后可以再回去记下来你存了哪些东西，并且是可以搜索，我们是做这个，你看不出来吗？他说鬼才知道。他说外面的人都会有首页，然后说明他们做什么，就建议我们做一个首页，我想说对，我还没做，所以我就做了一个这样的(英文00:04:39)page，我就做了一个首页这样子，紧急就做一个首页。因为在测试的时候很多人给我们这些反馈，所以我就花了一点时间，我就花了半个小时，写好这个投影片，丢给我的朋友修我自己也修了遍，并且在台下排练了至少五遍以上，你知道吗？我们程序员上台，我们都会紧张，一紧张就结结巴巴讲不好，更何况还要Demo，Demo错了之后完蛋了。所以那时候我就因为有做这几件事情，所以我在五六点的时候Demo兼职就是完美。
最后为什么位移？第一个我们的投影片非常牛逼。第二个我本人发表非常的牛逼。第三个，然后我们做了一个有意义的产品。要知道这个黑客松是Facebook办的，所以我们做了其实Facebook想要做的一个功能，但又不敢做，也不知道有没有市场，所以我们第三个做了一个有意义的产品。第四个我们的产品是没有bug的，因为给很多人测过了，所以没有bug。第五个就是它100%production
ready，也就是说明天上线，我要跟各位收钱或是直接使用，是完全没有什么问题，它完成度极高，这就是为什么我们当场赢得那一场。当赢的当场的地区的黑客松的第一名，业务赢到了亚洲跟世界的第一名是有原因，因为我们的产品完整度跟意义实在是太高了。这里我要跟各位分享，其他人是如何搞砸他们的黑客松，不要说搞砸其实他们也不是故意的，但我要跟你说一般人去打黑客松的时候，他是怎么样做的？首先他就到会场第一个先找小伙伴，牛逼的小伙伴看谁，然后就讨论说你要不来我们这一组，然后要不要来？然后即使他们组的组成了一个非常牛逼的组，他们就觉得他们要做一个牛逼的产品，于是他们就提出了每个人假设有五个人，他们就每个人提了两个feature。
然后到最后就一直吵个没完，然后吵到最后花了一个多小时才决定我们要做十个功能，然后做不完，但是要做六个功能，所以他们就分头去做六个功能。接着他们就在花了五个小时，然后疯狂地做实做这些功能，然后快到截止日快到(英文00:01:35)的时间的时候上台发表时间。他们还在fuck我们又做不完了，就只好砍到两个功能急急忙忙的收尾。然后急急忙忙的收尾之后，再赶快谁偷就是有个人就妥投影片，另外一个人就是在彩排练习。然后一上去因为这产品是没有测试过，就上去第一个就先道歉，抱歉我们这个产品没有做完，请大家不要见怪。第二个，就是他顺利得demo之后，然后(听不清00:02:09)一按，烂掉了，台下一按烂掉了，然后它自然就被打零分或者是很低分，几乎99%以上的人打黑客松都是这样输掉，包括我以前也是一样这样输掉的。当中我跟他们的差别在哪里？
一个我非常知道我的节奏，我坚持在中午12点前把一切的东西都做完，并且我预留的最后的时间可以彩排，你注意到我几乎是留了两个时间，两个小时去彩排，两个小时的时间是修bug。然后非常节制的做功能，但是其他人是不管城市的，就是埋头苦干去做，导致我们都拥有七个小时，但是我把功能完整的上线，但是他们只做出了一个什么都不是的东西。我要今天跟各位透露的诀窍就在哪里？你可以发现到。因为其实我以前常常做很多大型的项目，大型的项目两个月，三个月，其实我都有办法准时的完工，唯独在黑客松我是没有管，做专案管理技巧的，没有做项目管理技巧，所以输。所以我其实在这次用的是我以前做两个月，三个月大型项目的技巧，然后去控制，也一样拿来控制我的七个小时，我最后才决胜。
我今天要跟各位分享是说，如果平常做大型的这个项目，你要怎么样控制的时间？这一样可以用在大的中的小的项目都可以。运用这样的原理，先不管是多少时间，假设今天我们要做的这个项目有三个月好了，我是怎么样管理这个项目的时间？首先假设我们有三个月好了，我不管这个项目是要做什么东西，我一定会预留最后一个月的时间，最后一个月的时间不能动。也就是说变成三个月老板给我三个月时间做这个项目，我只有两个月时间做开发。然后我一定会预留最后一段空白，谁都不能动，去测试东西，只留两个月的时间好做功能。
接下来我会把剩下来那两个月的时间再把它切三段，第一段就是做地板作业，之后在最后不做会死的东西，我尽早要排除掉，接下来再做主要的功能。最后才是小小的功能慢慢修补，最后一段我有充裕的时间，可以完整的就去闪过那些风险，把这个细节打磨到最好。所以你看其实我的(英文00:00:33)也是这样子做的，我的(英文00:00:33)我下午两个小时的时间是完整的去表留起来我做demo，我以中间的中午12点这个为界限，早上去把大的功能跟最危险的(英文00:00:52)都把它做完，下午在做小的功能跟用户的测试，我很顺利的之后就去做demo
pitch，完成这个上线。这个其实就是找到你自己这个节奏。
通常是这样子的，很多人碰到一个大项目非常大，他就失去了准则，以为只要猛力做，最后就会达到所谓的成功，但我的做事方法并不是这样子的。我第一个要做任何事之前我都会定义，第一个成功的定义叫做什么？比如说做大项目就是说顺利完成，收到钱，这个叫做我们的成功。如果你做的东西没有收到钱，这个钱就要失败，所以你的金牛的东西一定要做得非常，因为这才叫成功。所以我做我(英文00:01:38)什么叫做成功？成功的我发现的定义并不是你做的多牛逼，而是你要让评审认知到你做产品的价值，要让评审认知到你做产品的价值，也就是你唯有做好的投影片，跟好的pitch，让吸引他借着你的产品的代码才有机会被看见。所以就我花了很多的时间，我花了两个小时，这只是(听不清00:02:11)这件事情，我明明写(英文00:02:11)非常牛逼，但我却选择把最重要的地方放在这里，因为这个东西才叫success。
success之后我们就可以按照这个成功的定义去安排我们的进度，你就可以再把什么东西是对于成功的定义，什么是主线？什么是副线？什么是风险？你就可以把它排出来，你一开始就把风险的这个问题都先抓出来，并且在主干的地方大部分的完成，副干的地方也慢慢的修整，你就会有充裕的时间知道什么事要做，什么事不要做的。因为项目它其实活的，很多人觉得项目是死的，它是一个项目经理写完的一页纸或是说一本的纸。事实上不是这样子，你在做项目的时候你就会发现，很多当初的预想都跟真实的想象是不一样，所以项目是活的，你要准确的抓住这个项目的工时，花费的人力，其实你是没有办法去抓的。所以你有办法抓的是知道是什么叫做成功，你尽可能的去逼近成功，那我的方法就是这样子。
什么叫做成功？只做master(英文00:00:00)，我砍掉所有的(英文00:00:00)，当我有时间的时候，我再重新排，我去做，所以我做的方法就是不管时间有多长，七个小时也好，一个月也好，三个月也好，我一定会先把它砍掉三分之一的时间，假设我有90天时间做功能，我一定把那30天砍掉，只剩下60天。为什么我要这么做这件事情？我要跟你说，一般人做项目是这样子，假设这个老板就是有90天的时间，跟你说要做个项目，很多项目经理会跟你说，好的，我们一定做得到。接着，他们觉得因为这个项目很重要，所以不能闪失，所以他们可能会花上两个月时间，也就是说60天，去专注的把企划书生出来，接着计划书终于生出来，讨论出来之后，他们接下来会把这个企划书交给美术去执行，美术把所有的画面都画出来，这个当中又花了20天的时间，注意到，你原本有90天的时间，你用了60天的时间，这又花了得有20天的时间，所以你只有10天的时间可以写代码。
每次RD拿到这个代码就觉得，fuck，我写不完的，所以他就拼命的加班，这10天他就自己积极的加班，结果还是写不完，一上线了，因为已经有发布会了，没办法，一上线，这个代码千疮百孔，消费者按着按着就发现烂掉了，烂掉就不行，所以他又只好加班的修，所以任何新东西上线，有一些物联网的产品，你一用就知道bug就非常多，事实上是因为这样子，他们完全没有资源管理的概念，又是这样一鼓作气的冲，做了以后消费者反响不好，于是他们就决定要改版，改版就说我们再来个90天改版，就又是这样，这次我们情况不能做，他又花了更多的时间写企划书，于是又发生同样的情形。事实上这种东西就像灾难一样，我要跟各位讲，怎么样破除这件事情？是这样的，你有没有发现？当比如说你要是赶报告，写文章，写项目的时候，你会发现当时间不够的时候，你的效率特别高。所以我发现每个人都有这种劣根性，包括我都有，所以我发明的做法就是假设有90天，我就砍掉了30天，跟我自己说，只有60天的时间可以做完，或者跟我团队的人说我们只有60天的时间。
然后大家就会非常紧张，所以他就会想办法在60天里面之内冲进度，到了60天之后，我说我跟各位说，各位，我们还有30天的时间可以慢慢打磨，他们就说fuck。
虽然会觉得我这个人套路很深，但是我们就会有充足的时间把这个东西就排好，因为如果你有这么多时间，你也只会把它浪费掉，与其浪费掉，不如你把时间先存下来，到用的时间你就可以尽情的挥霍，你可以让你排练的时间，测试时间尽量的多，所以你可以反复的复盘，而不是把时间就是都浪费在无意义的加班，无意义的失火与救火，这其实就是我管理进度的方法。给各位分享今天的重点，今天的重点就是各位不要觉得学了(英文00:03:43)之后，你就无所不能，事实上你下一个挑战，就是当你在做一个比较复杂的项目，包括我们接下来后面可能会交给各位其他的项目，包括你学习，包括你做事情，包括你参加比赛。其实任何需要时间的东西，都需要这样的时间管理，甚至这个东西都是你个人就可以应用到的这技巧，你学到的这个技巧，对你在(听不清00:04:02)安排东西会非常的有帮助。
这是春节前送给各位的礼物，因为春节我知道大家都不会想要写一写(听不清00:04:32)，所以我们这一期的(英文00:04:32)就先暂停一周，我们在春节之后会教各位写购物车，这个礼拜的时间我们教大家怎么样做项目管理？各位把握最后一周的时间，把大家的(英文00:04:32)冲刺完毕，谢谢各位。
后一个月是测试期。这一个月又分成
- close alpha
- close beta
close alpha 的对象是开发组以及营运组人员。也就是与核心较为相关的组别。此时针对的测试目标是这个 project 业务上应该被「实作」的 functionalty。比如说是食谱网站，就应该可以
- 上传食物照片
- 新增烹饪步骤
- 站方精选
- 有热门食谱、新进食谱
- 分享到社群网路 ...etc
如果是讨论区，要应该可以
- 可以发表文章
- 可以回应文章
- 可以贴图
- 可以收藏
- 可以搜寻
- 编辑器运作正常 ...etc.
另外测试时要拟定使用「未登入会员」、「登入会员」、「营运权限」、「Admin 权限」各测过一次。
因为开发组成员在撰写功能时，为了方便，几乎都是以 admin 帐号在开发，如果不制定测试步骤和角色，很容易没测到死角。
此时的修复重点放在 feature complete ( 或取舍 ) 以及 functionaly 是否正常运作。
请不要在此时进行任何 UI 动线调整
close beta 的对象是全公司所有人，公司员工的亲朋好友，可以信赖的死忠会员等等...etc. 此时针对的测试目标是这个 project 的 UI 动线。
如果是讨论区：
- 发表的动线是否顺畅
- 是否 UI 的暗示容易让使用者 miss 掉上传照片步骤
- 回应文章的动线是否流畅
- 网站新讯息的流动是否不够快速，容易造成网站看起来一片死城。
此时已经是视同准上线了（所以 Close Alpha 阶段的资料会清掉），所有营运组的人必须视同营运状态一样运营站务，以避免正式开站遇到状况时手忙脚乱。
（这一招是从参访壹电视时学到的。当时壹电视快开台时有受邀去内部参访，当时听到他们已经内部试run 报新闻run 了一年时，震撼非常... XD）
此时的修复重点放在 UI 动线的调整，以及运营方针、步骤的调整，避免开站之后网站就变成死城。
我在开发阶段时，最常向 RD 宣导的事情是：我不想管你这个功能怎么写出来，但我要你准时交出来。 （但最少要符合内部写程式规范，有办法读懂）
原因是：网站最重要的是 Deliver 上线。而不是站上的 feature 用了多屌的技术，用了多棒的 best practices，没有用户会在意这件事。而「贪玩」「迟交」会砸了一切。
直到 Open Beta 期，Optimized 这件事都不会被提到。因为在网站稍微 stable 之前，所有的 optimized 都毫无意义，做了也是白作。因为会发生效能瓶颈的地方，永远在你设计时意想不到的地方。
如何作 Performance Tuning？
- 抓出最慢的地方 Refactor 掉
- 找出最常造访的页面压力测试
既然已经进入 Open Beta 期了，这时候手上应该可以拿到这个网站最常造访和效率最差的页面。
可以使用 ab 去对网站进行压力测试。
再决定是要 refactor slow code 或者是先上 cache 档着先。
影响网站使用者感受最大的其实不是 backend 的效率，而是 Browser side 的效率。
以上说的都只是 Performance。但是这跟实际运营没有那么大的正关系。我擅长开发的是「内容网站」以及「社群网站」，这一类的网站重点其实是 SEO 以及社群穿透力。
- SEO 以及 Facebook OpenGraph
比如说：这是在 T 客邦累积出来的两套 gem。
网站的每一个页面都会确保分享至社群网站是正常的。
- Advertising
靠广告赚钱，所以要调整广告板位
- RSS / Email Subscribe / 粉丝团活动经营操作
跟 user 的互动...etc.
这些都确认没什么问题了，然后才是开站。然而开站不是这一切的结束，还有其他事情需要作...