Cracking Hackathon第三届 Hackathon 已经圆满落幕，有人拿奖拿到手软，也有人会带来遗憾，不过最

第三届 Hackathon 已经圆满落幕，有人拿奖拿到手软，也有人会带来遗憾，不过最终大家还是都跑完了这场黑客马拉松。

这已经是我第三次参加了，分享一些经验，这个经验并不是帮助你拿奖的，而是如何能让自己少些遗憾，多些幸福感和成就感，避免耗了太多精力然后进入贤者时间。

在这次 Hackathon 开始之前，有几个事情需要先确定下来：

知己知彼，百战不殆，前面两点，就是了解自己和了解别人。

先看看自己想做哪方面的角色，精力上够不够，我在第二届 Hackathon 的时候是队长，但是发现同时我还需要做开发，48 小时的时间非常紧张，而且因为过程非常累，最后的期望值反而比较高，容易产生落差。

每个人都有 ta 擅长的地方，有的人点子比较多，有的人设计能力强，有的人做 keynote 做得很好，有的人开发效率高能保质保量。组建团队本就不是件容易的事情，更何况有些可能还是生面孔。

这次我不是队长，组建团队由队长负责，基本上也是完全按照角色需要来找人。

参加 Hackathon 之前需要统一整个团队的目标和期望值，有些团队铆足了劲上甚至通宵，有些团队第一次参加重在参与。而我们团队有新人有老人，大概是这么几个原则：

Hackathon 的评价标准主要在于评委，我们这次是全员当观众评委进行投票，这个相对来说人气的因素会高些，而且因为不是专业评委，所以对一些标准的拿捏也不会很严格，比如下面这些：

作品的完成度

设计好不好看占得比例比较高，但功能实现了多少主要依赖于现场的展示效果
切题率

如果题目有 2 个要求，那么切题率通常来讲是 A x B，也就是说如果其中一个是 0.6 另一个是 1，实际就是 0.6，但从结果来看更像是 A + B
演讲时间分配

三分之一演讲 + 三分之一的边讲边演示 + 三分之一的互动交流，这是我们团队的分配，觉得这样对体现每个人的贡献度比较平衡

接下来是不是要马上撸起袖子干了呢，当然不是，如果说前两届的 Hackathon 题目是可以站在巨人的肩膀上，那么这次的题目显然是自由度更大了。这就需要我们把它当成一个从零开始的小项目来对待，具体需要做好这么几件事情：

明确工作量

开发的工作量站多大比重，按照演讲的时间规划，开发的整体工作量应该不能超出准备 keynote 和演讲的时间，毕竟演讲占了 presentation 超过一半时间，开发太多功能意义不大，万一演讲没估算好时间，很可能开发的功能评委都没有体验到就结束了，非常打击开发这个角色的参与感和贡献度
明确 idea 合理性

这个比较关键，一个好的 idea 事半功倍，否则事倍功半，有两个误区非常容易踩坑

既然上面的坑非常容易踩，可以先去网上看看厉害的人们都有哪些原则：

What NOT to do

Don’t create many products inside your idea

可能会踩的是同时做了 iOS 和 Android 端，如果没有互动的场景，没必要做两个，现场同时做的好像只有我们 team，因为我们 team 有双端互动的场景，并且想让双端的都体验到（前提是安排好演讲时间，否则很可能白做）
Don’t be too ambitious and plan to do 99 different features

这个非常多的 team 踩了坑，做了太多功能，其实 demo 只要表达核心的部分就可以了，工作量应该不会特别大
Know what to hardcode

该 hardcode 的地方要 hardcode，避免过度设计，但基本的代码质量还是要保证的，毕竟没有多少时间留给你去做 debug
No login screen

千万不要有登录界面，浪费的不只是开发时间，还破坏用户体验流程

再讲一个我认为非常重要的一点，Hackathon 不等于 presentation，也不等于 demo，而是用 presentation 讲清楚 demo。

合理安排时间就成功了一半，鉴于这次 Hackathon 的题目提前公布了，所以我们的时间安排如下：

好的 idea 就是成功的另一半，天马行空的脑暴并不可取，虽然有些 idea 其实非常好，但是工作量不适合 Hackathon，我们 team 首先缩小了范围，用几个关键字先在网上搜一些 idea 的方向，看看大概应该往哪些方向上去想，关键字如下：

根据这个我们看了数百个 idea，这样脑子里就有一个范围了，不至于去讨论一些不着边际的东西。

最后还是队长的 idea 获得了其他人的认同，但 idea 的评价标准还是上面这些，有了标准以后才能迅速认同，否则只是你想你的我想我的，不容易统一，团队的凝聚力是非常重要的。

后来我知道有些团队的 idea 是因为时间不够了为了开发时间所以做了妥协，就我自己的感觉，如果时间不够，就继续想，最多开发的 demo 完成度低点，起码是大家都想做的东西，否则为了完成度高，结束了之后会非常空虚的（我为啥来参加 Hackathon ？？？）。

我们给 team 技术预研的时间是半天，因为再多就没时间进行业务开发了，而我们又不想熬夜或者通宵这么肝。

这里先说一个 Hackathon 的原则，本质都是做技术整合，不可能短时间开发一门新技术，所以技术和框架的选型是非常重要的。

我们在接入 sdk 的过程中也遇到过问题，比如 demo 跑得好好的，但是基于 demo 改了一下就不行，log 也看不出什么问题，最后决定基于文档来重新写代码测试，这样能保证一行一行加进去，自己能够掌控。

presentation 非常重要，辛辛苦苦开发了个 demo，如果 keynote 做得不好或者演讲的时候没把握好时间，那工作量白费不说，参与感也会大打折扣。

keynote 和演讲是门技术活，尤其是做能够吸引人的 keynote 和对演讲进行彩排，其实也是有章可循的：