Keith McFarlane, pääarkkitehti
Pidimme äskettäin yhdestoista LiveOps Hack Day -tapahtumamme, ja se oli jotain erityistä; useita todella mielenkiintoisia ideoita syntyi vain 24 tunnissa joidenkin erittäin intohimoisten ja omistautuneiden tiimien ja yksilöiden ponnistelujen ansiosta. Jotkut esittelyn aikana näytetyistä hakkeroista olivat:
- Pivot to Video – tässä työssä mukana ollut tiimi löysi tavan siirtää agenttikeskustelu livenä videon maailmaan käyttämällä tokbox.
- Monikanavainen visualisointi – raportointitiimimme esitteli uuden tavan tarkastella päällekkäisiä työvirtoja, joita agentti käsittelee samalla kun hän käsittelee useita työkohteita samanaikaisesti.
- Agent Telephony in-Browser – insinööri esitteli agenttipuhelinpaneelisovelluksemme integroinnin TwilioJavaScript-pohjainen asiakasohjelma, joka mahdollistaa äänipuhelut pelkän tietokoneen avulla.
- Scriptable Callflow – jotkut alustan suunnittelijoistamme löysivät sulavan tavan hallita rakeisia puhelintoimintoja REST API:n kautta.
Olemme työskennelleet parantaaksemme Hack Day -tapahtumaa vuosien ajan ensimmäisestä tapahtumasta lähtien, ja vaikka olemme tehneet monia asteittain muutoksia, olemme myös tunnistaneet joukon ydinperiaatteita, jotka voivat tehdä tai rikkoa tapahtuman riippuen siitä, kuinka tarkasti niitä seurataan.
1) Suuret hakkerit tulevat sydämestä, eivät ruuhkasta
Olen aivan liian usein nähnyt insinöörien tai tuotepäälliköiden yrittävän käyttää Hack Day -ohjelmaa tekosyynä nopeuttaakseen suosikkiruuhkansa. Vaikka tämä varmasti saa aikaan jotain hyödyllistä, se kumoaa tapahtuman todellisen tarkoituksen: innovaation. Kehittäjien tulisi käyttää tämä aika toteuttaakseen villeimpiä ohjelmistounelmiaan ja kokeillakseen uusia teknologioita. Sama koskee tuotepäälliköitä; heidän tulisi tehdä yhteistyötä kehittäjien kanssa integroidakseen yllättävillä tavoilla muihin verkkopalveluihin tai yrittääkseen määritellä ja toteuttaa ideaa, joka näyttäisi riskialttiilta normaaleissa olosuhteissa. Sen pitäisi olla mahdollisuus tutkimiseen, ei tavallista toimintaa hieman eri järjestyksessä.
Kehittäjälle ruuhkakohteen valitseminen hakkerointipäiväprojektiksi merkitsee pohjimmiltaan tuotehallintatiimin tärkeysjärjestystä. Ajattele kaikkia ajatuksia ja keskusteluja, jotka ovat käyneet saadaksesi tarinajärjestyksen oikeaan ketjuun, ja kuvittele sitten, että jätät kaiken tämän työn huomiotta ja valitset tarinoita satunnaisesti. On selvää, että edellinen on parempi kuin jälkimmäinen.
Hack Dayn tarkoituksena on antaa mahtavien ideoiden syntyä odottamattomista paikoista. Korostamatta uusien ideoiden ajamista olemassa olevien ideoiden sijaan, se menettää suurimman osan arvostaan.
2) keskittyä, keskittyä, keskittyä; Scope creep tappaa hacks dead
Vaikka minkä tahansa uuden idean pitäisi olla reilu peli hakkerointipäivänä, olen huomannut, että suurimmat onnistumiset syntyvät pienistä, kohdistetuista ponnisteluista, joilla pyritään saamaan loppuun pieni mutta arvokas ominaisuus tai esitellä laaja konsepti tarkasti määritellyn esimerkin avulla, joka on rajoitettu laajuus. Usein tällaiset projektit voivat saavuttaa menestystä varhaisessa vaiheessa ja lisätä ominaisuuksia sitten ajan salliessa. Lisäksi, koska voittoolosuhteet ovat hyvin määriteltyjä, joukkue voi hylätä hakkeroinnin, jos se osoittautuu liian monimutkaiseksi, ja siirtää huomionsa johonkin muuhun ideaan.
Kaikilla kehittäjillä on "suuria käsitteitä" päässään; Valitettavasti nämä voivat olla vaikeimpia rakentaa, jopa rajoitetussa muodossa, osana Hack Daytä. Jos haluat onnistuneesti toteuttaa jotain näistä suurista suunnitelmista hakkerointimuodossa, vedä enemmän ihmisiä mukaan keskusteluun ja löydä palapelistä pieni pala, joka pysyy hyvin sellaisenaan, mutta saa silti pointtisi perille.
3) Joskus hakkeroinnin luomiseen tarvitaan kylä
Tietyt hakkerit ovat niin selkeästi määriteltyjä ja laajuudeltaan rajoitettuja, että yksi kehittäjä voi toteuttaa ne ajoissa; Vaikka useimmat verkkopalvelut ovatkin monimutkaisia, on kuitenkin paljon yleisempää, että mikä tahansa todella mielenkiintoinen hakkerointi vaatii useiden aiheiden asiantuntijoiden ponnisteluja useilta eri alustoilta.
Hackathonit ovat pohjimmiltaan sosiaalisia tapahtumia, ja niissä on yhtä paljon kyse tiimityöstä ja moraalista kuin innovaatiosta. Jos olet järjestämässä Hack Day -tapahtumaa, tarjoa foorumi tiimin muodostamiselle ennen itse tapahtumaa; Olemme pitäneet Hack-päivää edeltävän "rekrytointi"-kokouksen useiden vuosien ajan LiveOpsissa, mikä on tuottanut tiimiyhdistelmiä, joita ei välttämättä tapahdu normaalissa projektityössä, ja edistänyt tiimien välistä vuorovaikutusta pitkällä aikavälillä.
4) Käyttöönotto on paras palkinto
Kyllä, on tärkeää tarjota jonkinlainen konkreettinen "paras hakkerointi" -palkinto, vaikka jokaisella iPadin haluavalla on jo sellainen. Jokaisella kehittäjällä ei kuitenkaan ole omaa tuoteideaa omasta toimivuudestaan ominaisuutena tuotannossa; monet insinöörit voivat työskennellä tuotepäälliköiden visioiden mahdollistamiseksi vuosia ilman, että heidän omat innovatiiviset ideansa näkevät päivänvalon. Jos hakkerit näyttävät lupaavilta tuotteina tai jos ne ovat heti käyttökelpoisia, ne tulisi saada nopeasti tuotantoon sekä yrityksen eduksi että palkkioksi mukana oleville insinööreille.
Jokaisen ohjelmistoyrityksen (ei vain web-aloitusyritysten) tulisi järjestää säännöllisesti hackathoneja innovaatioiden synnyttämiseksi, motivaation lisäämiseksi ja tiimien välisten viestintälinjojen parantamiseksi. Kuten minkä tahansa yrityksen toiminnassa, on kuitenkin tehokkaampia ja vähemmän tehokkaita tapoja tehdä se. Seuraa, mikä toimii ja mikä ei, tee parannuksia ajan myötä ja kuuntele osallistujien palautetta. Vaikka yllä olevat periaatteet ovat toimineet erittäin hyvin meillä LiveOpsissa, kehität todennäköisesti joukon ohjeita, jotka toimivat paremmin organisaatiossasi ajan myötä.
