Building a Better Hackathon: Fire Core Principles from LiveOps Hack Day
Keith McFarlane, sjefsarkitekt Keith McFarlane, sjefsarkitekt

Vi holdt nylig vårt ellevte LiveOps Hack Day-arrangement, og det var noe spesielt; en rekke virkelig interessante ideer kom til live i løpet av bare 24 timer takket være innsatsen fra noen svært lidenskapelige og dedikerte team og enkeltpersoner. Noen av hackene som ble vist på demotidspunktet var:

  • Pivot to Video – teamet involvert i denne fant en måte å flytte en live agent chat-samtale inn i videoverdenen ved å bruke tokbox.
  • Multikanalvisualisering – vårt rapporteringsteam presenterte en ny måte å se på de overlappende arbeidsstrømmene en agent håndterer mens han håndterer flere arbeidselementer samtidig.
  • Agenttelefoni i nettleseren – ingeniøren viste frem integrasjon av vår agenttelefonpanelapplikasjon med Twilio's JavaScript-baserte klient, som muliggjør taleanrop ved bruk av en PC alene.
  • Skriptbar samtaleflyt – noen av våre plattformingeniører fant en smidig måte å kontrollere detaljerte telefonifunksjoner via REST API.
Dette er bare en undergruppe av prosjektene som ble fullført denne gangen; disse og andre kan bli produkter i en ikke altfor fjern fremtid.

Vi har jobbet for å forbedre Hack Day i løpet av årene siden vi holdt det første arrangementet, og mens vi har gjort mange trinnvise endringer, har vi også identifisert et sett med kjerneprinsipper som kan gjøre eller bryte arrangementet avhengig av hvor tett de blir fulgt.

1) Store hacks kommer fra hjertet, ikke fra etterslepet

Alt for ofte har jeg sett ingeniører eller produktledere prøve å bruke Hack Day som en unnskyldning for å akselerere sine favorittbacklog-elementer. Selv om dette absolutt oppnår noe nyttig, beseirer det den sanne hensikten med arrangementet: innovasjon. Utviklere bør bruke denne tiden til å forfølge sine villeste programvaredrømmer og prøve ut ny teknologi. Det samme gjelder for produktsjefer; de bør slå seg sammen med utviklere for å integrere med andre nettjenester på uventede måter, eller for å gjøre et forsøk på å definere og implementere en idé som ville virke risikabelt under normale omstendigheter. Det skal være en mulighet for utforskning, ikke business as usual i en litt annen rekkefølge.

For utviklere er det å velge en backlog-vare som hack-dag-prosjektet i hovedsak å tommel nesen til produktledelsens prioriteringer. Tenk på alle tankene og diskusjonene som har gått med til å få historierekkefølgen riktig for scrumen din, og forestill deg å ignorere alt dette arbeidet og velge historier tilfeldig. Det første er klart å foretrekke fremfor det siste.

Hack Day handler om å la gode ideer dukke opp fra uventede steder. Uten vekt på å forfølge nye ideer i stedet for eksisterende, mister den mesteparten av sin verdi.

2) Fokus, fokus, fokus; scope creep dreper hacks døde

Selv om enhver ny idé burde være rettferdig spill for hack-dagen, har jeg lagt merke til at de største suksessene kommer fra små, fokuserte innsatser som tar sikte på å fullføre en mindre, men verdifull funksjon, eller å demonstrere et stort konsept gjennom et veldefinert eksempel som er begrenset i omfang. Ofte kan prosjekter som dette oppnå suksess tidlig, og deretter legge til funksjoner når tiden tillater det. Fordi seiersbetingelsene er veldefinerte, kan teamet også forlate hacket hvis det viser seg å være for komplekst, og flytte fokuset til en annen idé.

Alle utviklere har «store konsepter» som flyter rundt i hodet; Dessverre kan disse være de vanskeligste å bygge, selv i begrenset form, som en del av Hack Day. Hvis du ønsker å lykkes med en av disse store planene i hack-form, kan du trekke flere mennesker inn i diskusjonen og finne en liten brikke i puslespillet som står godt alene, men som likevel får frem poenget ditt.

3) Noen ganger tar det en landsby for å lage et hack

Enkelte hacks er så klart definert og begrenset i omfang at en enkelt utvikler kan få dem til å skje i tide; Men så komplekse som de fleste nettjenester er, er det langt mer vanlig at ethvert virkelig interessant hack vil kreve innsats fra flere fageksperter på en rekke forskjellige plattformer.

I deres hjerte er hackathons sosiale begivenheter, og de handler like mye om teaming og moral som om innovasjon. Hvis du organiserer et Hack Day-arrangement, gi et forum for teamformasjon før selve arrangementet; vi har holdt et "rekrutteringsmøte" før Hack-Day i flere år på LiveOps, noe som har gitt teamkombinasjoner som kanskje ikke forekommer innenfor den normale flyten av prosjektarbeid, og fremmet større interaksjoner mellom team på lang sikt.

4) Utplassering er den beste belønningen

Ja, det er viktig å tilby en slags håndgripelig "best hack"-premie, selv om alle som vil ha en iPad sannsynligvis har en allerede. Det er imidlertid ikke alle utviklere som har en produktidé om at de selv kjører som en funksjon i produksjonen; mange ingeniører kan jobbe med å muliggjøre visjonene til produktledere i årevis uten at deres egne innovative ideer ser dagens lys. Hvis hacks viser løfte som produkter, eller hvis de er umiddelbart brukbare, bør de raskt spores inn i produksjon til både selskapets beste og som en belønning for de involverte ingeniørene.

Alle programvareselskaper (ikke bare nettstartups) bør holde regelmessige hackathons for å skape innovasjon, øke motivasjonen og forbedre kommunikasjonslinjene mellom teamene. Som med enhver bedriftsaktivitet, er det imidlertid mer effektive og mindre effektive måter å gjøre det på. Hold styr på hva som fungerer og ikke fungerer, gjør forbedringer over tid, og lytt til tilbakemeldinger fra deltakerne. Selv om prinsippene ovenfor har fungert veldig bra for oss i LiveOps, vil du mer enn sannsynlig utvikle et sett med retningslinjer som fungerer bedre for organisasjonen din over tid.