Hvorfor har en hardware-opstart brug for et software-hackathon?

Sidste december afholdt vi vores eget startup hackathon med seks andre Skolkovo-virksomheder. Uden virksomhedssponsorer eller ekstern støtte samlede vi to hundrede deltagere fra 20 russiske byer takket være programmeringsfællesskabets indsats. Nedenfor vil jeg fortælle dig, hvordan vi lykkedes med det, hvilke faldgruber vi stødte på undervejs, og hvorfor vi straks begyndte at samarbejde med et af de vindende teams.

Grænsefladen til applikationen, der styrer Watts Battery-modulerne fra banefinalisterne "Wet Hair"

selskab

Vores virksomhed Watts Battery fremstiller modulære, bærbare kraftværker. Produktet er et bærbart kraftværk på 46x36x11 cm, der er i stand til at producere fra 1,5 til 15 kilowatt i timen. Fire sådanne moduler kan dække energiforbruget i et lille landhus i to dage.

Selvom vi begyndte at sende serielle prøver sidste år, er Watts Battery en startup på alle måder. Virksomheden blev grundlagt i 2016 og har siden da været en del af Skolkovo Energy Efficient Technologies Cluster. I dag har vi 15 ansatte og en enorm efterslæbning af, hvad vi gerne vil lave på et tidspunkt, men lige nu har vi ikke tid til det.

Dette omfatter også rene softwareopgaver. Hvorfor?

Modulets hovedopgave er at levere en uafbrudt, balanceret strømforsyning til en optimal pris. Hvis du oplever strømafbrydelse af årsager uden for din kontrol, bør du altid have en reserve til fuldt ud at forsyne den nødvendige netværksbelastning under nedlukningen. Og når alt er i orden med strømforsyningen, kan du bruge solenergi til at spare.

Den enkleste løsning er at oplade batteriet fra solen om dagen og bruge det om aftenen, men kun i det nødvendige omfang, så du ikke står uden strøm i tilfælde af strømafbrydelse. På denne måde kommer du aldrig i en situation, hvor du har haft strøm til din belysning fra batteriet hele aftenen (fordi det er billigere), og strømmen er afbrudt om natten, og dit køleskab er optøet.

Det er tydeligt, at en person sjældent er i stand til at forudsige den mængde elektricitet, han har brug for, med stor nøjagtighed, men et system udstyret med en prædiktiv model kan. Derfor er maskinlæring som sådan et af vores prioriterede områder. Det er bare det, at vi lige nu fokuserer på hardwareudvikling og ikke kan afsætte nok ressourcer til disse opgaver, hvilket er det, der har bragt os til Startup Hackathon.

Forberedelse, data, infrastruktur

Til sidst valgte vi to spor: dataanalyse og styringssystemer. Udover vores, var der syv yderligere spor fra kolleger.

Selvom hackathon-formatet endnu ikke var defineret, overvejede vi at skabe "vores egen atmosfære" med et pointsystem: deltagerne laver ting, der virker svære og interessante for os, og får point for dette. Vi havde mange opgaver. Men i takt med at hackathon-strukturen blev opbygget, bad andre arrangører om at bringe alt i en fælles form, hvilket vi gjorde.

Så kom vi op med følgende skema: Fyrene laver en model baseret på deres data, så får de vores data, som modellen ikke har set før, den lærer og begynder at lave forudsigelser. Det blev antaget, at alt dette kunne gøres på 48 timer, men for os var det den første hackathon på vores data, og vi har måske overvurderet tidsressourcerne eller graden af ​​dataparathed. Ved specialiserede hackathons om maskinlæring ville en sådan tidslinje være normen, men vores var anderledes.

Vi fjernede modulets software og hardware så meget som muligt og lavede en version af vores enhed specifikt til hackathonet med en meget enkel og klar intern brugerflade, som enhver udvikler kunne understøtte.

Til sporet på styresystemet var der en mulighed for at lave en mobilapplikation. For at deltagerne ikke skulle bekymre sig om, hvordan det skulle se ud, og ikke spilde ekstra tid, gav vi dem et designlayout af applikationen, super let, så de, der ønskede det, blot kunne "trække" de funktioner, de havde brug for, over på den. For at være ærlig forventede vi ikke nogen moralske dilemmaer her, men et af teamene opfattede det som om, vi begrænsede deres fantasiflugt, idet de ønskede at få en færdiglavet løsning gratis og ikke teste dem i aktion. Og de trak sig.

Et andet team valgte at lave en helt anden applikation fra bunden, og alt fungerede. Vi insisterede ikke på, at applikationen skulle være præcis sådan her, den skulle bare indeholde nogle elementer, der demonstrerer løsningens tekniske niveau: grafer, analyser osv. Det færdige designlayout var også en slags hint.

Da det ville have taget for lang tid at analysere et Watts Battery-modul i realtid ved hackathonet, gav vi deltagerne et færdigt tværsnit af data for en måned, taget fra vores klienters virkelige moduler (som vi omhyggeligt anonymiserede på forhånd). Da det var juni, var der intet, der inkluderede sæsonbestemte ændringer i analysen. Men i fremtiden vil vi tilføje eksterne data til dem, såsom sæsonbestemte og klimatiske forhold (i dag er dette branchestandarden).

Vi ønskede ikke at skabe urealistiske forventninger blandt deltagerne, så vi sagde det direkte i hackathon-annonceringen: arbejdet ville være så tæt på feltarbejde som muligt: ​​støjende, beskidte data, som ingen havde udarbejdet specifikt. Men der var en positiv side ved dette: I den agile ånd var vi konstant i kontakt med deltagerne og foretog straks ændringer i opgaven og optagelsesbetingelserne (mere om dette nedenfor).

Vi gav også deltagerne adgang til Amazon AWS (så aktivt, at Amazon blokerede én region; vi finder ud af, hvad vi kan gøre ved det). Der kan man implementere IoT-infrastruktur og bygge en fuldgyldig løsning på 24 timer, selv ved hjælp af simple Amazon-skabeloner. Men i sidste ende gik alle deres egne veje og gjorde så meget som muligt på egen hånd. Nogle formåede at overholde tidsfristen, mens andre ikke gjorde. Et team, Nubble, brugte Yandex.Cloud, mens andre brugte deres eget. hosting Vi var endda villige til at give domæner væk (vi har registrerede nogle), men de var ikke nødvendige.

For at bestemme vinderne i det analytiske spor planlagde vi at sammenligne resultaterne, som vi udarbejdede numeriske målinger til. Men i sidste ende behøvede vi ikke at gøre dette, da tre ud af fire deltagere af forskellige årsager ikke nåede finalen.

Hvad angår husholdningsinfrastrukturen, hjalp Skolkovo Technopark os ved (gratis) at stille en af ​​sine hyggelige modulære haller med en videovæg til præsentationer og et par mindre rum til opholdsområde og til at organisere catering til rådighed.

Analytics

Opgave: et selvlærende system, der identificerer uregelmæssigheder i forbrug og moduldrift baseret på kontroldata. Vi har bevidst ladet formuleringen være så generel som muligt, så deltagerne kunne tænke sammen med os om, hvad der kunne gøres baseret på de tilgængelige data.

Specificitet: det mere komplekse af de to spor. Industrielle data har nogle forskelle fra data i lukkede systemer (f.eks. digital markedsføring). Her skal du forstå den fysiske natur af de parametre, du forsøger at analysere; at se på alt som abstrakte numeriske serier vil ikke fungere. For eksempel fordelingen af ​​elforbruget i løbet af dagen. Disse er som ritualer: om morgenen på hverdage tændes en elektrisk barbermaskine, og i weekenderne - en mixer. Så essensen af ​​selve anomalierne. Og glem ikke, at Watts Battery er beregnet til personlig brug, så hver klient vil have sine egne ritualer, og én universel model vil ikke fungere. At finde kendte afvigelser i dataene er ikke engang en opgave, en anden ting er at skabe et system, der autonomt søger efter umærkede anomalier. En anomali kan trods alt være hvad som helst, inklusive den snigende menneskelige faktor. For eksempel var der i vores testdata et tilfælde, hvor systemet med magt blev skiftet til batteritilstand af brugeren. Uden grund gør brugerne nogle gange dette (jeg vil fastslå, at denne bruger tester modulet for os og af denne grund har adgang til manuel kontrol af tilstandene, for andre brugere er styringen fuldautomatisk). Som det er let at forudsige, aflades batteriet i en sådan situation ret aktivt, og hvis belastningen er høj, slutter opladningen, før solen står op, eller en anden energikilde dukker op. I sådanne tilfælde forventer vi at se en form for meddelelse om, at systemets opførsel har afveget fra standarden. Eller den person, der er tilbage, har glemt at slukke for ovnen. Systemet ser, at forbruget normalt på dette tidspunkt af dagen er 500 watt, og i dag - 3,5 tusind - en anomali! Som Denis Matsuev på flyet: "Jeg forstår ikke noget om flymotorer, men på vej derhen lød motoren anderledes."

Prædiktiv modelgraf på open source neuralt netværk Yandex CatBoost

Hvad har virksomheden egentlig brug for?: et selvdiagnostisk system inde i enheden, prædiktiv analyse, inklusive uden netværksinfrastruktur (som praksis viser, har ikke alle vores kunder travlt med at forbinde batterier til internettet - de fleste er tilfredse med, at alt simpelthen fungerer pålideligt), identifikation af anomalier, hvis natur vi endnu ikke kender, et selvlærende system uden en lærer, klyngedannelse, neurale netværk og hele arsenalet af moderne analysemetoder. Vi er nødt til at forstå, at systemet begyndte at opføre sig anderledes, selvom vi ikke ved præcis, hvad der har ændret sig. Ved selve hackathonet var det meget vigtigt for os at se, at der er folk, der er klar til at træde ind i industriel analyse eller allerede er i det, og at de leder efter nye anvendelsesområder for deres evner. I starten var det overraskende, at der var så mange mennesker, der var villige: Det er trods alt et meget specifikt køkken, men gradvist faldt alle undtagen én af de fire deltagere fra, så til en vis grad faldt alt på plads.

Hvorfor er det ikke muligt på nuværende tidspunkt?Hovedproblemet med data mining-opgaver er utilstrækkelig data. I dag er der flere dusin Watts Battery-enheder i drift i verden, men mange af dem er ikke forbundet til netværket, så vores data er endnu ikke særlig forskelligartede. Vi har knap nok skrabet to anomalier sammen - og de opstod på prototyper, industrielle Watts Battery fungerer ret stabilt. Hvis vi havde en intern maskinlæringsingeniør, og vi vidste - ja, dette kan presses ud af disse data, og vi ønsker at få en køligere forudsigelseskvalitet - ville det være en anden historie. Men indtil videre har vi ikke gjort noget med disse data. Derudover ville dette kræve dyb fordybelse fra deltagernes side i detaljerne i vores produkt, halvanden dag er ikke nok til dette.

Hvordan besluttede du dig?Vi satte ikke en præcis, endelig opgave med det samme. I stedet var vi i dialog med deltagerne i alle 48 timer og fandt hurtigt ud af, hvad de kunne, og hvad de ikke kunne. Baseret på dette, i en kompromisånd, færdiggjorde vi opgaven.

Hvad fik vi som følge heraf?Vinderne af banen var i stand til at rense dataene (samtidig fandt de "funktioner" i beregningen af ​​nogle parametre, som vi ikke havde bemærket før, da vi ikke brugte en del af dataene til at løse vores problemer), identificere afvigelser fra den forventede adfærd for Watts Battery-modulerne og opsætte en prædiktiv model, der er i stand til at forudsige elforbruget med en høj grad af nøjagtighed. Ja, dette er kun gennemførlighedsfasen i udviklingen af ​​en industriel løsning, derefter vil der være behov for uger med omhyggeligt teknisk arbejde, men selv denne prototype, der blev skabt lige under hackathonet, kan danne grundlag for en reel industriel løsning, hvilket er sjældent.

hovedkonklusionBaseret på de data vi har, kan vi opsætte prædiktiv analyse. Vi antog dette, men havde ikke ressourcerne til at kontrollere. Hackathon-deltagerne kontrollerede og bekræftede vores hypotese. Vi vil fortsætte med at arbejde med vinderne af banen på denne opgave.

Prædiktiv modelgraf på open source neuralt netværk Facebook Prophet

Råd til fremtidenNår du sammensætter en opgave, skal du ikke kun se på din produktionsplan, men også på deltagernes interesse. Da vores hackathon ikke har pengepræmier, spiller vi på dataforskernes naturlige nysgerrighed og ønsket om at løse nye, interessante problemer, hvor ingen endnu har vist noget, eller hvor du kan vise dig selv bedre end de eksisterende resultater. Hvis du tager interessefaktoren i betragtning med det samme, behøver du ikke at flytte fokus undervejs.

ledelse

Opgave(applikation) administration af et netværk af Watts Battery-moduler med en personlig konto, datalagring i skyen, statusovervågning.

SpecificitetI dette spor ledte vi ikke efter en ny teknisk løsning, vi har selvfølgelig vores egen brugergrænseflade. Vi valgte det til hackathonet for at demonstrere vores systems muligheder, for at dykke ned i det og for at teste fællesskabets interesse for emnet udvikling af smarte og alternative energisystemer. Vi positionerede mobilapplikationen som en mulighed, man kunne gøre det eller ej efter eget skøn. Men efter vores mening viser det godt, hvordan folk formåede at organisere datalagring i skyen med adgang fra flere forskellige kilder på én gang.

Hvad har virksomheden egentlig brug for?et fællesskab af udviklere, der vil komme med forretningsidéer, teste hypoteser og skabe arbejdsværktøjer til deres implementering.

Hvorfor er det ikke muligt på nuværende tidspunkt?Markedsstørrelsen er stadig for lille til den organiske dannelse af et sådant fællesskab.

Hvordan besluttede du dig?Vi udførte en specifik undersøgelse af den fysiske karakter inden for hackathonet, om det er muligt at opfinde ikke bare funktioner, men fuldgyldige forretningsmodeller omkring vores meget specifikke produkt. Desuden, for at dette kan gøres af folk, der er i stand til at implementere en prototype, er det trods alt her - jeg vil ikke fornærme nogen - ikke niveauet for programmering af en blinkende LED på Arduino (selvom dette kan gøres med innovationer), her kræves der ret specifikke færdigheder: udvikling af backend- og frontend-systemer, forståelse af principperne for at bygge skalerbare Internet of Things-systemer.

*Optræden af ​​vinderne af andet nummer*

Hvad fik vi som følge heraf?To teams tilbød fuldgyldige forretningsidéer til deres arbejde: det ene fokuserede mere på det russiske segment, det andet på det udenlandske. Det vil sige, at de i finalen ikke kun fortalte, hvordan de kom op med applikationen, men i bund og grund kom til at drive forretning omkring Watts. Fyrene skitserede, hvordan de ser brugen af ​​Watts i flere forretningsmodeller, leverede statistikker, viste i hvilke regioner hvilke problemer, hvilke love der vedtages hvor, skitserede den globale tendens: det er umoderne at mine bitcoins, det er moderne at mine kilowatt. De kom målrettet til alternativ energi, hvilket vi virkelig kunne lide. Det faktum, at deltagerne derudover var i stand til at lave en fungerende teknisk løsning, tyder på, at de selvstændigt kan starte en startup.

hovedkonklusionDer er teams, der er klar til at tage Watts Battery som grundlag for deres forretningsmodel, udvikle den og blive partnere/ledsagere for virksomheden. Nogle af dem ved endda, hvordan man identificerer en forretningsidés MVP og arbejder på den først, hvilket er noget, der mangler i branchen overalt i dag. Folk forstår ikke, hvornår de skal stoppe, hvornår det er nødvendigt at frigive en løsning til markedet, omend en tidlig en, men en fungerende en. Faktisk slutter fasen med at finpudse løsningen ofte ikke, den tekniske løsning krydser grænsen for rimelig kompleksitet, kommer overbelastet ud på markedet, det er ikke længere klart, hvad den oprindelige idé var, hvilken kundemålretning, hvilke forretningsmodeller der er indlejret. Som i joken om Akunin, der skrev en anden bog, da han underskrev den forrige til nogen. Og her blev det gjort i sin rene form: her er en graf, her er en tæller, her er indikatorer, her er en forudsigelse - det er det, der skal ikke mere til for at lancere. Med dette kan du gå til en investor og få penge til at starte en virksomhed. De, der fandt denne balance, kom ud af banen som vindere.

Råd til fremtiden: ved den næste hackathon (vi planlægger den i marts i år), måske giver det mening også at eksperimentere med hardware. Vi har vores egen hardwareudvikling (en af ​​Watts' fordele), vi kontrollerer fuldt ud produktionen og testningen af ​​alt, hvad vi gør, men vi mangler ressourcerne til at teste nogle hardwarehypoteser. Det kan meget vel være, at der i fællesskabet af system- og lavniveauprogrammører og hardwareudviklere er dem, der vil hjælpe os med dette og blive vores partner på dette område i fremtiden.

Mennesker

Ved hackathonet forventede vi snarere dem, der ønsker at prøve sig af inden for et nyt felt (for eksempel kandidater fra forskellige programmeringsskoler), end dem, der specialiserer sig i denne form for udvikling. Men vi forventede stadig, at de inden hackathonet ville lave noget forberedende arbejde, læse om, hvordan energiforbrug generelt forudsiges, og hvordan Internet of Things-systemer er arrangeret. Så alle ville komme ikke bare for sjov, for at få interessante data og opgaver, men også for at fordybe sig i emneområdet. For vores vedkommende forstår vi, at det til dette formål er nødvendigt at offentliggøre de tilgængelige data, deres beskrivelse og mere præcise krav til resultatet på forhånd, offentliggøre modulernes API osv.

Det teknologiske niveau var nogenlunde det samme for alle, plus eller minus også kapaciteterne. På denne baggrund var koordineringsniveauet ikke den mindst vigtige faktor. En række teams kom ikke i gang, fordi de ikke klart kunne opdele dem i arbejdsområder. Der var også dem, hvor én person stod for al udvikling, resten var involveret i forberedelsen af ​​præsentationen, i andre - nogen fik opgaver, som de sandsynligvis udførte for første gang i deres liv.

Deltagerne var for det meste unge, hvilket ikke betyder, at der ikke var stærke maskinlæringsingeniører og -udviklere iblandt dem. De fleste kom i teams, der var praktisk talt ingen enkeltpersoner. Alle drømte om at vinde, nogle ville finde et job i fremtiden, omkring 20% ​​har allerede fundet det, og jeg tror, ​​at dette tal vil stige.

Vi manglede hardware-nørder, men det håber vi at kunne kompensere for ved det andet hackathon.

Hackathon-fremskridt

Som jeg skrev ovenfor, brugte vi størstedelen af ​​hackathonets 48 timer med deltagerne, og mens vi overvågede deres fremskridt ved checkpoints, forsøgte vi at tilpasse opgaven og acceptbetingelserne for det første, analytiske spor, så deltagerne på den ene side kunne gennemføre det inden for den resterende tid, og det på den anden side var af interesse for os.

Den sidste præcisering af opgaven blev foretaget et sted omkring det sidste checkpoint lørdag eftermiddag (finalen var planlagt til søndag aften). Vi forenklede alt lidt mere: Vi fjernede kravet om at genberegne modellen på nye data og beholdt de data, som holdene allerede havde arbejdet med. Sammenligning af metrikker gav os ikke længere noget, de havde allerede færdige resultater baseret på de tilgængelige data, og på andendagen var fyrene allerede trætte. Så vi besluttede at plage dem mindre.

Tre ud af fire deltagere nåede dog ikke finalen. Et hold indså i starten, at de var mere interesserede i vores kollegers spor, et andet indså lige før finalen, at de havde filtreret de nødvendige data fra på forhånd under bearbejdningen og nægtede at præsentere deres arbejde.

"21 (Wet Hair Effect)"-teamet deltog i begge vores spor helt til det sidste. De ville dække alt på én gang: maskinlæring, udvikling, appen og hjemmesiden. Indtil vi truede med at trække dem tilbage i sidste øjeblik, troede de, at de havde tid til alt, selvom det allerede ved det andet kontrolpunkt var tydeligt, at de ikke havde været i stand til at gøre væsentlige fremskridt med det vigtigste - maskinlæring: De havde generelt klaret den anden blok, men var ikke klar til at forudsige elforbruget. Til sidst, da vi definerede minimumsopgaven for at kvalificere sig til den første, valgte de stadig det andet spor.

Fit-predict havde et balanceret team med fokus på dataanalyse, så de var i stand til at overkomme alt. Det var mærkbart, at fyrene var interesserede i at "føle" ægte industrielle data. De fokuserede straks på det vigtigste: de analyserede, rensede dataene og håndterede hver eneste anomali. Det faktum, at de var i stand til at bygge en fungerende model under hackathonet, er en stor præstation. I praksis tager det normalt uger: mens dataene renses, mens de dykker ned i dem. Så vi vil helt sikkert arbejde sammen med dem.

I det andet spor (ledelse) forventede vi, at alle ville gøre alt på en halv dag og komme og spørge for at gøre opgaven vanskeligere. I praksis lykkedes det os kun lige akkurat at fuldføre den grundlæggende opgave. Vi arbejdede i JS, Python, hvilket afspejler branchens nuværende tilstand.

Her opnåede velkoordinerede teams også resultater med en veletableret arbejdsfordeling og en klar forståelse af, hvem der gjorde hvad.

Det tredje hold, FSociety, syntes at have en løsning, men til sidst besluttede de sig for ikke at vise deres udvikling, da de sagde, at de ikke mente, at det fungerede. Vi respekterede dette og diskuterede ikke.

Vinderen blev holdet "Strippers from Baku", som formåede at stoppe sig selv, ikke jagte "dikkedarer", men lave en MVP, som ikke er pinlig at vise frem, og som tydeligt viser, at den kan videreudvikles og skaleres. Vi fortalte dem med det samme: at yderligere funktioner ikke interesserer os for meget. Hvis de ønsker registrering via QR-kode, ansigtsgenkendelse, så lad dem først lave grafer i applikationen, og derefter tage de valgfrie.

I dette nummer gik "Wet Hair" selvsikkert ind i finalen, og vi diskuterede yderligere samarbejde med dem og "Striptease". Vi mødtes allerede med sidstnævnte i det nye år.

Jeg håber, at alt går som planlagt, og vi glæder os til jer alle ved det andet hackathon i marts!

Kilde: www.habr.com