🥇Hvordan vi arbejder med ideer, og hvordan LANBIX blev til

I "LANIT-Integration" er der mange kreative medarbejdere. Idéer til nye produkter og projekter hænger bogstavelig talt i luften. At identificere de mest interessante kan ofte være en stor udfordring. Derfor har vi i fællesskab udviklet vores egen metode. Læs i denne artikel, hvordan man udvælger de bedste projekter og realiserer dem.

I Rusland og i verden generelt er der en række processer i gang, som fører til en transformation af IT-markedet. Takket være den stigende computerkraft og fremkomsten af server-, netværks- og andre virtualiseringsteknologier, har markedet ikke længere behov for store mængder 'hardware'. Leverandører foretrækker i stigende grad at arbejde direkte med kunderne. Outsourcing blomstrer på IT-markedet i alle sine former, fra klassisk outsourcing til den nye bølge af udbydere – 'cloud-udbydere'. Infrastruktur-systemer og elementer bliver væsentligt enklere at vedligeholde og konfigurere. Kvaliteten af software stiger hvert år, og integratorens opgaver transformeres.

Hvordan vi arbejder med idéer

Produktstart-up-retningen i "LANIT-Integration" har eksisteret i mere end et år. Vores primære mål er at skabe nye produkter og bringe dem på markedet. Det første, vi startede med, var at organisere selve produktudviklingsprocessen. Vi har gennemgået mange metodologier, fra de klassiske til de hypede. Men ingen af dem svarede til vores behov. Derfor besluttede vi at tage udgangspunkt i Lean Startup-metodologien og tilpasse den til vores behov. "Lean Startup" er en entreprenørskabs teori, skabt af Eric Ries. Den bygger på principper, tilgange og praksisser fra koncepter som slank produktion, customer development og agil udviklingsmetodologi.

Når det kommer til selve tilgangen til produktudviklingsledelse: vi opfandt ikke hjulet, men anvendte en allerede eksisterende udviklingsmetodologi SCRUM, tilføjet kreativitet, og nu kan det trygt kaldets SCRUM-WATERFALL-BAN. SCRUM, på trods af sin fleksibilitet, er et meget stramt system og egner sig til at styre et team, der kun er ansvarligt for ét produkt/projekt. Som du forstår, tillader en klassisk 'integrator'-forretning ikke, at tekniske specialister tildeles fuldtid til at arbejde på ét projekt (der er undtagelser, men de er sjældne), da alle er beskæftiget med igangværende projekter udover arbejdet med produkterne. Fra SCRUM har vi taget arbejdet op i sprint, daglig rapportering, retrospektiver og roller. For at arbejde med opgavernes flow valgte vi Kanban, og det integrerede sig glimrende i vores eksisterende opgavetrackingssystem. Vi har struktureret arbejdet og glidende integreret os i den allerede eksisterende orden.
Før et produkt kommer på markedet, gennemgår det 5 faser: idé, udvælgelse, koncept, MЖП (se nærmere nedenfor) og produktion.

Idé

På dette stadium er der noget efemerisk – en idé. Ideelt set en idé til løsning af et eksisterende problem eller en opgave for kunden. Vi har ikke mangel på idéer. Ifølge den oprindelige plan skal de genereres af medarbejdere i de tekniske retninger. For at en idé kan godkendes til videre udvikling, skal forfatteren udfylde 'Idéformuleringens skabelon'. Der er kun fire spørgsmål: Hvad? Hvorfor? Hvem har brug for det? Og hvis ikke vores produkt, hvad så?

Kilde

Udvælgelse

Når den udfyldte skabelon kommer til os, starter behandlings- og udvælgelsesprocessen. Udvælgelsesfasen er den mest arbejdskrævende. På dette stadium dannes hypoteser om problemer (jeg nævnte ikke for ingenting, at idéen ideelt set skal løse et kundeproblem) og produktets værdi. Det formuleres en skala-hypotese, dvs. hvordan vores forretning planlægger at vokse og trives. Der gennemføres problem- og ekspertinterviews med potentielle kunder for at bekræfte, at vi har til hensigt at producere noget nyttigt. Der kræves mindst 10-15 interviews for at drage konklusioner om produktets nødvendighed.

Hvis hypoteser bekræftes, gennemføres en foreløbig finansiel analyse, der vurderer det omtrentlige investeringsbeløb og den mulige indtjening for investoren. Som resultat af dette stadium skabes et dokument kaldet Lean Canvas, som præsenteres for ledelsen.

Koncept

På dette stadium sorteres cirka 70% af ideerne fra. Hvis konceptet godkendes, begynder fasen med udvikling af ideen. De funktionelle muligheder for det fremtidige produkt formes, implementeringsveje og optimale tekniske løsninger bestemmes, og forretningsplanen aktualiseres. Resultatet af dette trin er en teknisk opgave til udvikling og en detaljeret business case. Ved succes går vi videre til MLP eller MVP-fasen.

MLP eller MVP

MLP er det minimum levedygtige produkt. Det vil sige, et produkt, der ikke er færdigudviklet, men allerede kan skabe værdi og opfylde sine funktioner. På dette udviklingstrin indsamler vi nødvendigvis feedback fra rigtige brugere og foretager ændringer.

Produktion

Den aller sidste fase er produktion. Ikke mere end 5% af produkterne når denne fase. Disse 5% er kun de vigtigste, nødvendige, levedygtige og funktionelle produkter.

Vi har mange ideer og en omfattende portefølje samlet. Vi gennemgår hver idé og gør alt, hvad vi kan, for at bringe dem til den endelige fase. Det er meget tilfredsstillende, at kolleger ikke har været ligeglade med vores R&D-område og deltager aktivt i udviklingen og implementeringen af produkter og løsninger.

Hvordan vi lavede LANBIX

Lad os se på produktudviklingen med et konkret eksempel - produktet LANBIX. Dette er et "boxeret" software-hardware kompleks, designet til overvågning af små IT-infrastrukturer og hurtig varsling af ansvarlige personer og forretningsbrugere om fejl med styring gennem en chatbot. Ud over overvågningsfunktionen inkluderer LANBIX Help Desk-funktionen. Dette produkt er eksklusivt for den markedssegment, vi har målrettet. Dette er både vores fordel og vores udfordring. Men mere om det senere. Jeg vil straks sige, at LANBIX er et levende produkt (dvs. det er ikke endeligt i sin udvikling og er på en ny MVP-cyklus).

Så den første fase er idéen. For at en idé kan opstå, er det nødvendigt med problemer, og vi havde nogle, nærmere bestemt ikke vi, men vores bekendte. Nedenfor vil vi se på flere virkelige situationer, der er sket i forskellige erhverv.

Et lille ejendomsselskab håndterer to bygninger i Moskva-regionen. Personalet med adgang til en computer tæller omkring 15 personer. Systemadministratoren er en freelancetekniker (den snedige søn af en af de engagerede beboere). Det skulle synes, at ejendomsselskabets aktivitet i høj grad er uafhængig af IT, men en særlig egenskab ved denne forretning er månedlig rapportering til mange instanser. Den systemdisk, som lederen benytter (som sædvanligt kombinerer mange funktioner), var løbet tør for plads. Således skete dette ikke pludseligt; advarslen havde været synlig i næsten 2 måneder og blev konstant ignoreret. Men der kom en opdatering, OS blev opdateret, og som ved en dårlig skæbne frøs det midt i opdateringen og klagede inden 'døden' over den optagne disk. Computeren gik i en cyklisk genstart. Mens man kæmpede med problemet og hentede rapporterne, overskred de fristen for at indsende rapporten. Det skulle synes, at en banal fejl blev årsag til forskellige problemer: fra tab til retssager og administrativt ansvar.

Kilde

En lignende hændelse fandt sted i en stor koncern, som samler mange små virksomheder, med en central teknisk supporttjeneste for hele kontoret. I en af afdelingerne brød computerens hovedbogholder sammen. At den kunne gå i stykker, var allerede kendt i lang tid (computeren havde desperat forsinket arbejdet og var blevet overophedet), men bogholderens hænder nåede ikke til at sende en anmodning til teknisk support. Selvfølgelig gik den i stykker lige på lønningsdagen, og medarbejderne i afdelingen sad i flere dage uden penge.

En lille virksomhed, der driver engroshandel, havde et salgshjemmeside, der blev hostet på en ekstern platform. De fik besked om dets utilgængelighed via telefon fra en fast kunde. På tidspunktet for opkaldet havde hjemmesiden været uden forbindelse i omkring tre timer. Det tog yderligere et par timer at finde den ansvarlige for hjemmesiden, og at løse problemet tog yderligere to timer. Derfor var hjemmesiden praktisk talt utilgængelig i hele arbejdsdagen. Ifølge virksomhedens kommercielle direktør kostede denne nedetid dem omtrent 1 million rubler.

Jeg har selv stået i en lignende situation, da jeg kom til konsultation i klinikken og skulle tilmelde mig DMS. De kunne ikke sende mig til lægen af en simpel årsag - der havde været et strømsvigt om morgenen, og efter uheldet fungerede deres e-mailservice og en forbindelse til forsikringsselskabet ikke. På mit spørgsmål om, hvor deres administrator var, blev jeg fortalt, at de havde en vikaradministrator, som kun kom én gang om ugen. Og nu (på det tidspunkt var klokken allerede 16:00) tog han ikke telefonen. Klinikken havde været afskåret fra omverdenen i mindst 7 timer og kunne ikke tilbyde betalte tjenester.

Hvad har alle disse tilfælde til fælles? Absolut alle problemer kunne have været forhindret på forhånd. Med rettidig reaktion fra de personer, der håndterer IT, kunne den påførte skade være blevet reduceret. Dette ville også have været muligt ved korrekt fortolkning af tidlige symptomer fra brugerne.

Vi har identificeret problemhypoteser:

betydelige økonomiske og omdømmemæssige tab på grund af lav reaktionstid på fejl i IT-infrastrukturen;
forkert fortolkning af tidlige symptomer på fejl fra brugerne.

Hvad kan kunden gøre ved dem, og hvordan undgår man lignende situationer i fremtiden? Mulighederne er ikke mange:

ansætte en højt kvalificeret systemadministrator og sikre, at han arbejder ordentligt;
overdrage IT-service til et specialiseret servicefirma;
selv implementere et overvågnings- og alarmsystem for fejl;
afholde træning af brugerne/business-personale i grundlæggende computerfærdigheder.

Vi fokuserer på den tredje mulighed. Lad os foreslå et overvågningssystem til dem, der ikke bruger det af forskellige årsager.

Et lyrisk afsnit. Forskellige systemer til overvågning af IT-tjenester på enterprise-markedet har været brugt i lang tid, og deres nytteværdi kan ikke bestrides. Jeg har talt med repræsentanter for større virksomheder og set, hvordan relationerne mellem forretning og IT er opbygget. Chief Technology Officer for en stor maskinfabrik har outsourcet driften af IT-infrastrukturen til et eksternt firma, men holder sig selv ajour med alt. I hans kontor hænger der en stor skærm med overvågningssystemet, der viser statusindikatorer for IT-tjenester. Systemet omfatter de mest kritiske. På ethvert tidspunkt kan den tekniske direktør finde ud af, hvordan infrastrukturen har det, hvad der sker, hvor problemet er, om de ansvarlige personer er blevet informeret, og om problemet bliver løst.

De nævnte historier fik vores team til at overveje, hvordan man kan lave et optimalt overvågningssystem for små virksomheder. Resultatet blev LANBIX — et overvågningssystem, som helt almindelige mennesker kan implementere uden nogen som helst IT-viden. Systemets primære mål er simpelt, ligesom alle systemer der sigter mod at forbedre kontinuiteten og tilgængeligheden — at minimere økonomiske og andre tab i tilfælde af uventede nedetider. Enheden er designet til at forkorte tiden mellem "jeg har et eller andet, der er gået i stykker" og "problemet er løst".

For at bekræfte hypoteserne blev der gennemført probleminterviews. Jeg kunne ikke forestille mig, hvor meget folk er villige til at dele, hvis man ikke forsøger at sælge dem noget. Hver samtale varede mindst 1,5 timer, og vi fik en masse information, der var nyttig til det videre udviklingsarbejde.

Lad os opsummere resultatet af denne fase:

forståelse for problemet — check,
forståelse for værdien — check,
idéen til løsning — check.

Den anden fase var mere detaljeret. På baggrund af dens resultater skulle vi præsentere ledelsen, som i princippet fungerer som investor, en business case (den såkaldte Lean Canvas) for at træffe beslutning om produktets videre skæbne.

Vi begyndte med at undersøge markedet og lave en konkurrentanalyse for at finde ud af, hvem der gør hvad, og vigtigst af alt, hvordan de gør det på dette marked.

Det viste sig følgende.

På markedet findes der ikke færdige box-løsninger til overvågning for vores segment (små virksomheder), bortset fra et par stykker, som jeg af åbenlyse grunde ikke vil nævne.
Vores største konkurrenter er, underligt nok, systemadministratorer med deres egne scripts og 'tilpasninger' til systemer med open source overvågning.
Der er en åbenlys problematik omkring brugen af open source overvågningssystemer. Der findes systemer, og der er en enorm mængde information om drift og tilpasning af systemet til egne behov. Af de administratorer, jeg har talt med, har mange indrømmet, at de ikke har de nødvendige kompetencer til at realisere deres ideer selv. Og de kan ikke indrømme dette over for ledelsen af frygt for at miste jobbet. Det skaber en ond cirkel.

Derefter gik vi videre til at analysere behovene hos vores potentielle kunder. Vi identificerede et segment af små organisationer, der af en eller anden grund ikke har deres egen IT-afdeling, hvor IT håndteres af en ekstern systemadministrator, freelancer eller servicefirma. Vi besluttede os for at træde ind fra forretningens perspektiv snarere end IT, og tilbyde virksomhedsejere et værktøj til at forbedre kvaliteten af IT-infrastrukturen. Et produkt, der skal hjælpe ejere med at sikre deres forretning, men som samtidig vil skabe mere arbejde for dem, der er ansvarlige for IT. Et produkt, der giver forretningen et værktøj til at kontrollere kvaliteten af IT-support.

Som et resultat af behandlingen af de indsamlede data blev den første liste over krav (en slags grov backlog) til det fremtidige produkt født:

Overvågningssystemet skal være baseret på en løsning med open source, og som følge heraf være billig;
Det skal være enkelt og hurtigt at installere;
Det må ikke kræve specifik IT-viden, selv en revisor (jeg ønsker på ingen måde at fornærme repræsentanter for dette erhverv) skal kunne opsætte og konfigurere systemet;
Det skal automatisk kunne opdage overvågningsobjekter i netværket;
Det skal kunne automatisere (ideelt set automatisk) installationen af overvågningsagenter;
Det skal have mulighed for at overvåge eksterne tjenester, mindst et CRM-system og en salgswebsite;
Det skal give besked om problemer til både virksomheden og systemadministratoren;
Graden af dybde og 'sprog' i varslerne skal være forskelligt for administratorer og virksomheder;
Systemet skal leveres på eget hardware;
Hardwaren skal være så tilgængelig som muligt;
Systemet skal være så uafhængigt som muligt af eksterne faktorer.

Dernæst blev investeringerne til produktudvikling beregnet (inklusive arbejdstimer fra medarbejdere i den tekniske afdeling). En skitse til forretningsmodellen er forberedt, og produktets unit economics er beregnet.

Resultatet af denne fase:

høj-niveau backlog for produktet;
formuleret forretningsmodel eller skala-hypotese, som stadig skal testes i praksis.

Lad os gå videre til næste fase – konceptet. Her kommer vi som ingeniører ind i vores rette element. Der er "ønsker", der nedbrydes til komponenter / subsystemer / funktioner, dernæst omdannes de til kravspecifikationer / brugerhistorier, derefter til projekt osv. Jeg vil ikke gå i detaljer med processen for at forberede et væld af alternative muligheder, men vi går direkte til kravene og de valgte metoder til deres implementering.

Krav
Løsning

Det skal være et åbent overvågningssystem;

Vi tager et overvågningssystem med open source.

Systemet skal være enkelt og hurtigt at installere;
det må ikke kræve specifik viden inden for IT. Selv bogholderen skal være i stand til at implementere og konfigurere systemet.

Vi tilbyder et installeret system, så brugeren kun skal tænde enheden og justere den lidt, ligesom med en router.

Vi vil holde interaktionen med enheden enkel og forståelig for alle.

Vi skriver vores egen chatbot til en af de kendte messaging-tjenester og lader al interaktion med systemet foregå via den.

Systemet skal:

automatisk opdage de objekter, der skal overvåges, i netværket;
automatisk installere overvågningsagenter;
have mulighed for at overvåge eksterne tjenester, som minimum CRM-systemer og salgswebsteder.

Vi skriver udvidelser til overvågningssystemet om:

automatisk opdagelse af objekter;
automatisk installation af agenter;
overvågning af tilgængelighed af eksterne tjenester.

Systemet skal:

underrette både virksomhed og systemadministrator om problemer;
have mulighed for at overvåge eksterne tjenester, som minimum CRM-systemer og salgswebsteder. Dybden af og "sproget" i underretningerne skal være forskelligt for administrator og virksomhed.
Systemet må ikke kræve specifik viden inden for IT, selv bogholderen skal være i stand til at implementere og konfigurere systemet.

Vi tilføjer forskellige typer beskeder til forskellige brugergrupper. De adskiller sig i formidling og dybde. En business-bruger vil modtage en besked af typen "alt fungerer fint, men Ivanovs computer er snart ude af drift". En administrator vil modtage en fuld fejlinformation om, hvem, hvad og hvordan noget er sket eller kan ske.
Vi tilføjer muligheden for at bruge e-mail fra en ekstra ansvarlig person, så han kan modtage beskeder ved nedbrud.
Vi tilføjer interaktion med eksterne serviceudbydere baseret på sending af e-mails med forberedt tekst, da elektronisk post danner grundlag for oprettelse af hændelser.
Al interaktion med systemet vil blive centraliseret i en chatbot, hvor kommunikationen foregår i dialogstil.

Sårbarheden er bekræftet i mange officielle Docker-billeder, herunder billeder af couchbase, elasticsearch, flink, solr, storm osv.

Vi tilføjer en funktion til "chat med administratoren", så brugeren kan sende en besked med en beskrivelse af problemet direkte til administratoren.

Systemet skal leveres på eget udstyr.
Udstyret skal være tilgængeligt.
Systemet skal være så uafhængigt af omgivelserne som muligt.

Vi tager en færdig og billig Raspberry PI computer.
Vi designer et strømforsyningskort.
Vi tilføjer en modem for uafhængighed af den lokale netværks tilstand.
Vi designer et flot kabinet.

Vi har tre delsystemer med deres egne krav og visioner for implementeringen:

hardware delsystem;
monitorerings delsystem;
brugers interaktions delsystem.

For hardware delsystemet har vi udviklet et skitseprojekt. Ja, vi har brudt alle regler for agil udvikling og lavet et dokument, fordi producenterne arbejder det med dokumenter. For de andre delsystemer har vi identificeret brugere (personas), forberedt brugerhistorier og skrevet opgaver til udvikling.

På dette konceptstadie er vi færdige, og resultatet blev:

et projekt til hardware platformen;
et formuleret vision i form af brugerhistorier for de øvrige to delsystemer;
et prototype af software delen, implementeret som en virtuel maskine;
et prototype af hardware delen, implementeret som en testopstilling, hvor de hardwareløsninger blev afprøvet;
testning udført af vores administratorer.

Problemerne på dette stadium var hovedsageligt organisatoriske og relateret til den utilstrækkelige juridiske og regnskabsmæssige viden blandt ingeniørpersonalet i forbindelse med salget. Det vil sige, det er én ting at finde ud af, hvad og hvordan man skal sælge, og noget helt andet at stå over for den ubarmhjertige juridiske maskine: patenter, udviklingsopgaver, aktivering, EULA og meget mere, som vi som kreative mennesker oprindeligt ikke havde overvejet.

Det var ikke et problem, men snarere en vanskelighed i forbindelse med designet af kabinetterne. I vores team er der kun ingeniører, så den første version af kabinettet blev 'savet' af vores elektronikekspert af akrylplast.

Kabinetset var, for at sige det mildt, kontroversielt, især for et publikum, der var vant til moderne teknologi. Der var selvfølgelig nogle, der satte pris på det blandt de 'håndværkere' fra den ældre generation — kabinettet vækkede nostalgiske følelser hos dem. Det blev besluttet at fremstille og designe kabinettet på ny, da det gamle, ud over de æstetiske mangler, også havde konstruktive — akrylplast kunne ikke klare at blive samlet og adskilt igen og havde en tendens til at gå i stykker. Jeg vil tale videre om produktionen af kabinettet.

Og nu er vi tæt på målstregen — MVP. Selvfølgelig er dette ikke det endelige serieprodukt, men det er allerede nyttigt og har værdi. Hovedmålet på dette stadium er at starte cyklussen 'skabe-vurdere-lære'. Det er netop her, LANBIX befinder sig.

I stadiet 'skabe' har vi skabt en enhed, som udfører den angivne funktionalitet. Ja, det er stadig ikke perfekt, og vi fortsætter med at arbejde på det.

Lad os vende tilbage til fremstillingen af kabinettet, altså opgaven med at forvandle vores enhed fra at vække nostalgiske følelser til moderne. I starten undersøgte jeg markedet for producenter af kabinetter og ydelser inden for industriel design. For det første er der ikke mange virksomheder, der producerer kabinetter på det russiske marked, og for det andet er omkostningerne til industriel design på nuværende tidspunkt urimeligt høje, omkring 1 million rubler.

Design was handled by our marketing department, where a young designer was ready for creative experiments. We laid out our vision for the casing (after studying the best examples of casing design), and he turned it into a work of art. We just needed to produce it. Proud of our design, we approached our partners. Their CEO immediately shattered our fantasies, pointing out for free the issues that made our chosen production method unworkable. The casing can be produced, and it will be no worse than Apple's, but the cost would be three to four times higher than the entire electronic filling. After a series of operations and approvals, we designed a casing that can be manufactured. Yes, it’s not as beautiful as we planned, but it's perfect for achieving our current goals.

Result of the stage: the first batch of devices is ready for battle and testing.

And now comes the most challenging part - the 'evaluation' stage, and with our product, we are right at this point. We can only evaluate based on the results of real customers using it, and no assumptions work here. We need those 'early adopters' to provide feedback and make the changes in the product that are truly necessary. The question arises: where do we find customers and how do we convince them to participate in the experiment?

Out of all possible options, we chose the classic set of digital tools: a landing page and an advertising campaign on social media.

The process has already started, but it’s too early to talk about results, although we have already received feedback confirming many of our hypotheses. A pleasant surprise was the response from representatives of completely different segments of the business, much larger than those we were counting on. It would be foolish to ignore these new inputs, and based on the results of the interviews conducted, we made the decision to launch a parallel line of LANBIX named LANBIX Enterprise. We added support for distributed infrastructures, monitoring of Wi-Fi networks with fault detection and localization, and monitoring the quality of communication channels. Service companies showed the greatest interest in the solution. Meanwhile, the devices we had already developed play a significant role in the solutions.

Hvad vil der ske videre

Hvad der vil ske med det oprindelige LANBIX, vil blive klart efter resultaterne af kampagnen. Hvis vores hypoteser ikke bekræftes, vil vi uden nåde slippe af med det ifølge Lean-metodologien, eller det vil forvandles til noget nyt, for der er ikke noget værre end at lave et produkt, som ingen har brug for. Men allerede nu kan vi sige, at det udførte arbejde ikke har været forgæves, og takket være det er der opstået en hel gren af parallelle produkter, som vi aktivt arbejder på. Ved succes vil LANBIX gå fra MVP-fasen til den endelige fase og udvikle sig i overensstemmelse med kendte klassiske love for produktmarkedsføring.

Jeg gentager, at vi nu ønsker at finde tidlige tilhængere, virksomheder, der kan installere vores produkt med det formål at indsamle feedback. Hvis du er interesseret i at teste LANBIX, så skriv i kommentarerne eller i private beskeder.

Kilde

Kilde: habr.com