Keith McFarlane, chefsarkitekt
Vi höll nyligen vårt elfte LiveOps Hack Day-event, och det var något speciellt; ett antal riktigt intressanta idéer kom till liv på bara 24 timmar tack vare ansträngningarna från några mycket passionerade och dedikerade team och individer. Några av de hack som visades vid demotiden var:
- Pivot to Video – teamet som är involverat i denna hittade ett sätt att flytta en liveagentchattkonversation in i videovärlden med hjälp av tokbox.
- Multichannel Visualization – vårt rapporteringsteam presenterade ett nytt sätt att se på de överlappande arbetsflödena som en agent hanterar samtidigt som de hanterar flera arbetsobjekt samtidigt.
- Agenttelefoni i webbläsaren – ingenjören visade upp integrationen av vår agenttelefonpanelapplikation med Twilios JavaScript-baserade klient, som möjliggör röstsamtal med enbart en PC.
- Skriptbart samtalsflöde – några av våra plattformsingenjörer hittade ett smart sätt att styra detaljerade telefonifunktioner via REST API.
Vi har arbetat för att förbättra Hack Day under åren sedan vi höll det första evenemanget, och även om vi har gjort många inkrementella förändringar, har vi också identifierat en uppsättning kärnprinciper som kan göra eller bryta evenemanget beroende på hur noga de följs.
1) Stora hack kommer från hjärtat, inte från eftersläpningen
Allt för ofta har jag sett ingenjörer eller produktchefer försöka använda Hack Day som en ursäkt för att påskynda sina favoritposter. Även om detta verkligen åstadkommer något användbart, motverkar det det sanna syftet med evenemanget: innovation. Utvecklare bör använda denna tid för att fullfölja sina vildaste mjukvarudrömmar och prova ny teknik. Samma sak gäller för produktchefer; de bör samarbeta med utvecklare för att integrera med andra webbtjänster på oväntade sätt, eller göra ett försök att definiera och implementera en idé som skulle verka riskabel under normala omständigheter. Det ska vara ett tillfälle för utforskning, inte business as usual i en lite annan ordning.
För utvecklare är att välja en eftersläpning som ditt hackdag-projekt i huvudsak att tumma på produktledningsgruppens prioriteringar. Tänk på alla tankar och diskussioner som har gått till att få berättelseordningen rätt för din scrum, och föreställ dig sedan att ignorera allt det arbetet och välja berättelser slumpmässigt. Det är klart att det förra är att föredra framför det senare.
Hack Day handlar om att låta fantastiska idéer dyka upp från oväntade platser. Utan betoning på att driva nya idéer snarare än befintliga, förlorar det det mesta av sitt värde.
2) Fokusera, fokusera, fokusera; scope creep dödar hacks döda
Även om alla nya idéer borde vara rättvisa spel för hackdagen, har jag märkt att de största framgångarna kommer från små, fokuserade ansträngningar som syftar till att slutföra en mindre men värdefull funktion, eller att demonstrera ett stort koncept genom ett väldefinierat exempel som är begränsad i omfattning. Ofta kan projekt som detta nå framgång tidigt och sedan lägga till funktioner när tiden tillåter. Dessutom, eftersom segervillkoren är väldefinierade, kan laget överge hacket om det visar sig vara för komplext, och flytta sitt fokus till någon annan idé.
Alla utvecklare har "stora koncept" som svävar runt i sina huvuden; Tyvärr kan dessa vara de svåraste att bygga, även i begränsad form, som en del av Hack Day. Om du vill genomföra ett av dessa storslagna scheman i hackform framgångsrikt, dra in fler människor i diskussionen och hitta en liten pusselbit som står sig väl för sig, men som ändå får fram din poäng.
3) Ibland krävs det en by för att skapa ett hack
Vissa hack är så tydligt definierade och begränsade i omfattning att en enda utvecklare kan få dem att hända i tid; Men hur komplicerade som de flesta webbtjänster är, är det mycket vanligare att alla verkligt intressanta hack kräver ansträngningar från flera ämnesexperter på ett antal olika plattformar.
I deras hjärta är hackathons sociala evenemang, och de handlar lika mycket om teaming och moral som om innovation. Om du organiserar ett Hack Day-evenemang, tillhandahåll ett forum för lagbildning innan själva evenemanget; vi har hållit ett "rekryterings"-möte före Hack-Day i flera år på LiveOps, vilket har gett teamkombinationer som kanske inte inträffar inom det normala flödet av projektarbete och främjat större interaktioner mellan team på lång sikt.
4) Utplacering är den bästa belöningen
Ja, det är viktigt att erbjuda något slags konkret "bästa hack"-pris, även om alla som vill ha en iPad förmodligen redan har en. Men inte alla utvecklare har en egen produktidé som körs som en funktion i produktionen; många ingenjörer kan arbeta med att möjliggöra produktchefers visioner i flera år utan att deras egna innovativa föreställningar ser dagens ljus. Om hacks visar löfte som produkter, eller om de är omedelbart användbara, bör de snabbspåras till produktion för både företagets bästa och som en belöning för de inblandade ingenjörerna.
Varje mjukvaruföretag (inte bara webstartups) bör hålla regelbundna hackathons för att skapa innovation, öka motivationen och förbättra kommunikationslinjerna mellan team. Som med alla företagsaktiviteter finns det dock mer effektiva och mindre effektiva sätt att gå tillväga. Håll koll på vad som fungerar och inte fungerar, gör förbättringar över tid och lyssna på deltagarnas feedback. Även om principerna ovan har fungerat mycket bra för oss på LiveOps, kommer du med största sannolikhet att utveckla en uppsättning riktlinjer som fungerar bättre för din organisation över tid.
