Hvordan vi arbejder med ideer og hvordan LANBIX blev født

Der er mange kreative medarbejdere hos LANIT-Integration. Idéer til nye produkter og projekter hænger bogstaveligt talt i luften. Det kan nogle gange være meget svært at identificere de mest interessante. Derfor har vi sammen udviklet vores egen metode. Læs denne artikel om, hvordan du vælger de bedste projekter og implementerer dem.

I Rusland og i verden som helhed foregår der en række processer, der fører til transformationen af ​​it-markedet. Takket være stigningen i computerkraft og fremkomsten af ​​server-, netværks- og andre virtualiseringsteknologier har markedet ikke længere brug for en stor mængde hardware. Leverandører foretrækker i stigende grad at arbejde direkte med kunder. It-markedet oplever et boom inden for outsourcing i alle dens former, fra klassisk outsourcing til den nye bølge af outsourcing – “cloud providers”. Infrastruktursystemer og -elementer bliver meget nemmere at vedligeholde og konfigurere. Kvaliteten af ​​software vokser hvert år, og integratorens opgaver bliver transformeret.

Hvordan vi arbejder med ideer

Produktstartretning ind "LANIT-integration" har eksisteret i over et år. Vores hovedmål er at skabe nye produkter og bringe dem på markedet. Det første, vi startede med, var at organisere processen med at skabe produkter. Vi har studeret mange metoder, fra klassisk til hype. Men ingen af ​​dem opfyldte vores behov. Så besluttede vi at tage udgangspunkt i Lean Startup-metoden og tilpasse den til vores opgaver. Lean Startup er en teori om iværksætteri skabt af Eric Ries. Den er baseret på principperne, tilgange og praksis for begreber som lean manufacturing, kundeudvikling og fleksibel udviklingsmetodologi.

Med hensyn til den direkte tilgang til produktudviklingsstyring: vi genopfandt ikke hjulet, men anvendte en allerede eksisterende udviklingsmetodologi SCRUM, tilføjer kreativitet, og nu kan det roligt kaldes SCRUM-WATERFALL-BAN. SCRUM er på trods af sin fleksibilitet et meget stift system og er velegnet til at lede et team med ansvar for kun ét produkt/projekt. Som du forstår, involverer den klassiske "integrations"-virksomhed ikke at tildele fuldtids tekniske specialister til at arbejde på et projekt (der er undtagelser, men ekstremt sjældent), da alle ud over at arbejde med produkter har travlt med aktuelle projekter. Fra SCRUM tog vi arbejdsdelingen i sprint, daglig rapportering, retrospektiver og roller. Vi valgte Kanban til vores opgaveflow, og det integrerede godt i vores eksisterende opgavesporingssystem. Vi strukturerede vores arbejde ved problemfrit at integrere i den eksisterende orden af ​​tingene.
Inden det kommer på markedet, gennemgår et produkt 5 faser: idé, udvælgelse, koncept, MVP (flere detaljer nedenfor) og produktion.

Idea

På dette stadium er der noget flygtigt - en idé. Ideelt set en idé til at løse et eksisterende problem eller klientproblem. Vi mangler ikke idéer. Ifølge den oprindelige plan skal de genereres af ansatte i tekniske områder. For at en idé kan accepteres til videreudvikling, skal forfatteren udfylde "Idédesignskabelonen". Der er kun fire spørgsmål: Hvad? For hvad? Hvem har brug for dette? Og hvis ikke vores produkt, hvad så?

Kilde

Udvælgelse

Så snart den udfyldte skabelon når os, begynder behandlings- og udvælgelsesproceduren. Udvælgelsesfasen er den mest arbejdskrævende. På dette stadium dannes der hypoteser om problemer (det var ikke for ingenting, at jeg nævnte i det foregående afsnit, at en idé ideelt set skulle løse en klients problem) og værdien af ​​produktet. Der dannes en skalahypotese, dvs. hvordan vores virksomhed kommer til at vokse og blomstre. Der gennemføres problem- og ekspertinterviews med potentielle kunder for at give en foreløbig bekræftelse på, at vi skal producere noget, der er nødvendigt. Det tager mindst 10-15 interviews at drage en konklusion om behovet for produktet.

Hvis hypoteserne bekræftes, udføres en foreløbig finansiel analyse, det omtrentlige investeringsvolumen og investorens mulige indtjening vurderes. Som et resultat af denne fase er et dokument kaldet Lean Canvas født og præsenteret for ledelsen.

koncept

På dette stadium er omkring 70 % af ideerne elimineret. Hvis konceptet godkendes, så begynder idéudviklingsfasen. Funktionaliteten af ​​det fremtidige produkt dannes, implementeringsveje og optimale tekniske løsninger fastlægges, og forretningsplanen opdateres. Resultatet af denne fase er en teknisk specifikation for udvikling og en detaljeret business case. Hvis det lykkes, går vi videre til MVP- eller MVP-stadiet.

MVP eller MVP

MVP er et minimum levedygtigt produkt. De der. et produkt, der ikke er færdigudviklet, men som allerede kan bringe værdi og udfører sin funktionalitet. Det er bydende nødvendigt, at vi på dette udviklingstrin indsamler feedback fra rigtige brugere og foretager ændringer.

Produktion

Og den allersidste fase er produktionen. Ikke mere end 5% af produkterne når dette stadie. Disse 5 % omfatter kun de vigtigste, nødvendige, levedygtige og funktionelle produkter.

Vi har en masse ideer og har allerede samlet en omfangsrig portefølje. Vi analyserer enhver idé og gør alt for at sikre, at den når slutfasen. Det er meget behageligt, at vores kolleger ikke forblev ligeglade med vores F&U-retning og tog aktivt del i udviklingen og implementeringen af ​​produkter og løsninger.

Hvordan vi lavede LANBIX

Lad os se på at skabe et produkt ved hjælp af et rigtigt eksempel - LANBIX-produktet. Dette er et "indpakket" software- og hardwaresystem designet til at overvåge små it-infrastrukturer og omgående advare beslutningstagere og forretningsbrugere om funktionsfejl styret via en chatbot. Ud over overvågningsfunktionen inkluderer LANBIX Help Desk-funktionalitet. Dette produkt er eksklusivt til det markedssegment, vi målretter mod. Dette er både vores fordel og vores smerte. Men først ting først. Jeg vil med det samme sige, at LANBIX er et levende produkt (det vil sige, at det ikke er endeligt i sin udvikling og er ved næste runde af MVP).

Så den første fase er ideen. For at en idé kan blive født, har du brug for problemer, og vi havde dem, eller rettere sagt ikke os, men vores venner. Nedenfor vil vi se på flere virkelige situationer, der opstod i forskellige forretningsområder.

Et lille administrationsselskab vedligeholder to huse i Moskva-regionen. Personalet med pc'er er omkring 15 personer. Systemadministratoren er en besøgende freelancer (den smarte søn af en af ​​de omsorgsfulde beboere). Det ser ud til, at administrationsselskabets aktiviteter er svagt afhængige af IT, men det særlige ved denne virksomhed er månedlig rapportering til mange myndigheder. Systemdisken for virksomhedens leder (der som sædvanligt kombinerer mange roller) er løbet tør for ledig plads. Dette skete naturligvis ikke pludseligt; advarslen hang i omkring 2 måneder og blev konstant ignoreret. Men en opdatering ankom, operativsystemet blev opdateret, og som heldet ville det, frøs det midt i opdateringen og klagede før "døden" over en travl disk. Computeren gik i en cyklisk genstart. Mens vi ordnede problemet og fik rapporter, missede vi rapporteringsfristen. Det ser ud til, at en triviel funktionsfejl har forårsaget forskellige problemer: fra tab til retssager og administrativt ansvar.

Kilde   

En lignende hændelse fandt sted i et stort holdingselskab, der forener mange små virksomheder med en enkelt teknisk supporttjeneste for hele kontoret. I en af ​​afdelingerne gik regnskabschefens computer i stykker. Man havde længe vidst, at den kunne gå i stykker (computeren var desperat langsommere og varmes op), men regnskabschefen nåede aldrig at sende en anmodning til teknisk support. Det gik naturligvis i stykker præcis på lønningsdagen, og afdelingens medarbejdere stod uden penge i flere dage.

En lille virksomhed i mindre engroshandel havde en salgshjemmeside, som var hostet på en ekstern side. Vi hørte om dets utilgængelighed via telefon fra en almindelig kunde. På tidspunktet for opkaldet havde stedet været nede i omkring tre timer. Det tog endnu et par timer at finde den ansvarlige for webstedet og yderligere to at løse problemet. Derfor var siden utilgængelig næsten hele arbejdsdagen. Ifølge virksomhedens kommercielle direktør kostede denne nedetid dem omkring 1 million rubler.

Jeg stødte selv på en lignende situation, da jeg kom til en tid på klinikken og skulle til VHI-registreringen. De kunne ikke sende mig til lægen af ​​en triviel grund - der var en strømstød om morgenen, og efter ulykken fungerede deres postvæsen og en bestemt service til at kommunikere med forsikringsselskabet. Som svar på mit spørgsmål, hvor er dine administratorer, fik jeg at vide, at deres administrator kommer og besøger dem en gang om ugen. Og nu (på det tidspunkt var klokken allerede 16:00) tager han ikke telefonen. I mindst 7 timer var klinikken afskåret fra omverdenen og kunne ikke levere betalte ydelser.

Hvad har alle disse sager til fælles? Absolut alle problemer kunne have været forhindret på forhånd. Med rettidig respons fra IT-folkene kunne skaden være blevet reduceret. Dette ville være muligt, hvis de tidlige symptomer blev fortolket korrekt af brugerne.

Vi har identificeret problemhypoteser:

• betydelige penge- og omdømmetab på grund af den lave reaktionshastighed på fejl i it-infrastrukturen;
• fejlfortolkning af tidlige symptomer på en funktionsfejl af brugere.

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

1. ansætte en højt kvalificeret systemadministrator og få ham til at arbejde samvittighedsfuldt;
2. outsource it-vedligeholdelse til en specialiseret servicevirksomhed;
3. selvstændigt implementere et overvågnings- og fejlrapporteringssystem;
4. give undervisning til brugere/forretningspersonale i det grundlæggende i computerfærdigheder.

Lad os nøjes med den tredje mulighed. Lad os tilbyde et overvågningssystem til dem, der ikke bruger det af forskellige årsager.

Lyrisk digression. Forskellige systemer til overvågning af it-tjenester på virksomhedsmarkedet har været brugt i lang tid, og deres fordele er ikke bestridt. Jeg talte med repræsentanter for store virksomheder, så på, hvordan forholdet mellem forretning og IT blev bygget. Den tekniske direktør for en stor maskinbyggeri har outsourcet vedligeholdelsen af ​​it-infrastrukturen til en ekstern virksomhed, men han er selv ved med at vide om alle forhold. På hans kontor hænger en stor overvågningssystemskærm med indikatorer for status for it-tjenester. De mest kritiske er inkluderet i systemet. Den tekniske direktør kan til enhver tid finde ud af, hvordan infrastrukturens tilstand er, hvad der sker, hvor problemet er, om de ansvarlige er blevet underrettet, og om problemet bliver løst.

Historierne nævnt ovenfor fik vores team til at tænke over, hvordan man kan skabe et optimalt overvågningssystem for små virksomheder. Som et resultat blev LANBIX født - et overvågningssystem, der kan implementeres af absolut enhver uden IT-viden. Hovedformålet med systemet er enkelt, ligesom alle systemer, der har til formål at øge kontinuiteten og tilgængeligheden - at reducere penge- og andre tab i tilfælde af uplanlagt nedetid. Enheden er designet til at reducere tiden mellem "noget er gået i stykker" og "problemet er løst" til et minimum.

For at bekræfte hypoteserne blev der gennemført probleminterviews. Jeg kunne ikke forestille mig, hvor meget folk ville være villige til at fortælle uden at forsøge at sælge til dem. Hver samtale varede mindst 1,5 time, og vi modtog en masse information, der var nyttig til videre udvikling.

Lad os opsummere resultaterne af denne fase:

1. der er en forståelse af problemet,
2. forståelse af værdi - der er,
3. Der er en idé til en løsning.

Anden fase var mere detaljeret. Baseret på dets resultater, var vi nødt til at præsentere en business case (det samme Lean Canvas) for ledelsen, som i det væsentlige spiller rollen som investor, for at træffe en beslutning om produktets fremtidige skæbne.

Vi startede med markedsundersøgelser og konkurrenceanalyser for at finde ud af, hvem, hvad og vigtigst af alt, hvordan de klarer sig på dette marked.

Det viste sig følgende.

1. Der er ingen færdige boxed monitoring-systemer på markedet til vores segment (små virksomheder), med undtagelse af et par eller tre, som jeg af indlysende grunde ikke vil tale om.
2. Vores største konkurrenter er mærkeligt nok systemadministratorer med hjemmeskrevne scripts og "add-ons" til open source-overvågningssystemer.
3. Der er et klart problem med at bruge open source-overvågningssystemer. Der er et system, der er en enorm mængde information om, hvordan man arbejder og ændrer systemet, så det passer til dine behov. Af de administratorer, jeg interviewede, indrømmede mange, at de ikke havde nok kompetencer til at implementere deres ideer på egen hånd. Men det kan de ikke indrømme over for ledelsen af ​​frygt for afskedigelse. Det viser sig at være en ond cirkel.

Derefter gik vi videre til at analysere vores potentielle kunders behov. Vi har selv identificeret et segment af små organisationer, der af en eller anden grund ikke har deres egen IT-service, hvor enten en indgående systemadministrator, en freelancer eller en servicevirksomhed står for IT. Det var ikke IT-siden, der besluttede at gå ind, men forretningssiden, der tilbyder stiftere og virksomhedsejere et værktøj til at forbedre kvaliteten af ​​IT-infrastrukturservice. Et produkt, der skal hjælpe ejere med at sikre deres forretning, men samtidig vil tilføre arbejde til de mennesker, der har ansvaret for IT. Et produkt, der giver virksomheder et værktøj til at overvåge kvaliteten af ​​IT-support.

Som et resultat af behandlingen af ​​de modtagne data blev den første liste over krav (en slags groft efterslæb) for det fremtidige produkt født:

• overvågningssystemet skal være baseret på en open source-løsning og som følge heraf billigt;
• nem og hurtig at installere;
• bør ikke kræve specifik viden inden for IT, selv en revisor (på ingen måde ønskede jeg at støde repræsentanter for denne profession) bør være i stand til at implementere og konfigurere systemet;
• skal automatisk opdage objekter til overvågning på netværket;
• bør automatisk (og ideelt set automatisk) installere overvågningsagenter;
• skal være i stand til at overvåge eksterne tjenester, mindst et CRM-system og en sælgende hjemmeside;
• bør underrette både virksomheden og systemadministratoren om problemer;
• graden af ​​dybde og "sprog" af advarsler bør være forskellige for administratoren og virksomheden;
• systemet skal forsynes på dets egen hardware;
• jern skal være så tilgængeligt som muligt;
• systemet skal være så uafhængigt som muligt af eksterne faktorer.

Dernæst blev investeringer i produktudvikling beregnet (inklusive lønomkostninger for medarbejdere i teknisk afdeling). Der blev udarbejdet en skitse af forretningsmodellen, og produktets enhedsøkonomi blev beregnet.

Etape resultat:

• produktefterslæb på højt niveau;
• en formuleret forretningsmodel eller skalahypotese, som endnu ikke er testet i praksis.

Lad os gå videre til næste fase - koncept. Her befinder vi os som ingeniører i vores oprindelige element. Der er "ønskelister", der nedbrydes i komponenter/delsystemer/features, så bliver de omdannet til tekniske specifikationer/brugerhistorier, så til et projekt osv. Jeg vil ikke dvæle i detaljer ved processen med at forberede en række alternative muligheder; lad os gå direkte til kravene og de valgte metoder til deres implementering.

Krav
beslutning

• Det bør være et åbent overvågningssystem;

Vi tager et open source overvågningssystem.

• Systemet skal være enkelt og hurtigt at installere;
• bør ikke kræve specifik IT-viden. Selv en revisor bør være i stand til at implementere og konfigurere systemet.

Vi tilbyder et installeret system, så brugeren kun skal tænde for enheden og konfigurere den lidt, svarende til en router.

Lad os lukke interaktionen med enheden til noget enkelt og forståeligt for alle.

Lad os skrive vores egen chatbot til en af ​​de velkendte instant messengers og overføre alle interaktioner med systemet til den.

Systemet skal:

• automatisk opdage objekter, der kræves til overvågning på netværket;
• automatisk installere overvågningsagenter;
• Kunne overvåge eksterne tjenester, i det mindste et CRM-system og en sælgende hjemmeside.

Vi skriver tilføjelser til overvågningssystemet til:

• automatisk genkendelse af objekter;
• automatisk installation af agenter;
• overvågning af tilgængeligheden af ​​eksterne tjenester.

Systemet skal:

• underrette både virksomheden og systemadministratoren om problemer;
• kunne overvåge eksterne services, i hvert fald et CRM-system og en sælgende hjemmeside. Graden af ​​dybde og "sprog" af notifikationer bør være forskellig for administratoren og virksomheden.
• Systemet bør ikke kræve specifik it-viden; selv en revisor bør være i stand til at implementere og konfigurere systemet.

• Lad os tilføje forskellige typer meddelelser til forskellige typer brugere. De adskiller sig i tonehøjde og dybde. En erhvervsbruger vil modtage meddelelser som "alt er i orden, men Ivanovs computer dør snart." Administratoren vil modtage en komplet besked om fejlen, hvem, hvordan og hvad der skete eller kunne ske.
• Lad os tilføje muligheden for at bruge mailen fra en yderligere ansvarlig person, så han i tilfælde af et sammenbrud vil modtage en besked.
• Lad os tilføje interaktion med eksterne tjenesteudbydere baseret på at sende e-mails med forudforberedt tekst, fordi Det er e-mailen, der giver anledning til hændelsen.
• Al interaktion med systemet vil blive forbundet med en chatbot; kommunikation foregår i en dialogstil.

supplement:

• Lad os tilføje funktionaliteten "chat med administratoren", så brugeren kan sende administratoren en besked, der beskriver problemet direkte.

• Systemet skal forsynes på egen hardware.
• Jern skal være tilgængeligt.
• Systemet skal være så uafhængigt som muligt af miljøet.

• Lad os tage en færdiglavet og billig Raspberry PI-computer.
• Vi designer et uafbrydeligt strømforsyningskort.
• Lad os tilføje et modem for at være uafhængigt af det lokale netværks tilstand.
• Vi vil tegne en smuk bygning.

Vi har nu tre delsystemer med deres egne krav og vision for deres implementering:

• hardware undersystem;
• overvågning delsystem;
• brugerinteraktion undersystem.

Vi udviklede et foreløbigt design til hardware-undersystemet. Ja Ja! Efter at have overtrådt alle reglerne for agile, udviklede vi et dokument, fordi produktionsanlæg arbejder med dokumenter. For de resterende delsystemer identificerede vi brugere (personer), udarbejdede brugerhistorier og skrev opgaver til udvikling.

Dette afslutter konceptstadiet, og resultatet er:

• projekt for en hardwareplatform;
• formuleret vision i form af brugerhistorier for de resterende to delsystemer;
• en softwareprototype implementeret som en virtuel maskine;
• en prototype af hardwaren, implementeret i form af et stativ, hvor hardwareløsningerne rent faktisk blev testet for styrke;
• test udført af vores administratorer.

Problemerne på dette stadium var for det meste organisatoriske og relateret til ingeniørpersonalets manglende kendskab til de juridiske og regnskabsmæssige aspekter af salg. De der. En ting er at finde ud af, hvad og hvordan man sælger, og noget andet er at stå over for en hensynsløs juridisk maskine: patenter, udviklingsopgaver, registrering, EULA og meget mere, som vi som kreative mennesker ikke i første omgang tog højde for.

Der var endnu ikke et problem, men derimod en vanskelighed forbundet med udformningen af ​​kabinetterne. Vores team består kun af ingeniører, så den første version af kabinettet blev "bygget" af plexiglas af vores elektronikspecialist.

Kroppen så mildt sagt kontroversiel ud, især for offentligheden, forkælet af moderne teknologi. Der var selvfølgelig kendere blandt den ældre generation af "Kulibins" - bygningen fremkaldte nostalgiske følelser hos dem. Det blev besluttet at fremstille og designe kabinettet på ny, da det gamle ud over æstetiske fejl også havde strukturelle - plexiglasset tålte ikke montering og demontering af enheden godt og havde en tendens til at revne. Jeg vil fortælle dig om fremstillingen af ​​sagen yderligere.

Og nu er vi tæt på målstregen - MVP. Selvfølgelig er dette endnu ikke et endeligt produktionsprodukt, men det er allerede nyttigt og værdifuldt. Hovedmålet med denne fase er at lancere "skab-evaluer-lær"-cyklussen. Det er præcis det stadie LANBIX er på.

På "opret"-stadiet oprettede vi en enhed, der udfører den angivne funktionalitet. Ja, det er ikke perfekt endnu, og vi fortsatte med at arbejde på det.

Lad os vende tilbage til fremstillingen af ​​kroppen, dvs. til opgaven med at transformere vores enhed fra nostalgisk til moderne. I begyndelsen gennemsøgte jeg markedet for skabsproducenter og industridesigntjenester. For det første er der ikke mange virksomheder, der producerer sager på det russiske marked, og for det andet er omkostningerne ved industrielt design på dette stadium uoverkommeligt høje, omkring 1 million rubler.

De kontaktede vores marketingafdeling for designet, den unge designer var klar til kreative eksperimenter. Vi skitserede vores vision om skroget (har tidligere studeret de bedste eksempler på skrogkonstruktion), og han gjorde det til gengæld til et kunstværk. Det eneste, der er tilbage, er at producere det. Vi, stolte af vores design, henvendte os til vores partnere. Deres administrerende direktør knuste straks vores fantasier ved helt gratis at påpege ting, der ikke kunne produceres på vores valgte måde. Etuiet kan produceres, og det bliver ikke værre end Apples, men omkostningerne ved sagen bliver tre til fire gange dyrere end alle de elektroniske komponenter. Efter en række operationer og godkendelser har vi designet et hus, der kan produceres. Ja, det er ikke så smukt, som vi havde planlagt, men det er ideelt til at nå nuværende mål.

Resultat af etapen: den første batch af enheder klar til kamp og test.

Og nu er det sværeste "evalueringsstadiet", og med vores produkt er vi præcis på dette punkt. Vi kan kun evaluere baseret på resultaterne af brug af rigtige kunder, og ingen antagelser virker her. Vi har brug for disse "early adopters" til at give feedback og foretage de ændringer af produktet, der virkelig er behov for. Spørgsmålet opstår: hvor kan man få kunder, og hvordan man kan overbevise dem om at deltage i eksperimentet?

Af alle de mulige muligheder valgte vi et klassisk sæt digitale værktøjer: landingsside og reklamekampagne på sociale netværk.

Processen er allerede sat i gang, men det er for tidligt at tale om resultater, selvom der allerede er svar, og vi har fået bekræftet mange af vores hypoteser. En behagelig overraskelse var reaktionen fra repræsentanter for helt andre forretningssegmenter, meget større end dem, vi forventede. Det ville være dumt at ignorere de nye introduktioner, og på baggrund af resultaterne af interviewene blev det besluttet at lancere en parallel LANBIX-linje kaldet LANBIX Enterprise. Vi har tilføjet support til distribuerede infrastrukturer, overvågning af Wi-Fi-netværk med fejlfinding og lokalisering og overvågning af kvaliteten af ​​kommunikationskanaler. Servicevirksomheder udtrykte størst interesse for løsningen. Samtidig spiller de enheder, vi allerede har udviklet, en vigtig rolle i driften af ​​løsningerne.

Hvad sker der nu

Hvad der derefter vil ske med den originale LANBIX vil blive klart baseret på resultaterne af kampagnen. Hvis vores hypoteser ikke bekræftes, vil vi ifølge Lean-metoden nådesløst slippe af med det, eller det vil blive transformeret til noget nyt, for der er ikke noget værre end at lave et produkt, som ingen har brug for. Men nu kan vi sige, at det udførte arbejde ikke var forgæves, og takket være det er der dukket en hel gren af ​​parallelle produkter op, som vi arbejder aktivt på. Hvis det lykkes, vil LANBIX gå fra MVP-stadiet til slutfasen og udvikle sig i overensstemmelse med de forståelige klassiske love for produktmarkedsføring.

Jeg gentager, nu vil vi finde early adopters, virksomheder, der kan installere vores produkt for at indsamle feedback. Hvis du er interesseret i at teste LANBIX, så skriv i kommentarerne eller private beskeder.

Kilde

Kilde: www.habr.com