Hackathon, czyli sposób na programistyczną monotonię

Łatwo nam przychodzi zbywanie zastrzeżeń wobec metodyk zwinnych. Zawsze mamy wszak do dyspozycji argument dyżurny, brzmiący "to nie był prawdziwy agile!". Całkiem nieźle do podważania uwag nadaje się też przekonanie o nieuzasadnionej roszczeniowości najmłodszych pokoleń informatyków.

Krytyka zwinnych metod pracy nie musi zresztą wynikać z jakichś fundamentalnych, niemożliwych do rozwiązania problemów. Zdarza się, że jest ona efektem chwilowego "zmęczenia materiału". Niekoniecznie wypalenia, a raczej przejściowego zużycia wyobraźni. W takich chwilach aparat organizacyjny potrafi przeszkadzać w pracy, a wszelkie nowe rozwiązania – wyglądać jak fanaberie wymyślone na potrzeby zabłyśnięcia na hermetycznych konferencjach.

Dlatego o wyobraźnię programisty należy dbać. Zwłaszcza, że nie każdy pomysł da się początkowo w łatwy sposób ująć w sztywne ramy organizacyjne. Skodyfikowany proces, nawet lekki (jak to powinno być w agile), potrafi zaszkodzić niektórym pomysłom i uniemożliwić badawcze prototypowanie. Na szczęście istnieją alternatywy.

Jest ich trochę, ale najpopularniejszą z nich jest tzw. hakaton (coraz częściej słowo występuje w wersji spolszczonej), czyli maraton programowania. W przeciwieństwie do zbioru iteracji rozplanowanych na zadania w wielomiesięcznej perspektywie, hakaton jest skondensowanym w czasie "atakiem na problem". Zagadnienie jest przedstawiane ramowo, a organizacja leży całkowicie w gestii zespołu. Jeżeli ktoś chce przesiedzieć 14 godzin bez dłuższej przerwy, bo inaczej zapomni, co chce osiągnąć w prototypie, na hakatonie są do tego okazje.

Takie maratony stały się popularne jako metoda promocji oraz sposób na "restart" kreatywny pracowników. Oznacza to potencjalne korzyści nie tylko na polu mitycznego "samorozwoju": udział w hakatonach pozwala organizatorom otrzymać prototyp niekoniecznie łatwy do uzyskania zwyczajowym tokiem badawczym (R&D). Obie strony są więc zadowolone.

Hakatony organizuje coraz więcej firm, powstają także całe platformy maratonowe, oferujące zasoby uczestnikom-organizatorom. Prędko można się przekonać, że taka forma pracy, choć przeznaczona jedynie do szczególnych zagadnień, potrafi dać wartościowe owoce.

Wie o tym już Exatel, biorący w tym roku udział w hakatonie HackYeah. Exatel dostarcza usługi z zakresu cyberbezpieczeństwa i telekomunikacji. Od lat zatrudnia w tym celu szanowanych ekspertów. Eksperymentuje też z różnymi formami interakcji. Zadaniem zdefiniowanym przez Exatela, na którego realizację uczestnicy mieli nieco ponad dobę, było stworzenie narzędzia kategoryzującego dane, opartego o uczenie maszynowe. Cel został zrealizowany, zwycięzcy nagrodzeni, a my mieliśmy okazję porozmawiać na temat doświadczeń Exatela z hakatonem. Zamieniliśmy także parę słów na temat definiowania celu pracy i metod pomiaru jakości, co było źródłem cennych spostrzeżeń.

Kamil Dudek, dobreprogramy: Hakaton kojarzy się niektórym z ulgą względem scruma, z większą przestrzenią do realizacji pasji. Czy udział w tegorocznym HackYeah to była bardziej próba rekrutacji, czy może obejście agile'a? Ewentualnie eksperyment w ramach jakiegoś istniejącego procesu?

Piotr Dudzic, Exatel: To było najbliżej eksperymentu. Mamy w zespole dużo pomysłów, więcej pomysłów niż czasu, więc skupiamy się na tym, co priorytetowe. Niektóre pomysły, które po prostu "fajnie byłoby zrobić" nierzadko musiały czekać. Pewnego razu, gdy już mieliśmy się przymierzać do jednego z nich, pojawiła się sugestia, by zgłosić ten pomysł do hakatonu HackYeah, ze względu na jego skalę i różnorodność. Zazwyczaj formuła hakatonu zakłada jedno zdefiniowane zadanie, nad którym pracują wszystkie zespoły. Tutaj było inaczej, pula dostępnych zadań była większa. Dlatego zgłosiliśmy nasz pomysł, licząc na zainteresowanie zespołów. Zdecydowaliśmy się zdefiniować zadanie tak, by uczestnicy mieli pewien poziom swobody - by w przeciwieństwie do "dev-tasku" zadanie pełniło rolę inspiracji związanej z celem, który chcieliśmy osiągnąć.

Co to było za zadanie? Początkowo było ono chyba sformułowane dość ogólnie...?

Początkowo tak. Chodziło nam o to, żeby z użyciem uczenia maszynowego, opracować mechanizm, który pozwoli odsiać szum w wielkim morzu informacji. Tym morzem był enigmatycznie opisany "zbiór danych z internetu". W praktyce chodziło o narzędzie zbierające dane z pastebina, komentarzy, darknetu i wielu innych miejsc oferujących nieskategoryzowane, pełne szumu dane. Wśród wielu niewinnych danych zdarzają się np. wycieki danych osobowych i kart kredytowych. Leżą obok wierszy, zadań domowych z programowania i statystyk z Pokemonów.

W oparciu o takie oględne wytyczne, zespoły miały stworzyć narzędzie umiejące zaciągnąć dane, podzielić je na grupy ze wskazaniem jakie prawdopodobieństwo przynależności wykazuje dany element. Następnie pozwolić jakoś przeszukać te dane: albo fraza językiem naturalnym, albo wzorzec, na podstawie którego wyszukiwano podobne elementy. Tak nauczony model pozwalałby odsiać z danych szum, spam i niepasujące nam rzeczy.

Zupełnie nie spodziewaliśmy się, że w ramach projektu dostaniemy również interfejs użytkownika, tymczasem zwycięskiej drużynie udało się przygotować bardzo intuicyjny GUI. To na pewno przyczyniło się do zwycięstwa.

Czy zespół który się zgłosił, podzielił się na role spontanicznie, czy też była to grupa freelancerów, która obrała podział ról wcześniej, jako metodę sprzedawania swojej pracy? Jak to wyglądało w innych zespołach? Czy było widać powtarzalne cechy szczególne? Czy pracowano według zbliżonych schematów?

Było bardzo różnie. Próbowaliśmy się z każdym zespołem poznać. Obraliśmy unikatowe podejście, bo w zadaniach innych uczestników hakatonu temat od razu pozwalał na rozpoczęcie pracy. U nas było inaczej i dlatego zespoły zabiegały o kontakt w celu otrzymania wskazówek. Było nas trzech, a do komunikacji w ramach hakatonu zestawiono Discorda. Z zespołami rozmawialiśmy też osobiście, tłumacząc na czym polega zadanie - ze szczegółami i przykładami.

W większości zespołów przyjechały już drużyny złożone wcześniej. Mieliśmy też zespoły tworzone na miejscu, ale nie wybierały one naszego zadania. Było ono trudniejsze, niż pozostałe, mieliśmy mniej chętnych, a ludzie pracowali do ostatniej minuty. Jeżeli chodzi o podział prac: były zespoły ściśle techniczne i dostarczały one rozwiązania będące zbiorem niepołączonych narzędzi. Aby uzyskać rezultat o który pytaliśmy, konieczne było wykonanie kilku kroków ręcznie. Więc nawet sensowne rozwiązania użytkowo były dość słabe, przez co trudniej je było oceniać.

Od początku starali się jak najlepiej zrozumieć zagadnienie i konfrontowali z nami swoje hipotezy. Staraliśmy się ich naprowadzać na rozwiązania bez podawania szczegółów. Opisywaliśmy, co robimy w firmie i co nas interesuje.

Były też zespoły, które nie pytały o pomoc, ale wtedy sięgaliśmy do nich sami. Czasem chcieliśmy niektórym coś podpowiedzieć ponad miarę, bo widzieliśmy, że niektórzy są blisko, ale staraliśmy się nikogo nie faworyzować. Więc jeżeli mówiliśmy coś jednemu zespołowi - informowaliśmy wszystkich innych, jakie było pytanie i jaka jest odpowiedź. Było trochę biegania przez pierwsze kilka godzin.

Zespół, któremu się udało wykazał się więc samoorganizacją.

Ale to niejedyny zespół, który się samodzielnie zorganizował. Ale to zwycięzcy posiadali komplementarne umiejętności. Była osoba od danych, od aplikacji-interfejsu i od środowiska graficznego.

Poinformowaliśmy przed końcem, jak będzie wyglądać proces oceny: należało wskazać elementy podobne do wzorca podanego programowi. Okazało się jednak, że w przypadku niektórych rozwiązań, trudno to było zrobić. Mimo sensownego pomysłu, nie dało się pokazać że on działa.[quote]Zespoły ekspertów technicznych skupiły się na stronie algorytmicznej, dostarczając rozwiązanie w częściach. I to był ich błąd. Nie zadbali o implementację przypadku użycia, realizację potrzeby. Nie pomyśleli o prezentacji/sprzedaniu swojego pomysłu. [/quote]Wynikły też problemy z komunikacją. Wynikały po części z tego, że nasze zadanie było trudniejsze. Zakładaliśmy, że zespoły wybiorą zadanie i zadbają o to, żeby nawiązać z nami współpracę. Tymczasem formuła zakładała o wiele większą swobodę:, np. wybór kilku zadań. Nie wszyscy utrzymywali stały kontakt przez komunikator. Dlatego pytaliśmy zespoły sami – czy potrzebują pomocy.

Czy zwycięzcy byli kimś, kto prawdopodobnie najlepiej radzi sobie właśnie w takiej formule jak hakaton? Czy takie okazje pozwalają się wybijać osobom, które być może ciężko docenić w innych okolicznościach? Czy też pracowaliby bez problemu w zwykłym, nudnym agile'u?

Agile skupia się na koncepcji minimum viable product, szybkim dostarczeniu elementarnej, działającej wersji spełniającej minimum oczekiwań. Pod tym względem hakaton ma wiele podobieństw. W firmie jednak myśli się w kategoriach stabilności i późniejszej odpowiedzialności za kod. Nie oczekiwaliśmy od zespołów narzędzi o gotowości produkcyjnej i integracyjnej. Oczekiwaliśmy weryfikacji pewnej koncepcji. Gdybyśmy chcieli to samo dostarczyć w ramach procesu w firmie, potrzebowalibyśmy spotkań, dyskusji. Tymczasem część drużyn zrobiła sobie przerwę, niektórzy wynieśli się na noc do hotelu, pozostali siedzieli na miejscu. Wszyscy żyli atmosferą nastawienia na cel.

To tworzy kolejne pytanie: czy hakaton nadaje się jako metodyka pracy (nieregularnie)? Czy jest sens przerzucać część zagadnień do rozwiązywania właśnie w taki sposób, czy jest to zbyt zuchwałe?

Przy produkcji gier komputerowych od czasu do czasu zdarzają się takie imprezy. Rezultaty bywają fajne: ludzie bardzo chcą i lubią pokazywać, co są w stanie zrobić, jeżeli tylko da się im swobodę. Oczywiście, najlepsi dostają nagrody. Ale zdarza się też, że zwycięski projekt został przekuty w produkt. U nas była to pierwsza próba kontaktu z taką formułą, więc trudno o wnioski.

Co jest kluczowe, to nie metodyka, a dobrze zdefiniowany cel. Każda drużyna miała swoje pomysły, zupełnie różne technologie i koncepcje. Spodziewaliśmy się, że wszyscy skorzystają z tego samego, ale okazało się, że wykorzystano całe spektrum. Więc pomogło nastawienie na cel i możliwość pokazania, że można coś wymyślić bez sugestii od jury. To jest tutaj kluczowe. Staramy się w pracy zawsze robić ciekawe rzeczy. W przypadku R&D widać to najlepiej, są to unikalne rozwiązania.

**Co do nudy: często można się spotkać z narzekaniem, że ten backlog rozpisany na zadania ciągnący się w nieskończoność, zwłaszcza w utrzymaniowych projektach, z definicji powstrzymuje kreatywność. Ale czy taki hakaton nie jest właśnie metodą pokazania takich projektów ciekawie? Skoro proces czyni produkt nudnym. **

Zainteresować można na wiele innych sposobów niż hakaton, kwestia doboru właściwego. Hakaton może istotnie dać powiew świeżości, ale cykliczny hakaton w tym samym projekcie by się nie powiódł. To służy jednak do eksplorowania nowych pomysłów. Na skostniałe projekty pomagają burze mózgów, ale wtedy cel spotkania jest inny i musi być zgodny z celami biznesowymi. Jeżeli mamy duży projekt i morale siada, możemy próbować oznajmiać cel przez komunikację z biznesem - co chcemy osiągnąć, po co robimy ten soft. I zadać zagadkę "gdybyśmy mieli powiedzieć, że to ma od dziś działać zupełnie inaczej, to jak miałoby to wyglądać?".

Czy do hakatonu warto wracać?

Hakaton jest czymś obok. Nie da się w ten sposób pracować. Jest to coś zupełnie obok metodyki pracy: robienie hakatonu za hakatonem się nie sprawdzi. Zawsze istnieją elementy, które będą nudne i które trzeba odbębnić. Z developmentu produktu który ma zarabiać pieniądze nie da się zrobić nieustającej imprezy. To musi spełniać cele biznesowe. Metodą uniknięcia tej nudy jest przychodząca wraz z doświadczeniem umiejetność takiego planowania pracy, żeby tzw. "nudne" elementy dostarczać jak najprościej. Powiem też niepopularną rzecz: niekoniecznie zawsze jestem zwolennikiem scruma.

Na każdą wątpliwość, Gilb ma sugestię rozwiązania popartą doświadczeniem lat jako konsultant. Wyłonienie krytycznej wartości, tego co tak naprawdę chcemy osiągnąć jest kluczem. To podejście może być wykorzystane przez scruma, ale nie musi. I tak góra "patrzy" na metryki właśnie w taki sposób. Scrum nie jest odpowiedzią na wszystko.

Jak organizacja reaguje na inicjatywę udziału w hakatonie? Czy to wychodzi od programistów, czy może od PR?

Zachęta przyszła z góry i pojawił się pomysł, co przedstawić. Większy opór był na najniższym szczeblu, bo był najbardziej obciążony. Ale było z tego dużo radości.

**Co z logistyką - jak było z dostępnością mentorów na sali? Czy było to wyciągnięcie ich z życiorysu, za co potem mogli nie być wdzięczni? **

Musieliśmy być dostępni przez długi czas i poświęcić kilka dni. Musieliśmy się z tym liczyć. Nasze zespoły potrzebowały wsparcia. Dało się korzystać z "cudzych mentorów", ale raczej z tego nie korzystano. Ale my nie mieliśmy czasu dla innych zespołów, więc nasze zadanie okazało się na tle innych nieco bardziej wymagające. Jesteśmy przede wszystkim spółką telekomunikacyjną. To co zrobiliśmy w ramach hakatonu poszerza portfolio rzeczy, które mamy. W ciekawy i odświeżający sposób.

Nie kończymy naszych dyskusji na temat procesów i metodyki wytwarzania oprogramowania. W kolejnej odsłonie zajmiemy się podejściem do metodyki stosowanym w firmie Red Hat.