Sådan hackes i 5 nemme trin

Hvorfor taler ikke flere om Hackathons? De er en eksplosion og leverer ofte gratis mad og fidget-spinnere. Men vigtigst af alt er det en god måde for softwareudviklere at forbedre deres færdigheder på kort tid, samtidig med at de tilbyder ikke-tekniske fagfolk en mulighed for at udføre en vision og bringe en idé til live.

Hvis du er interesseret i at komme ind i en, holder colleges og teknologirelaterede organisationer dem hele tiden. Jeg er stolt af at arbejde for et firma (Asurion), der sponsorerer en årlig hackathon, der producerer snesevis af innovative ideer og imponerende implementeringer. Under dette års begivenhed fulgte jeg disse fem trin for at optimere min hackathon-oplevelse, bortset fra at formå at omringe mig selv med gode holdkammerater.

1. Vælg noget aktuelt

Mange interessante projekter kommer ud af hackathons, men når du har været i nogle få, vil du begynde at se nogle gentagelser. For at maksimere nyhed skal du prøve at vælge en relativt ny teknologi eller tema. Selv hvis du ikke vinder, lærer du mere og udvider begrænsningerne i din komfortzone.

På grund af den enorme stigning i ejendom til hjemmeassistent (129% år over år) besluttede vores team for eksempel at bruge Amazon Echo til vores hack. Vores service, Soluto, giver øjeblikkelig premium support til teknologispørgsmål. Vi troede, at ekkoet kunne være et praktisk indgangspunkt til vores service.

Din hackathon-idé behøver ikke altid at ændre verden. Det kan være noget enkelt og sjovt, der er inspireret af et spændende nyt show, film eller spil. Jeg deltog i min første hackathon for et par år siden, da 2048 oprindeligt kom ud. Fordi en af ​​vores sponsorer var SendGrid, besluttede jeg at hacke sammen et e-mail-drevet 2048 spil. Det blev godt modtaget på grund af dets relevans på det tidspunkt.

2. Definer en MVP

De fleste hackathons varer mellem 24 og 72 timer. Selvom dette kan se ud som om det er meget tid at arbejde med, er det ikke, selvom du har en sovepose med. Som sådan skal du definere et minimalt levedygtigt produkt (MVP), som er muligt for dit team at skabe, samtidig med at du giver dig tid til overs.

Du kan udføre dette ved at begrænse dit hack til et par kernefunktioner. Hvis dit hack er for bredt, vises hver funktion sandsynligvis upoleret. Hvis du har ideer til, hvordan du kan udvide dit hack i fremtiden, skal du medtage dem i din præsentation som talepunkter. Publikum og dommere tilgir dig dog ikke, hvis du har en stor salgsbane, men intet håndgribeligt at vise for det.

Præmieceremoni ved Asurion Hackathon 2017 (Nashville). Fra venstre til højre: Barry Vandevier (dommer og præsident for operationer), Alex Hughes, Lucas Rudd, Jonathan Hughes, Daniel Cottone og Brandon Evans

3. Test tredjepartsintegrationer tidligt

Mange hacks bruger applikationsprogrammeringsgrænseflader (API'er) til at integrere deres applikation med andre webbaserede tjenester. Du kan få dine brugere til at logge ind via deres Google-konto, sende tweets, der kroniserer deres in-app-aktivitet og meget mere. Brug af API'er udvider din målgruppe, forenkler udviklingsarbejdet og beriger din brugeroplevelse.

Desværre har API'er, efter design, deres begrænsninger. Disse tredjeparter arbejdede meget hårdt for deres databaser og funktioner, og de vil ikke lade dig bruge dem uformindsket. Nogle API'er kræver betaling, mest begrænser hvor mange opkald du kan foretage inden for en given tidsperiode, og alle begrænser adgangen til deres data på en eller anden måde. For at undgå misforståelser, skal du teste din integrationsbrugssag tidligt, måske før du opretter nogen anden funktionalitet.

Jeg lærte dette på den hårde måde. Ved et tidligere hackathon begyndte mit team at oprette en Facebook-applikation, der identificerede, hvilke venner, du ikke har interageret med for nylig, og gav dig muligheden for at oprette forbindelse igen med dem. Vi byggede hele applikationen i løbet af den første halvdel af hackathon, før vi startede API-integrationen. Der var kun et problem: Facebook forhindrer dig i at få oplysninger om dine venner, medmindre de også har appen. Da appen ville være ubrugelig, indtil en betydelig del af befolkningen installerede den, måtte vi omarbejde vores idé med meget begrænset tid.

Ved Asurion Hackathon drages fordel af at være i stand til at bruge interne API'er, som vi tidligere har arbejdet med. Selv stadig arbejdede vi med integrationerne først, i tilfælde af, at der kom noget op undervejs. Dette gjorde det muligt for os at fokusere det meste af vores energi på at skabe og foredle brugeroplevelsen.

4. Hvis det ikke er ødelagt, skal du ikke rette det

Hvis du har implementeret din MVP med tiden til overs, kan du blive fristet til at ændre den på en eller anden måde. Dit team bør ikke tage denne beslutning let. Et hack er ikke et klar-til-marked produkt. I sidste øjeblik kodekonfigurering har ingen plads ved en hackathon. Hvis dit hack kunne bruge nogle ekstra forbedringer eller funktioner, som brugeren vender mod, skal du evaluere, hvad risikoen mod belønningen ved disse ændringer er, og give dig selv tid til at komme dig, hvis noget går galt. I det mindste vil jeg afstå fra at foretage ændringer i hacket inden for en time efter din endelige præsentation. På et tidspunkt skal du stoppe med at bryde ting!

Dette betyder ikke, at du ikke skal oprette en liste over mulige ændringer, du kan tackle på et andet tidspunkt. Som tidligere nævnt er et hack, hvis det er gjort korrekt, bare en MVP, ikke et færdigt produkt. Men det bør ikke forhindre dig i at tænke på fremtidige iterationer af konceptet. Forhåbentlig er dit hack noget, du tror på, så føl dig fri til at hente projektet op igen, når konkurrencen er afsluttet. Bare risiker ikke at bryde noget lige før din præsentation. Apropos hvoraf…

5. Nuværende som dit hack afhænger af det (det gør)

Nogle hackathons har sekventielle demonstrationer, mens andre har udstillingsvinduer, hvor dommerne tjekker hacks på deres fritid. Uanset hvad betyder præsentation lige så meget, hvis ikke mere, end selve hacket. Hvis du har et fantastisk projekt, men ikke kan formidle dets ærlighed, hvad er da poenget? Sørg for at afsætte en betydelig mængde af din tid til at forberede og øve din præsentation.

Det er her, at have ikke-udviklere på dit team kan være enormt nyttigt. Efter at have defineret MVP kan disse medlemmer af teamet planlægge, hvordan de bedst kan markedsføre det parallelt med udvikling - så længe begge grupper kommunikerer med hinanden om større ændringer. Udviklere kan hjælpe med at fokusere på "hvad", mens de andre hjælper med at forbedre "hvorfor".

Før du designer din tonehøjde, skal du identificere dit publikum. Hvis din hackathon opfordrer offentligheden til at dømme, vil du fange deres opmærksomhed og holde den lys på den pittige. Hvis du præsenterer for forretningsinteressenter, skal du inkorporere vigtige økonomiske fremskrivninger og eksempler på værditilvækst for organisationen. Til sidst, hvis dine kollegale hackere bedømmer dit projekt, skal du gå over tech-stakken og vise de komplicerede problemer i din arkitektur.

De mest mindeværdige præsentationer er normalt de mest interaktive. Det er en ting at se et program, der bruges; det er en anden at opleve det selv. Hvis du kan finde en måde, hvorpå publikum kan demonstrere dit produkt, skal du gå til det (så længe du er opmærksom på dine potentielle kanter).

Hvis du følger disse trin, skal du forlade hackathon med en interessant, unik og godt udført levering. Det betyder ikke, at du er garanteret at vinde, men det er langt mindre vigtigt end de færdigheder og erfaringer, du får ved at deltage i disse begivenheder.

Hvis du er interesseret i at blive medlem af vores team, er du velkommen til at tjekke jobmulighederne hos Soluto Nashville og sende mig en note!