Coś na pewno pójdzie nie tak i nie ma w tym nic złego: jak wygrać hackaton w trzyosobowym zespole

W jakiej grupie najczęściej uczestniczysz w hackatonach? Początkowo stwierdziliśmy, że idealny zespół składa się z pięciu osób – menadżera, dwóch programistów, projektanta i marketera. Jednak doświadczenie naszych finalistów pokazało, że hackaton można wygrać mając mały, trzyosobowy zespół. Spośród 26 drużyn, które wygrały finał, 3 rywalizowały i wygrały z muszkieterami. Jak oni to zrobili – czytaj dalej.

Coś na pewno pójdzie nie tak i nie ma w tym nic złego: jak wygrać hackaton w trzyosobowym zespole

Rozmawialiśmy z kapitanami wszystkich trzech drużyn i zdaliśmy sobie sprawę, że ich strategia ma wiele wspólnego. Bohaterami tego wpisu są zespoły PLEXeT (Stawropol, nominacja Ministerstwa Telekomunikacji i Komunikacji Masowej), „Klucz Kompozytowy” (Tula, nominacja Ministerstwa Informacji i Komunikacji Republiki Tatarstanu) i Jingu Digital (Jekaterynburg, nominacja Ministra Przemysłu i Handlu). Dla zainteresowanych krótki opis poleceń ukryty jest pod kotem.
Opisy poleceńPLEXeT
Zespół składa się z trzech osób - programisty (kompetencje webowe, C++, bezpieczeństwo informacji), projektanta i menadżera. Nie znaliśmy się przed regionalnym hackatonem. Zespół został skompletowany przez kapitana na podstawie wyników testów on-line.
Klucz kompozytowy
W zespole pracuje trzech innych programistów – fullstack z dziesięcioletnim doświadczeniem w IT, backend i mobile oraz backend skupiający się na bazach danych.
Cyfrowy Jingu
Zespół składa się z dwóch programistów – backendowego i AR/Unity oraz projektanta, który był jednocześnie odpowiedzialny za zarządzanie zespołem. Zwyciężył w nominacji Ministra Przemysłu i Handlu

Wybierz zadanie bliskie Twoim kompetencjom

Pamiętacie, że był taki rymowany „klub dramatyczny, klub fotograficzny, a ja też chcę śpiewać”? Myślę, że wiele osób zna to uczucie – kiedy wszystko wokół jest ciekawe, chcesz pokazać się w nowy sposób w swoim kierunku i wypróbować nową branżę/obszar rozwoju. Wybór tutaj zależy wyłącznie od celów Twojego zespołu i chęci podjęcia ryzyka – czy możesz zaakceptować swój błąd, jeśli nagle w trakcie hackatonu zorientujesz się, że rozwiązanie tego problemu jest nierealne? Eksperymenty w kategorii „Nie jestem dobry w programowaniu mobilnym, ale o co tu do cholery chodzi?” nie są dla każdego. Czy jesteś typem amatora?

Artem Koszko (aszczuk), polecenie „Klucz złożony”: „Początkowo planowaliśmy spróbować czegoś nowego. Na etapie regionalnym wypróbowaliśmy kilka pakietów nuget, do których nigdy nie dotarliśmy, oraz Yandex.Cloud. Na koniec wdrożyliśmy CockroachDB w Kubernetes i próbowaliśmy przenieść na niego migracje za pomocą EF Core. Niektóre rzeczy poszły dobrze, inne nie za bardzo. Dowiedzieliśmy się więc nowych rzeczy, przetestowaliśmy siebie i upewniliśmy się co do niezawodności sprawdzonych podejść.”.

Jak wybrać zadanie, jeśli Twoje oczy błądzą:

  • Zastanów się, jakie kompetencje są potrzebne do rozwiązania tej sprawy i czy wszyscy członkowie zespołu je posiadają
  • Jeśli brakuje Ci kompetencji, czy możesz je zrekompensować (wymyśl inne rozwiązanie, szybko naucz się czegoś nowego)
  • Przeprowadź krótkie badanie rynku, dla którego będziesz wytwarzać produkt
  • Oblicz konkurencję - na jaki tor/firmę/zadanie pójdzie najwięcej osób?
  • Odpowiedz na pytanie: co będzie Cię najbardziej kręciło?

Oleg Bachtadze-Karnauchow (PLEXeT), polecenie PLEXeT: „Podjęliśmy decyzję o dziesięciogodzinnym postoju na lotnisku – już w momencie lądowania przyszła do nas poczta z listą torów i krótkim zestawieniem zadań. Od razu zidentyfikowałem cztery zadania, które zainteresowały mnie jako programistę i dla których plan działania po starcie był jasny – co trzeba zrobić i jak to zrobimy. Następnie oceniałem zadania każdego członka zespołu i oceniałem poziom rywalizacji. W rezultacie wybraliśmy między zadaniami Gazpromu i Ministerstwa Telekomunikacji i Komunikacji Masowej. Ojciec naszego projektanta pracuje w branży naftowej i gazowniczej, zadzwoniliśmy do niego i zadaliśmy mu pytania dotyczące branży. W końcu zdaliśmy sobie sprawę, że tak, jest ciekawie, ale nie będziemy w stanie zaoferować niczego zasadniczo nowego i na pewno nie będziemy w stanie dorównać kompetencjom, bo jest zbyt wiele specyfiki branży, którą trzeba wziąć pod uwagę konto. W końcu zaryzykowaliśmy i pojechaliśmy na pierwszy tor.”

Diana Ganiewa (dirilean), zespół Jingu Digital: „Na etapie regionalnym mieliśmy zadanie związane z rolnictwem, a w finale – AR/VR w przemyśle. Zostały one wybrane przez cały zespół, tak aby każda osoba mogła realizować swoje możliwości. Następnie odrzuciliśmy to, co nie wydawało nam się szczególnie interesujące”.

Odrób swoją pracę domową

I nie mówimy teraz o przygotowywaniu kodu — generalnie nie ma to sensu. Chodzi o komunikację w zespole. Jeśli jeszcze razem nie graliście, nie nauczyliście się rozumieć i dojść do porozumienia, zbierzcie się kilka razy wcześniej i przeprowadźcie symulację hackatonu, albo przynajmniej zadzwońcie do siebie, żeby omówić najważniejsze punkty, pomyślcie poprzez plan działania i omawiajcie swoje mocne i słabe strony. Można nawet znaleźć jakiś przypadek i spróbować go rozwiązać – przynajmniej schematycznie, na poziomie „jak dostać się z punktu A do punktu B”.

W tym akapicie narażamy się na wyłapanie minusów w karmie i komentarze, jak to możliwe, że nic nie rozumiesz, ale co z ekscytacją, zapałem, poczuciem, że teraz z pierwotnego narodzi się prototyp rosół (witaj, lekcje biologii).

Tak ale.

Improwizacja i popęd są dobre tylko wtedy, gdy stają się jedynie niewielkim odstępstwem od strategii - w przeciwnym razie ryzyko jest zbyt duże, aby spędzać czas na sprzątaniu chaosu i poprawianiu błędów, zamiast pracować, jeść lub spać.

Oleg Bakhtadze-Karnaukhov, zespół PLEXeT: „Przed zawodami nie znałem żadnego z członków mojego zespołu, wybierałem ich i zapraszałem na podstawie ich kompetencji i ocen na etapie testów online. Kiedy wygraliśmy regionalny hackaton i zdaliśmy sobie sprawę, że musimy jeszcze razem pojechać do Kazania i dokończyć projekt hackatonu w Stawropolu, postanowiliśmy, że zbierzemy się razem i potrenujemy. Przed finałem spotkaliśmy się dwukrotnie – znaleźliśmy losowy problem i go rozwiązaliśmy. Coś w rodzaju mistrzostwa przypadku. I już na tym etapie dostrzegliśmy problem w komunikacji i podziale zadań – podczas gdy Polina (projektant) i Lew (menedżer) zastanawiali się nad stylem korporacyjnym, cechami produktu, szukali danych rynkowych, ja miałem dużo wolnego czasu. Zdaliśmy sobie więc sprawę, że musimy podjąć się trudniejszej nominacji (nie przechwalam się, po prostu natrafialiśmy głównie na zadania związane z siecią, ale u mnie to tylko jedno lub dwa) i muszę bardziej angażować się w procesy pracy . W efekcie na finale, w trakcie badań wstępnych, zajmowałem się modelowaniem matematycznym i opracowywaniem algorytmów.”

Artem Koshko, zespół ds. klucza kompozytowego : „Przygotowaliśmy się bardziej mentalnie, nie było mowy o przygotowaniu kodu. Mieliśmy już wcześniej przydzielone role w zespole – cała nasza trójka jest programistami (mamy full stack i dwa backendy, a ponadto znam się trochę na mobile developmentu), ale było jasne, że ktoś będzie musiał się tego podjąć role projektanta i menedżera. W ten sposób bez mojej wiedzy zostałem liderem zespołu, sprawdziłem się w roli analityka biznesowego, mówcy i twórcy prezentacji. Myślę, że gdybyśmy nie rozmawiali o tym wcześniej, nie potrafilibyśmy odpowiednio zarządzać czasem i nie dotarlibyśmy do ostatniej obrony.

Diana Ganieva, Jingu Digital: „Nie przygotowywaliśmy się do hackatonu, bo wierzymy, że projekty hackerskie należy tworzyć od podstaw – to sprawiedliwe. Z góry, na etapie wyboru utworów, mieliśmy ogólną koncepcję tego, co chcemy zrobić”.

Nie możesz pracować sam z programistami

Diana Ganieva, zespół Jingu Digital: „W naszym zespole mamy trzech specjalistów z różnych dziedzin. Moim zdaniem jest to idealna kompozycja na hackaton. Każdy jest zajęty swoimi sprawami i nie ma nakładania się ani podziału zadań. Jedna osoba więcej byłaby zbędna.”

Statystyki wykazały, że przeciętny skład naszych zespołów to od 4 do 5 osób, w tym (w najlepszym przypadku) jeden projektant. Powszechnie przyjmuje się, że konieczne jest wzmocnienie zespołu programistami o różnych specjalnościach - aby móc zarówno dodawać do bazy danych, jak i zaskakiwać „maszyną”, jeśli coś się wydarzy. W najlepszym wypadku i tak zabierają ze sobą projektanta (nie obrażaj się, kochamy Cię!), prezentacja i interfejsy w końcu same się nie wrysują. Jeszcze częściej zaniedbywana jest rola menadżera – zazwyczaj tę funkcję przejmuje kapitan drużyny, programista pracujący na pół etatu.
I to jest zasadniczo błędne.

Artem Koshko, zespół ds. klucza kompozytowego: „W pewnym momencie żałowaliśmy, że nie przyjęliśmy do zespołu wyspecjalizowanego specjalisty. Chociaż w jakiś sposób poradziliśmy sobie z projektem, było to trudne z biznesplanem i innymi strategicznymi kwestiami. Uderzającym przykładem jest sytuacja, w której konieczne było obliczenie docelowej grupy odbiorców i wielkości rynku, TAM, SAM.”

Oleg Bakhtadze-Karnaukhov, zespół PLEXeT: „Wkład dewelopera w produkt jest daleki od 80% pracy, jak się powszechnie uważa. Nie można powiedzieć, że chłopakom było łatwiej – prawie cała większość zadań spoczywała na nich. Mój kod bez interfejsów, prezentacji, filmów, strategii to tylko zbiór symboli. Gdyby zamiast nich w zespole było więcej programistów, prawdopodobnie byśmy sobie z tym poradzili, ale wszystko wyglądałoby mniej profesjonalnie. Zwłaszcza prezentacja to generalnie połowa sukcesu, jak mi się wydaje. Podczas obrony, a potem w prawdziwym życiu za kilka minut nikt nie będzie miał czasu, aby zrozumieć, czy Twój prototyp naprawdę działa. Jeśli dasz się ponieść schematom, nikt cię nie wysłucha. Jeśli posuniesz się za daleko z tekstem, wszyscy zrozumieją, że sam nie wiesz, co jest ważne w Twoim produkcie, jak to zaprezentować i komu to potrzebne.

Zarządzanie czasem i relaks

Pamiętasz, jak w kreskówkach z dzieciństwa, takich jak „Tom i Jerry”, bohaterowie wkładali zapałki pod powieki, aby zapobiec ich zamknięciu? Niedoświadczeni (lub nadmiernie entuzjastyczni) uczestnicy hackatonu wyglądają mniej więcej tak samo.

Na hackatonie łatwo stracić kontakt z rzeczywistością i poczucie czasu – atmosfera sprzyja nieskrępowanemu kodowaniu bez przerw na odpoczynek, sen, wygłupy w pokoju gier, komunikację z partnerami czy uczęszczanie na kursy mistrzowskie. Jeśli traktujesz to jak mistrzostwa świata czy igrzyska olimpijskie, to tak, być może tak właśnie powinieneś się zachować. Nie bardzo.

Artem Koshko, zespół ds. klucza kompozytowego: „Mieliśmy dużo chak-czaka, dużo – na środku naszego stołu zbudowano z niego wieżę, która podnosiła nam morale i dostarczała nam węglowodanów we właściwym czasie. Odpoczywaliśmy i pracowaliśmy prawie cały czas razem, a nie odpoczywaliśmy osobno. Ale spali inaczej. Andrey (programista fullstack) lubi spać w ciągu dnia, Denis i ja lubimy spać w nocy. Dlatego w ciągu dnia więcej pracowałem z Denisem, a w nocy z Andreyem. I spał na przerwach. Nie mieliśmy żadnego systemu pracy i ustalania zadań, wszystko działo się spontanicznie. Nam to jednak nie przeszkadzało, ponieważ dobrze się rozumiemy i uzupełniamy. Pomogło nam to, że jesteśmy kolegami i blisko się komunikujemy. Jestem byłym stażystą Andreya, a Denis przyszedł do firmy jako mój stażysta.”

A tak na marginesie, to ta sama góra Chak-chak.

Prawie wszyscy uczestnicy, z którymi rozmawialiśmy, jako główne kryterium sukcesu hackatonu uznali właściwe zarządzanie czasem. Co to znaczy? Rozdzielasz zadania tak, abyś miał czas na sen i jedzenie, a zadania nie są realizowane w sposób regularny. wszystko się zawaliło, ale w tempie wygodnym dla każdego członka zespołu.
Coś na pewno pójdzie nie tak i nie ma w tym nic złego: jak wygrać hackaton w trzyosobowym zespole

Oleg Bakhtadze-Karnaukhov, zespół PLEXeT"Naszym celem nie była praca jak największej liczby godzin, ale utrzymanie produktywności tak długo, jak to możliwe. Mimo że spaliśmy 3-4 godziny dziennie, wydawało się, że nam się to udało. Mogliśmy udać się do pokoju gier lub spędzić wolny czas na stoiskach naszych partnerów i zarezerwować normalny czas na jedzenie. Drugiego dnia staraliśmy się jak najbardziej odciążyć Lwa, aby mógł się wyspać i mieć czas na uporządkowanie się przed występem. Pomogły nam próby hackathonu, bo już zrozumieliśmy, jak rozdzielić zadania i zsynchronizować codzienność – jednocześnie jedliśmy, spaliśmy i nie spaliśmy. W rezultacie działały jako jeden mechanizm”.

Nie wiemy, jak temu zespołowi udało się zaprosić Oko Agomoto na hackaton, ale w końcu udało im się nakręcić film o projekcie i przygotować materiały informacyjne.

Kilka wskazówek dotyczących zarządzania czasem podczas hackatonu:

  • Przejdź od dużego do małego – podziel zadania na małe bloki.
  • Hackaton to maraton. Co jest najważniejsze w maratonie? Staraj się biec w tym samym tempie, w przeciwnym razie spadniesz na koniec dystansu. Staraj się pracować z mniej więcej tą samą intensywnością i nie doprowadzaj się do stanu wyczerpania.
  • Zastanów się z wyprzedzeniem, jakie będą zadania każdego uczestnika i ile czasu mu to zajmie. Pomoże Ci to uniknąć niespodzianek, gdy termin realizacji już za pół godziny, a nie masz gotowej dużej pracy.
  • Sprawdź współrzędne, aby dostosować zakres zadań. Czy czujesz, że idzie Ci dobrze i że masz jeszcze trochę czasu? Świetnie - możesz przeznaczyć je na spanie lub sfinalizowanie prezentacji.
  • Nie skupiaj się na szczegółach, pracuj szerokimi pociągnięciami.
  • Trudno jest zrobić sobie przerwę w pracy, dlatego przeznacz czas specjalnie na sen, relaks lub relaks. Można na przykład ustawić alarmy.
  • Poświęć trochę czasu na przygotowanie i przećwiczenie przemówienia. Jest to obowiązkowe dla każdego i zawsze. Mówiliśmy o tym w jednym z poprzednich posty.

Istnieje również ta alternatywna opinia. Którą opcję wolisz – tortury poprzez kodowanie czy wojnę z wojną i lunch zgodnie z harmonogramem?

Diana Ganieva, zespół Jingu Digital: „Każda osoba w naszym zespole jest odpowiedzialna za jedną rzecz, nie było nikogo, kto mógłby nas zastąpić, więc nie mogliśmy pracować na zmiany. Kiedy już nie było już sił, spaliśmy po trzy godziny, w zależności od ilości pracy, jaka pozostała jeszcze uczestnikowi. Nie było absolutnie czasu na spędzanie czasu, nie marnowaliśmy na to cennego czasu. Produktywność była wspierana, choć krótkim snem i smakołykami z herbatą – bez napojów energetycznych i kawy.”

Pod wycięciem ukrytych jest kilka przydatnych linków, jeśli chcesz zgłębić temat zarządzania czasem. Przyda się w życiu codziennym - uwierz autorowi tego wpisu, który zawsze się spóźnia :)
Dla zdobywców czasu — Skuteczne techniki zarządzania czasem zostały zebrane na blogu Netology przez menedżera projektu z Kaspersky Lab: płakać
— Dobry artykuł dla początkujących na temat Cossa: płakać

Spróbuj się wyróżnić

Coś na pewno pójdzie nie tak i nie ma w tym nic złego: jak wygrać hackaton w trzyosobowym zespole

Powyżej pisaliśmy o zespole, który przygotował ulotkę mającą na celu ochronę projektu. Byli jedyni na swojej drodze i jesteśmy pewni, że wśród ponad 3500 uczestników nie było drugiej takiej osoby jak oni.
Oczywiście nie to było głównym powodem ich zwycięstwa, ale zdecydowanie przyniosło dodatkowy plus – przynajmniej sympatię ekspertów. Można się wyróżnić na różne sposoby – niektórzy z naszych zwycięzców każdy występ rozpoczynają od żartu o tym, jak zrobili bombę (zespół Sacharowa, halo!).

Nie będziemy się nad tym rozwodzić szczegółowo, ale po prostu podzielimy się przypadkiem z zespołu PLEXeT – uważamy, że warto stać się żartem na temat syna koleżanki matki.

Oleg Bakhtadze-Karnaukhov, zespół PLEXeT: „Zdaliśmy sobie sprawę, że wyprzedzamy konkurencję i zdecydowaliśmy, że fajnie byłoby przejść do obrony przed obroną ze sprawą transferową. Projekt zawiera wiele szczegółów technicznych, objaśnień algorytmów, które w ogóle nie zostały ujęte w prezentacji. Ale chcę to pokazać. Eksperci poparli pomysł, a nawet pomogli go zoptymalizować. Nawet nie spojrzeli na pierwszą wersję, mówili, że takiego obrazu nigdy nie przeczytają. Byliśmy jedynymi, którzy stanęli w obronie.”

Coś na pewno pójdzie nie tak i to jest w porządku.

Na hackatonie, jak w zwykłym życiu, zawsze jest miejsce na błędy. Nawet jeśli wydaje się, że pomyślałeś o wszystkim, kto z nas nie spóźnił się na samolot/egzamin/ślub tylko dlatego, że samochody utknęły w korku, zepsuły się schody ruchome, a paszport został zapomniany w domu?

Oleg Bakhtadze-Karnaukhov, zespół PLEXeT: „Polina i ja spędziliśmy całą noc na tworzeniu prezentacji, ale w końcu zapomnieli ją wgrać na komputer w sali, w której odbywała się obrona. Próbujemy otworzyć go z dysku flash, a program antywirusowy postrzega plik jako wirusa i usuwa go. Dzięki temu udało nam się wszystko rozpocząć już na minutę przed zakończeniem naszego występu. Udało nam się pokazać wideo, ale i tak byliśmy bardzo zdenerwowani. Podobna historia przydarzyła nam się podczas przedobrony. Nasz prototyp nie uruchomił się, komputery Poliny i Lwa zawiesiły się, a ja z jakiegoś powodu zostawiłem swój w hangarze, w którym stał nasz tor. I choć eksperci rano widzieli naszą pracę, to wyglądaliśmy jak ekipa ekscentryków z ulotką, pięknymi słowami, ale bez produktu. Biorąc pod uwagę, że wielu uczestników postrzegało moją pracę nad modelami matematycznymi jako „siedzi, coś rysuje, nie patrzy na komputer”, sytuacja nie była zbyt dobra.

Zabrzmi to banalnie, ale jedyne, co możesz zrobić w tej sytuacji, to wydychać powietrze. To już się wydarzyło. Nie, nie jesteś jedyny, wszyscy schrzanili. Nawet jeśli jest to fatalny błąd, jest to przeżycie. I zastanów się też, czy osoba, która Cię ocenia, uzna tę sprawę za fakap?

Podziel się w komentarzach, w jakim składzie czujesz się najlepiej pracując na hackatonie (zarówno osobom, jak i specjalistom) i jak budujesz procesy w zespole.

Źródło: www.habr.com

Dodaj komentarz