身为程序设计师、软件开发者应该都对于 Hackathon 不陌生，可能或多或少都有听过，但不是资工背景的人也许是第一次听到 Hackathon。
Hackathon 这个术语是由两个字合成，编程「hack」加上马拉松「marathon」，诞生于 1999 年。Hackathon 除了叫做黑客松，又称为黑客日、黑客节或是编程节，是一个由计算机程序设计师和其他软件开发人员共襄盛举的活动，时间大约在一周左右，其举办的本意为：在一段特定的时间内，很多人相聚在一起，形式内容不拘，编程的过程与结果没有任何限制，透过团体合作，把他们所想要的项目结果进行编写与应用。换句话说，Hackathon 提供了一个场合让开发者能互相交流，并增添乐趣。
那如果不是相关背景的人，但是自学 Coding，可以去参加吗？
本文作者 Xin Wang不是开发者也不是设计师，但却报名了第一次的 Hackathon。以下由作者第一人称撰写。
在 Hackathon 当天，一直被问到我的工作是什么，但我找不到一个适当的时机告诉大家我其实是一个顾问，但已经辞掉了工作，而且同时在学习开发并寻找在新创公司产品开发的机会。不管怎么说，我很希望可以搞清出其他人在做些什么、在 Hackathon 这样的场合要怎么增加一个非开发人员的价值，以及减少焦虑及降低阻挠你的不确定感。
准备好一些点子再参加
你该做的就是行动，而不是花时间在做市场调查或是使用者行为分析研究。脑中要装点想法，或者是说，如果你像我一样，对每天的痛点都会有很多一闪而过的想法也好。当然如果你已经跑过程序、测试过很多遍，那即使没有想法来参加，也绝对是没问题的。
在一个团队里，你要明白自己的角色定位在哪
在开始之前，我已经先预设自己是很没用的，因为我不会设计也不会开发，想东想西令我窒碍难行，没有高谈阔论，更多的是闭上嘴巴安静到不行的时候；结果我发现，即使是设计师和开发者，在创造一个产品时仍然有许多东西是需要帮忙的，包含以下 9 点：
1. 使概念具体化并策略化：
其实你知道，要想出解决什么问题的方法是高难度的，要对你的目标客群呈现什么才是好的、你的目标客群最需要的是什么，运用你的想象力，就是你能跟得上其他人的地方。
2. 用 UI/UX 设计语言来沟通，并且让使用者能与设计师合一：
作为一个给予设计师的顾客意见回报者，对于非资工背景的你来说会是很有利的。
特别是当你有远见时。很快地告诉他们你所期待的产品是如何和用户互动，以及如何以最好的方式呈现产品信息。比如说，在我们的团队里，不断地抛给彼此想法，然后这个想法就会不断的演进、进步。我也建议设计师，可以在 App 上利用某个象征图案来进行搜寻与下载，并且以颜色的选择来做区别，让使用者可以给予回馈。
3. 支援设计师：
对待 Google 要像对待你最好的朋友一样，不只在 Hackathon 是如此，平常生活也是一样。
对我们的 App 来说，我们必须要从不同的来源中收集到数据，我负责下载这些资料给开发者。然后我们了解到只能得到以 XML 格式的数据，然而他想要在 JSON（JavaScript Object Notation，为一种轻量级的数据交换语言，以文字为基础、易阅读）里的数据。
我没有问到底 XML 和 JSON 的差别是什么，我试着利用在线转换器、语法分析器，有些错误被我修正好了，部分无效的 JSON 编码我没办法修复，我只好请开发者帮忙。
4. 成为设计师与开发者的沟通桥梁：
有时候团队间的相处可能会产生小摩擦，要准备好成为和事佬和沟通桥梁，让他们愿意站在同一阵线并且好好谈要如何进步与改变。
5. 执行使用者行为研究：
因为时间不够，我提早进行这个部分，但是你要有时间来随机地问人，关于他们对产品的态度及想法，当然，你可以采纳他们所说的，或是取其中的一部分来实行（虽然最后可能什么都不会采用，实际一点，对于你的产品、资源以及有什么限制，你最清楚不过了），但是至少你会获得验证并且获得他人对你想法的支持。
6. 时间控管：
和时间赛跑这是需要智慧的，不要假定人们会坚守到截止时间，你得明确的知道时间轴会不断的变动，当你要改善产品或是问题发生时，多点弹性会更好。但在开始前记得要设定缓冲期间，要定时提醒你的团队们还剩下多少时间，并且什么是在时间内一定要完成的。
7. 上台报告的呈现：
开发者不会使用 ppt，他们宁愿做文字上的编辑或是仿真 App 及网站运作。而设计师也不会使用 ppt，虽然有的人可以上台报告，无论哪种方式，明白在团队中谁最不擅长上台报告－这对他们而言就是一种艺术，你必须要说一个具有说服力的故事，并和自身经验做连结来抓住观众的目光。
接着陈述遇到的什么困难，怎么解决，然后再实际操作 App 和网站。还有很重要的一点是，不要觉得做出来的就是最好的，要告诉观众如果你有更多的时间，你还会想要做哪些地方或是修改哪些部分，如果你能让观众对你的产品与呈现深深着迷，那就很有机会晋级，这一切就是要包装。
8. Q&A：
当第二天我们完成了 App以及上台发表，我们的开发者决定不出现。
因此就剩我和设计师花了好几个小时在做最后的修正调整，在完成我们最终的报告呈现后，我们开始进行模拟 Q&A 时间，我问他关于设计的原型（为确保所有的按键都链接到正确的页面），他问我关于我的报告内容（为了确定我们初始想法及用字遣词是否恰当），这会是很有帮助的，可以厘清、找出错误，进而修正。
9. 上台呈现与模拟操作：
不得不说，上台报告的魅力对于有的人来说是与生俱来的，不是每个人都能够轻松的和台下互动并且让观众哈哈大笑。
事实上我们获得了许多笑声，而且之后还有很多人跑过来告诉我们说，他们也有相同的痛点与需求。这听起来真的是个还不错的呈现，但是我坦承的说我不记得最后一次我公开发表是什么时候，而且上台报告并不是我的强项。但唯有奋力一搏，你才不会后悔。
你唯一能做的就是不断的反复练习、练习再练习，能够在一群陌生人面前练习也是一件很有趣的事。
如上述所说的，除非在一个团队里有一个很明确的*，不然没有人会告诉你你该做什么或你可以做什么，因此你必须要知道自己可以做什么，以及事情完成的优先级，或者是你可以扮演项目管理者并上台发表；就是不要只是坐着什么都没做，或是游手好闲，一定有什么事情是还没完成要去做的。
讨厌改变的很快，也讨厌总是出错
这是一定的，在一开始你所想要完成的那些伟大的愿景，在截止时间以前，很可能就被改了五到十次，在真实世界里，你需要更多的时间来仔细讨论、彻夜思量、然后执行你的想法。
在 Hackathons 中，你决定你想要做什么的时间以及如何做，就会花了大半时间，所以你必须要准备好解决这些问题与阻碍：
1. 初始想法太伟大了：
你真正开始创造、实现你的想法的时间比起你所预定的时间一定还要长许多，你必须要试着把范围缩小，不能什么都想要，要不就可能会有做不完的风险。
2. 开发过程中的问题
所有的开发者都会遇到的问题，有的他们不能解决，或是要解决可以，但是要花太多的时间，最好是删减、重新思考建立，然后更上一层楼。
3. 所创造出来的东西不见得是你一开始构思的样子
这样的情形就发生在我们的身上，为解决资料收集的问题，我们中断 App 的开发流程，并重新评估 App 然后想出一个有趣的功能，但这个功能事实上我们没有时间去和后端做连结，然而却实际地增加了实用性的程度以及使用者的喜爱，并且这个想法更值得被大家讨论。
4. 有的人不想出现或是不愿意上台报告
这样的事情一定会发生，你必须要做的不是把报告包装的与众不同，就是做你可以做的事情。就拿我们的例子来说，原本我们有想要改、想要加的东西，但是开发者不在，因此我们只好在设计上做些小改变，不会被注意到的地方。
我真正想要参加的原因，是因为新创公司不会录取没有涉略过程序设计的人，不论你有多好的想法，或是其他多厉害的强项，就是要证明给他看。
因此，Hackathon 会是我的第一步，连我不是资工背景的人都愿意跨出这一步，做中学比起藉由看文章学，获得的一定更多，所以就别害怕，只要你勇敢跨出这一步，其实没你想象中那么困难。