Keith McFarlane, główny architekt
Niedawno zorganizowaliśmy jedenastą imprezę LiveOps Hack Day i było to coś wyjątkowego; wiele naprawdę interesujących pomysłów pojawiło się w ciągu zaledwie 24 godzin dzięki wysiłkom bardzo pełnych pasji i oddanych zespołów i osób. Kilka hacków pokazanych w czasie demonstracji to:
- Pivot to Video – zespół zaangażowany w ten projekt znalazł sposób na przeniesienie rozmowy na czacie agenta na żywo do świata wideo za pomocą tokbox.
- Wizualizacja wielokanałowa — nasz zespół ds. raportowania przedstawił nowy sposób patrzenia na nakładające się strumienie pracy, którymi zajmuje się agent, zajmując się jednocześnie wieloma elementami pracy.
- Agent Telephony in-Browser – inżynier zaprezentował integrację naszej aplikacji z panelem telefonicznym agenta TwilioKlient oparty na JavaScript, umożliwiający rozmowy głosowe przy użyciu samego komputera.
- Skryptowalny przepływ połączeń – niektórzy z naszych inżynierów platformy znaleźli zręczny sposób kontrolowania szczegółowych funkcji telefonicznych za pośrednictwem interfejsu API REST.
Przez lata, odkąd zorganizowaliśmy pierwsze wydarzenie, pracowaliśmy nad ulepszeniem Hack Day i chociaż wprowadziliśmy wiele stopniowych zmian, zidentyfikowaliśmy również zestaw podstawowych zasad, które mogą zadecydować o losie lub porażce wydarzenia w zależności od tego, jak dokładnie są przestrzegane.
1) Świetne hacki pochodzą z serca, a nie z zaległości
Zbyt często widziałem inżynierów lub menedżerów produktu, którzy próbowali wykorzystać Hack Day jako pretekst do przyspieszenia swoich ulubionych zadań. Chociaż z pewnością przynosi to coś pożytecznego, mija się to z prawdziwym celem wydarzenia: innowacjami. Programiści powinni wykorzystać ten czas na realizację swoich najśmielszych marzeń o oprogramowaniu i wypróbowanie nowych technologii. To samo dotyczy menedżerów produktu; powinni współpracować z programistami, aby zintegrować się z innymi usługami internetowymi w nieoczekiwany sposób lub podjąć próbę zdefiniowania i wdrożenia pomysłu, który w normalnych okolicznościach wydawałby się ryzykowny. To powinna być okazja do eksploracji, a nie zwykły biznes w nieco innej kolejności.
Dla programistów wybranie elementu zaległości jako projektu dnia hackerskiego jest w gruncie rzeczy ignorowaniem priorytetów zespołu zarządzającego produktem. Pomyśl o wszystkich przemyśleniach i dyskusjach, które wpłynęły na ustawienie odpowiedniej kolejności historii dla twojego scruma, a następnie wyobraź sobie, że ignorujesz całą tę pracę i wybierasz historie losowo. Wyraźnie widać, że to pierwsze jest lepsze od drugiego.
W Hack Day chodzi o to, by wspaniałe pomysły wyłaniały się z nieoczekiwanych miejsc. Bez nacisku na realizację nowych pomysłów, a nie istniejących, traci większość swojej wartości.
2) Skup się, skup się, skup się; pełzanie lunety zabija hacki na śmierć
Chociaż każdy nowy pomysł powinien być uczciwy w dniu hackowania, zauważyłem, że największe sukcesy wynikają z małych, skoncentrowanych wysiłków, których celem jest ukończenie drobnej, ale wartościowej funkcji lub zademonstrowanie dużej koncepcji za pomocą dobrze zdefiniowanego przykładu, tj. ograniczony w zakresie. Często projekty takie jak ten mogą osiągnąć sukces wcześnie, a następnie dodawać funkcje, gdy pozwala na to czas. Ponadto, ponieważ warunki zwycięstwa są dobrze określone, zespół może zrezygnować z hakowania, jeśli okaże się to zbyt skomplikowane, i skupić się na innym pomyśle.
Wszyscy programiści mają w głowach „wielkie koncepcje”; niestety mogą być najtrudniejsze do zbudowania, nawet w ograniczonej formie, w ramach Hack Day. Jeśli chcesz z powodzeniem realizować jeden z tych wielkich schematów w formie hakerskiej, przyciągnij więcej osób do dyskusji i znajdź mały element układanki, który dobrze się sprawdza, ale nadal przekazuje Twój punkt widzenia.
3) Czasami stworzenie hacka wymaga całej wioski
Niektóre hacki są tak jasno zdefiniowane i mają ograniczony zakres, że jeden programista może je wykonać na czas; jednak, jakkolwiek złożona jest większość usług internetowych, o wiele bardziej powszechne jest, że każdy naprawdę interesujący hack będzie wymagał wysiłków kilku ekspertów merytorycznych na wielu różnych platformach.
W swej istocie hackathony są wydarzeniami społecznymi i dotyczą zarówno tworzenia zespołów i morale, jak i innowacji. Jeśli organizujesz wydarzenie Hack Day, zapewnij forum do tworzenia zespołów przed samym wydarzeniem; przez kilka lat w LiveOps organizowaliśmy spotkania „rekrutacyjne” przed Hack-Day, dając kombinacje zespołów, które mogą nie wystąpić w normalnym przepływie pracy projektowej, i wspierając większe interakcje między zespołami na dłuższą metę.
4) Wdrożenie jest najlepszą nagrodą
Tak, ważne jest, aby zaoferować jakąś namacalną nagrodę „najlepszy hack”, chociaż każdy, kto chce iPada, prawdopodobnie już go ma. Jednak nie każdy programista ma własny pomysł na produkt, który działa jako funkcja w środowisku produkcyjnym; wielu inżynierów może latami pracować nad urzeczywistnieniem wizji menedżerów produktu bez ujrzenia światła dziennego przez własne innowacyjne koncepcje. Jeśli hacki okażą się obiecującymi produktami lub jeśli nadają się od razu do użytku, należy je przyspieszyć do produkcji zarówno dla dobra firmy, jak i jako nagrodę dla zaangażowanych inżynierów.
Każda firma zajmująca się oprogramowaniem (nie tylko startupy internetowe) powinna regularnie organizować hackathony, aby tworzyć innowacje, zwiększać motywację i usprawniać komunikację między zespołami. Jednak, jak w przypadku każdej działalności firmy, istnieją bardziej i mniej skuteczne sposoby jej realizacji. Śledź, co działa, a co nie, wprowadzaj ulepszenia w miarę upływu czasu i słuchaj opinii uczestników. Chociaż powyższe zasady bardzo dobrze sprawdziły się w LiveOps, z czasem najprawdopodobniej opracujesz zestaw wytycznych, które będą lepiej sprawdzać się w Twojej organizacji.
