Vilken typ av grupp brukar du gå på hackathons? Inledningsvis konstaterade vi att det ideala teamet består av fem personer - en chef, två programmerare, en designer och en marknadsförare. Men erfarenheterna från våra finalister visade att du kan vinna ett hackathon med ett litet team på tre personer. Av de 26 lag som vann finalen tävlade 3 och vann med musketörer. Hur de gjorde det – läs vidare.
Vi pratade med kaptenerna för alla tre lagen och insåg att deras strategi har mycket gemensamt. Hjältarna i det här inlägget är teamen PLEXeT (Stavropol, nominering av ministeriet för telekom och masskommunikation), "Composite Key" (Tula, nominering av ministeriet för information och kommunikation i Republiken Tatarstan) och Jingu Digital (Ekaterinburg, nominering av industri- och handelsministeriet). För den som är intresserad finns en kort beskrivning av kommandona gömd under katten.
KommandobeskrivningarPLEXeT
Teamet har tre personer - en utvecklare (webb, C++, informationssäkerhetskompetens), en designer och en chef. Vi kände inte varandra innan det regionala hackathonet. Laget sattes ihop av kaptenen baserat på resultaten av onlinetestning.
Kompositnyckel
Teamet har tre medutvecklare – fullstack med tio års erfarenhet av IT, backend och mobil, och backend med fokus på databaser.
Jingu Digital
Teamet består av två programmerare - backend och AR/Unity, samt en designer som även ansvarade för ledningen av teamet. Vann i nomineringen av industri- och handelsministeriet
Välj en uppgift som ligger nära dina kompetenser
Kommer du ihåg att det fanns en sådan ramsa "dramaklubb, fotoklubb, och jag vill också sjunga"? Jag tror att många känner till den här känslan - när allt runt omkring dig är intressant vill du visa dig på ett nytt sätt i din riktning, och prova en ny bransch/utvecklingsområde. Valet här beror bara på målen för ditt lag och viljan att ta risker – kan du acceptera ditt misstag om du plötsligt mitt under hackathonet inser att det är orealistiskt att lösa detta problem? Experiment i kategorin "Jag är inte bra på mobilutveckling, men vad fan är det?" är inte för alla. Är du den typen av amatör?
Artem Koshko (), kommandot "Kompositnyckel": ”Vi planerade först att prova något nytt. På det regionala stadiet provade vi flera nuget-paket, som vi aldrig kom över till, och Yandex.Cloud. I slutet distribuerade vi CockroachDB i Kubernetes och försökte rulla migreringar till den med EF Core. Vissa saker gick bra, andra inte så mycket. Så vi lärde oss nya saker, testade oss själva och försäkrade oss om tillförlitligheten hos beprövade metoder.".
Hur man väljer en uppgift om dina ögon vandrar:
- Fundera på vilka kompetenser som behövs för att lösa detta fall, och om alla teammedlemmar har dem
- Om du saknar kompetens, kan du kompensera för dem (kom på en annan lösning, lär dig snabbt något nytt)
- Gör en kort undersökning av marknaden som du kommer att göra en produkt för
- Räkna ut tävlingen - vilket spår/företag/uppgift kommer flest att gå på?
- Svara på frågan: vad kommer att driva dig mest?
Oleg Bakhtadze-Karnaukhov (), kommandot PLEXeT: "Vi fattade ett beslut om ett tio timmar långt uppehåll på flygplatsen - precis vid landningsögonblicket kom en lista med spår och korta uppgifter om uppgifter i vår post. Jag identifierade direkt fyra uppgifter som var intressanta för mig som programmerare och för vilka handlingsplanen efter starten var tydlig – vad som behöver göras och hur vi ska göra det. Sedan bedömde jag varje lagmedlems uppgifter och bedömde tävlingsnivån. Som ett resultat valde vi mellan uppgifterna för Gazprom och ministeriet för telekom och masskommunikation. Vår designers pappa jobbar med olja och gas, vi ringde honom och ställde frågor om branschen. Till slut insåg vi att ja, det är intressant, men vi kommer inte att kunna erbjuda något i grunden nytt och vi kommer definitivt inte att kunna matcha kompetenserna, eftersom det finns för många branschspecifika detaljer som måste beaktas konto. Till slut tog vi en risk och gick till första spåret.”
Diana Ganieva (), Jingu Digital-team: ”På det regionala skedet hade vi ett uppdrag relaterat till jordbruket, och vid finalen - AR/VR i industrin. De valdes ut av hela teamet så att varje person kunde inse sina förmågor. Sedan sårade vi bort det vi inte tyckte var så intressant."
Gör dina läxor
Och vi pratar inte om kodförberedelser nu – det är i allmänhet meningslöst att göra det. Det handlar om kommunikation inom teamet. Om ni inte har spelat tillsammans ännu, inte lärt er att förstå varandra och kommit överens, träffas ett par gånger i förväg och simulerar ett hackathon, eller åtminstone ring varandra för att prata igenom huvudpunkterna, tänk genom en handlingsplan, och diskutera varandras styrkor och svagheter. Du kan till och med hitta ett fall och försöka lösa det - åtminstone schematiskt, på nivån "hur man tar sig från punkt A till punkt B."
Under det här stycket riskerar vi att fånga minus i karma och kommentarer och säga, hur är det möjligt, du förstår ingenting, men hur är det med spänningen, drivkraften, känslan av att nu kommer en prototyp att födas ur det ursprungliga. buljong (hej, biologilektioner).
Ja men.
Improvisation och driv är bra bara när det bara blir en liten avvikelse från strategin – annars är riskerna för stora för att lägga tid på att städa upp i kaoset och rätta till misstag, istället för att jobba, äta eller sova.
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: "Jag kände inte någon av medlemmarna i mitt team före tävlingen; jag valde ut och bjöd in dem baserat på deras kompetens och bedömningar i teststadiet online. När vi vann det regionala hackathonet och insåg att vi fortfarande måste åka till Kazan tillsammans och avsluta hackathonprojektet i Stavropol, bestämde vi oss för att vi skulle samlas och träna. Inför finalen möttes vi två gånger – vi hittade ett slumpmässigt problem och löste det. Något som liknar ett case-mästerskap. Och redan i detta skede såg vi ett problem i kommunikation och distribution av uppgifter - medan Polina (designer) och Lev (chef) funderade på företagsstilen, produktegenskaper, letade efter marknadsdata, jag hade mycket fritid. Så vi insåg att vi behövde ta oss an en svårare nominering (jag skryter inte, vi stötte bara mest på uppgifter relaterade till webben, men för mig är det bara en eller två) och jag behöver vara mer involverad i arbetsprocesser . Som ett resultat, vid finalen, under den preliminära forskningen, var jag engagerad i matematisk modellering och utveckling av algoritmer.
Artem Koshko, Composite Key-teamet : "Vi förberedde oss mer mentalt, det var inget snack om att förbereda en kod. Vi hade redan tilldelat roller i teamet i förväg - vi tre är alla programmerare (vi har en full stack och två backends, plus att jag kan lite om mobilutveckling), men det var klart att någon skulle behöva ta på sig roller som designer och chef. Det var så jag, utan att jag visste det, blev en teamledare, försökte mig som affärsanalytiker, talare och presentationsmakare. Jag tror att om vi inte hade pratat om det här i förväg så hade vi inte kunnat hantera tiden på rätt sätt, och vi skulle inte ha tagit oss till slutförsvaret.”
Diana Ganieva, Jingu Digital: "Vi förberedde oss inte för hackathon, eftersom vi anser att hackprojekt bör göras från grunden - det är rättvist. I förväg, vid valet av spår, hade vi en allmän uppfattning om vad vi ville göra".
Du kan inte arbeta med utvecklare ensam
Diana Ganieva, Jingu Digital-team: ”Vi har tre specialister inom olika områden i vårt team. Enligt min mening är detta den idealiska kompositionen för ett hackathon. Alla är upptagna med sin egen verksamhet och det finns ingen överlappning eller arbetsfördelning. En person till skulle vara överflödig."
Statistik har visat att den genomsnittliga sammansättningen av våra team är från 4 till 5 personer, inklusive (i bästa fall) en designer. Det är allmänt accepterat att det är nödvändigt att stärka teamet med utvecklare av olika ränder - för att både kunna lägga till databasen och överraska med en "maskin" om något händer. I bästa fall tar de fortfarande med sig en designer (bli inte förolämpad, vi älskar dig!), presentationen och gränssnitten kommer inte att rita sig själva, till slut. Rollen som chef försummas ännu oftare - vanligtvis tas denna funktion på av lagkaptenen, en deltidsutvecklare.
Och detta är i grunden fel.
Artem Koshko, Composite Key-teamet: "Vid något tillfälle ångrade vi att vi inte tog med en specialiserad specialist till laget. Samtidigt som vi på något sätt kunde hantera designen var det svårt med affärsplanen och andra strategiska saker. Ett slående exempel är när det var nödvändigt att beräkna målgrupp och marknadsvolym, TAM, SAM.”
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: "Utvecklarens bidrag till produkten är långt ifrån 80% av arbetet, som man brukar tro. Det kan inte sägas att det var lättare för killarna – nästan hela huvuddelen av uppgifterna låg hos dem. Min kod utan gränssnitt, presentationer, videor, strategier är bara en uppsättning symboler. Om det hade funnits fler utvecklare i teamet istället för dem hade vi förmodligen klarat det, men allt hade sett mindre professionellt ut. Speciellt presentationen är i allmänhet halva framgången, som det verkar för mig. Under försvaret och sedan i verkligheten om ett par minuter kommer ingen att hinna förstå om din prototyp verkligen fungerar. Om du rycker med planer kommer ingen att lyssna på dig. Om du går för långt med texten kommer alla att förstå att du själv inte vet vad som är viktigt i din produkt, hur du ska presentera den och vem som behöver den.”
Tidshantering och avkoppling
Kommer du ihåg hur karaktärerna i barndomstecknade serier som "Tom och Jerry" satte tändstickor under ögonlocken för att hindra dem från att stängas? Oerfarna (eller alltför entusiastiska) hackathondeltagare ser ungefär likadana ut.
På ett hackathon är det lätt att tappa kontakten med verkligheten och en känsla av tid - atmosfären bidrar till otyglad kodning utan pauser för vila, sömn, busa i spelrummet, kommunicera med partners eller gå på mästarklasser. Om du behandlar detta som världsmästerskapen eller OS, så ja, det kanske är så du ska bete dig. Inte riktigt.
Artem Koshko, Composite Key-teamet: "Vi hade mycket chak-chak, mycket - ett torn av det byggdes mitt på vårt bord, det höll vår moral uppe och gav oss kolhydrater vid rätt tidpunkt. Vi vilade och jobbade nästan hela tiden tillsammans, och vilade inte var för sig. Men de sov annorlunda. Andrey (fullstack-utvecklare) gillar att sova på dagen, Denis och jag gillar att sova på natten. Därför arbetade jag mer med Denis på dagen och med Andrey på natten. Och han sov på rasterna. Vi hade inget system för att arbeta eller sätta uppgifter, snarare var allt spontant. Men detta störde oss inte, eftersom vi förstår varandra väl och kompletterar varandra. Det hjälpte att vi är kollegor och kommunicerar nära. Jag är Andreys tidigare praktikant och Denis kom till företaget som min praktikant.”
Och här är förresten samma chak-chak berg.
Nästan alla deltagare vi intervjuade utnämnde kompetent tidshantering som huvudkriteriet för framgång på hackathon. Vad betyder det? Du fördelar uppgifter så att du hinner med sömn och mat och uppgifter genomförs inte på ett vanligt sätt. allt kollapsade, men i en takt som är bekväm för varje gruppmedlem.
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet"Vårt mål var inte att arbeta så många timmar som möjligt, utan att vara produktiv så länge som möjligt. Trots att vi sov 3-4 timmar om dagen så verkade vi lyckas. Vi kunde gå till spelrummet eller hänga i våra partners bås och avsätta normal tid för mat. Andra dagen försökte vi avlasta Lev så mycket som möjligt så att han kunde få tillräckligt med sömn och hinna göra ordning på sig själv inför föreställningen. Hackathonrepetitionerna hjälpte oss, eftersom vi redan förstod hur vi skulle fördela uppgifter, och synkroniseringen av den dagliga rutinen - vi åt, sov och var vakna på samma gång. Som ett resultat fungerade de som en enda mekanism."
Vi vet inte hur det här laget lyckades få Agomotos öga till hackathonet, men till slut lyckades de till och med spela in en video om projektet och förbereda en handout.
Några tips för tidshantering på ett hackathon:
- Gå från stort till litet – dela upp uppgifter i små block.
- Ett hackathon är ett maraton. Vad är det viktigaste på ett maraton? Försök att springa i samma takt, annars faller du av vid slutet av sträckan. Försök att arbeta med ungefär samma intensitet och inte pressa dig själv till utmattning.
- Tänk i förväg vad som kommer att vara varje deltagares uppgifter och hur mycket tid det kommer att ta honom. Det hjälper dig att undvika överraskningar när deadline är en halvtimme bort och du inte har ett stort arbete redo.
- Kontrollera koordinaterna för att justera uppgifternas omfattning. Känner du att du mår bra och till och med har tid över? Fantastiskt - du kan spendera det på att sova eller slutföra din presentation.
- Häng dig inte i detaljer, arbeta i stora drag.
- Det är svårt att ta en paus från jobbet, så avsätt tid specifikt för sömn, avkoppling eller avkoppling. Du kan till exempel ställa in larm.
- Ta dig tid att förbereda och repetera ditt tal. Detta är obligatoriskt för alla och alltid. Vi pratade om detta i en av de tidigare .
Och det finns också denna alternativa åsikt. Vilket alternativ är du för - tortyr genom kodning eller krig med krig, och lunch enligt ett schema?
Diana Ganieva, Jingu Digital-team: "Varje person i vårt team är ansvarig för en sak, det fanns ingen som ersatte oss, så vi kunde inte arbeta i skift. När det absolut inte fanns några krafter kvar sov vi i tre timmar, beroende på hur mycket arbete som fortfarande återstod för deltagaren. Det fanns absolut ingen tid att umgås, vi slösar inte dyrbar tid på detta. Produktiviteten stöddes, om än med kort sömn, och godsaker med te - inga energidrycker eller kaffe.”
Gömda under snittet finns flera användbara länkar om du vill dyka in i ämnet tidshantering. Det kommer väl till pass i vardagen - tro författaren till detta inlägg, som alltid är sen :)
För tidens erövrare — Effektiva tidshanteringstekniker samlades in i Netology-bloggen av en projektledare från Kaspersky Lab:
— En bra artikel för nybörjare om Cossa:
Försök att sticka ut
Ovan skrev vi om teamet som gjorde en utdelning för att skydda projektet. De var de enda i deras spår, och vi är säkra på att bland de 3500+ deltagarna fanns det inga andra som dem.
Naturligtvis var detta inte huvudorsaken till deras seger, men det gav definitivt ett extra plus - åtminstone experternas sympati. Du kan sticka ut på olika sätt - några av våra vinnare inleder varje föreställning med ett skämt om hur de gjorde en bomb (Sakharov-teamet, hej!).
Vi kommer inte att uppehålla oss i detalj, utan kommer helt enkelt att dela ett fall från PLEXeT-teamet - vi tycker att det är värt att bli ett skämt om sonen till en mammas vän.
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: "Vi insåg att vi var före kurvan och bestämde oss för att det skulle vara coolt att komma till försvaret med ett transferfall. Projektet har en hel del tekniska detaljer, förklaringar av algoritmer, som inte alls ingår i presentationen. Men jag vill visa det. Experter stödde idén och hjälpte till med att optimera den. De tittade inte ens på den första versionen, de sa att de aldrig skulle läsa en sådan målning. Vi var de enda i försvaret."
Något måste gå fel, och det är okej.
På ett hackathon, som i det vanliga livet, finns det alltid utrymme för misstag. Även om det verkar som att du har tänkt på allt, vem av oss har inte kommit för sent till ett flyg/tenta/bröllop bara för att bilarna bestämde sig för att fastna i en bilkö, så bestämde sig rulltrappan för att gå sönder, och passet glömdes bort hemma?
Oleg Bakhtadze-Karnaukhov, PLEXeT-teamet: ”Polina och jag tillbringade hela natten med att göra en presentation, men till slut glömde de att ladda upp den på datorn i hallen där försvaret ägde rum. Vi försöker öppna den från en flashenhet, och antivirusprogrammet uppfattar filen som ett virus och tar bort den. Som ett resultat lyckades vi få igång allt bara en minut före slutet av vår föreställning. Vi lyckades visa videon, men vi var fortfarande väldigt upprörda. En liknande historia hände oss under försvaret. Vår prototyp startade inte, Polinas och Levs datorer frös, och av någon anledning lämnade jag min i hangaren där vår bana satt. Och även om experterna såg vårt arbete på morgonen, såg vi ut som ett team av excentriker med en utdelning, vackra ord, men ingen produkt. Med tanke på att många deltagare uppfattade mitt arbete med matematiska modeller som "han sitter och ritar något, inte tittar på datorn", var situationen inte särskilt bra.
Det kommer att låta korkat, men allt du kan göra i den här situationen är att andas ut. Det har redan hänt. Nej, du är inte den enda, alla tjatar. Även om detta är ett ödesdigert misstag så är det en upplevelse. Och tänk också, kommer personen som utvärderar dig att betrakta det här fallet som en fakap?
Dela i kommentarerna vilken sammansättning du känner dig mest bekväm med att arbeta på ett hackathon (både människor och specialister) och hur du bygger processer i ett team.
Källa: will.com