Hogyan Hackathon 5 egyszerű lépésben

Miért nem beszélnek több ember a Hackathonsról? Robbanásveszélyesek, és gyakran ingyenes ételt és izgul fonókat szállítanak. De ami a legfontosabb: nagyszerű módja annak, hogy a szoftverfejlesztők rövid idő alatt javítsák készségeiket, miközben a nem műszaki szakembereknek lehetőséget kínálnak egy jövőkép megvalósítására és egy ötlet életre keltésére.

Ha érdekli a belépés, a kollégiumok és a technológiával kapcsolatos szervezetek állandóan tartják őket. Büszke vagyok arra, hogy egy olyan vállalatnál (Asurion) dolgozom, amely szponzorál egy éves hackathonot, amely tucatnyi innovatív ötletet és lenyűgöző megvalósítást hoz létre. Az idei rendezvény ideje alatt, kivéve azt, hogy nagyszerű csapattársakkal körülvettem magam, ezt az öt lépést követtem, hogy optimalizáljam a hackathon tapasztalataimat.

1. Válasszon valami aktuális dolgot

Sok érdekes projekt jön ki a hakatonokból, de miután néhányat már meglátogattál, látni fog néhány ismétlést. Az újdonság maximalizálása érdekében próbáljon meg választani egy viszonylag új technológiát vagy témát. Még ha nem is nyer, akkor többet fog tanulni és kibővíti a kényelmi zóna korlátait.

Például az otthoni asszisztens tulajdonjogának jelentős növekedése miatt (évvel ezelőtt 129% -kal), csapatunk úgy döntött, hogy az Amazon Echo-t használja fel a csapdánkhoz. Szolgáltatásunk, a Soluto azonnali prémium támogatást nyújt technológiai kérdésekben. Úgy gondoltuk, hogy az Echo kényelmes belépési pont lehet szolgáltatásunk számára.

A hackathon-ötletednek nem mindig kell megváltoztatnia a világot. Ez lehet valami egyszerű és szórakoztató, amelyet egy vonzó új műsor, film vagy játék ihlette. Néhány évvel ezelőtt, amikor 2048-ban jelent meg, részt vettem az első hackathonon. Mivel az egyik szponzorunk a SendGrid volt, úgy döntöttem, hogy összekapcsolom az e-mail alapú 2048 játékot. Az akkori relevancia miatt jól fogadták.

2. Határozzon meg egy MVP-t

A legtöbb hackaton 24 és 72 óra között tart. Bár úgy tűnik, hogy nagyon sok idő van együtt dolgozni, mégsem, még akkor is, ha hálózsákot hozsz. Mint ilyen, meg kell határoznia egy minimálisan életképes terméket (MVP), amelyet a csapata létrehozhat, miközben időt hagy a tartalékra.

Ezt úgy érheti el, ha a csapkod néhány alapvető funkcióra korlátozza. Ha a hacke túl széles, akkor minden funkció valószínűleg nem csiszolt. Ha vannak ötleted a hack kibővítéséhez a jövőben, beszélő pontként vegye fel őket az előadásába. A közönség és a bírók azonban nem fognak megbocsátani neked, ha jó eladási hangmagassággal rendelkezik, de semmi kézzelfogható megmutatni nem tudja.

Díjátadó ünnepség a 2017. évi Asurion Hackathonon (Nashville). Balról jobbra: Barry Vandevier (bíró és a műveleti elnök), Alex Hughes, Lucas Rudd, Jonathan Hughes, Daniel Cottone és Brandon Evans

3. Korán tesztelje a harmadik féltől származó integrációkat

Sok hack alkalmazásprogramozási felületeket (API-kat) használ, hogy alkalmazásukat integrálják más web-alapú szolgáltatásokkal. A felhasználók bejelentkezhetnek a Google-fiókjukon keresztül, küldhetnek tweeteket az alkalmazáson belüli tevékenységeik krónikus megjelenítéséért és még sok minden mást. Az API-k használata kibővíti a célközönséget, leegyszerűsíti a fejlesztési munkát, és gazdagítja a felhasználói élményt.

Sajnos az API-knak tervezésüknél fogva vannak korlátozásuk. Ezek a harmadik felek nagyon keményen dolgoztak az adatbázisuk és a funkcióik érdekében, és nem engedik, hogy te nem használják őket. Egyes API-k fizetést igényelnek, a legtöbb korlátozza, hogy hány hívást tegyen egy adott időn belül, és valamennyien korlátozza az adatokhoz való hozzáférést. A tévhitek elkerülése érdekében korábban kell kipróbálnia az integrációs használati esetet, esetleg bármilyen más funkció létrehozása előtt.

Megtanultam ezt a kemény utat. Egy korábbi hackathonon a csapatom egy Facebook-alkalmazás létrehozását tűzte ki célul, amely meghatározta, hogy melyik baráttal nem voltál kapcsolatban a közelmúltban, és lehetőséget adott számukra, hogy újra kapcsolatba lépjen velük. A teljes alkalmazást a hackathon első felében készítettük el, mielőtt megkezdenénk az API-integrációt. Csak egy probléma merült fel: a Facebook megakadályozza, hogy információkat szerezzen barátaidról, kivéve, ha nekik is van az alkalmazásuk. Mivel az alkalmazás haszontalan lenne, amíg a lakosság jelentős része nem telepíti azt, nagyon korlátozott idő alatt teljesen át kellett dolgoznunk az ötletünket.

Az Asurion Hackathonon előnye volt, hogy belső API-kat tudtunk használni, amelyekkel a múltban együtt dolgoztunk. Mégis először az integrációkon dolgoztunk, csak arra az esetre, ha valami felmerülne az út mentén. Ez lehetővé tette számunkra, hogy az energia nagy részét a felhasználói élmény megteremtésére és finomítására összpontosítsuk.

4. Ha nem tört, akkor ne javítsa meg

Ha időben megtakarította az MVP-t, akkor valószínűleg kísértésnek tűnik valamilyen módon megváltoztatni. A csapatodnak nem szabad enyhén meghoznia ezt a döntést. A hack nem forgalomba hozható termék. A last minute kódmegújításnak nincs helye a hackathonon. Ha a csapkod felhasználhat további felhasználói szemléletű fejlesztéseket vagy funkciókat, akkor ki kell értékelnie, hogy milyen kockázatokkal jár e változások haszna és haszonnal kell időt adnia magának, hogy helyreálljon, ha valami rosszul fordul elő. Legalább tartózkodnék attól, hogy a hacket bármilyen módosítást elvégezzük a végső bemutatótól számított egy órán belül. Egy bizonyos ponton abba kell hagynia a dolgok törését!

Ez nem azt jelenti, hogy nem kellene létrehoznia a lehetséges változtatások listáját, amelyekkel egy másik időpontban meg lehet oldani. Mint korábban említettük, a hack, ha helyesen hajtják végre, csak egy MVP, nem pedig késztermék. De ez nem akadályozhatja meg a koncepció jövőbeli iterációinak gondolkodását. Remélhetőleg a csapkod olyan, amiben hisz, tehát nyugodtan választhatja a projektet, miután a verseny lezárult. Csak ne kockáztasson semmit, hogy közvetlenül a bemutató előtt megsérül. Ha már itt tartunk…

5. Olyan jelen, mint a csapkod attól függ (igaz)

Egyes hackatonok egymást követő bemutatókat tartanak, míg mások olyan kirakatokat mutatnak, ahol a bírák szabadidejükben ellenőrzik a csapdákat. Akárhogy is, a bemutatás ugyanolyan, ha nem több, akkor számít, mint maga a hack. Ha van egy csodálatos projektje, de nem tudod közvetíteni annak fantasztikus jellegét, mi értelme? Ügyeljen arra, hogy jelentős időt fordítson előadása előkészítésére és gyakorlására.

Ebben az esetben óriási segítséget jelenthet a nem-fejlesztői részvétel a csapatban. Az MVP meghatározása után a csapat ezek a tagjai megtervezhetik, hogyan lehet a legjobban piacra dobni a fejlesztéssel párhuzamosan - mindaddig, amíg mindkét csoport kommunikál egymással a nagyobb változásokról. A fejlesztők hozzájárulhatnak a „mi” -re való összpontosításhoz, míg mások a „miért” pontosításához segítenek.

A hangmagasság megtervezése előtt meg kell határoznia a közönséget. Ha a hackathon meghívja a nyilvánosságot, hogy ítélkezzen, akkor érdemes megragadni a figyelmüket, és tartani világossá az apróságaikat. Ha bemutatja az üzleti érdekelt feleknek, vegye be a legfontosabb pénzügyi előrejelzéseket és a szervezet hozzáadott értékének példáit. Végül, ha más hackerek értékelik a projektet, akkor menjen át a tech verembe, és mutassa meg építészetének bonyolultságát.

A legemlékezetesebb előadások általában a leginkább interaktív. Egy dolog a tanúja annak, hogy egy programot használnak; ez egy másik, hogy megtapasztald magadnak. Ha megtalálja a módját, hogy lehetővé tegye a közönségnek a termék demonstrációját, akkor keresse meg (mindaddig, amíg tisztában van a potenciális előzményekkel).

Ha követi ezeket a lépéseket, érdekes, egyedi és jól kivitelezett anyaggal kell elhagynia a hackathonot. Ez nem azt jelenti, hogy garantáltan nyerünk, de ez sokkal kevésbé fontos, mint az ezen eseményeken való részvételhez szükséges készségek és tapasztalatok.

Ha érdekli csatlakozni a csapatunkhoz, nyugodtan nézze meg a Soluto Nashville-n belüli álláslehetőségeket, és küldjön nekem egy felhívást!