身為程式設計師、軟體開發者應該都對於 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 會是我的第一步，連我不是資工背景的人都願意跨出這一步，做中學比起藉由看文章學，獲得的一定更多，所以就別害怕，只要你勇敢跨出這一步，其實沒你想像中那麼困難。
延伸閱讀：
我是個 9 歲的女孩，我已經站上 TechCrunch 駭客松展示我的 APP：Super Fun Kid Time
（資料來源：Medium；圖片來源：Sebastiaan ter Burg, hackNY, CC Licensed）
Source: techorange.com
