Hvilken slags gruppe deltager du normalt i hackathons? Indledningsvis oplyste vi, at det ideelle team består af fem personer - en leder, to programmører, en designer og en marketingmedarbejder. Men erfaringerne fra vores finalister viste, at du kan vinde et hackathon med et lille hold på tre personer. Af de 26 hold, der vandt finalen, konkurrerede 3 og vandt med musketerer. Hvordan de gjorde det - læs videre.
Vi talte med anførerne for alle tre hold og indså, at deres strategi har meget til fælles. Heltene i dette indlæg er holdene PLEXeT (Stavropol, nominering af ministeriet for telekommunikation og massekommunikation), "Composite Key" (Tula, nominering af ministeriet for information og kommunikation i Republikken Tatarstan) og Jingu Digital (Ekaterinburg, indstilling af Industri- og Handelsministeriet). For de interesserede er der gemt en kort beskrivelse af kommandoerne under katten.
KommandobeskrivelserPLEXeT
Teamet har tre personer - en udvikler (web, C++, informationssikkerhedskompetencer), en designer og en leder. Vi kendte ikke hinanden før det regionale hackathon. Holdet blev samlet af kaptajnen baseret på resultaterne af online test.
Sammensat nøgle
Teamet har tre medudviklere – fullstack med ti års erfaring inden for IT, backend og mobil, og backend med fokus på databaser.
Jingu Digital
Teamet består af to programmører - backend og AR/Unity, samt en designer, der også var ansvarlig for ledelsen af teamet. Vandt i nomineringen af Industri- og Handelsministeriet
Vælg en opgave, der ligger tæt på dine kompetencer
Kan du huske, at der var sådan et rim "dramaklub, fotoklub, og jeg vil også synge"? Jeg tror, at mange kender til denne følelse - når alt omkring dig er interessant, vil du gerne vise dig selv på en ny måde i din retning, og prøve en ny branche/udviklingsområde. Valget her afhænger kun af dit teams mål og risikovillighed – kan du acceptere din fejl, hvis du pludselig midt i hackathonet indser, at det er urealistisk at løse dette problem? Eksperimenter i kategorien "Jeg er ikke god til mobiludvikling, men hvad fanden er det?" er ikke for alle. Er du den slags amatør?
Artem Koshko (), kommandoen "Sammensat nøgle": "Vi planlagde oprindeligt at prøve noget nyt. På den regionale scene prøvede vi adskillige nuget-pakker, som vi aldrig kom uden om, og Yandex.Cloud. Til sidst implementerede vi CockroachDB i Kubernetes og forsøgte at rulle migrationer ind på det ved hjælp af EF Core. Nogle ting gik godt, andre ikke så meget. Så vi lærte nye ting, testede os selv og sikrede os pålideligheden af gennemprøvede tilgange.".
Sådan vælger du en opgave, hvis dine øjne vandrer:
- Tænk over hvilke kompetencer der skal til for at løse denne sag, og om alle teammedlemmer har dem
- Hvis du mangler kompetencer, kan du så kompensere for dem (kom med en anden løsning, lær hurtigt noget nyt)
- Foretag en kort undersøgelse af markedet, som du vil lave et produkt til
- Beregn konkurrencen - hvilket spor/virksomhed/opgave vil flest gå til?
- Besvar spørgsmålet: hvad vil drive dig mest?
Oleg Bakhtadze-Karnaukhov (), PLEXeT kommando: "Vi tog en beslutning om en ti-timers mellemlanding i lufthavnen - lige i landingsøjeblikket kom en liste over spor og korte opgavebeskrivelser med vores post. Jeg identificerede med det samme fire opgaver, der var interessante for mig som programmør, og som handlingsplanen efter starten var klar til – hvad skal der laves og hvordan vi vil gøre det. Derefter vurderede jeg opgaverne for hvert holdmedlem og vurderede konkurrenceniveauet. Som følge heraf valgte vi mellem Gazproms opgaver og ministeriet for tele- og massekommunikation. Vores designers far arbejder med olie og gas; vi ringede til ham og stillede ham spørgsmål om branchen. Til sidst indså vi, at ja, det er interessant, men vi vil ikke kunne tilbyde noget fundamentalt nyt, og vi vil bestemt ikke kunne matche kompetencerne, fordi der er for mange branchespecifikationer, der skal tages i betragtning. konto. Til sidst tog vi en risiko og gik til det første spor.”
Diana Ganieva (), Jingu Digital team: ”På det regionale stadie havde vi en opgave relateret til landbruget, og ved finalen - AR/VR i industrien. De blev udvalgt af hele holdet, så hver person kunne realisere deres evner. Så lugede vi ud i det, vi ikke fandt så interessant."
Lav dine lektier
Og vi taler ikke om kodeforberedelse nu - det er generelt meningsløst at gøre det. Det handler om kommunikation i teamet. Hvis I ikke har spillet sammen endnu, ikke har lært at forstå hinanden og nået til enighed, så tag jer sammen et par gange i forvejen og simuler et hackathon, eller ring i det mindste til hinanden for at tale hovedpunkterne igennem, tænk gennem en handlingsplan, og diskuter hinandens styrker og svagheder. Du kan endda finde en sag og prøve at løse den - i det mindste skematisk på niveauet "hvordan man kommer fra punkt A til punkt B."
I løbet af dette afsnit risikerer vi at fange minusser i karma og kommentarer og sige, hvordan er det muligt, du forstår ingenting, men hvad med spændingen, drivet, følelsen af, at nu vil en prototype blive født fra det oprindelige bouillon (hej, biologitimer).
Ja, men.
Improvisation og drive er kun godt, når det kun bliver en lille afvigelse fra strategien – ellers er risiciene for store til at bruge tid på at rydde op i kaosset og rette op på fejl, i stedet for at arbejde, spise eller sove.
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: "Jeg kendte ingen af medlemmerne af mit team før konkurrencen; jeg udvalgte og inviterede dem på baggrund af deres kompetencer og vurderinger på online teststadiet. Da vi vandt det regionale hackathon og indså, at vi stadig skulle til Kazan sammen og afslutte hackathon-projektet i Stavropol, besluttede vi, at vi ville tage os sammen og træne. Inden finalen mødtes vi to gange - vi fandt et tilfældigt problem og løste det. Noget som et case-mesterskab. Og allerede på dette tidspunkt så vi et problem i kommunikation og fordeling af opgaver - mens Polina (designer) og Lev (leder) tænkte på virksomhedens stil, produktfunktioner, på udkig efter markedsdata, havde jeg en masse fritid. Så vi indså, at vi skulle påtage os en sværere nominering (jeg praler ikke, vi stødte bare mest på opgaver relateret til nettet, men for mig er det bare en eller to), og jeg skal være mere involveret i arbejdsprocesser . Som et resultat, ved finalen, under den indledende forskning, var jeg engageret i matematisk modellering og udvikling af algoritmer."
Artem Koshko, Composite Key team : "Vi forberedte os mere mentalt, der var ingen snak om at udarbejde en kode. Vi havde allerede tildelt roller i teamet på forhånd - vi tre er alle programmører (vi har en fuld stack og to backends, plus jeg ved lidt om mobiludvikling), men det var klart, at nogen skulle tage fat på roller som designer og leder. Sådan blev jeg, uden at jeg vidste, teamleder, forsøgte mig som forretningsanalytiker, foredragsholder og præsentationsmager. Jeg tror, at hvis vi ikke havde talt om det her på forhånd, ville vi ikke have været i stand til at styre tiden korrekt, og vi ville ikke have nået det sidste forsvar.”
Diana Ganieva, Jingu Digital: "Vi forberedte os ikke på hackathonet, fordi vi mener, at hack-projekter skal laves fra bunden - det er fair. I forvejen havde vi på tidspunktet for udvælgelsen af numre en generel idé om, hvad vi ville gøre".
Du kan ikke arbejde med udviklere alene
Diana Ganieva, Jingu Digital team: ”Vi har tre specialister inden for forskellige områder på vores team. Efter min mening er dette den ideelle sammensætning til et hackathon. Alle har travlt med deres egen virksomhed, og der er ingen overlapning eller opgavefordeling. En person mere ville være overflødig."
Statistikker har vist, at den gennemsnitlige sammensætning af vores teams er fra 4 til 5 personer, inklusive (i bedste fald) en designer. Det er generelt accepteret, at det er nødvendigt at styrke teamet med udviklere af forskellige striber - for både at kunne tilføje til databasen og overraske med en "maskine", hvis der sker noget. I bedste fald tager de stadig en designer med sig (bliv ikke fornærmet, vi elsker dig!), præsentationen og interfaces vil ikke tegne sig selv, i sidste ende. Rollen som leder negligeres endnu oftere - normalt overtages denne funktion af holdkaptajnen, en deltidsudvikler.
Og dette er grundlæggende forkert.
Artem Koshko, Composite Key team: ”På et tidspunkt fortrød vi, at vi ikke tog en specialiseret specialist med på holdet. Selvom vi på en eller anden måde var i stand til at klare designet, var det svært med forretningsplanen og andre strategiske ting. Et slående eksempel er, når det var nødvendigt at beregne målgruppen og markedsvolumen, TAM, SAM.”
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: "Udviklerens bidrag til produktet er langt fra 80% af arbejdet, som man almindeligvis tror. Man kan ikke sige, at det var nemmere for gutterne – næsten hele hovedparten af opgaverne lå hos dem. Min kode uden grænseflader, præsentationer, videoer, strategier er blot et sæt symboler. Hvis der havde været flere udviklere på holdet i stedet for dem, ville vi nok have klaret det, men alt havde set mindre professionelt ud. Især præsentationen er generelt halvdelen af succesen, som det forekommer mig. Under forsvaret og derefter i det virkelige liv om et par minutter, vil ingen have tid til at forstå, om din prototype virkelig virker. Hvis du lader dig rive med af ordninger, vil ingen lytte til dig. Hvis du går for langt med teksten, vil alle forstå, at du ikke selv ved, hvad der er vigtigt i dit produkt, hvordan du præsenterer det, og hvem der har brug for det.”
Tidsstyring og afslapning
Kan du huske, hvordan karaktererne i barndoms tegnefilm som "Tom og Jerry" satte tændstikker under deres øjenlåg for at forhindre dem i at lukke? Uerfarne (eller alt for entusiastiske) hackathon-deltagere ser omtrent det samme ud.
Ved et hackathon er det let at miste kontakten med virkeligheden og en følelse af tid - atmosfæren er befordrende for uhæmmet kodning uden pauser til hvile, søvn, fjols i spillelokalet, kommunikere med partnere eller deltage i master classes. Hvis du behandler dette som verdensmesterskaberne eller OL, så ja, måske er det sådan, du skal opføre dig. Ikke rigtig.
Artem Koshko, Composite Key team: "Vi havde en masse chak-chak, meget - et tårn af det blev bygget midt på vores bord, det holdt vores moral oppe og gav os kulhydrater på det rigtige tidspunkt. Vi hvilede og arbejdede næsten hele tiden sammen, og hvilede ikke hver for sig. Men de sov anderledes. Andrey (fullstack-udvikler) kan lide at sove om dagen, Denis og jeg kan godt lide at sove om natten. Derfor arbejdede jeg mere med Denis om dagen og med Andrey om natten. Og han sov i pauserne. Vi havde ikke noget system til at arbejde eller sætte opgaver; snarere var alt spontant. Men det generede os ikke, for vi forstår hinanden godt og supplerer hinanden. Det hjalp, at vi er kollegaer og kommunikerer tæt. Jeg er Andreys tidligere praktikant, og Denis kom til virksomheden som min praktikant."
Og her er i øvrigt det samme chak-chak bjerg.
Næsten alle de deltagere, vi interviewede, nævnte kompetent tidsstyring som hovedkriteriet for succes ved hackathonet. Hvad betyder det? Du fordeler opgaver, så du har tid til søvn og mad, og opgaver bliver ikke løst på en regulær måde. alt kollapsede, men i et tempo, der er behageligt for hvert teammedlem.
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet'Vores mål var ikke at arbejde så mange timer som muligt, men at forblive produktive så længe som muligt. Selvom vi sov 3-4 timer om dagen, så det ud til at lykkes. Vi kunne gå i spillelokalet eller hænge ud ved vores partneres stande og sætte normal tid af til mad. På andendagen forsøgte vi at aflaste Lev så meget som muligt, så han kunne få nok søvn og nå at komme i orden inden forestillingen. Hackathon-øvelserne hjalp os, da vi allerede forstod, hvordan vi skulle fordele opgaver, og synkroniseringen af den daglige rutine - vi spiste, sov og var vågne på samme tid. Som et resultat fungerede de som en enkelt mekanisme."
Vi ved ikke, hvordan dette hold formåede at få Agomotos øje til hackathonet, men i sidste ende lykkedes det endda at optage en video om projektet og forberede en uddeling.
Nogle tips til tidsstyring ved et hackathon:
- Gå fra stort til småt - nedbryd opgaver i små blokke.
- Et hackathon er et maraton. Hvad er det vigtigste ved et maraton? Prøv at løbe i samme tempo, ellers falder du af ved slutningen af distancen. Prøv at arbejde med nogenlunde samme intensitet og ikke presse dig selv til et punkt af udmattelse.
- Tænk på forhånd, hvad der vil være hver enkelt deltagers opgaver, og hvor meget tid det vil tage ham. Det hjælper dig med at undgå overraskelser, når deadline er en halv time væk, og du ikke har et stort stykke arbejde klar.
- Tjek koordinater for at justere omfanget af opgaver. Føler du, at du har det godt og endda har tid tilbage? Fantastisk - du kan bruge det på at sove eller færdiggøre din præsentation.
- Bliv ikke hængt op i detaljer, arbejd i store træk.
- Det er svært at tage en pause fra arbejdet, så sæt tid specifikt af til søvn, afslapning eller afslapning. Du kan f.eks. indstille alarmer.
- Tag dig tid til at forberede og øve din tale. Dette er obligatorisk for alle og altid. Vi talte om dette i en af de foregående .
Og der er også denne alternative opfattelse. Hvilken mulighed er du til - tortur ved kodning eller krig med krig og frokost efter en tidsplan?
Diana Ganieva, Jingu Digital team: "Hver person i vores team er ansvarlig for én ting, der var ingen til at erstatte os, så vi kunne ikke arbejde på skift. Når der absolut ingen kræfter var tilbage, sov vi i tre timer, afhængig af hvor meget arbejde der stadig var tilbage for deltageren. Der var absolut ingen tid til at hænge ud, vi spilder ikke dyrebar tid på dette. Produktiviteten blev understøttet, omend med kort søvn, og lækkerier med te - ingen energidrikke eller kaffe.”
Gemt under snittet er flere nyttige links, hvis du vil dykke ned i emnet tidsstyring. Det vil komme til nytte i hverdagen - tro forfatteren til dette indlæg, som altid kommer for sent :)
For tidens erobrere — Effektive tidsstyringsteknikker blev samlet i Netology-bloggen af en Kaspersky Lab-projektleder:
— En god artikel for begyndere om Cossa:
Prøv at skille dig ud
Ovenfor skrev vi om holdet, der lavede en uddeling for at beskytte projektet. De var de eneste i deres spor, og vi er sikre på, at der blandt de 3500+ deltagere ikke var andre som dem.
Selvfølgelig var dette ikke hovedårsagen til deres sejr, men det medførte bestemt et ekstra plus - i det mindste eksperternes sympati. Du kan skille dig ud på forskellige måder - nogle af vores vindere begynder hver forestilling med en joke om, hvordan de lavede en bombe (Sakharov-holdet, hej!).
Vi vil ikke dvæle ved dette i detaljer, men vil blot dele en sag fra PLEXeT-teamet - vi synes, det er værd at blive en joke om søn af en mors veninde.
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: "Vi indså, at vi var foran kurven og besluttede, at det ville være fedt at komme til forforsvaret med en transfersag. Projektet har en masse tekniske detaljer, forklaringer af algoritmer, som slet ikke indgår i præsentationen. Men jeg vil gerne vise det. Eksperter støttede ideen og hjalp endda med at optimere den. De så ikke engang på den første version; de sagde, at de aldrig ville læse sådan et maleri. Vi var de eneste i forsvaret."
Noget er nødt til at gå galt, og det er okay.
Ved et hackathon, som i det almindelige liv, er der altid plads til fejl. Selvom det ser ud til, at du har tænkt på alt, hvem af os er ikke kommet for sent til et fly/eksamen/bryllup, blot fordi bilerne besluttede at sidde fast i en bilkø, besluttede rulletrappen at bryde sammen, og passet blev glemt hjemme?
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: “Polina og jeg brugte hele natten på at lave en præsentation, men til sidst glemte de at uploade den på computeren i hallen, hvor forsvaret fandt sted. Vi forsøger at åbne den fra et flashdrev, og antivirusprogrammet opfatter filen som en virus og sletter den. Som et resultat lykkedes det at få det hele i gang kun et minut før afslutningen af vores forestilling. Vi nåede at vise videoen, men vi var stadig meget kede af det. En lignende historie skete for os under forforsvaret. Vores prototype startede ikke, Polinas og Levs computere frøs, og af en eller anden grund efterlod jeg min i hangaren, hvor vores bane sad. Og selvom eksperterne så vores arbejde om morgenen, lignede vi et team af excentrikere med en uddeling, smukke ord, men intet produkt. I betragtning af, at mange deltagere opfattede mit arbejde med matematiske modeller som "han sidder og tegner noget, ikke kigger på computeren", var situationen ikke særlig god.
Det vil lyde banalt, men alt du kan gøre i denne situation er at puste ud. Det er allerede sket. Nej, du er ikke den eneste, alle sviner til. Selvom dette er en fatal fejltagelse, er det en oplevelse. Og tænk også, vil den person, der vurderer dig, betragte denne sag som en fakap?
Del i kommentarerne, hvilken sammensætning du føler dig mest tryg ved at arbejde på et hackathon (både mennesker og specialister), og hvordan du bygger processer i et team.
Kilde: www.habr.com