Er kan altijd iets misgaan, en dat is oké: hoe win je een hackathon met een team van drie

Met welke groep ga je meestal naar hackathons? Aanvankelijk stelden we dat het ideale team uit vijf personen bestaat: een manager, twee programmeurs, een ontwerper en een marketeer. Maar de ervaring van onze finalisten leerde dat je met een klein team van drie personen een hackathon kunt winnen. Van de 26 teams die de finale wonnen, deden er 3 mee en wonnen met musketiers. Hoe ze het deden - lees verder.

Er kan altijd iets misgaan, en dat is oké: hoe win je een hackathon met een team van drie

We spraken met de aanvoerders van alle drie de teams en realiseerden ons dat hun strategie veel gemeen heeft. De helden van dit bericht zijn de teams PLEXeT (Stavropol, nominatie van het Ministerie van Telecom en Massacommunicatie), "Composite Key" (Tula, nominatie van het Ministerie van Informatie en Communicatie van de Republiek Tatarstan) en Jingu Digital (Ekaterinburg, voordracht van het Ministerie van Industrie en Handel). Voor wie geïnteresseerd is, onder de kat zit een korte beschrijving van de commando's verborgen.
CommandobeschrijvingenPLEXeT
Het team bestaat uit drie mensen: een ontwikkelaar (web, C++, informatiebeveiligingscompetenties), een ontwerper en een manager. We kenden elkaar niet vóór de regionale hackathon. Het team werd door de kapitein samengesteld op basis van de resultaten van online testen.
Samengestelde sleutel
Het team bestaat uit drie collega-ontwikkelaars: fullstack met tien jaar ervaring in IT, backend en mobiel, en backend met focus op databases.
Jingu Digitaal
Het team bestaat uit twee programmeurs - backend en AR/Unity, en een ontwerper die tevens verantwoordelijk was voor de aansturing van het team. Gewonnen op nominatie van het Ministerie van Industrie en Handel

Kies een taak die dicht bij uw competenties ligt

Weet je nog dat er zo'n rijm was "dramaclub, fotoclub, en ik wil ook zingen"? Ik denk dat veel mensen dit gevoel kennen: als alles om je heen interessant is, wil je jezelf op een nieuwe manier in jouw richting laten zien en een nieuwe branche/ontwikkelingsgebied uitproberen. De keuze hangt hier alleen af ​​van de doelstellingen van je team en de bereidheid om risico's te nemen. Kun je je fout accepteren als je plotseling midden in de hackathon beseft dat het onrealistisch is om dit probleem op te lossen? Experimenten in de categorie “Ik ben niet goed in mobiele ontwikkeling, maar wat is dat in godsnaam?” zijn niet voor iedereen weggelegd. Ben jij zo'n amateur?

Artem Koshko (aschuk), commando “Samengestelde sleutel”: “In eerste instantie waren we van plan om iets nieuws te proberen. In de regionale fase hebben we verschillende nuget-pakketten geprobeerd, waar we nooit aan toe zijn gekomen, en Yandex.Cloud. Uiteindelijk hebben we CockroachDB in Kubernetes geïmplementeerd en geprobeerd er migraties naar toe te rollen met behulp van EF Core. Sommige dingen gingen goed, andere minder. We hebben dus nieuwe dingen geleerd, onszelf getest en ons verzekerd van de betrouwbaarheid van beproefde benaderingen.”.

Zo kies je een taak als je ogen afdwalen:

  • Bedenk welke competenties nodig zijn om deze casus op te lossen, en of alle teamleden deze bezitten
  • Als je competenties mist, kun je die dan compenseren (verzin een andere oplossing, leer snel iets nieuws)
  • Voer een kort onderzoek uit naar de markt waarvoor u een product gaat maken
  • Bereken de concurrentie: naar welk circuit/bedrijf/taak zullen de meeste mensen gaan?
  • Beantwoord de vraag: wat drijft jou het meest?

Oleg Bakhtadze-Karnaechov (PLEXeT), PLEXeT-opdracht: “We besloten een tussenstop van tien uur op de luchthaven te maken - net op het moment van de landing arriveerden er een lijst met routes en korte takenoverzichten in onze mail. Ik identificeerde meteen vier taken die voor mij als programmeur interessant waren en waarvoor het actieplan na de start duidelijk was: wat er moet gebeuren en hoe we dat gaan doen. Vervolgens beoordeelde ik de taken van elk teamlid en beoordeelde ik het concurrentieniveau. Als gevolg hiervan hebben we gekozen tussen de taken van Gazprom en het Ministerie van Telecom en Massacommunicatie. De vader van onze ontwerper werkt in de olie- en gassector; we hebben hem gebeld en hem vragen gesteld over de industrie. Uiteindelijk realiseerden we ons dat het inderdaad interessant is, maar dat we niets fundamenteel nieuws kunnen bieden en dat we zeker niet in staat zullen zijn om de competenties te evenaren, omdat er te veel sectorspecifieke kenmerken zijn waarmee rekening moet worden gehouden. rekening. Uiteindelijk hebben we het risico genomen en zijn we naar het eerste circuit gegaan.”

Diana Ganieva (dirilisch), Jingu Digital-team: “In de regionale fase hadden we een taak gerelateerd aan de landbouw, en tijdens de finale - AR/VR in de industrie. Ze werden door het hele team gekozen, zodat elke persoon zijn capaciteiten kon realiseren. Wat we niet zo interessant vonden, hebben we vervolgens verwijderd.”

Doe je huiswerk

En we hebben het nu niet over het voorbereiden van code; het is over het algemeen zinloos om dat te doen. Het gaat om de communicatie binnen het team. Als je nog niet samen hebt gespeeld, elkaar nog niet hebt leren begrijpen en tot overeenstemming bent gekomen, kom dan een paar keer van tevoren bij elkaar en simuleer een hackathon, of bel elkaar in ieder geval om de belangrijkste punten door te spreken, denk na via een plan van aanpak, en bespreek elkaars sterke en zwakke punten. Je kunt zelfs een casus vinden en proberen deze op te lossen - in ieder geval schematisch, op het niveau van 'hoe kom je van punt A naar punt B'.

Tijdens deze paragraaf lopen we het risico minnen te vangen in karma en opmerkingen, door te zeggen: hoe is het mogelijk dat je niets begrijpt, maar hoe zit het met de opwinding, de drive, het gevoel dat nu een prototype zal worden geboren uit de oorspronkelijke bouillon (hallo, biologielessen).

Ja maar.

Improvisatie en gedrevenheid zijn alleen goed als ze slechts een kleine afwijking van de strategie vormen - anders zijn de risico's te groot om tijd te besteden aan het opruimen van de chaos en het corrigeren van fouten, in plaats van te werken, eten of slapen.

Oleg Bakhtadze-Karnaukhov, PLEXeT-team: “Ik kende geen van de leden van mijn team vóór de wedstrijd; ik heb ze geselecteerd en uitgenodigd op basis van hun competenties en beoordelingen in de online testfase. Toen we de regionale hackathon wonnen en beseften dat we nog samen naar Kazan moesten om het hackathonproject in Stavropol af te ronden, besloten we dat we samen zouden komen om te trainen. Voor de finale ontmoetten we elkaar twee keer: we vonden een willekeurig probleem en losten het op. Zoiets als een zaakkampioenschap. En al in dit stadium zagen we een probleem in de communicatie en taakverdeling - terwijl Polina (ontwerper) en Lev (manager) nadachten over de huisstijl, productkenmerken, op zoek naar marktgegevens, had ik veel vrije tijd. We realiseerden ons dus dat we een moeilijkere nominatie moesten aannemen (ik schep niet op, we kwamen vooral taken tegen die verband hielden met internet, maar voor mij zijn het er maar een of twee) en ik moest meer betrokken zijn bij de werkprocessen. . Hierdoor ben ik tijdens de finale, tijdens het vooronderzoek, bezig geweest met wiskundig modelleren en het ontwikkelen van algoritmen.”

Artem Koshko, Composite Key-team : “We hebben ons meer mentaal voorbereid; er was geen sprake van het opstellen van een code. We hadden van tevoren al rollen toegewezen in het team - we zijn alle drie programmeurs (we hebben een volledige stack en twee backends, plus ik weet een beetje van mobiele ontwikkeling), maar het was duidelijk dat iemand de leiding zou moeten nemen rollen van ontwerper en manager. Zo werd ik, zonder dat ik het wist, teamleider en probeerde ik mezelf uit als bedrijfsanalist, spreker en presentatiemaker. Ik denk dat als we hier niet van tevoren over hadden gesproken, we de tijd niet goed hadden kunnen beheren en de eindverdediging niet hadden gehaald.”

Diana Ganieva, Jingu Digital: “We hebben ons niet voorbereid op de hackathon, omdat we vinden dat hackprojecten helemaal opnieuw moeten worden gemaakt – dat is eerlijk. Van tevoren, in de fase van het selecteren van tracks, hadden we een algemeen concept van wat we wilden doen.".

Je kunt niet alleen met ontwikkelaars werken

Diana Ganieva, Jingu Digital-team: “We hebben drie specialisten op verschillende vakgebieden in ons team. Wat mij betreft is dit de ideale compositie voor een hackathon. Iedereen is met zijn eigen bedrijf bezig en er is geen sprake van overlap of taakverdeling. Eén persoon meer zou overbodig zijn.”

Uit statistieken blijkt dat de gemiddelde samenstelling van onze teams 4 tot 5 personen bedraagt, inclusief (in het beste geval) één ontwerper. Het is algemeen aanvaard dat het nodig is om het team te versterken met ontwikkelaars van verschillende pluimage - om zowel iets aan de database toe te voegen als te kunnen verrassen met een "machine" als er iets gebeurt. In het beste geval nemen ze nog steeds een ontwerper mee (wees niet beledigd, we houden van je!), De presentatie en interfaces zullen uiteindelijk niet vanzelf tekenen. De rol van manager wordt nog vaker verwaarloosd; meestal wordt deze functie vervuld door de teamcaptain, een parttime ontwikkelaar.
En dit is fundamenteel verkeerd.

Artem Koshko, Composite Key-team: “Op een gegeven moment hadden we spijt dat we geen gespecialiseerde specialist in het team hadden opgenomen. Hoewel we op de een of andere manier met het ontwerp om konden gaan, was het moeilijk met het businessplan en andere strategische zaken. Een treffend voorbeeld is wanneer het nodig was om de doelgroep en het marktvolume te berekenen, TAM, SAM.”

Oleg Bakhtadze-Karnaukhov, PLEXeT-team: “De bijdrage van de ontwikkelaar aan het product is verre van 80% van het werk, zoals algemeen wordt aangenomen. Er kan niet worden gezegd dat het gemakkelijker was voor de jongens - bijna het hele grootste deel van de taken lag bij hen. Mijn code zonder interfaces, presentaties, video's, strategieën is slechts een reeks symbolen. Als er in plaats van hen meer ontwikkelaars in het team hadden gezeten, was het ons waarschijnlijk gelukt, maar alles zou er minder professioneel uit hebben gezien. Vooral de presentatie is doorgaans de helft van het succes, zo lijkt mij. Tijdens de verdediging en vervolgens in het echte leven over een paar minuten heeft niemand tijd om te begrijpen of uw prototype echt werkt. Als je je laat meeslepen door plannen, zal niemand naar je luisteren. Als je te ver gaat met de tekst, begrijpt iedereen dat je zelf niet weet wat belangrijk is in je product, hoe je het moet presenteren en wie het nodig heeft.”

Timemanagement en ontspanning

Weet je nog hoe de personages in kindertekenfilms als 'Tom en Jerry' lucifers onder hun oogleden plaatsten om te voorkomen dat ze dicht zouden gaan? Onervaren (of overdreven enthousiaste) hackathondeelnemers zien er ongeveer hetzelfde uit.

Tijdens een hackathon kun je gemakkelijk het contact met de realiteit en het tijdsbesef verliezen - de sfeer is bevorderlijk voor ongebreideld coderen zonder pauzes om uit te rusten, te slapen, rond te rommelen in de gameroom, te communiceren met partners of masterclasses bij te wonen. Als je dit behandelt als de Wereldkampioenschappen of de Olympische Spelen, ja, misschien moet je je ook zo gedragen. Niet echt.

Artem Koshko, Composite Key-team: “We hadden veel chak-chak, heel veel - er werd een toren van gebouwd in het midden van onze tafel, het hield ons moreel op peil en gaf ons op het juiste moment koolhydraten. We rustten en werkten bijna de hele tijd samen, en rustten niet afzonderlijk. Maar ze sliepen anders. Andrey (fullstack developer) slaapt graag overdag, Denis en ik slapen graag 's nachts. Daarom werkte ik overdag meer met Denis en 's nachts met Andrey. En hij sliep tijdens de pauzes. We hadden geen systeem van werken of het stellen van taken; alles verliep spontaan. Maar wij hebben hier geen last van gehad, want wij begrijpen elkaar goed en vullen elkaar aan. Het hielp dat we collega’s zijn en nauw met elkaar communiceren. Ik ben de voormalige stagiair van Andrey en Denis kwam als mijn stagiair bij het bedrijf.”

En hier is trouwens diezelfde chak-chak-berg.

Bijna alle door ons geïnterviewde deelnemers noemden competent timemanagement het belangrijkste criterium voor succes op de hackathon. Wat betekent het? Je verdeelt taken zodat je tijd hebt voor slaap en eten, en taken worden niet op een regelmatige manier voltooid. alles stortte in, maar in een tempo dat voor elk teamlid comfortabel is.
Er kan altijd iets misgaan, en dat is oké: hoe win je een hackathon met een team van drie

Oleg Bakhtadze-Karnaukhov, PLEXeT-team"Ons doel was niet om zoveel mogelijk uren te werken, maar om zo lang mogelijk productief te blijven. Hoewel we 3-4 uur per dag sliepen, leek het ons te lukken. We zouden naar de speelkamer kunnen gaan of rondhangen bij de kraampjes van onze partners, en normale tijd vrijmaken voor eten. Op de tweede dag probeerden we Lev zoveel mogelijk te ontlasten, zodat hij voldoende kon slapen en tijd had om op orde te komen voor de voorstelling. De hackathon-repetities hebben ons geholpen, omdat we al begrepen hoe we taken moesten verdelen en hoe we de dagelijkse routine moesten synchroniseren - we aten, sliepen en waren tegelijkertijd wakker. Als gevolg hiervan werkten ze als één enkel mechanisme.”

We weten niet hoe dit team erin slaagde Agomoto’s Eye naar de hackathon te krijgen, maar uiteindelijk slaagden ze er zelfs in een video over het project te maken en een aalmoes voor te bereiden.

Enkele tips voor timemanagement tijdens een hackathon:

  • Ga van groot naar klein: deel taken op in kleine blokken.
  • Een hackathon is een marathon. Wat is het belangrijkste bij een marathon? Probeer in hetzelfde tempo te rennen, anders val je aan het einde van de afstand af. Probeer met ongeveer dezelfde intensiteit te werken en dwing jezelf niet tot het punt van uitputting.
  • Bedenk van tevoren wat de taken van elke deelnemer zullen zijn en hoeveel tijd het hem zal kosten. Zo voorkom je verrassingen als de deadline over een half uur is en je nog geen groot werkstuk klaar hebt staan.
  • Controleer coördinaten om de omvang van de taken aan te passen. Heb je het gevoel dat het goed met je gaat en dat je zelfs nog tijd over hebt? Geweldig - u kunt het besteden aan slapen of het afronden van uw presentatie.
  • Blijf niet hangen in details, maar werk in grote lijnen.
  • Het is moeilijk om een ​​pauze te nemen van je werk, dus maak tijd vrij voor slaap, ontspanning of ontspanning. U kunt bijvoorbeeld een alarm instellen.
  • Neem de tijd om uw toespraak voor te bereiden en te oefenen. Dit is verplicht voor iedereen en altijd. We hebben hierover in een van de vorige gesproken posts.

En er is ook deze alternatieve mening. Voor welke optie kies jij: martelen door te coderen of oorlog voeren met oorlog, en lunchen volgens een vast schema?

Diana Ganieva, Jingu Digital-team: “Elke persoon in ons team is voor één ding verantwoordelijk, er was niemand om ons te vervangen, dus we konden niet in ploegendiensten werken. Toen er helemaal geen kracht meer was, sliepen we drie uur, afhankelijk van de hoeveelheid werk die de deelnemer nog moest doen. Er was absoluut geen tijd om rond te hangen, we verspillen hier geen kostbare tijd aan. De productiviteit werd ondersteund, zij het met korte slaap en lekkers bij de thee – geen energiedrankjes of koffie.”

Verborgen onder de titel zijn verschillende nuttige links als je je wilt verdiepen in het onderwerp timemanagement. Het zal van pas komen in het dagelijks leven - geloof de auteur van dit bericht, die altijd te laat is :)
Voor de veroveraars van de tijd — Effectieve tijdmanagementtechnieken zijn verzameld op de Netology-blog door een projectmanager van Kaspersky Lab: schreeuw
— Een goed artikel voor beginners over Cossa: schreeuw

Probeer op te vallen

Er kan altijd iets misgaan, en dat is oké: hoe win je een hackathon met een team van drie

Hierboven schreven we over het team dat een aalmoes maakte om het project te beschermen. Zij waren de enigen in hun parcours, en we zijn er zeker van dat er onder de ruim 3500 deelnemers geen anderen waren zoals zij.
Dit was natuurlijk niet de belangrijkste reden voor hun overwinning, maar het bracht zeker een extra pluspunt met zich mee - tenminste de sympathie van experts. Je kunt op verschillende manieren opvallen: sommige van onze winnaars beginnen elk optreden met een grapje over hoe ze een bom hebben gemaakt (Sacharov-team, hallo!).

We zullen hier niet in detail op ingaan, maar zullen eenvoudigweg een casus van het PLEXeT-team delen - we denken dat het de moeite waard is om een ​​grap te worden over de zoon van de vriend van een moeder.

Oleg Bakhtadze-Karnaukhov, PLEXeT-team: “We realiseerden ons dat we voorop liepen en besloten dat het gaaf zou zijn om met een transfercase naar de voorverdediging te komen. Het project bevat veel technische details en uitleg van algoritmen, die helemaal niet in de presentatie zijn opgenomen. Maar ik wil het laten zien. Deskundigen steunden het idee en hielpen zelfs bij het optimaliseren ervan. Ze keken niet eens naar de eerste versie; ze zeiden dat ze zo’n schilderij nooit zouden lezen. Wij waren de enigen in de verdediging.”

Er zal ongetwijfeld iets misgaan, en dat is oké.

Bij een hackathon is er, net als in het gewone leven, altijd ruimte voor fouten. Ook al lijkt het erop dat je aan alles hebt gedacht, wie van ons is niet te laat gekomen voor een vliegtuig/examen/bruiloft simpelweg omdat de auto's besloten in de file te staan, de roltrap besloot kapot te gaan en het paspoort was vergeten? thuis?

Oleg Bakhtadze-Karnaukhov, PLEXeT-team: “Polina en ik zijn de hele nacht bezig geweest met het maken van een presentatie, maar uiteindelijk zijn ze vergeten deze te uploaden naar de computer in de zaal waar de verdediging plaatsvond. We proberen het te openen vanaf een flashstation en de antivirus beschouwt het bestand als een virus en verwijdert het. Het resultaat was dat we alles slechts een minuut voor het einde van ons optreden op gang konden krijgen. We hebben de video kunnen laten zien, maar we waren nog steeds erg overstuur. Een soortgelijk verhaal overkwam ons tijdens de voorverdediging. Ons prototype startte niet, de computers van Polina en Lev liepen vast en om de een of andere reden liet ik de mijne achter in de hangar waar onze baan stond. En hoewel de experts ons werk 's ochtends zagen, zagen we eruit als een team excentriekelingen met een aalmoes, mooie woorden, maar geen product. Gezien het feit dat veel deelnemers mijn werk aan wiskundige modellen ervoeren als ‘hij zit iets te tekenen, niet naar de computer kijkend’, was de situatie niet erg goed.

Het klinkt misschien oubollig, maar het enige wat je in deze situatie kunt doen is uitademen. Het is al gebeurd. Nee, je bent niet de enige, iedereen verprutst het. Ook al is dit een fatale fout, het is een ervaring. En denk ook eens na: zal de persoon die u beoordeelt deze zaak als een fakap beschouwen?

Deel in de reacties in welke samenstelling jij je het prettigst voelt om aan een hackathon te werken (zowel mensen als specialisten) en hoe je in teamverband processen bouwt.

Bron: www.habr.com

Voeg een reactie