Hackaton czyli test zgrania zespołu
2 tygodnie temu wziąłem razem z kolegami udział w firmowym hackatonie. Temat był dowolny, ale oczywiście skoro hackaton firmowy to i przydatność dla firmy punktowana. Czas trwania – 11-12h. Zespoły 2-3 osobowe. Nas było trzech.
Zespołów zgłosiło się w sumie 5. Nie dziwię się, że tak mało bo siedzenie w pracy w piątek do 21:00 albo i dłużej nie każdego zadowala, nawet jeśli dają pizzę, przekąski i napoje gratis.
Celujemy w praktyczność
W tym roku podeszliśmy do sprawy praktycznie i wybraliśmy temat, który ktoś z firmy zgłosił jako „przydasię”. Padło na soft dla naszej firmowej biblioteki. Bo do tej pory wyglądało to tak, że na Confluence była strona z tabelką zawierającą wszystkie dostępne książki. I jak ktoś chciał coś wypożyczyć to się tam wpisywał edytując tą tabelkę. Brak łatwego szukania, brak kontroli nad tym czy wszystko poprawnie uzupełnione itd. No więc zabraliśmy się za przygotowanie aplikacji webowej, która ten proces ogarnie. Brzmi banalnie, ale złożenie nawet kilku formularzy w całość w ciągu 12h, w dodatku tak żeby nie tylko działały ale też wyglądały to nie lada wyzwanie.
Technologie
Co do technologii jakie wybraliśmy to jako, że frontendem zająłem się ja to wziąłem na warsztat VueJS, którego wcześniej nie znałem (i o którym chyba coś napiszę bo mnie w pewnych sprawach rozczarował). Na backend poszedł .NET Core 2.1 wspomagany biblioteką Akka.NET. Dane lądowały w bazie MongoDB. A na deser całość stała w kontenerach Dockera i można było zbudować i postawić całą aplikację za pomocą jednego skryptu, na dowolnym komputerze z zainstalowanym Dockerem.
Trafiliśmy w gusta
Efekt jest taki, że na dwie kategorie zdobyliśmy nagrodę w jednej – The Best App. Wybierana przez grupę wszystkich dyrektorów operacyjnych. Czyli nasze podejście do wyboru tematu zadziałało. Niestety w głosowaniu wśród pracowników wygrał inny projekt, z lepszym marketingiem. Szkoda, bo byłyby dwie nagrody. A nagrody firma wybrała całkiem fajne i właśnie muszę jedną wybrać dla siebie. Mam do wyboru duży statek Lego, roczny dostęp do Pluralsighta, iWatcha, vouchery na koncerty dla 2 osób albo skok ze spadochronem. I to ostatnie jest moim faworytem, także śledźcie fanpage bo może zdam relację z odbierania nagrody ;)
Niestety nie mam screenshotów naszego projektu.
Test zespołu
A dlaczego napisałem w tytule, że hackaton to test zgrania zespołu? Ponieważ dopiero pod taką presją czasu doskonale widać czy grupa osób potrafi się dogadać. Kiedy w normalnym projekcie ktoś zawali sprawę albo się nie dogada lub nie zrozumie to opóźnienie o 1 dzień nie zrobi różnicy i wszystko się rozejdzie bo i tak każde zadanie jest wyceniane z pewną rezerwą.
W przypadku hackatonu każda minuta jest na wagę złota. Nie zrozumieliście się? Nie ma czasu na odwracanie rozjazdu. Założyliśmy, że robimy osobno frontend i backend z komunikacją przez REST API i dopiero na sam koniec integrujemy to w całość. Jeśli byśmy w takiej sytuacji nie potrafili w kilku zdaniach precyzyjnie przekazać czego oczekujemy od drugiej strony to naprawianie całkowicie skopanej integracji pogrążyło by projekt.
Coś nie chce działać bo się nie sprawdziło do końca jak coś zrobić albo źle dobrało technologię? Szukanie w Google przez godzinę właśnie zabrało 10% CAŁEGO czasu na CAŁY projekt. Wyobrażasz sobie, że w 10 miesięcznym projekcie znalezienie odpowiedzi dlaczego biblioteka nie działa zajmuje Ci cały miesiąc? Tak by było w tym przypadku. Dlatego trzeba w razie problemów liczyć na pomoc reszty członków.
No i do tego panowanie nad nerwami. Kiedy w 10h musicie dowieźć coś co będzie działało i jako tako wyglądało to nie ma czasu na denerwowanie się. Każda kłótnia pogrąża szanse na sukces. Wdawanie się w bezcelowe dyskusje zabiera cenne minuty, a robienie sobie na złość nie dość, że wymaga potem użerania się z błędami to jeszcze demotywuje wszystkich członków zespołu.
Dodatkowo cieszy mnie fakt, że mimo presji czasu i celu jakim jest po prostu dokończenie aplikacji udało nam się zachować czystość kodu i mądrze balansować pomiędzy wyborem rozwiązania szybkiego albo czystego. Także myślę, że udowodniliśmy też, że fakt dbania o kod nie wynika z ilości dostępnego czasu lub jego braku, a z podejścia programistów.
Czy warto?
Oczywiście, że warto brać udział w takich wydarzeniach. Nie dla nagród. Bo branie udziału dla samych nagród powoduje, że przegrana zniechęca.
Warto brać udział w hackatonie po to, żeby po pierwsze sprawdzić samego siebie. Czy jeśli wybiorę jakąś nową technologię to potrafię szybko się nauczyć czegoś czego wcześniej nie umiałem? Czy potrafię pracować pod presją czasu? Czy Umiem tak zorganizować swoją pracę aby była efektywna?
Warto brać udział w hackatonie po to, żeby po drugie sprawdzić zgranie zespołu. Czy umiecie sprawnie wymieniać się informacjami? Czy umiecie pod presją czasu dogadać szczegóły zadania? Czy potraficie ustalić wspólną wizję projektu? Czy dajecie radę panować nad nerwami nawet jak komuś w zespole coś nie idzie? Tak jak pisałem wyżej tego typu problemy bardzo szybko się rozmywają w zwykłym projekcie i bardzo mocno uwypuklają kiedy w ciągu kilku godzin trzeba dowieźć gotowy produkt.
Jeżeli Twoja firma organizuje coś takiego, albo widzisz, że tego typu event odbywa się w Twojej okolicy to zbieraj ekipę i testujcie siebie. Bo warto.
Leave a Comment