Keith McFarlane, hoofdarchitect
We hebben onlangs ons elfde LiveOps Hack Day-evenement gehouden en het was iets speciaals; een aantal echt interessante ideeën kwam tot leven in slechts 24 uur dankzij de inspanningen van enkele zeer gepassioneerde en toegewijde teams en individuen. Enkele van de hacks die tijdens de demo werden getoond, waren:
- Pivot to Video – het team dat hierbij betrokken was, vond een manier om een live agent-chatgesprek naar de wereld van video te verplaatsen met behulp van tokdoos.
- Visualisatie via meerdere kanalen – ons rapportageteam presenteerde een nieuwe manier om te kijken naar de overlappende werkstromen die een agent afhandelt terwijl hij tegelijkertijd met meerdere werkitems te maken heeft.
- Agent Telephony in-Browser – de ingenieur toonde de integratie van onze agenttelefoonpaneeltoepassing met Twilio's JavaScript-gebaseerde client, waardoor spraakoproepen alleen met een pc mogelijk zijn.
- Scriptable Callflow – sommige van onze platformingenieurs hebben een slimme manier gevonden om granulaire telefoniefuncties te beheren via REST API.
We hebben in de loop der jaren gewerkt aan het verbeteren van Hack Day sinds we het eerste evenement hielden, en hoewel we veel stapsgewijze wijzigingen hebben aangebracht, hebben we ook een reeks kernprincipes geïdentificeerd die het evenement kunnen maken of breken, afhankelijk van hoe nauwkeurig ze worden gevolgd.
1) Geweldige hacks komen uit het hart, niet uit de backlog
Maar al te vaak heb ik gezien dat ingenieurs of productmanagers Hack Day probeerden te gebruiken als een excuus om hun favoriete backlog-items te versnellen. Hoewel dit zeker iets nuttigs tot stand brengt, verslaat het het ware doel van het evenement: innovatie. Ontwikkelaars zouden deze tijd moeten gebruiken om hun stoutste softwaredromen na te jagen en nieuwe technologieën uit te proberen. Hetzelfde geldt voor productmanagers; ze zouden moeten samenwerken met ontwikkelaars om op onverwachte manieren te integreren met andere webservices, of om een idee te definiëren en te implementeren dat onder normale omstandigheden riskant lijkt. Het zou een kans moeten zijn om te verkennen, geen business as usual in een iets andere volgorde.
Voor ontwikkelaars is het kiezen van een backlog-item als je hackdagproject in wezen je neus op de prioriteiten van het productmanagementteam drukken. Denk aan alle gedachtes en discussies die zijn besteed aan het verkrijgen van de juiste volgorde van de verhalen voor je scrum, en stel je dan voor dat je al dat werk negeert en willekeurig verhalen selecteert. Het eerste verdient duidelijk de voorkeur boven het laatste.
Hack Day gaat over het laten ontstaan van geweldige ideeën uit onverwachte hoeken. Zonder nadruk op het nastreven van nieuwe ideeën in plaats van bestaande, verliest het het grootste deel van zijn waarde.
2) Focus, focus, focus; scope creep doodt hacks dood
Hoewel elk nieuw idee eerlijk spel zou moeten zijn voor hackdag, heb ik gemerkt dat de grootste successen voortkomen uit kleine, gerichte inspanningen die gericht zijn op het voltooien van een kleine maar waardevolle functie, of het demonstreren van een groot concept door middel van een goed gedefinieerd voorbeeld dat is beperkt van opzet. Projecten als deze kunnen vaak in een vroeg stadium succesvol zijn en vervolgens functies toevoegen als de tijd het toelaat. Omdat de overwinningsvoorwaarden goed gedefinieerd zijn, kan het team de hack opgeven als deze te ingewikkeld blijkt en hun focus verleggen naar een ander idee.
Alle ontwikkelaars hebben 'grote concepten' in hun hoofd; helaas kunnen deze het moeilijkst te bouwen zijn, zelfs in beperkte vorm, als onderdeel van Hack Day. Als je met succes een van deze grootse plannen in hackvorm wilt nastreven, betrek dan meer mensen bij de discussie en vind een klein stukje van de puzzel dat goed op zichzelf staat, maar toch je punt duidelijk maakt.
3) Soms is er een dorp nodig om een hack te maken
Bepaalde hacks zijn zo duidelijk gedefinieerd en beperkt in reikwijdte dat een enkele ontwikkelaar ze op tijd kan uitvoeren; hoe complex de meeste webservices ook zijn, het komt veel vaker voor dat een echt interessante hack de inspanningen vereist van verschillende materiedeskundigen op een aantal verschillende platforms.
In de kern zijn hackathons sociale evenementen, en ze gaan net zo goed over teaming en moreel als over innovatie. Als je een Hack Day-evenement organiseert, zorg dan voor een forum voor teamvorming voorafgaand aan het evenement zelf; we hebben een aantal jaren vóór Hack-Day een 'wervingsbijeenkomst' gehouden bij LiveOps, wat teamcombinaties opleverde die misschien niet voorkomen binnen de normale stroom van projectwerk, en meer interactie tussen teams op de lange termijn bevordert.
4) Implementatie is de beste beloning
Ja, het is belangrijk om een soort tastbare "beste hack"-prijs aan te bieden, hoewel iedereen die een iPad wil er waarschijnlijk al een heeft. Niet elke ontwikkelaar heeft echter een eigen productidee als onderdeel van de productie; veel ingenieurs kunnen jarenlang werken aan het mogelijk maken van de visies van productmanagers zonder dat hun eigen innovatieve ideeën het daglicht zien. Als hacks veelbelovend zijn als producten, of als ze onmiddellijk bruikbaar zijn, moeten ze snel in productie worden genomen voor zowel het welzijn van het bedrijf als als beloning voor de betrokken ingenieurs.
Elk softwarebedrijf (niet alleen webstartups) zou regelmatig hackathons moeten houden om innovatie te stimuleren, de motivatie te vergroten en de communicatielijnen tussen teams te verbeteren. Zoals bij elke bedrijfsactiviteit, zijn er echter effectievere en minder effectieve manieren om dit aan te pakken. Houd bij wat wel en niet werkt, breng in de loop van de tijd verbeteringen aan en luister naar feedback van deelnemers. Hoewel de bovenstaande principes heel goed hebben gewerkt voor ons bij LiveOps, zult u hoogstwaarschijnlijk een reeks richtlijnen ontwikkelen die in de loop van de tijd beter werken voor uw organisatie.
