Hoe wij met ideeën werken en hoe LANBIX is ontstaan

Bij LANIT-Integration werken veel creatieve medewerkers. Ideeën voor nieuwe producten en projecten hangen letterlijk in de lucht. Het kan soms erg moeilijk zijn om de meest interessante te identificeren. Daarom hebben we samen onze eigen methodiek ontwikkeld. Lees dit artikel over hoe u de beste projecten selecteert en implementeert.

In Rusland, en in de wereld als geheel, vinden een aantal processen plaats die leiden tot de transformatie van de IT-markt. Dankzij de toename van de rekenkracht en de opkomst van server-, netwerk- en andere virtualisatietechnologieën heeft de markt niet langer behoefte aan een grote hoeveelheid hardware. Leveranciers werken steeds liever rechtstreeks met klanten. De IT-markt ervaart een hausse aan outsourcing in al zijn vormen, van klassieke outsourcing tot de nieuwe golf van outsourcers – ‘cloudproviders’. Infrastructuursystemen en -elementen worden veel eenvoudiger te onderhouden en te configureren. De kwaliteit van software groeit ieder jaar en de taken van de integrator veranderen.

Hoe wij met ideeën werken

Opstartrichting product in "LANIT-integratie" bestaat al ruim een ​​jaar. Ons belangrijkste doel is om nieuwe producten te creëren en deze op de markt te brengen. Het eerste waar we mee begonnen was het organiseren van het proces van het maken van producten. We hebben veel methodieken bestudeerd, van klassiek tot hype. Geen van hen voldeed echter aan onze behoeften. Toen besloten we om de Lean Startup-methodiek als basis te nemen en deze aan te passen aan onze taken. De Lean Startup is een theorie over ondernemerschap bedacht door Eric Ries. Het is gebaseerd op de principes, benaderingen en praktijken van concepten als lean manufacturing, klantontwikkeling en flexibele ontwikkelingsmethodologie.

Wat de directe aanpak van productontwikkelingsmanagement betreft: we hebben het wiel niet opnieuw uitgevonden, maar een reeds bestaande ontwikkelingsmethodologie toegepast SCRUM, wat creativiteit toevoegt, en nu kan het gerust SCRUM-WATERFALL-BAN worden genoemd. SCRUM is, ondanks zijn flexibiliteit, een zeer rigide systeem en geschikt voor het aansturen van een team dat slechts verantwoordelijk is voor één product/project. Zoals u begrijpt, houdt de klassieke 'integratie'-business niet in dat fulltime technische specialisten aan één project worden toegewezen (er zijn uitzonderingen, maar uiterst zelden), omdat iedereen naast het werken aan producten ook bezig is met lopende projecten. Vanuit SCRUM hebben we de werkverdeling overgenomen in sprints, dagelijkse rapportage, retrospectives en rollen. We kozen voor Kanban voor onze takenstroom en het integreerde goed in ons bestaande taakvolgsysteem. We hebben ons werk gestructureerd door naadloos te integreren in de bestaande gang van zaken.
Voordat een product op de markt komt, doorloopt het 5 fasen: idee, selectie, concept, MVP (meer details hieronder) en productie.

Idee

In dit stadium is er iets vluchtigs: een idee. Idealiter een idee om een ​​bestaand probleem of klantprobleem op te lossen. Aan ideeën hebben we geen gebrek. Volgens het oorspronkelijke plan moeten ze worden gegenereerd door medewerkers van technische gebieden. Om ervoor te zorgen dat een idee geaccepteerd wordt voor verdere ontwikkeling, moet de auteur het “Idee Design Template” invullen. Er zijn slechts vier vragen: Wat? Waarvoor? Wie heeft dit nodig? En als het niet ons product is, wat dan?

Bron

Selectie

Zodra het ingevulde template ons bereikt, begint de verwerkings- en selectieprocedure. De selectiefase is het meest arbeidsintensief. In dit stadium worden probleemhypotheses gevormd (het was niet voor niets dat ik in de vorige paragraaf zei dat een idee idealiter het probleem van een klant zou moeten oplossen) en de waarde van het product. Er wordt een schaalhypothese gevormd, d.w.z. hoe ons bedrijf zal groeien en bloeien. Er worden probleem- en expertinterviews gehouden met potentiële klanten om een ​​voorlopige bevestiging te geven dat we iets gaan produceren dat nodig is. Er zijn minimaal 10-15 interviews nodig om een ​​conclusie te trekken over de noodzaak van het product.

Als de hypothesen worden bevestigd, wordt een voorlopige financiële analyse uitgevoerd, waarbij het geschatte investeringsvolume en de mogelijke inkomsten van de belegger worden beoordeeld. Als resultaat van deze fase wordt een document met de naam Lean Canvas geboren en gepresenteerd aan het management.

Concept

In dit stadium wordt ongeveer 70% van de ideeën geëlimineerd. Als het concept wordt goedgekeurd, begint de fase van ideeontwikkeling. De functionaliteit van het toekomstige product wordt gevormd, implementatiepaden en optimale technische oplossingen worden bepaald en het businessplan wordt bijgewerkt. Het resultaat van deze fase is een technische specificatie voor ontwikkeling en een gedetailleerde business case. Bij succes gaan we door naar de MVP- of MVP-fase.

MVP of MVP

MVP is een minimaal levensvatbaar product. Die. een product dat nog niet volledig ontwikkeld is, maar al waarde kan toevoegen en zijn functionaliteit vervult. Het is absoluut noodzakelijk dat we in deze ontwikkelingsfase feedback van echte gebruikers verzamelen en wijzigingen aanbrengen.

Productie

En de allerlaatste fase is de productie. Niet meer dan 5% van de producten bereikt dit stadium. Deze 5% omvat alleen de belangrijkste, noodzakelijke, levensvatbare en functionele producten.

We hebben veel ideeën en hebben al een omvangrijk portfolio samengesteld. Wij analyseren ieder idee en doen er alles aan om het de eindfase te laten bereiken. Het is heel prettig dat onze collega's niet onverschillig bleven tegenover onze R&D-richting en actief deelnemen aan de ontwikkeling en implementatie van producten en oplossingen.

Hoe we LANBIX hebben gemaakt

Laten we eens kijken naar het maken van een product aan de hand van een echt voorbeeld: het LANBIX-product. Dit is een “boxed” software- en hardwaresysteem dat is ontworpen voor het monitoren van kleine IT-infrastructuren en het onmiddellijk waarschuwen van besluitvormers en zakelijke gebruikers over storingen die worden beheerd via een chatbot. Naast de monitoringfunctie bevat LANBIX Help Desk-functionaliteit. Dit product is exclusief voor het marktsegment waarop wij ons richten. Dit is zowel ons voordeel als onze pijn. Maar eerst dingen eerst. Ik zal meteen zeggen dat LANBIX een levend product is (dat wil zeggen, het is nog niet definitief in zijn ontwikkeling en bevindt zich in de volgende MVP-ronde).

Dus de eerste fase is het idee. Om een ​​idee te laten ontstaan ​​heb je problemen nodig, en die hadden wij, of beter gezegd, niet wij, maar onze vrienden. Hieronder zullen we verschillende reële situaties bekijken die zich in verschillende bedrijfsgebieden hebben voorgedaan.

Een kleine beheermaatschappij onderhoudt twee huizen in de regio Moskou. Het personeelsbestand met pc's bedraagt ​​ongeveer 15 personen. De systeembeheerder is een bezoekende freelancer (de slimme zoon van een van de zorgzame bewoners). Het lijkt erop dat de activiteiten van de beheermaatschappij zwak afhankelijk zijn van IT, maar het bijzondere van dit bedrijf is de maandelijkse rapportage aan veel autoriteiten. De systeemschijf van het hoofd van het bedrijf (die, zoals gewoonlijk, vele rollen combineert) heeft geen vrije ruimte meer. Uiteraard gebeurde dit niet plotseling; de waarschuwing bleef ongeveer 2 maanden hangen en werd voortdurend genegeerd. Maar er kwam een ​​update, het besturingssysteem werd bijgewerkt en, zoals het toeval wilde, bevroor het midden in de update en klaagde vóór de "dood" over een drukke schijf. De computer werd cyclisch opnieuw opgestart. Terwijl we het probleem aan het oplossen waren en rapporten ontvingen, hebben we de deadline voor rapportage gemist. Het lijkt erop dat een triviale storing verschillende problemen heeft veroorzaakt: van verliezen tot rechtszaken en administratieve aansprakelijkheid.

Bron   

Een soortgelijk incident deed zich voor bij een grote holdingmaatschappij, waar veel kleine bedrijven samenkwamen, met één enkele technische ondersteuningsdienst voor het hele kantoor. Op één van de afdelingen ging de computer van de hoofdaccountant kapot. Het was al langer bekend dat de computer kapot kon gaan (de computer werd wanhopig langzamer en warmer), maar de hoofdaccountant kwam er nooit aan toe een verzoek te sturen naar de technische ondersteuning. Uiteraard ging het precies op de betaaldag kapot en zaten de afdelingsmedewerkers een aantal dagen zonder geld.

Een klein bedrijf in de kleine groothandel beschikte over een verkoopwebsite, die op een extern platform werd gehost. Via de telefoon hoorden we van een vaste klant dat het niet bereikbaar was. Op het moment van de oproep was de site ongeveer drie uur offline geweest. Het duurde nog een paar uur om de persoon te vinden die verantwoordelijk was voor de site, en nog eens twee uur om het probleem op te lossen. Hierdoor was de site bijna de gehele werkdag niet bereikbaar. Volgens de commercieel directeur van het bedrijf kostte deze downtime hen ongeveer 1 miljoen roebel.

Zelf kwam ik een soortgelijke situatie tegen toen ik voor een afspraak bij de kliniek kwam en naar de VHI-registratie moest. Ze konden me om een ​​triviale reden niet naar de dokter sturen - er was 's ochtends een stroompiek en na het ongeval werkten hun postdienst en een bepaalde dienst voor communicatie met de verzekeringsmaatschappij niet. In antwoord op mijn vraag, waar zijn uw beheerders, kreeg ik te horen dat hun beheerder hen één keer per week komt bezoeken. En nu (het was toen al 16 uur) neemt hij de telefoon niet op. De kliniek was minimaal zeven uur lang afgesloten van de buitenwereld en kon geen betaalde diensten verlenen.

Wat hebben al deze gevallen gemeen? Absoluut alle problemen hadden vooraf voorkomen kunnen worden. Met een tijdige reactie van de IT-mensen had de schade kunnen worden beperkt. Dit zou mogelijk zijn als de vroege symptomen correct door gebruikers zouden worden geïnterpreteerd.

We hebben probleemhypotheses geïdentificeerd:

• aanzienlijke financiële verliezen en reputatieschade als gevolg van de lage reactiesnelheid op fouten in de IT-infrastructuur;
• verkeerde interpretatie van vroege symptomen van een storing door gebruikers.

Wat kan de klant ermee doen en hoe kunnen soortgelijke situaties in de toekomst worden vermeden? Er zijn niet veel opties:

1. huur een hooggekwalificeerde systeembeheerder in en laat hem gewetensvol werken;
2. IT-onderhoud uitbesteden aan een gespecialiseerd servicebedrijf;
3. zelfstandig een monitoring- en storingsrapportagesysteem implementeren;
4. het bieden van training aan gebruikers/bedrijfspersoneel in de basisbeginselen van computerkennis.

Laten we genoegen nemen met de derde optie. Laten we een monitoringsysteem aanbieden aan degenen die het om verschillende redenen niet gebruiken.

Lyrische uitweiding. Verschillende systemen voor het monitoren van IT-diensten op de zakelijke markt worden al lange tijd gebruikt en de voordelen ervan staan ​​niet ter discussie. Ik sprak met vertegenwoordigers van grote bedrijven, keek hoe de relatie tussen business en IT werd opgebouwd. De technisch directeur van een grote machinebouwonderneming heeft het onderhoud van de IT-infrastructuur uitbesteed aan een extern bedrijf, maar hij blijft zelf van alle zaken op de hoogte. In zijn kantoor hangt een groot monitoringsysteemscherm met indicatoren van de status van IT-diensten. De meest kritische zijn in het systeem opgenomen. De technisch directeur kan op ieder moment nagaan wat de staat van de infrastructuur is, wat er gebeurt, waar het probleem zit, of de verantwoordelijken op de hoogte zijn gesteld en of het probleem wordt opgelost.

De hierboven genoemde verhalen hebben ons team doen nadenken over hoe we een optimaal monitoringsysteem voor kleine bedrijven kunnen creëren. Als gevolg hiervan werd LANBIX geboren: een monitoringsysteem dat door vrijwel iedereen zonder enige IT-kennis kan worden ingezet. Het hoofddoel van het systeem is eenvoudig, zoals alle systemen gericht op het vergroten van de continuïteit en beschikbaarheid: het verminderen van financiële en andere verliezen in het geval van ongeplande downtime. Het apparaat is ontworpen om de tijd tussen ‘er is iets kapot’ en ‘het probleem is opgelost’ tot een minimum te beperken.

Om de hypothesen te bevestigen zijn er probleeminterviews afgenomen. Ik kon me niet voorstellen hoeveel mensen bereid zouden zijn te vertellen zonder te proberen aan hen te verkopen. Elk gesprek duurde minimaal 1,5 uur en we kregen veel informatie die nuttig was voor verdere ontwikkeling.

Laten we de resultaten van deze fase samenvatten:

1. er is begrip voor het probleem,
2. begrip van waarde - er is,
3. Er is een idee voor een oplossing.

De tweede fase was gedetailleerder. Op basis van de resultaten moesten we aan het management, dat in wezen de rol van investeerder speelt, een business case (hetzelfde Lean Canvas) voorleggen om een ​​beslissing te nemen over het toekomstige lot van het product.

We zijn begonnen met marktonderzoek en concurrentieanalyse om erachter te komen wie, wat en vooral hoe ze het doen op deze markt.

Het bleek het volgende.

1. Er zijn geen kant-en-klare boxed monitoringsystemen op de markt voor ons segment (kleine bedrijven), met uitzondering van een paar of drie, waar ik om voor de hand liggende redenen niet over zal praten.
2. Onze belangrijkste concurrenten zijn, vreemd genoeg, systeembeheerders met zelfgeschreven scripts en “add-ons” voor open-source monitoringsystemen.
3. Er is een duidelijk probleem met het gebruik van open source monitoringsystemen. Er is een systeem, er is een enorme hoeveelheid informatie over hoe u moet werken en hoe u het systeem kunt aanpassen aan uw behoeften. Van de bestuurders die ik heb geïnterviewd, gaven velen toe dat ze niet over voldoende competenties beschikten om hun ideeën zelfstandig te implementeren. Maar ze kunnen dit niet toegeven aan het management, uit angst voor ontslag. Het blijkt een vicieuze cirkel te zijn.

Vervolgens gingen we verder met het analyseren van de behoeften van onze potentiële klanten. We hebben voor onszelf een segment van kleine organisaties geïdentificeerd die om de een of andere reden niet over een eigen IT-dienst beschikken, waarbij ofwel een inkomende systeembeheerder, een freelancer of een servicebedrijf verantwoordelijk is voor de IT. Het was niet de IT-kant die besloot mee te doen, maar de zakelijke kant, die oprichters en bedrijfseigenaren een hulpmiddel bood om de kwaliteit van de IT-infrastructuurservice te verbeteren. Een product dat eigenaren moet helpen hun bedrijf te beveiligen, maar tegelijkertijd werk zal toevoegen aan de mensen die verantwoordelijk zijn voor IT. Een product dat bedrijven een tool biedt om de kwaliteit van IT-ondersteuning te monitoren.

Als resultaat van de verwerking van de ontvangen gegevens werd de eerste lijst met vereisten (een soort ruwe achterstand) voor het toekomstige product geboren:

• het monitoringsysteem moet gebaseerd zijn op een open source-oplossing en daardoor goedkoop zijn;
• eenvoudig en snel te installeren;
• zou geen specifieke kennis op het gebied van IT moeten vereisen, zelfs een accountant (ik wilde op geen enkele manier vertegenwoordigers van dit beroep beledigen) zou het systeem moeten kunnen inzetten en configureren;
• zou automatisch objecten moeten detecteren voor monitoring op het netwerk;
• zou automatisch (en idealiter automatisch) monitoringagenten moeten installeren;
• moet externe diensten kunnen monitoren, minimaal een CRM-systeem en een verkoopwebsite;
• moet zowel het bedrijf als de systeembeheerder op de hoogte stellen van problemen;
• de mate van diepgang en ‘taal’ van waarschuwingen moet verschillend zijn voor de beheerder en het bedrijf;
• het systeem moet op eigen hardware worden geleverd;
• ijzer moet zo toegankelijk mogelijk zijn;
• het systeem moet zo onafhankelijk mogelijk zijn van externe factoren.

Vervolgens zijn de investeringen in productontwikkeling berekend (inclusief arbeidskosten voor medewerkers van de technische afdeling). Er werd een schets van het bedrijfsmodel gemaakt en de eenheidseconomie van het product berekend.

Etappe resultaat:

• productachterstand op hoog niveau;
• een geformuleerd businessmodel of schaalhypothese dat nog in de praktijk moet worden getoetst.

Laten we verder gaan naar de volgende fase: concept. Hier bevinden wij ons als ingenieurs in ons oorspronkelijke element. Er zijn ‘verlanglijstjes’ die worden opgesplitst in componenten/subsystemen/functies, vervolgens worden ze omgezet in technische specificaties/gebruikersverhalen, vervolgens in een project, enz. Ik zal niet in detail ingaan op het proces van het voorbereiden van een reeks alternatieve opties; laten we meteen naar de vereisten en de gekozen methoden voor de implementatie ervan gaan.

eis
beslissing

• Het moet een open monitoringsysteem zijn;

We nemen een open source monitoringsysteem.

• Het systeem moet eenvoudig en snel te installeren zijn;
• vereist geen specifieke IT-kennis. Zelfs een accountant zou het systeem moeten kunnen inzetten en configureren.

Wij bieden een geïnstalleerd systeem aan zodat de gebruiker het apparaat alleen maar hoeft aan te zetten en een beetje te configureren, vergelijkbaar met een router.

Laten we de interactie met het apparaat afsluiten tot iets eenvoudigs en begrijpelijks voor iedereen.

Laten we onze eigen chatbot schrijven voor een van de bekende instant messengers en alle interacties met het systeem ernaar overbrengen.

Het systeem moet:

• automatisch objecten detecteren die nodig zijn voor monitoring op het netwerk;
• automatisch monitoringagenten installeren;
• Externe diensten kunnen monitoren, in ieder geval een CRM-systeem en een verkoopwebsite.

Wij schrijven add-ons voor het monitoringsysteem voor:

• automatische objectdetectie;
• automatische installatie van agenten;
• het monitoren van de beschikbaarheid van externe diensten.

Het systeem moet:

• zowel het bedrijf als de systeembeheerder op de hoogte stellen van problemen;
• externe diensten kunnen monitoren, in ieder geval een CRM-systeem en een verkoopwebsite. De mate van diepgang en ‘taal’ van meldingen moet verschillend zijn voor de beheerder en het bedrijf.
• Het systeem hoeft geen specifieke IT-kennis te vereisen; zelfs een accountant moet het systeem kunnen inzetten en configureren.

• Laten we verschillende soorten meldingen toevoegen voor verschillende soorten gebruikers. Ze verschillen in toonhoogte en diepte. Een zakelijke gebruiker ontvangt meldingen als “alles is in orde, maar de computer van Ivanov zal binnenkort uitvallen.” De beheerder ontvangt een compleet bericht over de fout, wie, hoe en wat er is gebeurd of zou kunnen gebeuren.
• Laten we de mogelijkheid toevoegen om de e-mail van een extra verantwoordelijke persoon te gebruiken, zodat hij in geval van pech een bericht ontvangt.
• Laten we interactie met externe dienstverleners toevoegen op basis van het verzenden van e-mails met vooraf voorbereide tekst, omdat Het is de e-mail die aanleiding geeft tot het incident.
• Alle interactie met het systeem wordt verbonden met een chatbot; de communicatie verloopt in dialoogstijl.

aan te vullen:

• Laten we de functionaliteit van "chatten met de beheerder" toevoegen, zodat de gebruiker de beheerder een bericht kan sturen waarin het probleem rechtstreeks wordt beschreven.

• Het systeem moet op eigen hardware worden geleverd.
• IJzer moet beschikbaar zijn.
• Het systeem moet zo onafhankelijk mogelijk zijn van de omgeving.

• Laten we een kant-en-klare en goedkope Raspberry PI-computer nemen.
• We zullen een ononderbroken voedingsbord ontwerpen.
• Laten we een modem toevoegen om onafhankelijk te zijn van de status van het lokale netwerk.
• Wij ontwerpen een prachtig gebouw.

We hebben nu drie subsystemen met hun eigen eisen en visie voor de implementatie ervan:

• hardware-subsysteem;
• monitoringsubsysteem;
• subsysteem voor gebruikersinteractie.

We hebben een voorlopig ontwerp voor het hardwaresubsysteem ontwikkeld. Ja Ja! Nadat we alle regels van agile hadden overtreden, hebben we een document ontwikkeld, omdat fabrieken met documenten werken. Voor de overige subsystemen hebben we gebruikers (personen) geïdentificeerd, gebruikersverhalen opgesteld en taken voor ontwikkeling geschreven.

Hiermee is de conceptfase afgerond en het resultaat is:

• project voor een hardwareplatform;
• visie geformuleerd in de vorm van user stories voor de overige twee deelsystemen;
• een softwareprototype geïmplementeerd als een virtuele machine;
• een prototype van de hardware, geïmplementeerd in de vorm van een stand, waarbij de hardwareoplossingen daadwerkelijk op sterkte werden getest;
• testen uitgevoerd door onze beheerders.

De problemen in dit stadium waren vooral van organisatorische aard en hielden verband met het gebrek aan kennis van het technische personeel op het gebied van de juridische en boekhoudkundige aspecten van verkoop. Die. Het is één ding om erachter te komen wat en hoe je moet verkopen, en iets heel anders om geconfronteerd te worden met een meedogenloze juridische machine: patenten, ontwikkelingstaken, registratie, EULA en nog veel meer waar wij als creatieve mensen aanvankelijk geen rekening mee hielden.

Er was nog geen probleem, maar eerder een moeilijkheid in verband met het ontwerp van de behuizingen. Ons team bestaat uitsluitend uit engineers, dus de eerste versie van de behuizing is door onze elektronicaspecialist uit plexiglas “gebouwd”.

Het lichaam zag er, op zijn zachtst gezegd, controversieel uit, vooral voor het publiek, bedorven door moderne technologie. Er waren natuurlijk kenners onder de oudere generatie "Kulibins" - het gebouw riep bij hen nostalgische gevoelens op. Er werd besloten om de behuizing opnieuw te vervaardigen en te ontwerpen, omdat de oude, naast esthetische gebreken, ook structurele gebreken vertoonde - het plexiglas tolereerde de montage en demontage van het apparaat niet goed en had de neiging te barsten. Ik zal je verder vertellen over de productie van de behuizing.

En nu zijn we dicht bij de finish - MVP. Dit is uiteraard nog geen eindproduct van de productie, maar het is al nuttig en waardevol. Het belangrijkste doel van deze fase is het lanceren van de ‘create-evalueer-learn’-cyclus. Dit is precies het stadium waarin LANBIX zich bevindt.

In de ‘create’-fase hebben we een apparaat gemaakt dat de genoemde functionaliteit vervult. Ja, het is nog niet perfect en we zijn eraan blijven werken.

Laten we terugkeren naar de vervaardiging van het lichaam, d.w.z. aan de taak om ons apparaat van nostalgisch naar modern te transformeren. In het begin struinde ik de markt af naar kastenfabrikanten en industriële ontwerpdiensten. Ten eerste zijn er niet veel bedrijven die koffers produceren op de Russische markt, en ten tweede zijn de kosten van industrieel ontwerp in dit stadium onbetaalbaar hoog, ongeveer 1 miljoen roebel.

Voor het ontwerp namen ze contact op met onze marketingafdeling, de jonge ontwerper was klaar voor creatieve experimenten. We schetsten onze visie op de romp (nadat we eerder de beste voorbeelden van rompconstructie hadden bestudeerd), en hij maakte er op zijn beurt een kunstwerk van. Het enige dat overblijft is de productie ervan. Trots op ons ontwerp wendden wij ons tot onze partners. Hun CEO verpletterde onmiddellijk onze fantasieën door, geheel kosteloos, dingen aan te wijzen die niet op de door ons gekozen manier geproduceerd konden worden. De behuizing kan worden geproduceerd en zal niet slechter zijn dan die van Apple, maar de kosten van de behuizing zullen drie tot vier keer duurder zijn dan die van alle elektronische componenten. Na een reeks handelingen en goedkeuringen hebben we een behuizing ontworpen die geproduceerd kan worden. Ja, het is niet zo mooi als we hadden gepland, maar het is ideaal om de huidige doelen te bereiken.

Resultaat van de etappe: de eerste batch apparaten die klaar zijn voor gevechten en testen.

En nu is het moeilijkste de fase van ‘evalueren’, en met ons product zijn we precies op dit punt aangekomen. We kunnen alleen evalueren op basis van de gebruiksresultaten door echte klanten en hier werken geen aannames. We hebben die ‘early adopters’ nodig om feedback te geven en de veranderingen in het product aan te brengen die echt nodig zijn. De vraag rijst: waar kunnen we klanten vandaan halen en hoe kunnen we hen overtuigen om deel te nemen aan het experiment?

Van alle mogelijke opties hebben we gekozen voor een klassieke set digitale tools: landingspagina en advertentiecampagne op sociale netwerken.

Het proces is al op gang gekomen, maar het is nog te vroeg om over de resultaten te praten, hoewel er al reacties zijn en we bevestiging hebben gekregen van veel van onze hypothesen. Een aangename verrassing was de reactie van vertegenwoordigers van totaal verschillende bedrijfssegmenten, veel groter dan we hadden verwacht. Het zou dwaas zijn om de nieuwe introducties te negeren, en op basis van de resultaten van de interviews werd besloten een parallelle LANBIX-lijn te lanceren, genaamd LANBIX Enterprise. We hebben ondersteuning toegevoegd voor gedistribueerde infrastructuren, het monitoren van Wi-Fi-netwerken met probleemoplossing en lokalisatie, en het monitoren van de kwaliteit van communicatiekanalen. Dienstverlenende bedrijven toonden de grootste belangstelling voor de oplossing. Tegelijkertijd spelen de apparaten die we al hebben ontwikkeld een belangrijke rol in de werking van de oplossingen.

Wat zal er daarna gebeuren?

Wat er vervolgens met de originele LANBIX gaat gebeuren, zal duidelijk worden op basis van de resultaten van de campagne. Als onze hypothesen niet worden bevestigd, zullen we er volgens de Lean-methodiek meedogenloos vanaf komen of wordt het getransformeerd in iets nieuws, want er is niets erger dan een product maken dat niemand nodig heeft. Maar nu kunnen we zeggen dat het verrichte werk niet voor niets is geweest en dat er dankzij hem een ​​hele tak van parallelle producten is verschenen waar we actief aan werken. Als dit lukt, zal LANBIX van de MVP-fase naar de laatste fase gaan en zich ontwikkelen volgens de begrijpelijke klassieke wetten van productmarketing.

Ik herhaal: nu willen we early adopters vinden, bedrijven die ons product kunnen installeren om feedback te verzamelen. Als je geïnteresseerd bent in het testen van LANBIX, schrijf dan in de reacties of privéberichten.

Bron

Bron: www.habr.com