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

Det finns många kreativa medarbetare på LANIT-Integration. Idéer till nya produkter och projekt hänger bokstavligen i luften. Det kan ibland vara väldigt svårt att identifiera de mest intressanta. Därför har vi tillsammans utvecklat vår egen metodik. Läs den här artikeln om hur du väljer ut de bästa projekten och genomför dem.

I Ryssland, och i världen som helhet, pågår ett antal processer som leder till omvandlingen av IT-marknaden. Tack vare den ökade datorkraften och framväxten av server-, nätverks- och andra virtualiseringstekniker behöver marknaden inte längre en stor mängd hårdvara. Leverantörer föredrar allt oftare att arbeta direkt med kunder. IT-marknaden upplever en boom av outsourcing i alla dess former, från klassisk outsourcing till den nya vågen av outsourcing – ”molnleverantörer”. Infrastruktursystem och element blir mycket lättare att underhålla och konfigurera. Kvaliteten på mjukvaran växer för varje år och integratörens uppgifter förändras.

Hur vi arbetar med idéer

Produktstartriktning in "LANIT-integrationer" har funnits i över ett år. Vårt främsta mål är att skapa nya produkter och ta ut dem på marknaden. Det första vi började med var att organisera processen att skapa produkter. Vi har studerat många metoder, från klassisk till hype. Ingen av dem mötte dock våra behov. Då bestämde vi oss för att ta Lean Startup-metodiken som grund och anpassa den till våra uppgifter. Lean Startup är en teori om entreprenörskap skapad av Eric Ries. Den är baserad på principer, tillvägagångssätt och praxis för sådana koncept som lean manufacturing, kundutveckling och flexibel utvecklingsmetodik.

När det gäller den direkta inställningen till produktutvecklingsledning: vi uppfann inte hjulet på nytt, utan tillämpade en redan existerande utvecklingsmetodik KLUNGA, lägga till kreativitet, och nu kan det säkert kallas SCRUM-WATERFALL-BAN. SCRUM är, trots sin flexibilitet, ett mycket stelt system och lämpar sig för att leda ett team som bara ansvarar för en produkt/projekt. Som du förstår innebär den klassiska "integrations"-verksamheten inte att tilldela heltidsanställda tekniska specialister att arbeta med ett projekt (det finns undantag, men extremt sällan), eftersom alla förutom att arbeta med produkter är upptagna med aktuella projekt. Från SCRUM tog vi arbetsfördelningen i sprint, daglig rapportering, retrospektiv och roller. Vi valde Kanban för vårt uppgiftsflöde och det integrerade väl i vårt befintliga uppgiftsspårningssystem. Vi strukturerade vårt arbete genom att sömlöst integrera i den befintliga ordningen.
Innan en produkt går in på marknaden går den igenom 5 steg: idé, urval, koncept, MVP (mer information nedan) och produktion.

Idé

I detta skede finns det något tillfälligt - en idé. Helst en idé för att lösa ett befintligt problem eller klientproblem. Vi har ingen brist på idéer. Enligt den ursprungliga planen ska de genereras av anställda inom tekniska områden. För att en idé ska accepteras för vidareutveckling måste författaren fylla i "Idédesignmallen". Det finns bara fyra frågor: Vad? För vad? Vem behöver detta? Och om inte vår produkt, vad då?

Källa

Urval

Så snart den ifyllda mallen når oss påbörjas handläggnings- och urvalsförfarandet. Urvalsstadiet är det mest arbetskrävande. I detta skede bildas hypoteser om problem (det var inte för inte som jag nämnde i föregående stycke att en idé helst borde lösa en klients problem) och värdet av produkten. En skalhypotes bildas, d.v.s. hur vår verksamhet kommer att växa och blomstra. Problem- och expertintervjuer genomförs med potentiella kunder för att ge en preliminär bekräftelse på att vi kommer att ta fram något som behövs. Det krävs minst 10-15 intervjuer för att dra en slutsats om behovet av produkten.

Om hypoteserna bekräftas utförs en preliminär finansiell analys, den ungefärliga investeringsvolymen och investerarens eventuella vinst bedöms. Som ett resultat av detta skede föds ett dokument som heter Lean Canvas och presenteras för ledningen.

Koncept

I detta skede elimineras cirka 70 % av idéerna. Om konceptet godkänns börjar idéutvecklingsstadiet. Den framtida produktens funktionalitet formas, implementeringsvägar och optimala tekniska lösningar fastställs och affärsplanen uppdateras. Resultatet av detta steg är en teknisk specifikation för utveckling och ett detaljerat affärscase. Om vi lyckas går vi vidare till MVP- eller MVP-stadiet.

MVP eller MVP

MVP är en lägsta livskraftig produkt. De där. en produkt som inte är färdigutvecklad, men som redan kan ge värde och som utför sin funktionalitet. Det är absolut nödvändigt att vi i det här utvecklingsstadiet samlar in feedback från riktiga användare och gör ändringar.

Производство

Och det allra sista steget är produktionen. Inte mer än 5 % av produkterna når detta stadium. Dessa 5 % inkluderar endast de viktigaste, nödvändiga, livskraftiga och funktionella produkterna.

Vi har många idéer och har redan satt ihop en omfattande portfölj. Vi analyserar varje idé och gör allt för att säkerställa att den når slutskedet. Det är mycket trevligt att våra kollegor inte förblev likgiltiga för vår FoU-inriktning och tar en aktiv del i utvecklingen och implementeringen av produkter och lösningar.

Hur vi gjorde LANBIX

Låt oss titta på att skapa en produkt med ett verkligt exempel - LANBIX-produkten. Detta är ett "boxat" mjukvaru- och hårdvarusystem designat för att övervaka små IT-infrastrukturer och omedelbart varna beslutsfattare och affärsanvändare om fel som kontrolleras via en chatbot. Förutom övervakningsfunktionen innehåller LANBIX Help Desk-funktionalitet. Denna produkt är exklusiv för det marknadssegment som vi riktar in oss på. Detta är både vår fördel och vår smärta. Men först till kvarn. Jag ska genast säga att LANBIX är en levande produkt (det vill säga att den inte är slutgiltig i sin utveckling och är med i nästa omgång av MVP).

Så det första steget är idén. För att en idé ska födas behöver man problem, och vi hade dem, eller snarare inte vi, utan våra vänner. Nedan kommer vi att titta på flera verkliga situationer som inträffade inom olika affärsområden.

Ett litet förvaltningsbolag har två hus i Moskva-regionen. Personalen med PC är cirka 15 personer. Systemadministratören är en besökande frilansare (den smarte sonen till en av de omtänksamma invånarna). Det verkar som att förvaltningsbolagets verksamhet är svagt beroende av IT, men det speciella med denna verksamhet är månatlig rapportering till många myndigheter. Systemdisken för företagets chef (som, som vanligt, kombinerar många roller) har slut på ledigt utrymme. Naturligtvis hände detta inte plötsligt, varningen hängde i cirka 2 månader och ignorerades ständigt. Men en uppdatering kom, operativsystemet uppdaterades och, som tur var, frös det mitt i uppdateringen och klagade före "döden" över en upptagen disk. Datorn gick in i en cyklisk omstart. Medan vi löste problemet och fick rapporter missade vi rapporteringsdeadline. Det verkar som om ett trivialt fel har orsakat olika problem: från förluster till rättstvister och administrativt ansvar.

Källa

En liknande incident inträffade i ett stort holdingbolag, som förenar många små företag, med en enda teknisk supporttjänst för hela kontoret. På en av avdelningarna gick ekonomichefens dator sönder. Det hade varit känt länge att den kunde gå sönder (datorn saktade desperat ner och värmdes upp), men chefsrevisorn kom aldrig att skicka en förfrågan till teknisk support. Naturligtvis gick det sönder exakt på lönedagen och avdelningens anställda stod utan pengar i flera dagar.

Ett litet företag inom mindre partihandel hade en försäljningswebbplats, som var värd på en extern sida. Vi fick veta om dess otillgänglighet via telefon från en vanlig kund. Vid tidpunkten för samtalet hade platsen legat nere i cirka tre timmar. Det tog ytterligare ett par timmar att hitta den person som ansvarade för sajten och ytterligare två för att åtgärda problemet. Följaktligen var sajten otillgänglig under nästan hela arbetsdagen. Enligt företagets kommersiella direktör kostade denna driftstopp dem cirka 1 miljon rubel.

Jag råkade själv ut för en liknande situation när jag kom för en tid på kliniken och skulle gå till VHI-registreringen. De kunde inte skicka mig till doktorn av en trivial anledning - det var en strömstörning på morgonen, och efter olyckan fungerade inte deras posttjänst och en viss tjänst för att kommunicera med försäkringsbolaget. Som svar på min fråga, var är dina administratörer, fick jag veta att deras admin kommer och besöker dem en gång i veckan. Och nu (vid den tiden var klockan redan 16:00) tar han inte telefonen. Under minst 7 timmar var kliniken avskuren från omvärlden och kunde inte tillhandahålla betaltjänster.

Vad har alla dessa fall gemensamt? Absolut alla problem hade kunnat förhindras i förväg. Med snabb respons från IT-personalen hade skadorna kunnat minskas. Detta skulle vara möjligt om de tidiga symtomen tolkades korrekt av användarna.

Vi har identifierat problemhypoteser:

betydande monetära och anseendeförluster på grund av den låga reaktionshastigheten på fel i IT-infrastrukturen;
feltolkning av tidiga symtom på fel av användare.

Vad kan kunden göra med dem, och hur undviker man liknande situationer i framtiden? Det finns inte många alternativ:

anlita en högt kvalificerad systemadministratör och få honom att arbeta samvetsgrant;
outsourca IT-underhåll till ett specialiserat tjänsteföretag;
självständigt implementera ett övervaknings- och felrapporteringssystem;
ge utbildning till användare/företagspersonal i grunderna för datorkunskap.

Låt oss lösa det tredje alternativet. Låt oss erbjuda ett övervakningssystem till dem som inte använder det av olika anledningar.

Lyrisk utvikning. Olika system för att övervaka IT-tjänster på företagsmarknaden har använts under lång tid och deras fördelar är inte ifrågasatta. Jag pratade med företrädare för stora företag, tittade på hur relationen mellan verksamhet och IT byggdes upp. Den tekniska chefen för ett stort maskinbyggande företag har lagt ut underhållet av IT-infrastrukturen på entreprenad till ett externt företag, men han är själv fortfarande insatt i alla frågor. På hans kontor hänger en stor övervakningssystemskärm med indikatorer på status för IT-tjänster. De mest kritiska ingår i systemet. När som helst kan den tekniska chefen ta reda på hur infrastrukturen står till, vad som händer, var problemet finns, om de ansvariga har underrättats och om problemet håller på att lösas.

Berättelserna ovan fick vårt team att fundera på hur man skapar ett optimalt övervakningssystem för små företag. Som ett resultat föddes LANBIX - ett övervakningssystem som kan användas av absolut vem som helst utan någon IT-kunskap. Huvudsyftet med systemet är enkelt, liksom alla system som syftar till att öka kontinuiteten och tillgängligheten - att minska monetära och andra förluster i händelse av oplanerad driftstopp. Enheten är utformad för att till ett minimum minska tiden mellan "något är trasigt" och "problemet har åtgärdats."

För att bekräfta hypoteserna genomfördes problemintervjuer. Jag kunde inte föreställa mig hur mycket folk skulle vara villiga att berätta utan att försöka sälja till dem. Varje samtal varade i minst 1,5 timme och vi fick mycket information som var användbar för vidare utveckling.

Låt oss sammanfatta resultatet av detta steg:

det finns en förståelse för problemet,
förståelse för värde - det finns,
Det finns en idé till en lösning.

Den andra etappen var mer detaljerad. Baserat på dess resultat var vi tvungna att presentera för ledningen, som i huvudsak spelar rollen som en investerare, ett affärscase (samma Lean Canvas) för att fatta ett beslut om produktens framtida öde.

Vi började med marknadsundersökningar och konkurrensanalyser för att ta reda på vem, vad och, viktigast av allt, hur de gör på den här marknaden.

Det visade sig följande.

Det finns inga färdiga boxade övervakningssystem på marknaden för vårt segment (småföretag), med undantag för ett par eller tre, som jag av uppenbara skäl inte kommer att prata om.
Våra främsta konkurrenter är konstigt nog systemadministratörer med hemskrivna skript och "tillägg" till övervakningssystem med öppen källkod.
Det finns ett tydligt problem med att använda övervakningssystem med öppen källkod. Det finns ett system, det finns en enorm mängd information om hur man fungerar och modifierar systemet för att passa dina behov. Av de administratörer jag intervjuade erkände många att de inte hade tillräcklig kompetens för att genomföra sina idéer på egen hand. Men de kan inte erkänna detta för ledningen av rädsla för uppsägning. Det visar sig vara en ond cirkel.

Vi gick sedan vidare till att analysera behoven hos våra potentiella kunder. Vi har själva identifierat ett segment av små organisationer som av någon anledning inte har en egen IT-tjänst, där antingen en inkommande systemadministratör, en frilansare eller ett tjänsteföretag ansvarar för IT. Det var inte IT-sidan som bestämde sig för att gå in, utan affärssidan, som erbjuder grundare och företagare ett verktyg för att förbättra kvaliteten på IT-infrastrukturtjänster. En produkt som ska hjälpa ägare att säkra sin verksamhet, men samtidigt tillföra arbete till de personer som ansvarar för IT. En produkt som ger företag ett verktyg för att övervaka kvaliteten på IT-stödet.

Som ett resultat av bearbetningen av mottagna data föddes den första listan med krav (en sorts grov eftersläpning) för den framtida produkten:

övervakningssystemet måste baseras på en öppen källkodslösning och som ett resultat billigt;
enkel och snabb att installera;
bör inte kräva specifik kunskap inom IT, även en revisor (på inget sätt ville jag förolämpa representanter för detta yrke) ska kunna distribuera och konfigurera systemet;
ska automatiskt upptäcka objekt för övervakning på nätverket;
bör automatiskt (och helst automatiskt) installera övervakningsagenter;
måste kunna övervaka externa tjänster, åtminstone ett CRM-system och en säljande webbplats;
bör meddela både företaget och systemadministratören om problem;
graden av djup och "språk" för varningar bör vara olika för administratören och verksamheten;
systemet måste levereras på egen hårdvara;
järn ska vara så tillgängligt som möjligt;
systemet bör vara så oberoende som möjligt av yttre faktorer.

Därefter beräknades investeringar i produktutveckling (inklusive arbetskostnader för anställda på tekniska avdelningen). En skiss över affärsmodellen togs fram och enhetsekonomin för produkten beräknades.

Etappresultat:

produktstock på hög nivå;
en formulerad affärsmodell eller skalhypotes som ännu inte har testats i praktiken.

Låt oss gå vidare till nästa steg - koncept. Här befinner vi oss som ingenjörer i vårt inhemska element. Det finns ”önskelistor” som bryts ner i komponenter/delsystem/funktioner, sedan förvandlas de till tekniska specifikationer/användarberättelser, sedan till ett projekt osv. Jag kommer inte att uppehålla mig i detalj vid processen att förbereda en rad alternativa alternativ; låt oss gå direkt till kraven och de valda metoderna för deras implementering.

Krav
beslutet

Det bör vara ett öppet övervakningssystem;

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

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

Vi erbjuder ett installerat system så att användaren bara behöver slå på enheten och konfigurera den lite, liknande en router.

Låt oss stänga interaktionen med enheten till något enkelt och begripligt för alla.

Låt oss skriva vår egen chatbot för en av de välkända instant messengers och överföra all interaktion med systemet till den.

Systemet bör:

automatiskt upptäcka objekt som krävs för övervakning på nätverket;
automatiskt installera övervakningsagenter;
Kunna övervaka externa tjänster, åtminstone ett CRM-system och en säljande hemsida.

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

automatisk objektdetektering;
automatisk installation av agenter;
övervaka tillgängligheten av externa tjänster.

Systemet bör:

meddela både verksamheten och systemadministratören om problem;
kunna övervaka externa tjänster, åtminstone ett CRM-system och en säljande webbplats. Graden av djup och ”språk” för meddelanden bör vara olika för administratören och verksamheten.
Systemet ska inte kräva specifik IT-kunskap, även en revisor ska kunna distribuera och konfigurera systemet.

Låt oss lägga till olika typer av meddelanden för olika typer av användare. De skiljer sig åt i tonhöjd och djup. En företagsanvändare kommer att få meddelanden som "allt är bra, men Ivanovs dator kommer snart att dö." Administratören får ett komplett meddelande om felet, vem, hur och vad som hände eller kunde hända.
Låt oss lägga till möjligheten att använda posten från en ytterligare ansvarig person, så att han i händelse av ett haveri kommer att få ett meddelande.
Låt oss lägga till interaktion med externa tjänsteleverantörer baserat på att skicka e-postmeddelanden med förberedd text, eftersom Det är mejlet som ger upphov till händelsen.
All interaktion med systemet kommer att kopplas till en chatbot, kommunikationen sker i en dialogstil.

Tillägg:

Låt oss lägga till funktionen "chatta med administratören" så att användaren kan skicka ett meddelande till administratören som beskriver problemet direkt.

Systemet måste levereras på egen hårdvara.
Järn måste finnas tillgängligt.
Systemet ska vara så oberoende som möjligt av omgivningen.

Låt oss ta en färdig och billig Raspberry PI-dator.
Vi kommer att designa ett avbrottsfritt strömförsörjningskort.
Låt oss lägga till ett modem för att vara oberoende av det lokala nätverkets tillstånd.
Vi kommer att rita en vacker byggnad.

Vi har nu tre delsystem med egna krav och vision för deras implementering:

hårdvara undersystem;
övervakningsdelsystem;
delsystem för användarinteraktion.

Vi utvecklade en preliminär design för hårdvaruundersystemet. Jaja! Efter att ha brutit mot alla regler för agile utvecklade vi ett dokument, eftersom tillverkningsanläggningar arbetar med dokument. För de återstående delsystemen identifierade vi användare (personer), förberedde användarberättelser och skrev uppgifter för utveckling.

Detta avslutar konceptstadiet och resultatet är:

projekt för en hårdvaruplattform;
formulerad vision i form av användarberättelser för de återstående två delsystemen;
en mjukvaruprototyp implementerad som en virtuell maskin;
en prototyp av hårdvaran, implementerad i form av ett stativ, där hårdvarulösningarna faktiskt testades för styrka;
testning utförd av våra administratörer.

Problemen i detta skede var mestadels organisatoriska och relaterade till bristande kunskap hos ingenjörspersonalen i de juridiska och redovisningsmässiga aspekterna av försäljning. De där. Det är en sak att ta reda på vad och hur man ska sälja, och en helt annan att ställas inför en hänsynslös juridisk maskin: patent, utvecklingsuppgifter, registrering, EULA och mycket mer som vi som kreativa människor från början inte tog hänsyn till.

Det var ännu inget problem, utan snarare en svårighet i samband med utformningen av kapslingarna. Vårt team består endast av ingenjörer, så den första versionen av fodralet "byggdes" av plexiglas av vår elektronikspecialist.

Kroppen såg milt sagt kontroversiell ut, särskilt för allmänheten, bortskämd av modern teknik. Det fanns naturligtvis kännare bland den äldre generationen av "Kulibins" - byggnaden väckte nostalgiska känslor hos dem. Det beslutades att tillverka och designa höljet på nytt, eftersom det gamla, förutom estetiska brister, också hade strukturella - plexiglaset tålde inte montering och demontering av enheten väl och tenderade att spricka. Jag ska berätta om produktionen av fallet vidare.

Och nu är vi nära mållinjen – MVP. Naturligtvis är detta ännu inte en slutproduktionsprodukt, men den är redan användbar och värdefull. Huvudmålet med detta steg är att starta cykeln "skapa-utvärdera-lär". Det är exakt det stadiet som LANBIX befinner sig på.

I "skapa"-stadiet skapade vi en enhet som utför den deklarerade funktionen. Ja, det är inte perfekt än, och vi fortsatte att jobba på det.

Låt oss återgå till tillverkningen av kroppen, d.v.s. till uppgiften att förvandla vår enhet från nostalgisk till modern. I början letade jag igenom marknaden efter skåptillverkare och industridesigntjänster. För det första finns det inte många företag som producerar fodral på den ryska marknaden, och för det andra är kostnaden för industriell design i detta skede oöverkomligt hög, cirka 1 miljon rubel.

De kontaktade vår marknadsavdelning för designen, den unga designern var redo för kreativa experiment. Vi beskrev vår vision av skrovet (efter att tidigare ha studerat de bästa exemplen på skrovkonstruktion), och han gjorde det i sin tur till ett konstverk. Allt som återstår är att producera den. Vi, stolta över vår design, vände oss till våra partners. Deras VD krossade genast våra fantasier genom att helt kostnadsfritt peka ut saker som inte gick att producera på vårt valda sätt. Fodralet kan tillverkas, och det kommer inte att vara värre än Apples, men kostnaden för fodralet blir tre till fyra gånger dyrare än alla elektroniska komponenter. Efter en rad operationer och godkännanden har vi designat ett hus som kan tillverkas. Ja, det är inte så vackert som vi planerat, men det är idealiskt för att uppnå nuvarande mål.

Resultat av steget: den första satsen enheter redo för strid och testning.

Och nu är det svåraste steget "utvärdera", och med vår produkt är vi precis vid denna punkt. Vi kan bara utvärdera baserat på resultaten från användning av riktiga kunder och inga antaganden fungerar här. Vi behöver dessa "early adopters" för att ge feedback och göra de ändringar i produkten som verkligen behövs. Frågan uppstår: var ska man få kunder och hur man övertygar dem att delta i experimentet?

Av alla möjliga alternativ valde vi en klassisk uppsättning digitala verktyg: målsida och reklamkampanj på sociala nätverk.

Processen har redan inletts, men det är för tidigt att tala om resultat, även om det redan finns svar och vi har fått bekräftelse på många av våra hypoteser. En trevlig överraskning var reaktionen från representanter för helt andra affärssegment, mycket större än de vi förväntade oss. Det vore dumt att strunta i de nya introduktionerna, och baserat på resultaten av intervjuerna beslutades det att lansera en parallell LANBIX-linje kallad LANBIX Enterprise. Vi har lagt till stöd för distribuerad infrastruktur, övervakning av Wi-Fi-nätverk med felsökning och lokalisering och övervakning av kvaliteten på kommunikationskanaler. Tjänsteföretagen uttryckte det största intresset för lösningen. Samtidigt spelar de enheter vi redan har utvecklat en viktig roll i driften av lösningarna.

Vad kommer hända härnäst

Vad som kommer att hända härnäst med den ursprungliga LANBIX kommer att bli klart baserat på resultaten av kampanjen. Om våra hypoteser inte bekräftas, enligt Lean-metoden, kommer vi hänsynslöst att bli av med den eller så förvandlas den till något nytt, för det finns inget värre än att göra en produkt som ingen behöver. Men nu kan vi säga att det utförda arbetet inte var förgäves och tack vare det har det dykt upp en hel gren av parallella produkter som vi arbetar aktivt med. Om det lyckas kommer LANBIX att gå från MVP-stadiet till det sista steget och utvecklas enligt de begripliga klassiska lagarna för produktmarknadsföring.

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

Källa

Källa: will.com

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