Hva slags gruppe pleier du å delta på hackathons? Innledningsvis uttalte vi at det ideelle teamet består av fem personer - en leder, to programmerere, en designer og en markedsfører. Men erfaringene til finalistene våre viste at du kan vinne et hackathon med et lite team på tre personer. Av de 26 lagene som vant finalen, konkurrerte 3 og vant med musketerer. Hvordan de gjorde det – les videre.
Vi snakket med kapteinene på alle tre lagene og innså at strategien deres har mye til felles. Heltene i dette innlegget er lagene PLEXeT (Stavropol, nominasjon av departementet for telekom og massekommunikasjon), "Composite Key" (Tula, nominasjon av departementet for informasjon og kommunikasjon i Republikken Tatarstan) og Jingu Digital (Ekaterinburg, nominasjon av Nærings- og handelsdepartementet). For de som er interessert, er en kort beskrivelse av kommandoene gjemt under katten.
KommandobeskrivelserPLEXeT
Teamet har tre personer – en utvikler (web, C++, informasjonssikkerhetskompetanse), en designer og en leder. Vi kjente ikke hverandre før det regionale hackathonet. Laget ble satt sammen av kapteinen basert på resultatene av online testing.
Sammensatt nøkkel
Teamet har tre medutviklere – fullstack med ti års erfaring innen IT, backend og mobil, og backend med fokus på databaser.
Jingu Digital
Teamet består av to programmerere – backend og AR/Unity, samt en designer som også var ansvarlig for ledelsen av teamet. Vant i nominasjonen av Nærings- og handelsdepartementet
Velg en oppgave som er nær din kompetanse
Husker du at det var et slikt rim "dramaklubb, fotoklubb, og jeg vil også synge"? Jeg tror at mange er kjent med denne følelsen - når alt rundt deg er interessant, vil du vise deg selv på en ny måte i din retning, og prøve ut en ny bransje/utviklingsområde. Valget her avhenger kun av teamets mål og vilje til å ta risiko – kan du akseptere feilen din hvis du plutselig midt i hackathonet innser at det er urealistisk å løse dette problemet? Eksperimenter i kategorien «Jeg er ikke god på mobilutvikling, men hva i helvete er det?» er ikke for alle. Er du den typen amatør?
Artem Koshko (), kommandoen "Sammensatt nøkkel": – Vi planla først å prøve noe nytt. På den regionale scenen prøvde vi flere nuget-pakker, som vi aldri kom til, og Yandex.Cloud. På slutten distribuerte vi CockroachDB i Kubernetes og prøvde å rulle migreringer til den ved hjelp av EF Core. Noen ting gikk bra, andre ikke så mye. Så vi lærte nye ting, testet oss selv og forsikret oss om påliteligheten til velprøvde tilnærminger.».
Hvordan velge en oppgave hvis øynene dine vandrer:
- Tenk på hvilken kompetanse som trengs for å løse denne saken, og om alle teammedlemmene har den
- Hvis du mangler kompetanse, kan du kompensere for dem (finne på en annen løsning, raskt lære noe nytt)
- Gjennomfør en kort undersøkelse av markedet du skal lage et produkt for
- Beregn konkurransen - hvilket spor/firma/oppgave vil flest gå til?
- Svar på spørsmålet: hva vil drive deg mest?
Oleg Bakhtadze-Karnaukhov (), PLEXeT-kommandoen: «Vi tok en avgjørelse om en ti-timers pause på flyplassen - akkurat i landingsøyeblikket kom en liste over spor og korte oppgaveoppgaver i posten vår. Jeg identifiserte umiddelbart fire oppgaver som var interessante for meg som programmerer og som handlingsplanen etter oppstart var klar for – hva som må gjøres og hvordan vi skal gjøre det. Deretter vurderte jeg oppgavene til hvert lagmedlem og vurderte konkurransenivået. Som et resultat valgte vi mellom oppgavene til Gazprom og departementet for tele- og massekommunikasjon. Designerens far jobber innen olje og gass; vi ringte ham og stilte ham spørsmål om bransjen. Til slutt innså vi at ja, det er interessant, men vi vil ikke kunne tilby noe fundamentalt nytt, og vi vil definitivt ikke kunne matche kompetansen, fordi det er for mange bransjespesifikasjoner som må tas inn i regnskap. Til slutt tok vi en risiko og gikk til første spor.»
Diana Ganieva (), Jingu Digital-team: «På det regionale stadiet hadde vi en oppgave knyttet til landbruk, og på finalen - AR/VR i industri. De ble valgt av hele teamet slik at hver person kunne realisere sine evner. Så luket vi ut det vi ikke fant så interessant.»
Gjør leksene dine
Og vi snakker ikke om kodeforberedelse nå - det er generelt meningsløst å gjøre det. Det handler om kommunikasjon i teamet. Hvis dere ikke har spilt sammen ennå, ikke har lært å forstå hverandre og kommet til enighet, kom sammen et par ganger på forhånd og simuler et hackathon, eller i det minste ring hverandre for å snakke gjennom hovedpunktene, tenk gjennom en handlingsplan, og diskuter hverandres styrker og svakheter. Du kan til og med finne en sak og prøve å løse den - i det minste skjematisk, på nivået "hvordan komme fra punkt A til punkt B."
I løpet av denne paragrafen risikerer vi å fange minuser i karma og kommentarer, og si, hvordan er det mulig, du forstår ingenting, men hva med spenningen, drivkraften, følelsen av at nå vil en prototype bli født fra det opprinnelige buljong (hei, biologitimer).
Ja men.
Improvisasjon og driv er bra først når det bare blir et lite avvik fra strategien – ellers er risikoen for stor til å bruke tid på å rydde opp i kaoset og rette opp feil, i stedet for å jobbe, spise eller sove.
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: "Jeg kjente ingen av medlemmene i teamet mitt før konkurransen; jeg valgte og inviterte dem basert på deres kompetanse og vurderinger på teststadiet på nett. Da vi vant det regionale hackathonet og innså at vi fortsatt måtte til Kazan sammen og fullføre hackathonprosjektet i Stavropol, bestemte vi oss for at vi skulle samles og trene. Før finalen møttes vi to ganger – vi fant et tilfeldig problem og løste det. Noe som et case-mesterskap. Og allerede på dette stadiet så vi et problem i kommunikasjon og fordeling av oppgaver - mens Polina (designer) og Lev (leder) tenkte på bedriftsstilen, produktfunksjonene, på jakt etter markedsdata, hadde jeg mye fritid. Så vi skjønte at vi trengte å ta på oss en vanskeligere nominasjon (jeg skryter ikke, vi kom bare stort sett over oppgaver knyttet til nettet, men for meg er det bare en eller to) og jeg må være mer involvert i arbeidsprosesser . Som et resultat, på finalen, under den foreløpige forskningen, var jeg engasjert i matematisk modellering og utvikling av algoritmer.
Artem Koshko, Composite Key-teamet : "Vi forberedte oss mer mentalt; det var ikke snakk om å utarbeide en kode. Vi hadde allerede tildelt roller i teamet på forhånd - vi tre er alle programmerere (vi har en full stack og to backends, pluss at jeg kan litt om mobilutvikling), men det var klart at noen måtte ta på seg rollene som designer og leder. Det var slik, uten at jeg visste det, jeg ble en teamleder, prøvde meg som forretningsanalytiker, foredragsholder og presentasjonsmaker. Jeg tror at hvis vi ikke hadde snakket om dette på forhånd, ville vi ikke vært i stand til å disponere tiden riktig, og vi ville ikke ha kommet oss til sluttforsvaret.
Diana Ganieva, Jingu Digital: "Vi forberedte oss ikke på hackathon, fordi vi mener at hack-prosjekter bør lages fra bunnen av - det er rettferdig. På forhånd, på stadiet med valg av spor, hadde vi et generelt konsept om hva vi ønsket å gjøre.".
Du kan ikke jobbe med utviklere alene
Diana Ganieva, Jingu Digital-teamet: «Vi har tre spesialister på forskjellige felt i teamet vårt. Etter min mening er dette den ideelle komposisjonen for et hackathon. Alle er opptatt med egen virksomhet og det er ingen overlapping eller oppgavefordeling. En person til ville være overflødig."
Statistikk har vist at den gjennomsnittlige sammensetningen av teamene våre er fra 4 til 5 personer, inkludert (i beste fall) én designer. Det er generelt akseptert at det er nødvendig å styrke teamet med utviklere av forskjellige striper - for å kunne både legge til databasen og overraske med en "maskin" hvis noe skjer. I beste fall tar de fortsatt med seg en designer (ikke bli fornærmet, vi elsker deg!), presentasjonen og grensesnittene vil ikke tegne seg selv til slutt. Rollen som leder neglisjeres enda oftere - vanligvis overtas denne funksjonen av lagkapteinen, en deltidsutvikler.
Og dette er grunnleggende feil.
Artem Koshko, Composite Key-teamet: «På et tidspunkt angret vi på at vi ikke tok med en spesialisert spesialist på laget. Selv om vi på en eller annen måte klarte å takle designet, var det vanskelig med forretningsplanen og andre strategiske ting. Et slående eksempel er når det var nødvendig å beregne målgruppe og markedsvolum, TAM, SAM.»
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: «Utviklerens bidrag til produktet er langt fra 80 % av arbeidet, som man ofte tror. Det kan ikke sies at det var lettere for gutta – nesten hele hoveddelen av oppgavene lå hos dem. Koden min uten grensesnitt, presentasjoner, videoer, strategier er bare et sett med symboler. Hvis det hadde vært flere utviklere på laget i stedet for dem, hadde vi nok klart det, men alt hadde sett mindre profesjonelt ut. Spesielt presentasjonen er generelt halve suksessen, slik det virker for meg. Under forsvaret og deretter i det virkelige liv om et par minutter, vil ingen ha tid til å forstå om prototypen din virkelig fungerer. Hvis du lar deg rive med av ordninger, vil ingen høre på deg. Hvis du går for langt med teksten, vil alle forstå at du selv ikke vet hva som er viktig i produktet ditt, hvordan du skal presentere det og hvem som trenger det.»
Tidsstyring og avslapning
Husker du hvordan karakterene i barndoms tegneserier som "Tom og Jerry" la fyrstikker under øyelokkene for å hindre dem i å lukke seg? Uerfarne (eller altfor entusiastiske) hackathon-deltakere ser omtrent like ut.
På et hackathon er det lett å miste kontakten med virkeligheten og en følelse av tid - atmosfæren bidrar til uhemmet koding uten pauser for hvile, søvn, tulling i spillrommet, kommunikasjon med partnere eller delta på mesterklasser. Hvis du behandler dette som verdensmesterskapet eller OL, så ja, kanskje det er slik du bør oppføre deg. Ikke egentlig.
Artem Koshko, Composite Key-teamet: "Vi hadde mye chak-chak, mye - et tårn av det ble bygget midt på bordet vårt, det holdt moralen oppe og ga oss karbohydrater til rett tid. Vi hvilte og jobbet nesten hele tiden sammen, og hvilte ikke hver for seg. Men de sov annerledes. Andrey (fullstack-utvikler) liker å sove på dagtid, Denis og jeg liker å sove om natten. Derfor jobbet jeg mer med Denis om dagen, og med Andrey om natten. Og han sov i pausene. Vi hadde ikke noe system for arbeid eller setting av oppgaver; snarere var alt spontant. Men dette plaget oss ikke, for vi forstår hverandre godt og utfyller hverandre. Det hjalp at vi er kollegaer og kommuniserer tett. Jeg er Andreys tidligere praktikant, og Denis kom til selskapet som min praktikant.»
Og her er forresten det samme chak-chak-fjellet.
Nesten alle deltakerne vi intervjuet nevnte kompetent tidsstyring som hovedkriteriet for suksess på hackathon. Hva betyr det? Du fordeler oppgaver slik at du får tid til søvn og mat, og oppgaver blir ikke gjennomført på en vanlig måte. alt kollapset, men i et tempo som er behagelig for hvert lagmedlem.
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet'Målet vårt var ikke å jobbe så mange timer som mulig, men å være produktive så lenge som mulig. Selv om vi sov 3-4 timer i døgnet, så vi ut til å lykkes. Vi kunne gå til spillrommet eller henge på standene til partnerne våre og sette av normal tid til mat. Den andre dagen prøvde vi å avlaste Lev så mye som mulig slik at han kunne få nok søvn og få tid til å ordne seg før forestillingen. Hackathon-øvelsene hjalp oss, siden vi allerede forsto hvordan vi skulle fordele oppgaver, og synkroniseringen av den daglige rutinen - vi spiste, sov og var våkne samtidig. Som et resultat fungerte de som en enkelt mekanisme."
Vi vet ikke hvordan dette teamet klarte å få Agomotos øye til hackathonet, men til slutt klarte de til og med å filme en video om prosjektet og utarbeide en utdeling.
Noen tips for tidsstyring på et hackathon:
- Gå fra stort til lite – del opp oppgaver i små blokker.
- Et hackathon er et maraton. Hva er det viktigste i et maraton? Prøv å løpe i samme tempo, ellers faller du av ved slutten av distansen. Prøv å jobbe med omtrent samme intensitet og ikke presse deg selv til punktet av utmattelse.
- Tenk på forhånd hva som vil være oppgavene til hver deltaker og hvor mye tid det vil ta ham. Det vil hjelpe deg å unngå overraskelser når fristen er en halvtime unna og du ikke har et stort stykke arbeid klart.
- Sjekk koordinatene for å justere omfanget av oppgaver. Føler du at du har det bra og til og med har tid igjen? Flott - du kan bruke den på å sove eller fullføre presentasjonen.
- Ikke heng deg opp i detaljer, jobb i store trekk.
- Det er vanskelig å ta en pause fra jobben, så sett av tid spesielt til søvn, avslapning eller avslapning. Du kan for eksempel stille inn alarmer.
- Ta deg tid til å forberede og øve på talen din. Dette er obligatorisk for alle og alltid. Vi snakket om dette i en av de forrige .
Og det er også denne alternative oppfatningen. Hvilket alternativ er du for - tortur ved koding eller krig med krig, og lunsj på timeplan?
Diana Ganieva, Jingu Digital-teamet: "Hver person i teamet vårt er ansvarlig for én ting, det var ingen som erstattet oss, så vi kunne ikke jobbe i skift. Når det absolutt ikke var krefter igjen, sov vi i tre timer, avhengig av hvor mye arbeid som fortsatt gjensto for deltakeren. Det var absolutt ingen tid til å henge, vi kaster ikke bort dyrebar tid på dette. Produktiviteten ble støttet, om enn med kort søvn, og godbiter med te – ingen energidrikker eller kaffe.»
Skjult under kuttet er flere nyttige lenker hvis du ønsker å dykke ned i temaet tidsstyring. Det kommer godt med i hverdagen - tro forfatteren av dette innlegget, som alltid kommer for sent :)
For tidens erobrere — Effektive tidsstyringsteknikker ble samlet i Netology-bloggen av en prosjektleder fra Kaspersky Lab:
— En god artikkel for nybegynnere på Cossa:
Prøv å skille deg ut
Ovenfor skrev vi om teamet som laget en utdeling for å beskytte prosjektet. De var de eneste i sporet sitt, og vi er sikre på at blant de 3500+ deltakerne var det ingen som dem.
Selvfølgelig var dette ikke hovedårsaken til seieren deres, men det ga definitivt et ekstra pluss - i det minste sympatien til eksperter. Du kan skille deg ut på forskjellige måter - noen av vinnerne våre begynner hver forestilling med en vits om hvordan de laget en bombe (Sakharov-teamet, hei!).
Vi vil ikke dvele ved dette i detalj, men vil ganske enkelt dele en sak fra PLEXeT-teamet - vi synes det er verdig å bli en spøk om sønnen til en mors venn.
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: «Vi innså at vi var i forkant og bestemte oss for at det ville være kult å komme til forhåndsforsvaret med en overgangssak. Prosjektet har mange tekniske detaljer, forklaringer av algoritmer, som ikke er inkludert i presentasjonen i det hele tatt. Men jeg vil vise det. Eksperter støttet ideen og hjalp til og med med å optimalisere den. De så ikke engang på den første versjonen; de sa at de aldri ville lese et slikt maleri. Vi var de eneste i forsvar.»
Noe er nødt til å gå galt, og det er greit.
På et hackathon, som i det vanlige livet, er det alltid rom for feil. Selv om det virker som du har tenkt på alt, hvem av oss har ikke kommet for sent til fly/eksamen/bryllup bare fordi bilene bestemte seg for å sette seg fast i en trafikkork, bestemte rulletrappen seg for å bryte sammen, og passet ble glemt hjemme?
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: «Polina og jeg brukte hele natten på å lage en presentasjon, men til slutt glemte de å laste den opp på datamaskinen i hallen der forsvaret fant sted. Vi prøver å åpne den fra en flash-stasjon, og antiviruset oppfatter filen som et virus og sletter den. Som et resultat klarte vi å få alt i gang bare et minutt før slutten av forestillingen vår. Vi klarte å vise videoen, men vi var fortsatt veldig opprørte. En lignende historie skjedde med oss under forhåndsforsvaret. Prototypen vår startet ikke, Polinas og Levs datamaskiner frøs, og av en eller annen grunn la jeg min i hangaren der banen vår sto. Og selv om ekspertene så arbeidet vårt om morgenen, så vi ut som et team av eksentrikere med en utdeling, vakre ord, men ingen produkt. Tatt i betraktning at mange deltakere oppfattet arbeidet mitt med matematiske modeller som «han sitter, tegner noe, ikke ser på datamaskinen», var situasjonen ikke særlig god.
Det vil høres banalt ut, men alt du kan gjøre i denne situasjonen er å puste ut. Det har allerede skjedd. Nei, du er ikke den eneste, alle svir. Selv om dette er en fatal feil, er det en opplevelse. Og tenk også, vil personen som vurderer deg vurdere denne saken som en fakap?
Del i kommentarene hvilken sammensetning du føler deg mest komfortabel med å jobbe på et hackathon (både mennesker og spesialister) og hvordan du bygger prosesser i et team.
Kilde: www.habr.com