🥇Hur vi arbetar med idéer, och hur LANBIX föddes

På «LANIT-Integration» finns det många kreativa medarbetare. Idéer för nya produkter och projekt svävar bokstavligen i luften. Att identifiera de mest intressanta kan ibland vara mycket svårt. Därför har vi tillsammans utvecklat vår egen metodik. Hur vi väljer ut de bästa projekten och genomför dem kan du läsa om i denna artikel.

I Ryssland, och faktiskt i världen i stort, pågår en rad processer som leder till en transformation av IT-marknaden. Tack vare ökade beräkningskapaciteter och framväxten av server-, nätverks- och annan virtualisering behöver marknaden inte längre så mycket 'hårdvara'. Leverantörer föredrar allt oftare att arbeta direkt med kunderna. Outsourcing blomstrar på IT-marknaden i alla dess former, från klassisk outsourcing till den nya vågen av outsourcingleverantörer - 'molnleverantörer'. Infrastruktursystem och element blir avsevärt enklare att underhålla och konfigurera. Kvaliteten på mjukvaran ökar för varje år och uppgifterna för integratörerna förändras.

Hur vi arbetar med idéer

Produktstartup-riktningen inom «LANIT-Integration» har funnits i över ett år. Vårt huvudmål är att skapa nya produkter och lansera dem på marknaden. Det första vi började med var att organisera själva processen för produktutveckling. Vi har studerat många metodologier, från klassiska till trendiga. Men ingen av dem uppfyllde våra behov. Då bestämde vi oss för att basera oss på Lean Startup-metodologin och anpassa den efter våra behov. 'Lean Startup' är en entreprenörsteori skapad av Eric Ries. Den bygger på principerna, tillvägagångssätten och praktikerna från koncept som lean production, customer development och agil utvecklingsmetodik.

När det gäller själva tillvägagångssättet för produktutveckling: vi uppfann inte hjulet, utan använde en redan befintlig utvecklingsmetodologi SCRUM, med kreativitet tillagt, kan det nu stolt kallas SCRUM-WATERFALL-BAN. SCRUM, trots sin flexibilitet, är ett mycket strikt system som är lämpligt för att hantera ett team som ansvarar för endast en produkt/projekt. Som ni förstår, förutsätter klassisk "integrator”-verksamhet inte att tekniska specialister avsätts på heltid för att arbeta med ett enda projekt (det förekommer undantag, men extremt sällan), eftersom alla, förutom att arbeta med produkter, är upptagna med pågående projekt. Från SCRUM har vi tagit uppdelningen av arbete i sprinter, daglig rapportering, retrospektiv och roller. För att hantera flödet av uppgifter valde vi Kanban, och det har integrerats utmärkt i vårt befintliga system för uppgiftsspårning. Vi har organiserat arbetet genom att smidigt integrera oss i den redan existerande ordningen.
Innan en produkt lanseras på marknaden genomgår den 5 faser: idé, urval, koncept, MVP (mer om detta nedan) och produktion.

Tanken

I detta skede finns något efemärt – en idé. Idealt sett är det en idé för att lösa ett befintligt problem eller en uppgift för kunden. Vi har inga brist på idéer. Initialt ska de genereras av anställda inom teknikavdelningarna. För att en idé ska accepteras för vidare utveckling måste författaren fylla i "Idéformatet". Där finns totalt fyra frågor: Vad? För vad? Vem behöver detta? Om det inte är vår produkt, vad är det då?

Källa

Urval

När det ifyllda formatet kommer till oss startar behandlings- och urvalsprocessen. Urvalssteget är det mest arbetskrävande. I detta skede formuleras hypoteser om problem (jag nämnde inte förgäves i föregående stycke att idén idealiskt sett ska lösa kundens problem) och produktens värde. En hypotes om skala formuleras, det vill säga hur vårt företag planerar att växa och blomstra. Problematiska och expertrelaterade intervjuer genomförs med potentiella kunder för preliminär bekräftelse av att vi planerar att producera något användbart. Minst 10-15 intervjuer krävs för att dra slutsatsen att produkten är nödvändig.

Om hypoteserna bekräftas genomförs en preliminär ekonomisk analys, som bedömer den ungefärliga investeringsvolymen och den potentiella inkomsten för investeraren. Som ett resultat av detta steg föds ett dokument som kallas Lean Canvas och presenteras för ledningen.

Konceptet

I det här skedet filtreras cirka 70% av idéerna bort. Om konceptet godkänns börjar vi med att vidareutveckla idén. Funktionaliteter för den framtida produkten formuleras, implementeringsvägar och optimala tekniska lösningar definieras, och affärsplanen aktualiseras. Resultatet av detta skede är en teknisk specifikation för utveckling och en detaljerad affärsplan. Om allt går bra går vi vidare till stadiet för MDP eller MVP.

MDP eller MVP

MDP är en minimalt livskraftig produkt. Det vill säga, en produkt som inte är helt färdigutvecklad, men ändå kan ge värde och utföra sin funktion. Under denna utvecklingsfas samlar vi nödvändigtvis feedback från verkliga användare och gör justeringar.

Tillverkning

Den allra sista fasen är tillverkning. Endast 5% av produkterna når denna fas. Dessa 5% omfattar endast de mest viktiga, nödvändiga, livskraftiga och funktionella produkterna.

Vi har många idéer och en omfattande portfölj har redan samlats in. Vi undersöker varje idé och gör allt för att den ska nå finalskedet. Det är mycket trevligt att kollegorna har visat stort engagemang för vår R&D-inriktning och aktivt deltar i utvecklingen och implementeringen av produkter och lösningar.

Hur vi skapade LANBIX

Låt oss titta på skapandet av en produkt genom ett verkligt exempel — produkten LANBIX. Det är en 'boxad' programvaru- och hårdvarukomplex avsedd för att övervaka små IT-infrastrukturer och snabbt informera berörda personer och affärsanvändare om fel via en chatbot. Förutom övervakningsfunktionen inkluderar LANBIX även Help Desk-funktionalitet. Denna produkt är exklusiv för den marknadssegment vi riktar oss mot. Det är både vår fördel och vår utmaning. Men allt i tur och ordning. Jag ska direkt säga att LANBIX är en levande produkt (det vill säga den är inte slutgiltig i sin utveckling och är för närvarande i nästa MVP-cykel).

Så, det första steget är idén. För att en idé ska födas behövs problem, och vi hade dem, eller snarare våra bekanta hade dem. Nedan kommer vi att titta på några verkliga situationer som inträffat i olika affärsområden.

Ett litet förvaltningsföretag hanterar två byggnader i Moskva-regionen. Antalet anställda med datorer är runt 15 personer. Systemadministratören är en frilansare (en clever son till en av de boende). Det verkade som om förvaltningsbolagets verksamhet knappt berodde på IT, men det som gör detta företag unikt är den månatliga rapporteringen till många instanser. Det fanns inte tillräckligt med utrymme kvar på systemdisken hos företagsledaren (som vanligt samlar på sig många roller). Naturligtvis hände detta inte plötsligt, en varning hade hängt i nästan 2 månader och konstant ignorerats. Men en uppdatering kom, operativsystemet uppdaterades och, som tur var, fastnade det i mitten av uppdateringen och klagade innan "döden" på den upptagna disken. Datorn gick in i en cyklisk omstart. Medan de rattade med problemet och hämtade rapporterna missade de inlämningsfristen för redovisningen. Det verkade som om en trivial defekt orsakade många problem: från förluster till rättsliga tvister och administrativt ansvar.

Källa

Ett liknande fall inträffade i en stor koncern som förenar många små företag, med en gemensam teknisk supporttjänst för hela kontoret. I en av avdelningarna gick huvudbokförarens dator sönder. Att den skulle gå sönder var känt länge (datorn segade sig och blev överhettad), men huvudbokförarens händer hann aldrig nå till att skicka en begäran till teknisk support. Naturligtvis gick den sönder precis på löneutbetalningsdagen, och avdelningens anställda satt utan pengar i flera dagar.

Ett litet företag som sysslar med detaljhandel hade en försäljningswebbplats som hostades på en extern plattform. De fick veta om dess otillgänglighet via telefon från en återkommande kund. Vid tidpunkten för samtalet hade webbplatsen varit nere i cirka tre timmar. Det tog ytterligare några timmar att hitta den ansvariga för webbplatsen och två timmar till för att åtgärda felet. Därav var webbplatsen nästan hela arbetsdagen otillgänglig. Enligt företagets kommersiella direktör kostade denna driftstopp dem omkring 1 miljon rubel.

Jag har själv stött på en liknande situation när jag kom till vårdcentralen och skulle gå till registreringen för DMS. De kunde inte skicka mig till läkaren av en enkel anledning – på morgonen var det ett strömavbrott, och efter olyckan fungerade varken deras posttjänst eller något sätt att kontakta försäkringsbolaget. När jag frågade om var deras administratörer var fick jag veta att de har en inhyrd administratör som kommer en gång i veckan. Och just nu (vid den tidpunkten var klockan redan 16:00) svarade han inte i telefon. Vårdcentralen var avskärmad från omvärlden i minst 7 timmar och kunde inte erbjuda betaltjänster.

Vad förenar alla dessa fall? Absolut alla problem kunde ha förhindrats i förväg. Med en snabb reaktion från de som arbetar med IT hade man kunnat minska den skada som orsakats. Detta skulle även ha varit möjligt med en korrekt tolkning av tidiga symptom från användarna.

Vi har identifierat problemhypoteserna:

betydande ekonomiska och ryktemässiga förluster på grund av låg reaktionstid på fel i IT-infrastrukturen;
felaktig tolkning av tidiga symptom på fel från användarna.

Vad kan beställaren göra åt dem och hur undvika liknande situationer i framtiden? Alternativen är inte så många:

anställa en högt kvalificerad systemadministratör och se till att han arbetar ansvarsfullt;
överlämna IT-service till ett specialiserat serviceföretag;
själva implementera ett övervakningssystem och notifiering om fel;
genomföra utbildning av användare/affärspersonal i grundläggande datorkunskap.

Vi stannar vid det tredje alternativet. Låt oss erbjuda ett övervakningssystem till dem som inte använder det av olika skäl.

Lyriskt avsnitt. Olika system för övervakning av IT-tjänster har använts länge på företagsmarknaden, och deras nytta ifrågasätts inte. Jag har pratat med representanter för stora företag och sett hur relationerna mellan affär och IT är uppbyggda. Teknikdirektören för ett stort maskinbyggnadsföretag har överlåtit underhållet av IT-infrastruktur till ett externt företag, men han håller sig själv informerad om allt som händer. I hans kontor hänger en stor skärm med indikatorer för statusen på IT-tjänsterna. I systemet är de mest kritiska aspekterna registrerade. När som helst kan teknikdirektören få veta hur infrastrukturen mår, vad som pågår, var problemet ligger, om ansvarsfulla personer har meddelats och om problemet löses.

De nämnda historierna fick vårt team att fundera på hur vi kan skapa ett optimalt övervakningssystem för småföretag. Resultatet blev LANBIX — ett övervakningssystem som vem som helst kan installera utan förkunskaper inom IT. Systemets huvuduppgift är enkel, precis som alla system som syftar till att öka kontinuitet och tillgänglighet — att minska ekonomiska och andra förluster vid oförutsedda avbrott. Målet är att minimera tiden mellan "jag har något som är trasigt" och "problemet är löst".

För att bekräfta hypoteserna genomfördes problemintervjuer. Jag kunde inte föreställa mig hur mycket folk är villiga att berätta om man inte försöker sälja något till dem. Varje samtal varade i minst 1,5 timmar, och vi fick en massa information som är användbar för vidare utveckling.

Sammanfattar resultatet av detta steg:

förståelse för problemet — check,
förståelse för värdet — check,
idé för lösningen — check.

Det andra steget var mer detaljerat. Utifrån resultatet skulle vi presentera för ledningen, som i grunden agerar som investerare, en affärsplan (den så kallade Lean Canvas) för att fatta beslut om produktens framtid.

Vi började med att undersöka marknaden och göra en konkurrensanalys för att ta reda på vem, vad och, viktigast av allt, hur de verkar på denna marknad.

Följande framkom.

Det finns inga färdiga övervakningssystem för vår segment (småföretag) på marknaden, förutom ett par tre stycken som jag av självklara skäl inte kommer att nämna.
Våra största konkurrenter är, lite förvånande, systemadministratörer som använder skräddarsydda skript och "tillägg" till övervakningssystem med öppen källkod.
Det finns ett tydligt problem med användningen av övervakningssystem med öppen källkod. Det finns ett system och en stor mängd information om hur man arbetar med och anpassar systemet efter sina behov. Av de administratörer jag har intervjuat erkände många att de saknar kompetens för att genomföra sina idéer på egen hand. Dessutom kan de inte erkänna detta för ledningen av rädsla för att bli avskedade. Det blir en ond cirkel.

Sedan gick vi över till att analysera behoven hos våra potentiella kunder. Vi identifierade ett segment av små organisationer som, av någon anledning, saknar en egen IT-avdelning, där IT ansvaras av antingen en tillfällig systemadministratör, en frilansare eller ett serviceföretag. Vi beslutade oss för att gå in från affärssidan, inte IT-sidan, och erbjuda grundarna och företagsägarna ett verktyg för att förbättra kvaliteten på IT-infrastrukturen. Produkten ska hjälpa ägare att säkra sin verksamhet, men samtidigt kommer den att öka arbetsbelastningen för dem som ansvarar för IT. Produkten ska ge företaget ett verktyg för att kontrollera kvaliteten på IT-support.

Som ett resultat av bearbetningen av de insamlade uppgifterna föddes den första kravlistan (en ganska grov backlog) för den framtida produkten:

övervakningssystemet bör baseras på en lösning med öppen källkod och därmed vara billig;
enkel och snabb att installera;
bör inte kräva specifik IT-kompetens, även en revisor (jag vill under inga omständigheter förolämpa personer inom det yrket) bör kunna installera och konfigurera systemet;
bör automatiskt upptäcka objekt att övervaka i nätverket;
bör automatiserat (och helst automatiskt) installera övervakningsagenter;
bör kunna övervaka externa tjänster, minst ett CRM-system och en försäljningswebbplats;
bör varna både affärsverksamheten och systemadministratören om problem;
djupet och "språket" för varningar bör vara olika för administratören och affären;
systemet bör levereras på egen hårdvara;
hårdvaran bör vara så tillgänglig som möjligt;
Systemet ska vara så oberoende som möjligt av externa faktorer.

Därefter beräknades investeringarna för produktutvecklingen (inklusive arbetstimmar för personalen i teknikavdelningen). En skiss av affärsmodellen har förberetts och produktens enhetsekonomi har beräknats.

Resultatet av etappen:

ett högnivå-produkts backlog;
en formulerad affärsmodell eller skala-hypotes som fortfarande behöver testas i praktiken.

Vi går vidare till nästa steg — konceptet. Här går vi som ingenjörer in i vårt rätta element. Det finns "önskemål" som bryts ner i komponenter/subsystem/funktioner, och vidare omvandlas de till specifikationer/användarhistorier, sedan till projekt osv. Jag kommer inte att gå in på processen för att förbereda ett antal alternativa alternativ, vi går direkt till kraven och de valda metoderna för deras genomförande.

Krav
Lösning

Det ska vara ett öppet övervakningssystem;

Vi tar ett övervakningssystem med öppen källkod.

Systemet ska vara enkelt och snabbt att installera;
det får inte kräva specifik IT-kunskap. Även en revisor ska kunna installera och konfigurera systemet.

Vi erbjuder ett förinstallerat system, så att användaren bara behöver slå på enheten och göra några grundläggande inställningar, på liknande sätt som en router.

Vi ska hålla interaktionen med enheten enkel och förståelig för alla.

Vi kommer att skriva vår egen chattbot för en av de kända meddelande-apparna och föra all interaktion med systemet genom den.

Systemet ska:

automatiskt upptäcka objekt som kräver övervakning i nätverket;
automatiskt installera övervakningsagenter;
Kunna övervaka externa tjänster, åtminstone CRM-system och försäljningssajter.

Vi skriver tillägg för övervakningssystemet för:

automatiskt upptäckta objekt;
automatiskt installerade agenter;
övervakning av tillgänglighet för externa tjänster.

Systemet ska:

skicka meddelanden om problem både till företaget och till systemadministratören;
kunna övervaka externa tjänster, åtminstone CRM-system och försäljningssajter. Djupet och "språket" för meddelandena ska vara olika för administratörer och företag.
Systemet får inte kräva specifik IT-kunskap; även en revisor ska kunna installera och konfigurera systemet.

Vi lägger till olika typer av aviseringar för olika användartyper. De skiljer sig åt i presentation och djup. En affärsanvändare får aviseringar av typen "allt är bra, men Ivanovs dator kommer snart att slockna". Systemadministratören får ett fullständigt felmeddelande om vem, hur och vad som har hänt eller kan hända.
Vi lägger till möjligheten att använda e-post för en extra ansvarig person, så att de får meddelandet vid fel.
Vi lägger till interaktion med externa tjänsteleverantörer baserat på att skicka e-post med förberett meddelande, eftersom just e-post ger grund för att registrera en incident.
All interaktion med systemet låses till en chattbot, där kommunikationen sker i dialogstil.

Tillägg:

Vi lägger till funktionen "chatt med administratören", så att användaren kan skicka ett meddelande direkt till administratören för att beskriva problemet.

Systemet ska levereras på egen hårdvara.
Hårdvaran måste vara tillgänglig.
Systemet ska vara maximalt oberoende av omgivningen.

Vi tar en färdig och billig dator Raspberry PI.
Vi kommer att designa ett kretskort för obehindrad strömförsörjning.
Vi lägger till en modem för oberoende av det lokala nätverks tillstånd.
Vi designar ett snyggt hölje.

Vi har tre delsystem med sina egna krav och visioner för deras implementering:

delssystem för hårdvara;
delssystem för övervakning;
delssystem för användarinteraktion.

För delsystemet för hårdvara har vi utvecklat en skissprojekt. Ja, vi har brutit mot alla regler för agil utveckling, vi har skapat ett dokument, eftersom tillverkare arbetar just med dokument. För de andra delsystemen har vi skapat användare (personas), förberett användarhistorier och skrivit uppgifter för utveckling.

I detta skede avslutas konceptet, och resultatet blev:

ett projekt för hårdvaruplattformen;
en formulerad vision i form av användarhistorier för de andra två delsystemen;
en prototyp av programvarudelen, genomförd som en virtuell maskin;
en prototyp av hårddelen, genomförd som en monter där de faktiska hårdlösningarna testades;
testning utförd av våra administratörer.

Problemen i det här skedet var huvudsakligen organisatoriska och relaterade till ingenjörsteamets bristande kunskaper inom juridiska och bokföringsaspekter av försäljning. Det är en sak att komma på vad och hur man ska sälja, och en helt annan att ställas inför en obarmhärtig juridisk maskin: patent, utvecklingsuppdrag, redovisningsfrågor, EULA och mycket annat som vi som kreativa personer initialt inte hade beaktat.

Det var mer ett besvär än ett problem, kopplat till designen av chassit. I vårt team finns enbart ingenjörer, så den första versionen av chassit blev 'snickrad' av vår elektronikexpert i plexiglas.

Chassit såg, milt sagt, diskutabelt ut, särskilt för en publik som är van vid modern teknik. Det fanns förstås entusiaster bland de äldre 'uppfinnarna' — chassit väckte nostalgiska känslor hos dem. Det beslutades att tillverka och projektera chassit på nytt, eftersom det gamla hade inte bara estetiska brister, utan även konstruktiva --- plexiglaset höll dåligt för montering och demontering av enheten och hade en tendens att spricka. Jag kommer att berätta mer om produktionen av chassit senare.

Och nu är vi nära mållinjen — MVP. Självklart är detta inte den slutliga serieprodukten, men den ger redan nytta och representerar värde. Huvudmålet i detta skede är att starta cykeln 'skapa - utvärdera - lära'. Det är här LANBIX befinner sig.

I 'skapa'-stadiet skapade vi en enhet som utför de angivna funktionerna. Ja, den är fortfarande inte perfekt och vi fortsätter att arbeta med den.

Vi återvänder till tillverkningen av chassit, det vill säga uppgiften att förvandla vår enhet från att väcka nostalgiska känslor till att bli modern. I början utforskade jag marknaden för producenter av chassin och industrial design-tjänster. För det första, det finns inte många företag som tillverkar chassin på den ryska marknaden, och för det andra, kostnaden för industriell design i detta skede är orimligt hög, runt 1 miljon rubel.

För designen kontaktade vi vår marknadsavdelning, en ung designer var redo för kreativa experiment. Vi lade fram vår vision för chassit (efter att ha studerat de bästa exemplen på chassibyggande), och han i sin tur förvandlade det till ett konstverk. Det återstod bara att producera det. Stolta över vår design, kontaktade vi våra partners. Deras VD krossade genast våra fantasier, helt gratis, genom att påpeka saker som var omöjliga att producera på det sätt vi valt. Chassit kan produceras, och det kommer inte att vara sämre än Apples, men kostnaden för chassit kommer att vara tre till fyra gånger dyrare än all elektronisk utrustning. Efter en rad operationer och godkännanden designade vi ett chassi som kan produceras. Ja, det är inte lika vackert som vi hade planerat, men perfekt för att uppnå de aktuella målen.

Resultatet av fasen: den första batchen av enheter, redo för strid och tester.

Och nu kommer det svåraste — fasen "utvärdera", och med vår produkt befinner vi oss just nu i denna punkt. Vi kan bara utvärdera baserat på resultaten av verkliga användare, och några antaganden fungerar inte här. Vi behöver de så kallade "tidiga användarna" för att ge feedback och göra de ändringar i produkten som verkligen behövs. Frågan uppstår: var hittar vi kunder och hur övertygar vi dem att delta i experimentet?

Av alla möjliga alternativ valde vi en klassisk uppsättning digitala verktyg: en landningssida och en reklamkampanj i sociala medier.

Processen har redan startat, men det är för tidigt att prata om resultaten, även om det redan finns feedback och vi har fått bekräftelse på många av våra hypoteser. En trevlig överraskning var responsen från representanter från helt andra affärssegment, mycket större än de vi hade förväntat oss. Det skulle vara dumt att ignorera de nya omständigheterna, och baserat på resultaten av genomförda intervjuer togs beslutet att starta en parallell serie LANBIX under namnet LANBIX Enterprise. Vi lade till stöd för distribuerade infrastrukturer, övervakning av Wi-Fi-nätverk med felsökning och lokalisering avproblem, samt övervakning av kommunikationskvalitet. Det största intresset för lösningen uttrycktes av tjänsteföretag. Samtidigt spelar våra redan utvecklade enheter en viktig roll i lösningarna.

Vad som kommer härnäst

Vad som kommer att hända med det ursprungliga LANBIX blir tydligt efter kampanjens resultat. Om våra hypoteser inte bekräftas kommer vi, enligt Lean-metodologin, oförsonligt att bli av med det eller så kommer det att omvandlas till något nytt, eftersom det inte finns något värre än att skapa en produkt som ingen behöver. Men redan nu kan vi säga att det utförda arbetet inte har varit förgäves och tack vare det har en hel gren av parallella produkter uppstått som vi aktivt arbetar med. Vid framgång kommer LANBIX att gå från MVP-stadiet till det slutliga stadiet och kommer att utvecklas enligt de klassiska principerna för produktmarknadsföring.

Jag upprepar, just nu vill vi hitta tidiga följare, företag som kan installera vår produkt för att samla feedback. Om du är intresserad av att testa LANBIX, skriv i kommentarerna eller i privata meddelanden.

Källa

Källa: habr.com

Hur vi arbetar med idéer och hur LANBIX föddes