Jak wygrać hackathon, albo realizować projekty pod presją czasu

utworzone przez Marcin Żmigrodzki

(ten artykuł jest częścią książki Bardziej niż Agile, która ukaże się w 2023 roku)

Pierwszy hackathon został zorganizowany w 1999 roku w ramach konferencji OpenBSD. Dzisiaj Hackathon to krótki, zwykle dwudniowy, maraton, w trakcie którego zespoły rywalizują przy tworzeniu różnych rozwiązań technicznych. Najczęściej hackathony dotyczą technologii programistycznych, choć można spotkać również takie, które skupiają się na tworzeniu prototypów urządzeń. Największy w Polsce, a według organizatorów również w Europie to Hackyeah, które miałem okazję być uczestnikiem w 2022 roku jako mentor.

Istnieją hackathony otwarte, w których mogą wziąć udział wszyscy chętni i hackathony zamknięte, organizowane w ramach wybranej korporacji (takie na przykład organizuje ING). Są hackathony zdalne i stacjonarne, te ostatnie w opinii większości moich rozmówców mają gigantyczną przewagę zaangażowania i atmosfery zabawy oraz rywalizacji. 

Hackathony to oprócz zabawy dla uczestników, świetne narzędzie budowania profesjonalnego wizerunku dla patronów fundujących nagrody oraz dla pracodawców osób startujących w nich. Przez duże organizacje te konkursy są również tanią metodą wytestowania różnych ryzykownych koncepcji. Wystarczy zgłosić swoją potrzebę na konkurs, zafundować nagrodę i liczyć na to, że zgłosi się kilka zespołów, które spróbują zmierzyć się z wyzwaniem.

Mały zespół

Typowy zespół na hackathonie ma trzy do siedmiu osób. Ważne jest, aby pokryć kompetencjami wszystkie krytyczne obszary. Na przykład w przypadku hackathonów programistycznych takie obszary to:

• Przygotowanie prezentacji
• Grafika i interfejs użytkownika
• Technologie frontendowe
• Technologie backendowe
• Obsługa urządzeń, jeżeli takowe jest konieczne
• Przygotowanie danych, na przykład w przypadku rozwiązań z zakresu sztucznej inteligencji
• Koordynacja całości
• Zdobywanie wiedzy od mentorów i jury

Jeżeli zespół się nie zna za dobrze, to może wypisać na tablicy, co każdy potrafi, w jaki sposób może pomóc w projekcie. 

Jeżeli masz luki kompetencyjne w zespole. Jasno to zapisz na samym początku projektu i przedyskutuj, jak je wypełnić. Naturalnym adresem będą mentorzy krążący po sali. Warto ich eksploatować maksymalnie, jak się da. 

Pewnie temu tematowi warto by poświęcić osobny rozdział, ale efektywność zdobywania wiedzy bardzo podnosi aktywne zadawanie pytań i głośne przyznawanie się do swojej ignorancji. Dopóki otoczenie nie wie, że potrzebujesz pomocy, nie będzie wiedziało, że powinno ci pomóc. Rzadko zdarza się, aby ktoś podszedł i zagadnął: “czy przypadkiem nie jesteś zagubiony i nie trzeba ci pomóc?”. Po prostu pytaj. W najgorszym przypadku ktoś powie, że nie wie, albo nie ma czasu.

Product owner

To, co różni zespoły zmierzające ku klęsce od tych z potencjałem na zwycięstwo był brak lub obecność kogoś, kto pilnowałby wizji produktu.

Product owner dba o to, aby zespół zajmował się właściwymi zadaniami i nie odpłynął zabawy z technologią. Pilnuje też czasu i reaguje, gdy trzeba ciąć zakres, bo inaczej zespół nie zdąży z demonstracją.

Rekrutuj dla motywacji

Ciężko przecenić wagę zgranego zespołu. Motywacja wewnętrzna jest krytyczna dla innowacyjność. Niemal wszyscy rozmówcy podkreślali jej wagę i wskazują na to dziesiątki badań.

Źródeł wewnętrznej motywacji jest kilka:

• Nauka i poznawanie nieznanego – “Fajne jest wzięcie maczety i pójście przez dżunglę na przełaj”.
• Atmosfera zabawy i rywalizacji – najlepiej zilustrują tą tezę cytaty uczestników hackathonów: “będzie co opowiadać wnukom”, “można poznać ciekawych ludzi”, “na hackathonach zawsze dają darmową pizzę, a człowiekowi najlepiej się pracuje na darmowej pizzy!”, “spędzić czas razem”, “ znamy i się lubimy, i mamy zajawkę na punkcie robienia hackathonów”.
• Misyjność, poczucie wpływu na świat – misji poświęciłem następny akapit, ale podsumowując ludzie lubią odnajdywać głębszy sens w tym, co robią. Dotyczy to w większym stopniu aktywności, które nie są wynagradzane czynnikami zewnętrznymi takimi, jak płaca.

Jednak po wielu rozmowach doszedłem do wniosku, że nie istnieją proste i szybkie metody zbudowania motywacji wewnętrznej. Albo ktoś ją ma na starcie, albo jej nie zbuduje w sobie w trakcie hackathonu i tyle. Z tego między innymi powodu taką przewagę mają zespoły, które wcześniej się poznały i miały szansę współpracować.

Znajdź misję

Dużo przyjemniej buduje się system, który ma zredukować ilość śmieci w środowisku niż system oceny wiarygodności kredytowej klientów. Oba to duże wyzwanie intelektualne, ale ten pierwszy ma dodatkowo misję.

Rozpoznaj kryteria i preferencje jury

Niuanse zapisane są czasem między wierszami. Szczególnie na początku, na etapie analizy wymagań i wymyślania koncepcji, koniecznie zaangażuj członków jury. Gdy porozmawiasz z nimi, dowiesz się więcej niż to, co zostało zapisane w oficjalnych kryteriach konkursowych.

Warto zrozumieć też intencje, które stały za zleceniem danego tematu konkursowego. Skąd on się wziął? Z drugiej strony opłaca się poznać członków jury i zrozumieć ich osobiste preferencje. Czy prezentacja koncepcji jest ważniejsza, czy może proof of concept?

Wracam też do tezy, że pytając, można uzyskać dużo więcej wiedzy, niż pasywnie czekając na pomoc.

Spotkaj się w tym samym miejscu

 “Człowiek przejdzie kółko wokół laptopów, popatrzy w cudzy monitor i powie “hej, ja też miałem taki problem.” – potwierdził jeden z wielokrotnych zwycięzców hackathonów programistycznych.  “Praca zdalna obniża motywację do siedzenia po nocy.”

Moi rozmówcy podkreślali, że nawet gdy hackathon organizowany był w formule zdalnej to i tak zespół spotykał się w biurze lub w jednym mieszkaniu. 

Duża intensywność prac w połączeniu ze zmęczeniem i innowacyjnością rozwiązań i tak stanowią spore wyzwanie. Nie warto dokładać do tego ograniczeń komunikacyjnych.

Poza tym włącza się jeszcze efekt facylitacyjny, albo syndrom “jechania na jednym wózku”. Gdy widzę, jak inni dookoła intensywnie pracują, to samemu mi głupio odstawać. W projekcie Arystoteles Google’a dowiedziono, że był to jeden z najważniejszych czynników efektywności zespołów IT.

Cykl życia projektu

1. Analiza wymagań konkursowych
2. Burza mózgów na temat koncepcji – przez około godzinę do dwóch ludzie rzucają pomysły na projekt. “Trzeba wymyślić, coś czego nie ma i bardzo wielu ludzi boli ten brak”. Następnie trzeba zagłosować na najlepszy. Niektóre zespoły przygotowują prosty lean canvas, aby pokazać wszystkie aspekty pomysłu.
3. Szukanie źródeł wiedzy – jedną z dużych przewag jest ustalenie, czy ktoś, czegoś podobnego już kiedyś nie zrobił. Znalezienie analogii drastycznie redukuje ryzyko projektu. Źródłem może być internet, na przykład serwisy o startupach, poprzednie hackathony, serwisy z fragmentami kodów. Szczególnym źródłem są też mentorzy krążący po sali, bo z reguły mają sporą wiedzę dziedzinową.
4. Strukturalizacja pomysłu – od jednej do dwóch godzin trwa podzielenie wybranego pomysłu na części problemowe. Kryterium może być podział na eksperymenty do przeprowadzenia, albo główne zadania, albo różne technologie do użycia w rozwiązaniu. Efektem strukturalizacji jest przypisanie zadań do ludzi. Nie chodzi o to, aby mieć plan projektu do końca, tylko chodzi o to, aby zacząć jak najszybciej od najważniejszych rzeczy. Później ten plan będzie co godzinę ulegał zmianie, albo wręcz wyląduje w koszu, gdy pojawi się nowy pomysł. 
5. Produkcja – w kolejnym akapicie bardziej szczegółowo opisują jak zorganizować ten etap. Należy tylko wspomnieć, że w każdej chwili projekt może zostać zatrzymany i postawiony na głowie. Szczególnie, gdy okaże się, że pomysł jest niewykonalny albo zabraknie czasu.
6. Przygotowanie prezentacji – jedni mówią, że prezentacja powinna powstawać od samego początku hackathonu, inni, że od połowy prac, jeszcze inni, że poświęcają na nią ostatnie dwie godziny. Tak, czy siak to prezentacja w dużej mierze decyduje o zwycięstwie i nie można o niej zapomnieć.

Schematyczna prezentacja przebiegu projektu w trakcie hackathonu.

To co chciałem pokazać to, że pierwsza część projektu nie jest wcale poświęcana na prace. Niektórzy rozmówcy wręcz wskazywali, że nawet połowę czasu zajmuje wymyślanie i strukturalizacja koncepcji. Po drugie prace produkcyjne przebiegają równolegle w zmiennym rytmie. Jedne wątki toczą się w rytmie częstych wydań i krótkich zadań, bo taka jest ich natura. Inne są zupełnie nieprzewidywalne. Czasem przetwarzanie danych może zająć kwadrans, a czasem trzy godziny. To oznacza w konsekwencji, że niemożliwe jest zastosowanie wspólnych sprintów o stałej długości.

Co godzinę przegląd

Zespół co godzinę odkłada zadania dosłownie na pięć minut i omawia stan prac. Jak jest tablica kanban, to przestawia zadania na niej, jak jest Slack to wpisuje ustalenia, a jak nie ma nic, to po prostu dyskutuje. Główny problem przed zespołem to ten, czy zdąży przygotować rozwiązania na czas. I upewnienie się, że tak będzie jest głównym celem przeglądu projektu. “Czy z tym, co macie zrobić zdążycie do końca? Jeżeli nie, to dyskusja o redukcji zakresu i ewentualnie zmianie koncepcji.”.

Jeżeli zidentyfikowano problem techniczny, to dedykowani członkowie zespołu omawiają go, a reszta wraca do roboty. Jeden z rozmówców podrzucił następujący pomysł na podział każdej godziny produkcyjnej: około czterdziestu minut pracy w słuchawkach, wtedy sobie nie przeszkadzamy, a potem wszyscy je zdejmuje i trwa dalsza praca połączona z dyskusją.

Skup się na prezentacji

Daj sobie czas przed końcem hackathonu na doprowadzenie rozwiązania do poziomu, na którym można cokolwiek pokazać. Wielokrotnie zdarzało się, że zespoły najbardziej zaawansowane w obszarze technologicznym nie zdążały na koniec dopiąć rozwiązania i doprowadzić go do stanu, w którym można by cokolwiek zademonstrować.

“Kręcenie filmów jako elementu końcowej prezentacji mocno działa na korzyść.” – podkreślił mój rozmówca. – “Widzieliśmy dużo słabych prezentacji, na przykład gdy ludzie skupiają się na technikaliach (nikogo to nie interesuje), lub pokazują powerpointa z dziesięcioma tysiącami punktów (nie sprzedażowa), albo brakuje treści a jest tylko sama prezentacja, lub prezenter nie potrafi przekazać wartości pomysłu, niekiedy zespół nawet zrobi fajną prezentację, ale nie pokaże głównej idei i korzyści z pomysłu, zakładając, że jury domyśli się szczegółów (tzw. klątwa wiedzy).”

“Prezentacje trzeba robić od początku hackathonu. Nieważne, ile się zrobi przez 24h i tak cała robota sprowadza się do trzech minut prezentacji.”

“Ważne jest też, aby zrobić próby prezentacji.” Sama forma pokazania jest istotna w kontekście oceny rozwiązania przez jury.

Zarządzaj snem i frustracją

Hackathon to przede wszystkim zabawa. Bez dobrej atmosfery nic się nie będzie kleić.

“Gdy raz nie spałem, to prezentacja, którą wówczas przygotowałem była jedną z najgorszych. Trzeba spać w trakcie hackathonu.” “Na początku jest euforia, potem jest dołek, bo nie wychodzi, wszystko leży. Warto mieć świadomość istnienia takiego cyklu emocjonalnego.” “Nie spanie jest największym błędem.”

Warto z góry zaplanować, ile czasu członkowie zespołu poświęcą na sen i wyznaczyć szychty. Ktoś, kto przygotowuje prezentację powinien być wypoczęty na koniec, ktoś kto testuje koncepcję musi od razu być aktywny. Jednak każdy musi w pewnym momencie odpocząć. Im umysł jest bardziej zmęczony, to staje się mniej elastyczny i otwarty na nowe informacje. To prowadzi do konfliktów. 

Poniżej hackathon o drugiej w nocy, ja idę spać, oni walczą. 🙂

Żaden Scrum, Kanban!

“Scrum nie nadaje się, bo to jest za krótki projekt!” Bo nie ma czasu na sprinty – hackathon trwa od jednego dnia do dwóch zwykle. Sprint musiałby trwać dwie godziny. A organizowanie w jego trakcie planningów, review i retrospektyw stałoby się obciążającą biurokracją.

Bo prace trwają różnych rytmie – jeden obszar składa się z zadań po kwadrans, a w innym przez pół dnia opracowuje się koncepcję.

Bo nie ma inkrementu – jest tylko pomysł, lub kulawe rozwiązanie, które ma błędy, albo jedynie koncepcja w powerpoint. Jakość w hackathon schodzi na dalszy plan, celem jest zademonstrowanie fajnego prototypu.

Bo nie da się estymować – ludzie co najwyżej mówią “zdążę z tym, a z tym to chyba nie zdążę”. Jakakolwiek próba oszacowania wydajności zespołu i pracochłonności zadań mijałaby się ze zdrowym rozsądkiem. Po prostu trzeba zacząć robić i zobaczyć, jak nam wychodzi.

Natomiast pomaga pokazanie zadań na wspólnej tablicy. Ustalenie, które z nich są priorytetowe, bo mają największy wpływ na końcową ocenę rozwiązania, albo bo są najbardziej żmudne lub niepewne i wymagają eksperymentów. Pomaga też przydzielenie najbliższych zadań konkretnym członkom zespołu, aby maksymalnie wykorzystać ich produktywność.

Przywództwo zwinno – autokratyczne

Kiedy nagle ktoś z zespołu, nikomu nic nie mówiąc, wybiera się spać, potrzebna jest osoba z charyzmą, która utrzyma zespół w ryzach. Ten i wiele innych czynników występujących w takim projekcie powoduje, że samo przywództwo zwinne to za mało:

• Gigantyczna presja czasu
• Zmęczenie
• Częste pivoty
• Niska jakość
• Braki wiedzy technicznej

Na druga rękę potrzebny jest przyjazny dyktator z wizją całości.

Upraszczając, mamy dwa style liderskie i dwie sytuacje z perspektywy menedżerskiej w trakcie hackathonu:

1. Wszystko idzie zgodnie z planem – zespół wie, co ma robić, zadania zostały jasno podzielone, wizja rozwiązania jest wykonalna i atrakcyjna, atmosfera pozytywna i nikt stanął pod ścianą braku kompetencji. W takiej sytuacji działa servant leader. Przygląda się, pyta, czy może pomóc, usuwa przeszkody sprzed drogi projektu, upewnia się, że zespół jest zsynchronizowany, ale działa raczej w trybie coachingowym niż dyrektywnym. Na przykład “co sądzicie o takim pomyśle, czy coś jeszcze można tu poprawić?”, a nie “to nie zadziała, ty musisz jeszcze raz na to spojrzeć”.
2. Projekt stoi na rozdrożu – koncepcja okazała się niewykonalna, albo istnieje więcej niż jedna koncepcja na stole i trzeba wybrać, zespołowi siadło zaangażowanie, ludzie są zmęczeni, pojawiły się konflikty personalne. Wtedy wkracza przyjazny dyktator. Wysłuchuje opinii i przekonuje zespół do jednej koncepcji. Rozprawia się z konfliktami w zespole. Wywiera presję na tych, którym wszystko opadło. Kluczem jest czas reakcji. Zespół musi mieć szybko nową wizję. Jeden z rozmówców wprost mówił o “leciutkiej dyktaturze”: “Jedna osoba powinna mieć wizję i wymuszać ją na zespole do końca. Autokrata, który ma mapę w głowie i pilnuje, aby nie odpłynąć w pomysłach.”

Tu należy tylko uważać, aby ręcznym sterowaniem projektem nie zabić zaangażowania zespołu. Idealnie, gdy zespół jednomyślnie zagłosuje za decyzję o porzuceniu starej koncepcji na rzecz nowej. Jeżeli jednak nie ma zgody, to lider przynajmniej powinien wyczerpująco uzasadnić swoją decyzję. A najlepiej jeżeli dysponuje takim autorytetem, że przekona wszystkich do swojej perspektywy.

Z reguły lider zespołu, ów zwinno – autokratyczny przywódca, jest też odpowiedzialny za komunikację z mentorami i jury oraz przygotowanie prezentacji. Zatem idealnie, gdy lider rozumie technologię, ale i biznes. Wie, jakie wymagania będą krytyczne z perspektywy oceny pomysłu, a jakie mimo technologicznej atrakcyjności, można odłożyć.

Wędrując jako mentor po sali Hackyeah, gdzie kilka tysięcy inżynierów tworzyło rozwiązania, rzucił mi się w oczy jeden brak. Nigdzie nie było białej tablicy. Ludzie przywozili komputery, wielkie monitory, słuchawki, maskotki jak na przykład średniowieczny szyszak, czy mandolina, ale nikt nie przywiózł tablicy, na której zespół mógłby notować, omawiać i rozbijać problemy na małe części. Uważam, że w trakcie fazy tworzenia koncepcji mogłaby szalenie pomóc skupić uwagę na właściwych zagadnieniach.

Przydatne narzędzia

Tablica Kanban – to może być po prostu tablica, jeżeli zespół siedzi w biurze lub narzędzie typu Trello, Jira.

Lista dyskusyjna – mimo, że ludzie zwykle siedzą koło siebie, to i tak używają oprogramowania do rozmowy, jak Slack, Messenger, Whatsapp, czy Discord. Przewaga polega na tym, że na zadane pytanie mogę odpowiedzieć za dwie minuty, gdy uporam się z jakimś problemem, więc mniej mnie to rozprasza. Poza tym na liście dyskusyjnej zostają zapiski poprzednich ustaleń i można do nich wrócić bez angażowania członków zespołu. Można tam też wrzucać linki, kawałki kodu, obrazki, próbki prezentacji itd. Wszystko w jednym miejscu.

Wspólne repozytorium – w przypadku hackathonów programistycznych dobrze jest trzymać kod w jednym miejscu (Github) i zarządzać wersjami, szczególnie gdy rozwiązanie ma wiele powiązanych modułów. Choć pojawiły się też głosy, że za mało czasu jest na stosowanie repozytorium. Kod po prostu łatwiej jest przesłać na czasie.

Burza mózgów – jedni stosują mapy myśli (np. XMind), inni affinity diagram (np. biała tablica lub kartka), jeszcze inni rysują makiety ekranów (np. Figma) i procesy (np. Draw.io). Ważne, aby dane narzędzie “przykleiło się” do zespołu i faktycznie było użyteczne w danym wyzwaniu.

Typowe błędy

Za duże rozwiązanie

Jeden z uczestników hackathonów napisał, że obowiązuje tu zasada Pi razy oko – wszystkie estymacje musisz pomnożyć razy trzy. To oznacza, że trzeba brać do realizacji koncepcje trzy razy mniejsze niż by się nam wydawało, że damy radę. Lepiej zrobić coś małego niż nie zrobić nic. Na Hackyeah 2022 około dziesięciu procent zespołów nie oddało nic. Absolutnie nic, nawet nie zrobiło prezentacji.

Wystarczy, że zrobisz cokolwiek a już przeskakujesz tych dziesięć procent rywali.

Dla ominięcia tej pułapki kluczowa jest rola product ownera.

Brak czasu na przygotowanie prezentację i jej przetestowanie

Czasem zespół tak mocno wkręci się w produkcję, że albo nie zdąży przemyśleć prezentacji, albo nie przygotuje się do niej.

Tu trzeba sprzedać rozwiązanie. Pierwszym etapem oceny jest zwykle głosowanie jury lub mentorów na podstawie prezentacji w PDF, filmików lub slajdów. A drugim demonstrowanie osobiste rozwiązania.

Juror ma tylko kilka minut na rzucenie okiem na projekt, bo projektów może być nawet sto. Więc prezentację trzeba tak przygotować, aby w kilkanaście sekund człowiek dał radę zrozumieć, o co chodzi, jaka jest wartość, jak to działa i na jakim etapie jest produkcja rozwiązania.

Szczególnie do drugiego etapu oceny trzeba się przygotować osobiście, bo to jest trochę taki teatr. Ważna jest nie tylko treść, ale i sposób przekazania zamysłu stojącego za rozwiązaniem.

Nie przedstawienie w prezentacji, co chodzi w rozwiązaniu

Klątwa wiedzy objawia się tym, że zespół tak dobrze jest zaznajomiony ze swoim rozwiązaniem, że zapomina opowiedzieć o nim jurorom. Zakłada, że wszystko jest oczywiste. Nie jest, szczególnie, jeżeli juror ma tylko dwie minuty na ocenę pojedynczego projektu.

Przy niektórych projektach musiałem zdrowo się nagłówkować, jaką koncepcję miał zespół. Jedyne, co wyczytałem z prezentacji, to że Ziemia jest zaśmiecona, ludziom się to nie podoba i zobaczyłem kilka klimatycznych zdjęć ze stocka.

Zaprezentowanie tylko slajdów bez rozwiązania

Wcześniej wspomniałem o konieczności przygotowania się do prezentowania przed jury. Na drugim końcu osi pułapek jest zrobienie samej prezentacji bez rozwiązania. Około dwudziestu procent projektów nie pokazało samego projektu. Mogliśmy tylko poczytać o tym, jak to zespół wyobraża sobie rozwiązanie w przyszłości i jakie mógłby mieć zamierzenia. To nie buduje wiarygodności.

Skupienie się na drobiazgach

Wiecie, jaka była najczęściej implementowana funkcjonalność aplikacji na Hackyeah? Ekran logowania! Coś, co nie zmienia wartości pomysłu, nie wyróżnia i jest całkowicie oczywiste. Inny przykład to formularz rejestracyjny. Po co do oceny koncepcji prototypu produkować stronę z rejestracją użytkownika? Wystarczy przecież jeden testowy użytkownik do zademonstrowania rozwiązania. Jeszcze brakuje tylko funkcji “przypomnij hasło”.