I december förra året höll vi vårt eget startup hackathon med sex andra Skolkovo-företag. Utan företagssponsorer eller något externt stöd samlade vi tvåhundra deltagare från 20 städer i Ryssland genom insatser från programmeringsgemenskapen. Nedan ska jag berätta hur vi lyckades, vilka fallgropar vi stötte på på vägen och varför vi direkt började samarbeta med ett av de vinnande lagen.
Gränssnitt för applikationen som styr Watts batterimoduler från finalisterna på banan, "Wet Hair"
företaget
Vårt företag Watts Battery skapar modulära bärbara kraftverk. Produkten är en bärbar kraftstation 46x36x11 cm, kapabel att leverera från 1,5 till 15 kilowatt per timme. Fyra sådana moduler kan ge energiförbrukningen för ett litet hus på landet i två dagar.
Även om vi började skicka produktionsprover förra året, är Watts Battery av allt att döma en startup. Företaget grundades 2016 och har sedan samma år varit bosatt i Skolkovo Energy Efficient Technologies Cluster. Idag har vi 15 anställda och en enorm eftersläpning av saker som vi skulle vilja göra någon gång, men just nu finns det ingen dags för det.
Detta inkluderar även rena mjukvaruuppgifter. Varför?
Modulens huvuduppgift är att tillhandahålla oavbruten, balanserad energiförsörjning till en optimal kostnad. Om du upplever ett strömavbrott på grund av orsaker utanför din kontroll, bör du alltid ha en reserv för att fullt ut kunna driva den erforderliga nätverksbelastningen under hela avbrottet. Och när strömförsörjningen är bra kan du använda solenergi för att spara pengar.
Det enklaste alternativet är att du kan ladda batteriet från solen under dagen och använda det på kvällen, men exakt till den nivå som är nödvändig för att du i händelse av strömavbrott inte ska bli utan el. Så du kommer aldrig att hamna i en situation där du drev belysningen från ett batteri hela kvällen (eftersom det är billigare), men på natten slocknade elen och ditt kylskåp tinades upp.
Det är tydligt att en person sällan kan förutsäga med stor noggrannhet hur mycket el han behöver, men ett system beväpnat med en prediktiv modell kan. Därför är maskininlärning som sådan ett av våra prioriterade områden. Det är bara det att vi för närvarande fokuserar på hårdvaruutveckling och kan inte allokera tillräckligt med resurser till dessa uppgifter, vilket är det som förde oss till Startup Hackathon.
Förberedelser, data, infrastruktur
Som ett resultat tog vi två spår: dataanalys och ledningssystem. Utöver vårt fanns det ytterligare sju spår från kollegor.
Även om formatet för hackathonet inte var fastställt, tänkte vi skapa "vår egen atmosfär", med ett poängsystem: deltagarna gör några saker som verkar svåra och intressanta för oss och får poäng för det. Vi hade många uppgifter. Men när vi byggde upp strukturen för hackathon bad andra arrangörer att få allt till en gemensam form, vilket vi gjorde.
Sedan kom vi till följande schema: killarna gör en modell baserat på deras data, sedan får de vår data, som modellen inte hade sett tidigare, den lär sig och börjar förutsäga. Det antogs att allt detta kunde göras på 48 timmar, men för oss var detta det första hackathonet på vår data, och vi kan ha överskattat tidsresurserna eller graden av beredskap för datan. Vid specialiserade hackathon för maskininlärning skulle en sådan tidslinje vara normen, men vår var inte så.
Vi laddade av modulens mjukvara och hårdvara så mycket som möjligt, och gjorde en version av vår enhet specifikt för hackathon, med ett mycket enkelt och begripligt internt gränssnitt som alla utvecklare kunde stödja.
För banan baserad på styrsystemet fanns en möjlighet att göra en mobilapplikation. För att förhindra att deltagarna tjafsar om hur det ska se ut och slösar bort extra tid, gav vi dem en designlayout av applikationen, superlätt, så att de som vill ha den helt enkelt kan "sträcka ut" de funktioner de behöver på den . För att vara ärlig förväntade vi oss inga moraliska dilemman här, men ett av teamen tog det på ett sådant sätt att vi begränsade deras fantasi, vi ville få en färdig lösning gratis och inte testa dem i praktiken. Och de lyfte.
Ett annat team valde att göra en helt annan ansökan från grunden, och allt löste sig. Vi insisterade inte på att applikationen skulle vara exakt så här, vi behövde bara innehålla några element som visar lösningens tekniska nivå: grafer, analyser, etc. Den färdiga designlayouten var också en antydan.
Eftersom att analysera en levande Watts-batterimodul vid ett hackathon skulle vara för tidskrävande, gav vi deltagarna en färdig del av data för en månad hämtad från våra kunders riktiga moduler (som vi noggrant anonymiserade i förväg). Eftersom det var juni fanns det inget att ta med säsongsförändringar i analysen. Men i framtiden kommer vi att lägga till externa data till dem, såsom säsongs- och klimategenskaper (idag är detta industristandarden).
Vi ville inte skapa orealistiska förväntningar bland deltagarna, så i tillkännagivandet av hackathonet sa vi direkt: arbetet kommer att ligga så nära fältarbetet som möjligt: bullriga, smutsiga data, som ingen speciellt förberedde. Men detta hade också en positiv sida: i den agila andan var vi ständigt i kontakt med deltagarna och gjorde omgående ändringar i uppgiften och antagningsvillkoren (mer om detta nedan).
Dessutom gav vi deltagarna tillgång till Amazon AWS (så aktivt att Amazon blockerade en region åt oss, vi kommer att ta reda på vad vi ska göra åt det). Där kan du distribuera infrastruktur för Internet of Things och, baserat på till och med enkla Amazon-mallar, skapa en fullfjädrad lösning inom en dag. Men i slutändan gick absolut alla sin egen väg och gjorde allt på egen hand maximalt. Samtidigt lyckades vissa hålla tidsgränsen, andra inte. Ett team, Nubble, använde Yandex.cloud, någon tog upp det på sin värd. Vi var till och med redo att ge domäner (vi har registrerade sådana), men de var inte användbara.
För att avgöra vinnarna i det analytiska spåret planerade vi att jämföra resultaten, för vilka vi utarbetade numeriska mätvärden. Men i slutändan var det inte nödvändigt att göra detta, eftersom tre av de fyra deltagarna av olika anledningar inte nådde finalen.
När det gäller hushållsinfrastrukturen hjälpte Skolkovo Technopark till här genom att förse oss (gratis) med ett av sina mysiga modulrum med en videovägg för presentationer och ett par mindre rum för ett rekreationsområde och för att organisera catering.
Analytics
Uppgift: ett självlärande system som identifierar anomalier i förbrukning och moduldrift baserat på kontrolldata. Vi höll medvetet formuleringen så generell som möjligt så att deltagarna kunde arbeta tillsammans med oss för att fundera över vad som kunde göras utifrån tillgänglig data.
Specificitet: Det mer komplexa av de två spåren. Industriell data har vissa skillnader från data i slutna system (till exempel digital marknadsföring). Här måste du förstå den fysiska karaktären av parametrarna som du försöker analysera; att se på allt som abstrakta nummerserier kommer inte att fungera. Till exempel fördelningen av elförbrukningen under dygnet. Det är som ritualer: den elektriska rakhyveln slås på på morgonen på vardagar och mixern på helgerna. Sedan själva essensen av anomalierna. Och glöm inte att Watts-batteriet är avsett för personligt bruk, så varje klient kommer att ha sina egna ritualer, och en universell modell kommer inte att fungera. Att hitta kända anomalier i data är inte ens en uppgift; att skapa ett system som autonomt söker efter omärkta anomalier är en annan sak. När allt kommer omkring kan allt vara en anomali, inklusive den lömska mänskliga faktorn. Till exempel, i våra testdata fanns det ett fall där systemet tvingades av användaren till batteriläge. Utan någon anledning gör användare ibland detta (jag reserverar mig för att den här användaren testar modulen åt oss och det är av denna anledning som han har tillgång till manuell kontroll av lägen; för andra användare är kontrollen helt automatisk). Som är lätt att förutsäga, i en sådan situation laddas batteriet ur ganska aktivt, och om belastningen är stor kommer laddningen att sluta innan solen går upp eller en annan energikälla dyker upp. I sådana fall förväntar vi oss att se någon form av meddelande om att systemets beteende har avvikit från det normala. Eller så gick personen och glömde stänga av ugnen. Systemet ser att vanligtvis vid den här tiden på dagen är förbrukningen 500 watt, men idag - 3,5 tusen - en anomali! Som Denis Matsuev på planet: "Jag förstår ingenting om flygplansmotorer, men på vägen dit lät motorn annorlunda."
Graf över en prediktiv modell på det neurala nätverket Yandex CatBoost med öppen källkod
Vad behöver företaget egentligen?: självdiagnostiskt system inuti enheten, prediktiv analys, inklusive utan nätverksinfrastruktur (som praxis visar, har inte alla våra kunder bråttom att ansluta batterier till Internet - för de flesta räcker det för att allt bara fungerar tillförlitligt), identifiering av anomalier, vars natur vi ännu inte känner till, ett självlärande system utan lärare, klustring, neurala nätverk och hela arsenalen av moderna analytiska metoder. Vi måste förstå att systemet började bete sig annorlunda, även om vi inte vet exakt vad som har förändrats. På själva hackathonet var det väldigt viktigt för oss att se att det finns killar som är redo att kliva in i industriell analys eller redan är med i det, och de letar efter nya områden för att tillämpa sina förmågor. Först blev jag förvånad över att det var så många sökande: trots allt är det här ett väldigt specifikt kök, men efterhand hoppade alla utom en av de fyra deltagarna av så till viss del föll allt på plats.
Varför är det inte genomförbart i detta skede?: Det största problemet med datautvinningsuppgifter är inte tillräckligt med data. Det finns flera dussin Watts batterienheter i drift runt om i världen idag, men många av dem är inte anslutna till nätverket, så vår data är ännu inte särskilt mångsidig. Vi skrapade knappt ihop två anomalier - och de inträffade på prototyper; industriellt Watts-batteri fungerar ganska stabilt. Om vi hade en intern maskininlärningsingenjör, och vi visste - ja, detta kan pressas ut ur denna data, men vi vill få en bättre kvalitet på förutsägelser - det skulle vara en historia. Men hittills har vi inte gjort något med dessa uppgifter. Dessutom skulle detta kräva en djup fördjupning av deltagarna i detaljerna kring driften av vår produkt; en och en halv dag är inte tillräckligt för detta.
Hur bestämde du dig?: De satte inte omedelbart den exakta slutuppgiften. Istället var vi under hela 48 timmarna i dialog med deltagarna och fick snabbt reda på vad de kunde få och vad de inte kunde. Utifrån detta, i en kompromissanda, slutfördes uppgiften.
Vad fick du för resultat?: Vinnarna av banan kunde rensa upp data (samtidigt som de hittade "funktionerna" för att beräkna några parametrar som vi själva inte hade märkt tidigare, eftersom vi inte använde en del av data för att lösa våra problem) , markera avvikelser från det förväntade beteendet hos Watts batterimoduler, och ställ in en prediktiv modell som kan förutsäga energiförbrukningen med en hög grad av noggrannhet. Ja, detta är bara ett genomförbarhetssteg för att utveckla en industriell lösning, då kommer det att behövas veckor av mödosamt tekniskt arbete, men även denna prototyp, skapad direkt under hackathonet, kan utgöra grunden för en riktig industriell lösning, vilket är sällsynt.
huvudslutsats: Baserat på den data vi har är det möjligt att sätta upp prediktiv analys, vi antog detta, men hade inte resurser att kontrollera. Hackathondeltagarna testade och bekräftade vår hypotes, och vi kommer att fortsätta att arbeta med banvinnarna med denna uppgift.
Diagram över en prediktiv modell på det neurala nätverket Facebook Prophet med öppen källkod
Råd för framtiden: när du utarbetar en uppgift måste du inte bara titta på din produktionsfärdplan utan också på deltagarnas intresse. Eftersom vårt hackathon inte har några kontantpriser spelar vi på dataforskarnas naturliga nyfikenhet och viljan att lösa nya intressanta problem där ingen ännu har visat något eller där de kan visa sig bättre än befintliga resultat. Om du omedelbart tar hänsyn till faktorn av intresse, behöver du inte flytta ditt fokus på vägen.
Управление
Uppgift: (applikation) som hanterar ett nätverk av Watts batterimoduler, med ett personligt konto, datalagring i molnet och statusövervakning.
Specificitet: i det här spåret letade vi inte efter någon ny teknisk lösning, vi har naturligtvis vårt eget konsumentgränssnitt. Vi valde honom till hackathon för att demonstrera vårt systems kapacitet, fördjupa oss i det och kontrollera om samhället är intresserad av ämnet utveckling för smarta system och alternativ energi. Vi placerade mobilapplikationen som ett alternativ; du kan göra det eller inte göra det efter eget gottfinnande. Men enligt vår mening visar det väl hur människor lyckades organisera datalagring i molnet, med åtkomst från flera olika källor samtidigt.
Vad behöver företaget egentligen?: en gemenskap av utvecklare som kommer med affärsidéer, testar hypoteser och skapar arbetsverktyg för deras implementering.
Varför är det inte genomförbart i detta skede?: Marknadsvolymen är fortfarande för liten för den organiska bildandet av en sådan gemenskap.
Hur bestämde du dig?: Som en del av ett hackathon genomförde vi en slags fysikalisk studie för att se om det var möjligt att komma på inte bara funktioner, utan fullfjädrade affärsmodeller kring vår mycket specifika produkt. Dessutom, för att människor som kan implementera en prototyp ska göra detta, trots allt, här - jag vill inte förolämpa någon - är det inte nivån för att programmera en blinkande lysdiod på Arduino (även om detta kan göras med innovationer) , ganska specifika färdigheter krävs här: utveckling av backend- och frontend-system, förståelse för principerna för att bygga skalbara Internet of Things-system.
Vad fick du för resultat?: två team föreslog fullfjädrade affärsidéer för sitt arbete: ett fokuserade mer på det ryska segmentet, det andra på det utländska. Det vill säga, i finalen berättade de inte bara hur de kom med applikationen, utan kom i huvudsak att göra affärer runt Watts. Killarna beskrev hur de ser på användningen av Watts i flera affärsmodeller, lämnade statistik, visade vilka regioner som har vilka problem, vilka lagar som antas var, beskrev den globala trenden: det är omodernt att bryta bitcoins, det är på modet att bryta kilowatt. De kom medvetet till alternativ energi, vilket vi verkligen gillade. Att deltagarna utöver detta kunde skapa en fungerande teknisk lösning tyder på att de självständigt kan starta en startup.
huvudslutsats: Det finns team som är redo att ta Watts Battery som grund för sin affärsmodell, utveckla den och bli partners/kompanjoner till företaget. En del av dem vet till och med hur man identifierar MVP för en affärsidé och arbetar med den först, något som saknas överallt i branschen idag. Folk förstår inte när de ska sluta, när de ska släppa en lösning på marknaden, om än tidigt, men fungerar. Faktum är att scenen för att polera lösningen ofta inte slutar, tekniskt sett överskrider lösningen gränsen för rimlig komplexitet, den kommer in på marknaden överbelastad, det är inte längre klart vad den ursprungliga idén var, vad kundinriktning är, vilka affärsmodeller är ingår. Som i skämtet om Akunin, som skrev en annan bok samtidigt som han signerade den förra åt någon. Men här gjordes det i sin renaste form: här är ett diagram, här är en räknare, här är indikatorer, här är en förutsägelse - det är allt, inget annat behövs för att köra det. Med detta kan du gå till en investerare och få pengar för att starta ett företag. De som hittade denna balans kom ut ur banan som vinnare.
Råd för framtiden: vid nästa hackathon (vi planerar det ), kanske det är vettigt att experimentera med hårdvara. Vi har vår egen hårdvaruutveckling (en av fördelarna med Watts), vi kontrollerar helt produktionen och testningen av allt vi gör, men vi har inte tillräckligt med resurser för att testa vissa "hårdvaruhypoteser". Det kan mycket väl vara så att det i gemenskapen av system- och lågnivåprogrammerare och hårdvaruutvecklare finns de som hjälper oss med detta och i framtiden kommer att bli vår partner på detta område.
Människor
På hackathonet förväntade vi oss att de som vill prova sig på ett nytt område (till exempel utexaminerade från olika programmeringsskolor) snarare än de som är specialiserade på den här typen av utveckling. Men ändå förväntade vi oss att de innan hackathonet skulle göra lite förarbete, läsa om hur energiförbrukningen förutsägs i allmänhet och hur Internet of Things-system fungerar. Så att alla kommer inte bara för skojs skull, letar efter intressanta data och uppgifter, utan också med en preliminär fördjupning i ämnesområdet. För vår del förstår vi att för detta är det nödvändigt att i förväg publicera tillgängliga data, deras beskrivning och mer exakta krav på resultatet, publicera API-moduler etc.
Alla hade ungefär samma tekniska nivå, plus eller minus samma förmågor. Mot denna bakgrund var nivån av harmoni inte den sista faktorn. Ett antal lag sköt inte eftersom de inte tydligt kunde dela in sig i arbetsområden. Det fanns också de där en person gjorde all utveckling, resten var upptagna med att förbereda presentationen, i andra fick någon uppgifter som de gjorde, förmodligen för första gången i sitt liv.
De flesta av deltagarna var unga, det betyder inte att det inte fanns några starka maskininlärningsingenjörer och utvecklare bland dem. De flesta kom i lag, det fanns praktiskt taget inga individer. Alla drömde om att vinna, någon ville hitta ett jobb i framtiden, cirka 20% har redan hittat ett, jag tror att den här siffran kommer att växa.
Vi hade inte tillräckligt med hårdvaranördar, men vi hoppas kunna kompensera för det vid det andra hackathonet.
Hackathon framsteg
Som jag skrev ovan var vi med deltagarna under större delen av de 48 timmarna av hackathon och, övervakade deras framgångar vid checkpoints, försökte vi anpassa uppgiften och villkoren för att acceptera det första, analytiska spåret så att å ena sidan deltagarna kunde slutföra det på den återstående tiden, och å andra sidan var det av intresse för oss.
Det sista förtydligandet av uppgiften gjordes någonstans runt den sista checkpointen, på lördag eftermiddag (finalen var planerad till söndag kväll). Vi förenklade allt lite mer: vi tog bort kravet på att räkna om modellen på ny data, och lämnade data som teamen redan arbetade med. Att jämföra mätvärden gav oss inte längre något, de hade redan färdiga resultat baserat på tillgängliga data, och den andra dagen var killarna redan trötta. Därför bestämde vi oss för att tortera dem mindre.
Tre av fyra deltagare nådde dock inte finalen. Det ena teamet insåg redan i början att de var mer intresserade av våra kollegors spår, det andra, strax före finalen, insåg att de under bearbetningsprocessen hade filtrerat bort nödvändig data i förväg och vägrade att presentera sitt arbete.
Teamet "21 (Wet Hair Effect)" deltog i båda våra spår ända till slutet. De ville täcka allt på en gång: maskininlärning, utveckling, applikation och webbplats. Tills vi i sista stund hotade dem med tillbakadragande, trodde de att de gjorde allt i tid, även om det redan vid den andra kontrollpunkten var uppenbart att de med huvudsaken - maskininlärning - inte kunde göra betydande framsteg: de klarade sig i allmänhet av det andra blocket, men kunde inte förutse elförbrukningen var inte redo. Som ett resultat, när vi bestämde minimiuppgiften för att kvalificera sig till det första, valde de fortfarande det andra spåret.
Fit-predict hade en balanserad sammansättning skräddarsydd för dataanalys, så de kunde övervinna allt. Det märktes att killarna var intresserade av att "röra" riktig industriell data. De koncentrerade sig omedelbart på det viktigaste: att analysera, rengöra data, hantera varje anomali. Att de kunde bygga en fungerande modell under hackathonet är en stor bedrift. I praktiken tar detta vanligtvis veckor: medan data rensas, medan de fördjupar sig i den. Därför kommer vi definitivt att arbeta med dem.
I det andra spåret (ledning) förväntade vi oss att alla skulle göra allt på en halv dag och komma och fråga för att göra uppgiften svårare. I praktiken hann vi knappt slutföra grunduppgiften. Vi arbetade på JS och Python, vilket speglar branschens nuvarande tillstånd.
Även här uppnåddes resultaten av väl koordinerade team där arbetsfördelningen byggdes upp, det var tydligt vem som gjorde vad.
Det tredje laget, FSociety, verkade ha en lösning, men till slut bestämde de sig för att inte visa sin utveckling, de sa att de inte ansåg att det fungerade. Vi respekterar detta och bråkade inte.
Vinnare blev teamet ”Strippers from Baku”, som kunde hejda sig, inte för att jaga efter ”prylar”, utan för att skapa en MVP som inte skäms för att visa och som är tydlig att den kan vidareutvecklas och skalas. Vi sa direkt till dem att vi inte var alltför intresserade av ytterligare möjligheter. Om de vill ha registrering via QR-kod, ansiktsigenkänning, låt dem först göra grafer i applikationen och sedan ta sig an de valfria.
I det här spåret gick "Wet Hair" självsäkert in i finalen och vi diskuterade ytterligare samarbete med dem och "Hustlers." Den sistnämnda har vi redan träffat på det nya året.
Jag hoppas att allt löser sig, och vi ser fram emot att se alla på det andra hackathonet i mars!
Källa: will.com