Hvordan hackathon i 5 enkle trinn

Hvorfor snakker ikke flere om Hackathons? De er en eksplosjon og leverer ofte gratis mat og vri små spinnere. Men viktigst av alt er det en flott måte for programvareutviklere å forbedre ferdighetene deres på kort tid, samtidig som de tilbyr ikke-tekniske fagpersoner en mulighet til å utføre en visjon og gi en ide til liv.

Hvis du er interessert i å delta i en, holder høyskoler og teknologirelaterte organisasjoner dem hele tiden. Jeg er stolt av å jobbe for et selskap (Asurion) som sponser et årlig hackathon, som produserer dusinvis av innovative ideer og imponerende implementeringer. Under årets begivenhet, annet enn å klare å omgi meg med gode lagkamerater, fulgte jeg disse fem trinnene for å optimalisere hackathonopplevelsen.

1. Velg noe aktuelt

Mange interessante prosjekter kommer ut av hackathons, men etter at du har vært noen få, vil du begynne å se noen gjentakelser. For å maksimere nyheten, prøv å velge en relativt ny teknologi eller tema. Selv om du ikke vinner, vil du lære mer og utvide begrensningene i komfortsonen din.

På grunn av den enorme økningen i eierassistanse (129% år over år) bestemte teamet vårt å bruke Amazon Echo til hacket vårt. Vår tjeneste, Soluto, gir øyeblikkelig premium-støtte for teknologiproblemer. Vi trodde at ekkoet kan være et praktisk inngangspunkt for tjenesten vår.

Hackathon-ideen din trenger ikke alltid å forandre verden. Det kan være noe enkelt og morsomt som er inspirert av et engasjerende nytt show, film eller spill. Jeg deltok i mitt første hackathon for noen år siden da 2048 opprinnelig kom ut. Fordi en av sponsorene våre var SendGrid, bestemte jeg meg for å hacke sammen et e-postdrevet 2048-spill. Det ble godt mottatt, på grunn av dets relevans på den tiden.

2. Definer en MVP

De fleste hackathons varer mellom 24 og 72 timer. Selv om dette kan virke som det er mye tid å jobbe med, er det ikke det, selv om du har med deg sovepose. Som sådan må du definere et minimalt levedyktig produkt (MVP) som er mulig for teamet ditt å lage, og samtidig gi deg tid til overs.

Du kan oppnå dette ved å begrense hacket ditt til noen få kjernefunksjoner. Hvis hacket ditt er for bredt, vil hver funksjon sannsynligvis virke upolert. Hvis du har ideer for hvordan du kan utvide hacket ditt i fremtiden, kan du ta dem med i presentasjonen som samtalepunkter. Publikum og dommere tilgir deg ikke, hvis du har en god salgsbane, men ikke noe konkret å vise for det.

Prisutdeling under Asurion Hackathon 2017 (Nashville). Fra venstre til høyre: Barry Vandevier (dommer og driftspresident), Alex Hughes, Lucas Rudd, Jonathan Hughes, Daniel Cottone og Brandon Evans

3. Test tredjepartsintegrasjoner tidlig

Mange hacks bruker applikasjonsprogrammeringsgrensesnitt (API) for å integrere applikasjonen sin med andre nettbaserte tjenester. Du kan la brukerne logge seg på via Google-kontoen sin, sende ut tweets som kroniserer aktiviteten i appen og mye mer. Å bruke API-er utvider målgruppen din, forenkler utviklingsarbeidet og beriker brukeropplevelsen din.

Dessverre har APIer, etter design, sine begrensninger. Disse tredjepartene jobbet veldig hardt for sine databaser og funksjoner, og de vil ikke la deg bruke dem uforminsket. Noen API-er krever betaling, de fleste begrenser hvor mange samtaler du kan foreta innen en gitt tidsperiode, og alle begrenser tilgangen til dataene deres på noen måte. For å unngå misforståelser, bør du teste integrasjonsbruk-saken tidlig, kanskje før du oppretter annen funksjonalitet.

Jeg lærte dette på den harde måten. Ved et tidligere hackathon, forsøkte teamet mitt å lage en Facebook-applikasjon som identifiserte hvilke venner du ikke har hatt interaksjon med nylig, og ga deg muligheten til å koble til igjen med dem. Vi bygde hele applikasjonen i løpet av første halvdel av hackathon før vi startet API-integrasjonen. Det var bare ett problem: Facebook forhindrer deg i å få informasjon om vennene dine, med mindre de også har appen. Ettersom appen ville være ubrukelig til en betydelig del av befolkningen installerte den, måtte vi omarbeide ideen vår fullstendig med veldig begrenset tid.

På Asurion Hackathon hadde vi godt av å kunne bruke interne API-er som vi har jobbet med tidligere. Selv fortsatt jobbet vi med integrasjonene først, i tilfelle noe skulle komme opp underveis. Dette tillot oss å fokusere mesteparten av energien vår på å skape og foredle brukeropplevelsen.

4. Hvis den ikke er ødelagt, må du ikke fikse den

Hvis du har implementert MVP-en med tid til overs, kan du bli fristet til å endre den på noen måte. Teamet ditt skal ikke ta denne beslutningen lett. Et hack er ikke et produkt som er klart til å markedsføre. Lasting av kode for siste øyeblikk har ingen plass ved et hackathon. Hvis hacket ditt kan bruke noen ekstra forbedringer eller funksjoner som er vendt mot brukeren, må du vurdere hva risikoen mot belønningen for disse endringene er, og gi deg selv tid til å gjenopprette hvis noe går galt. I det minste vil jeg avstå fra å gjøre endringer i hackingen innen en time etter den endelige presentasjonen. På et tidspunkt må du slutte å ødelegge ting!

Dette betyr ikke at du ikke bør opprette en liste over mulige endringer du kan takle på et annet tidspunkt. Som tidligere nevnt er et hack, hvis det gjøres riktig, bare en MVP, ikke et ferdig produkt. Men det burde ikke hindre deg i å tenke på fremtidige iterasjoner av konseptet. Forhåpentligvis er hacket ditt noe du tror på, så velg gjerne prosjektet igjen når konkurransen er slutt. Bare ikke risikere å ødelegge noe rett før presentasjonen. Når vi snakkar om det…

5. Present som at hacket ditt avhenger av det (det gjør det)

Noen hackathons har sekvensielle demonstrasjoner, mens andre har utstillingsvinduer der dommerne sjekker ut hakkene på sin fritid. Uansett betyr presentasjon like mye, om ikke mer, enn selve hacket. Hvis du har et fantastisk prosjekt, men ikke kan formidle det som er vakkert, hva er poenget? Sørg for å vie en betydelig del av tiden din til å forberede og praktisere presentasjonen.

Det er her det å ha ikke-utviklere på laget ditt kan være enormt nyttig. Etter å ha definert MVP, kan disse medlemmene av teamet planlegge hvordan de skal markedsføres best mulig parallelt med utvikling - så lenge begge gruppene kommuniserer med hverandre om store endringer. Utviklere kan hjelpe med å fokusere på “hva”, mens de andre hjelper til med å avgrense “hvorfor”.

Før du designer tonehøyde, må du identifisere publikum. Hvis hackathonet ditt inviterer publikum til å dømme, vil du fange oppmerksomheten deres og holde den lett på den nissete. Hvis du presenterer for forretningsinteressenter, kan du ta med viktige økonomiske anslag og eksempler på verdiskapning for organisasjonen. Til slutt, hvis dine andre hackere vurderer prosjektet ditt, kan du gå over teknologibunken og vise frem intrikatene i arkitekturen din.

De mest minneverdige presentasjonene er vanligvis de mest interaktive. Det er en ting å være vitne til at et program blir brukt; det er en annen å oppleve det selv. Hvis du kan finne en måte å la publikum demonstrere produktet ditt, kan du gå etter det (så lenge du er klar over potensielle kortsaker).

Hvis du følger disse trinnene, bør du forlate hackathon med en interessant, unik og godt utført leverbar. Dette er ikke å si at du er garantert å vinne, men det er langt mindre viktig enn ferdighetene og erfaringene du får ved å delta i disse arrangementene.

Hvis du er interessert i å være med i teamet vårt, kan du gjerne sjekke jobbåpningene på Soluto Nashville og sende meg en lapp!