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

Bij «LANIT-Integraties» 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 gezamenlijk onze eigen methodiek ontwikkeld. Hoe we de beste projecten selecteren en tot realisatie brengen, lees je in dit artikel.

In Rusland, en ook wereldwijd, vinden er verschillende processen plaats die leiden tot een transformatie van de IT-markt. Dankzij de toename van rekenkracht en de opkomst van server-, netwerk- en andere virtualisatietechnologieën, heeft de markt niet langer behoefte aan een grote hoeveelheid ‘hardware’. Leveranciers verkiezen steeds vaker om rechtstreeks met klanten samen te werken. De IT-markt bloeit op in alle vormen van outsourcing, van klassieke outsourcing tot de nieuwe generatie outsourcingspecialisten – ‘cloudproviders’. Infrastructuursystemen en -elementen worden aanzienlijk eenvoudiger te onderhouden en in te stellen. De kwaliteit van software verbetert elk jaar en de taken van de integrator transformeren.

Hoe we met ideeën werken

Product startup-richting bij «LANIT-Integraties» bestaat al meer dan een jaar. Ons belangrijkste doel is de creatie van nieuwe producten en deze op de markt te brengen. Het eerste wat we hebben gedaan, is het proces van productontwikkeling georganiseerd. We hebben talloze methodologieën bestudeerd, van klassieke tot trendy. Geen van deze paste echter bij onze behoeften. Daarom besloten we de Lean Startup-methodologie als basis te nemen en deze aan onze behoeften aan te passen. De “lean startup” is een ondernemersconcept dat is ontwikkeld door Eric Ries. Het is gebaseerd op principes, benaderingen en praktijken uit concepten zoals lean productie, customer development en agile ontwikkelingsmethodologie.

Wat betreft de aanpak van productontwikkeling: we hebben het wiel niet opnieuw uitgevonden, maar hebben gebruikgemaakt van een al bestaande ontwikkelingsmethodologie SCRUM, door creativiteit toe te voegen, kan het nu gerust een SCRUM-WATERFALL-BAN genoemd worden. SCRUM, ondanks zijn flexibiliteit, is een zeer rigide systeem en is geschikt voor het managen van een team dat verantwoordelijk is voor slechts één product/project. Zoals u begrijpt, is de klassieke ‘integrator’ business niet geconfigureerd om technische specialisten fulltime in te zetten voor één project (uitzonderingen komen voor, maar zijn uiterst zeldzaam), aangezien iedereen druk bezig is met lopende projecten naast het werken aan producten. Van SCRUM hebben we het opdelen van werk in sprints, dagelijkse rapportages, retrospectieven en rollen overgenomen. Voor het werken met de stroom van taken hebben we Kanban gekozen, en dit heeft zich uitstekend geïntegreerd in ons bestaande taakvolgsysteem. We hebben ons werk georganiseerd, soepel geïntegreerd in de al bestaande gang van zaken.
Voordat een product de markt betreedt, doorloopt het 5 fasen: idee, selectie, concept, MVP (meer hierover hieronder) en productie.

Idee

In dit stadium is er iets efemeers - een idee. Idealiter, het idee voor een oplossing van een bestaand probleem of de behoefte van de klant. We hebben geen tekort aan ideeën. Volgens het oorspronkelijke plan zouden ze moeten worden gegenereerd door medewerkers van technische afdelingen. Om een idee voor verdere ontwikkeling te laten kwalificeren, moet de auteur de 'Sjabloon voor idee-indiening' invullen. Deze bevat slechts vier vragen: Wat? Waarom? Voor wie is dit nodig? En als het niet ons product is, wat dan?

Bron

Selectie

Zodra het ingevulde sjabloon bij ons aankomt, begint de procedure voor verwerking en selectie. De selectiefase is de meest arbeidsintensieve. In deze fase wordt de hypothese van problemen gevormd (ik heb niet voor niets in de vorige alinea genoemd dat een idee idealiter een probleem van de klant moet oplossen) en de waarde van het product. De hypothese van schaal wordt vastgesteld, dat wil zeggen hoe ons bedrijf van plan is te groeien en te bloeien. Probleem- en deskundige interviews met potentiële klanten worden uitgevoerd voor een voorlopige bevestiging dat we van plan zijn iets nuttigs te produceren. Er zijn minstens 10-15 interviews nodig om een conclusie te trekken over de noodzaak van het product.

Als de hypotheses worden bevestigd, wordt er een voorlopige financiële analyse uitgevoerd, worden de geschatte investeringsbedragen en de mogelijke opbrengsten voor de investeerder beoordeeld. Dit resulteert in een document genaamd Lean Canvas dat aan het management wordt gepresenteerd.

Concept

In deze fase worden ongeveer 70% van de ideeën gefilterd. Als het concept wordt goedgekeurd, begint de fase van ideeverwerking. De functionele mogelijkheden van het toekomstige product worden gedefinieerd, de realisatiepaden en optimale technische oplossingen worden vastgesteld en het businessplan wordt geactualiseerd. Het resultaat van deze fase is een technisch ontwerp voor de ontwikkeling en een gedetailleerde businesscase. Bij succes gaan we naar de MLP- of MVP-fase.

MLP of MVP

MLP is een minimaal levensvatbaar product. Dat wil zeggen, een product dat nog niet volledig is ontwikkeld, maar al waarde kan bieden en zijn functionaliteit kan vervullen. In deze fase van ontwikkeling verzamelen we essentieel feedback van echte gebruikers en brengen we wijzigingen aan.

Productie

En de laatste fase is productie. Tot deze fase komt niet meer dan 5% van de producten. Deze 5% omvat alleen de belangrijkste, noodzakelijke, levensvatbare en functionele producten.

We hebben veel ideeën en reeds een omvangrijke portefeuille verzameld. We analyseren elk idee en doen alles om ervoor te zorgen dat het de finale fase bereikt. Het is fijn dat collega's niet onverschillig stonden tegenover onze R&D-richting en actief deelnemen aan de ontwikkeling en implementatie van producten en oplossingen.

Hoe we LANBIX hebben gemaakt

Laten we de productontwikkeling bekijken aan de hand van een echt voorbeeld — het product LANBIX. Dit is een 'doos'-hardware- en softwarecomplex, bedoeld voor de monitoring van kleine IT-infrastructuren en voor het onmiddellijk informeren van verantwoordelijke personen en zakelijke gebruikers over storingen via beheer door middel van een chatbot. Naast de monitoringfunctie bevat LANBIX ook Help Desk-functionaliteit. Dit product is exclusief voor het marksegment waarop we ons richten. Dit is zowel ons voordeel als onze pijn. Maar laten we alles op volgorde bekijken. Ik zal meteen zeggen dat LANBIX een levend product is (dat wil zeggen, het is niet definitief in zijn ontwikkeling en bevindt zich in de volgende MVP-cyclus).

Dus, de eerste fase is het idee. Voor een idee om te ontstaan, zijn problemen nodig, en die hadden we, om precies te zijn, niet bij ons, maar bij onze bekenden. Hieronder bekijken we enkele echte situaties die zich in verschillende bedrijfssectoren hebben voorgedaan.

Een klein beheerbedrijf bedient twee huizen in de regio Moskou. Het personeel dat een pc heeft, bestaat uit ongeveer 15 mensen. De systeembeheerder is een externe freelancer (een slimme zoon van een betrokken bewoner). Het lijkt erop dat de activiteiten van het beheerbedrijf weinig afhankelijk zijn van IT, maar een kenmerk van deze business is de maandelijkse rapportage aan verschillende instanties. De systeemschijf van de directeur van het bedrijf (die zoals gewoonlijk meerdere rollen vervult) raakte vol. Uiteraard gebeurde dit niet plotseling; de waarschuwing was ongeveer 2 maanden zichtbaar en werd voortdurend genegeerd. Maar er kwam een update, het besturingssysteem werd bijgewerkt en zoals het vaak gaat, vastliep het halverwege de update en klaagde voor de 'dood' over de volle schijf. De computer viel in een continue reboot-cyclus. Terwijl ze met het probleem bezig waren en de rapporten aan het verzamelen waren, miste men de deadline voor de rapportage. Wat leek op een kleine storing, leidde tot verschillende ongemakken: van verliezen tot rechtszaken en administratieve aansprakelijkheden.

Bron   

Een vergelijkbaar geval deed zich voor in een grote holding die meerdere kleine bedrijven verenigt, met een centrale technische ondersteuningsdienst voor het hele kantoor. In een van de afdelingen ging de computer van de hoofdboekhouder kapot. Dat het kapot kon gaan was al lang bekend (de computer liep wanhopig vast en werd heet), maar de handen van de hoofdboekhouder kwamen maar niet vrij om een aanvraag naar de technische ondersteuning te sturen. Uiteraard ging het kapot op de dag van de salarisbetaling, en de medewerkers van de afdeling zaten enkele dagen zonder geld.

Een klein bedrijf in de groothandel had een verkoopwebsite die op een externe site werd gehost, die niet meer bereikbaar was. Ze ontdekten de onbeschikbaarheid via de telefoon van een vaste klant. Op het moment van de oproep was de site al ongeveer drie uur down. Het zoeken naar de verantwoordelijke voor de site kostte nog eens enkele uren, en het oplossen van de storing nam ook nog eens twee uur in beslag. Bijgevolg was de site praktisch de hele werkdag niet toegankelijk. Volgens de commercieel directeur van het bedrijf kostte deze downtime hen ongeveer 1 miljoen roebel.

Ik heb zelf een vergelijkbare situatie meegemaakt toen ik naar de kliniek ging en naar de DMS-registratie moest. Ze konden me niet naar de dokter sturen om een eenvoudige reden – er was een spanningspiek in de ochtend en na het voorval werkten hun e-mailservice en een bepaalde verbinding met de verzekeraar niet. Toen ik vroeg waar hun systeembeheerders waren, kreeg ik te horen dat ze een externe admin hadden die eens per week langskomt. En op dat moment (het was al 16:00) nam hij de telefoon niet op. Minstens 7 uur lang was de kliniek afgesloten van de buitenwereld en kon geen betaalde diensten verlenen.

Wat verbindt al deze gevallen? Alle problemen hadden van tevoren voorkomen kunnen worden. Met een tijdige reactie van de mensen die de IT onderhouden, had de schade kunnen worden verminderd. Dat zou ook mogelijk geweest zijn met een juiste interpretatie van de vroege symptomen door de gebruikers.

We hebben de probleemhypotheses geïdentificeerd:

• aanzienlijke financiële en reputatieschade door de trage reactie op storingen in de IT-infrastructuur;
• onjuiste interpretatie van vroege symptomen van storingen door de gebruikers.

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

1. een hooggekwalificeerde systeembeheerder in dienst nemen en ervoor zorgen dat hij zijn werk goed doet;
2. de IT-ondersteuning uitbesteden aan een gespecialiseerd servicebedrijf;
3. zelf een monitoringsysteem en waarschuwingsmechanisme voor storingen implementeren;
4. gebruikers/business personeel opleiden in de basis van computerkennis.

We kiezen voor de derde optie. Laten we een monitoringsysteem voorstellen aan degenen die het om verschillende redenen niet gebruiken.

Lyrische tussenpoos. Verschillende IT-servicemonitoringssystemen op de enterprise-markt worden al lang gebruikt, en hun nut staat niet ter discussie. Ik heb gesproken met vertegenwoordigers van grote bedrijven en gekeken hoe de relaties tussen het bedrijfsleven en IT zijn opgebouwd. De technisch directeur van een groot machinebouwbedrijf heeft het onderhoud van de IT-infrastructuur uitbesteed aan een extern bedrijf, maar blijft zelf op de hoogte van alles. In zijn kantoor hangt een groot scherm van het monitoringsysteem met indicatoren van de status van IT-diensten. In het systeem zijn de meest kritische systemen opgenomen. Op elk moment kan de technisch directeur informatie krijgen over de staat van de infrastructuur, wat er aan de hand is, op welk gebied er problemen zijn, of de verantwoordelijke mensen zijn gewaarschuwd en of er aan een oplossing wordt gewerkt.

De genoemde verhalen hebben ons team aan het denken gezet over hoe we een optimaal monitoringsysteem voor kleine bedrijven kunnen creëren. Het resultaat was LANBIX — een monitoringsysteem dat door iedereen zonder IT-kennis kan worden opgezet. De hoofdfunctie van het systeem is net zo eenvoudig als die van alle systemen die gericht zijn op het verhogen van continuïteit en beschikbaarheid: het verminderen van financiële en andere verliezen in geval van onvoorziene uitvallen. Het apparaat is bedoeld om de tijd tussen "ik heb een probleem" en "het probleem is opgelost" tot een minimum te beperken.

Om de hypothese te bevestigen, zijn er probleeminterviews gehouden. Ik kon me niet voorstellen hoeveel mensen bereid zijn te vertellen als je ze niet probeert te verkopen. Elk gesprek duurde minstens 1,5 uur, en we hebben een schat aan informatie verzameld die nuttig was voor de verdere ontwikkeling.

Samenvattend resultaat van deze fase:

1. begrip van het probleem — aanwezig,
2. begrip van de waarde — aanwezig,
3. idee voor de oplossing — aanwezig.

De tweede fase was gedetailleerder. Op basis van de resultaten moesten we aan het management, dat in feite de rol van investeerder vervult, een businesscase (diezelfde Lean Canvas) presenteren voor de beslissing over de toekomstige koers van het product.

We begonnen met een marktonderzoek en concurrentieanalyse om te achterhalen wie, wat en vooral hoe er op deze markt wordt gewerkt.

Het volgende bleek.

1. Op de markt zijn er geen kant-en-klare monitoringssystemen voor onze segment (kleine bedrijven), met uitzondering van een paar waarvan ik om begrijpelijke redenen niets zal zeggen.
2. Onze belangrijkste concurrenten zijn, vreemd genoeg, systeembeheerders met zelfgeschreven scripts en 'aanpassingen' voor systemen voor monitoring met open source.
3. Er is duidelijk een probleem met het gebruik van systemen voor monitoring met open source. Er is een systeem, er is een enorme hoeveelheid informatie over het functioneren en het aanpassen van het systeem aan eigen behoeften. Van de beheerder die ik heb ondervraagd, gaven velen toe dat ze niet de benodigde vaardigheden hebben om hun ideeën zelf te realiseren. Maar ze kunnen dit niet aan hun leidinggevend personeel toegeven uit angst voor ontslag. Dit creëert een vicieuze cirkel.

Daarna zijn we overgegaan tot de analyse van de behoeften van onze potentiële klanten. We hebben ons gericht op een segment van kleine organisaties die om verschillende redenen geen eigen IT-afdeling hebben, waar de IT wordt beheerd door een freelance systeembeheerder of een serviceteam. We besloten ons niet te richten vanuit de IT-kant, maar vanuit de zakelijke kant, en bieden oprichters en eigenaren van bedrijven een tool om de kwaliteit van de IT-infrastructuur te verbeteren. Een product dat eigenaren moet helpen hun bedrijf veiliger te maken, maar dat tegelijkertijd extra werk zal toevoegen voor degenen die verantwoordelijk zijn voor de IT. Een product dat bedrijven een instrument biedt voor het controleren van de kwaliteit van de IT-ondersteuning.

Als resultaat van de verwerking van de verkregen gegevens ontstond de eerste lijst met eisen (een soort ruwe backlog) voor het toekomstige product:

• het monitoringsysteem moet gebaseerd zijn op een open-sourceoplossing en dus goedkoop zijn;
• moet eenvoudig en snel te installeren zijn;
• mag geen specifieke IT-kennis vereisen, zelfs een boekhouder (ik wil vertegenwoordigers van dit beroep geenszins beledigen) moet in staat zijn om het systeem op te zetten en te configureren;
• moet automatisch objecten voor monitoring in het netwerk kunnen detecteren;
• moet automatisch (en idealiter volledig automatisch) monitoringagents installeren;
• moet de mogelijkheid hebben om externe services te monitoren, minimaal een CRM-systeem en een verkoopsite;
• moet zowel het bedrijf als de systeembeheerder waarschuwen bij problemen;
• de diepte van de waarschuwingen en de 'taal' moet verschillen voor de beheerder en het bedrijf;
• het systeem moet geleverd worden op eigen hardware;
• de hardware moet maximaal toegankelijk zijn;
• Het systeem moet volledig onafhankelijk zijn van externe factoren.

Vervolgens zijn de investeringen in de productontwikkeling berekend (inclusief de arbeidskosten van de medewerkers van de technische afdeling). Een schets van het business model is voorbereid en de unit-economie van het product is berekend.

Resultaat van deze fase:

• hoogwaardige product backlog;
• een geformuleerd businessmodel of schaalhypothese die nog in de praktijk moet worden getest.

Laten we doorgaan naar de volgende fase - het concept. Hier als ingenieurs komen we in ons eigen element. Er zijn "wensen", die worden gedecodeerd in componenten/subsystemen/functies, en vervolgens omgevormd naar technische specificaties/gebruiksverhalen, daarna naar het project, enzovoort. Ik zal niet in detail ingaan op het proces van het voorbereiden van een reeks alternatieve opties, laten we direct doorgaan naar de eisen en de gekozen methoden voor hun implementatie.

Eis
Oplossing

• Dit moet een open monitoring systeem zijn;

We nemen een open source monitoring systeem.

• Het systeem moet eenvoudig en snel te installeren zijn;
• het mag geen specifieke IT-kennis vereisen. Zelfs een accountant moet in staat zijn om het systeem op te zetten en in te stellen.

We bieden een geïnstalleerd systeem aan, zodat de gebruiker alleen het apparaat hoeft in te schakelen en het een beetje moet instellen, vergelijkbaar met een router.

Laten we de interactie met het apparaat simpel en duidelijk maken voor iedereen.

We zullen onze eigen chatbot schrijven voor een van de bekende messengers en alle interactie met het systeem daarop baseren.

Het systeem moet:

• automatisch de vereiste te monitoren objecten in het netwerk detecteren;
• automatisch monitoring agents installeren;
• De mogelijkheid hebben om externe diensten te monitoren, minimaal CRM-systemen en een verkoopwebsite.

We schrijven aanvullingen voor het monitoring systeem voor:

• automatische detectie van objecten;
• automatische installatie van agents;
• monitoring van de beschikbaarheid van externe diensten.

Het systeem moet:

• meldingen sturen over storingen, zowel aan de business als aan de systeemadministrator;
• de mogelijkheid hebben om externe diensten te monitoren, minimaal CRM-systemen en een verkoopwebsite. De diepte van de meldingen en hun 'taal' moet verschillend zijn voor de admin en de business.
• Het systeem moet geen specifieke IT-kennis vereisen, zelfs een accountant moet in staat zijn om het systeem op te zetten en in te stellen.

• We will add different types of notifications for different types of users. They differ in tone and depth. A business user will receive notifications like 'everything is fine, but Ivanov's computer will die soon'. An administrator will receive a complete error message detailing who, how, and what happened or may happen.
• We will add the ability to use the email of an additional responsible person, so that in the event of a failure, they receive a notification.
• We will add interaction with external service providers based on sending emails with pre-prepared text, as it is the email that provides the basis for incident creation.
• All interactions with the system will be through a chatbot, with communication conducted in a dialog style.

Addition:

• We will add a 'chat with admin' functionality, so that users can send messages to the administrator describing their issues directly.

• The system should be delivered on its own hardware.
• The hardware must be available.
• The system must be as independent as possible from its environment.

• Let's take a ready-made and inexpensive Raspberry Pi computer.
• We will design a power supply backup board.
• We will add a modem for independence from the state of the local network.
• We will design a nice case.

We have three subsystems with their own requirements and vision for their implementation:

• hardware subsystem;
• monitoring subsystem;
• user interaction subsystem.

For the hardware subsystem, we have developed a preliminary design. Yes! Breaking all agile rules, we created a document because manufacturers work with documents. For the other subsystems, we defined users (personas), prepared user stories, and wrote development tasks.

At this stage, the concept ends, resulting in:

• a project for the hardware platform;
• a formulated vision in the form of user stories for the other two subsystems;
• a software prototype realized as a virtual machine;
• a hardware prototype implemented as a stand, where the hardware solutions were tested for durability;
• testing conducted by our admins.

De problemen in deze fase waren vooral organisatorisch en verband houdend met de onvoldoende kennis van het engineeringteam op juridisch en boekhoudkundig gebied van verkoop. Het is namelijk één ding om te bedenken wat en hoe te verkopen, en iets heel anders om te worden geconfronteerd met een meedogenloze juridische machine: patenten, ontwikkelingsopdrachten, balansplaatsing, EULA en nog veel meer dat we als creatieve mensen aanvankelijk niet hadden overwogen.

Er was nog niet echt een probleem, maar eerder een complicatie met betrekking tot het ontwerp van de behuizingen. In ons team zitten alleen ingenieurs, dus de eerste versie van de behuizing is gemaakt van plexiglas door onze elektronicaspecialist.

De behuizing zag er, zacht gezegd, twijfelachtig uit, vooral voor een publiek dat gewend is aan moderne technologie. Natuurlijk waren er nog wel waarderende stemmen onder de 'knutselaars' van de oudere generatie — de behuizing wekte bij hen nostalgische gevoelens op. Besloten werd om de behuizing opnieuw te vervaardigen en te ontwerpen, omdat de oude niet alleen esthetische tekortkomingen had, maar ook constructieve — plexiglas kon niet goed tegen het in- en uitschroeven van het apparaat en vertoonde de neiging om te scheuren. Ik zal later vertellen over de productie van de behuizing.

En zo kwamen we in de buurt van de eindstreep — MVP. Natuurlijk is dit nog geen definitief product voor massaproductie, maar het brengt al wel waarde en nut. Het belangrijkste doel van deze fase is om de cyclus 'creëren-beoordelen-leren' te starten. Dit is precies waar LANBIX zich momenteel bevindt.

In de fase 'creëren' hebben we een apparaat gemaakt dat de aangegeven functionaliteit uitvoert. Ja, het is nog niet perfect, en we blijven eraan werken.

Laten we terugkeren naar de productie van de behuizing, dat wil zeggen, de taak om ons apparaat van een nostalgisch gevoel te transformeren naar iets moderns. In het begin heb ik de markt doorzocht naar fabrikanten van behuizingen en bedrijven die industriële ontwerpservices aanbieden. Ten eerste zijn er heel weinig bedrijven die behuizingen produceren op de Russische markt, en ten tweede zijn de kosten van industrieel ontwerp in deze fase buitensporig hoog, ongeveer 1 miljoen roebel.

Voor het ontwerp hebben we onze marketingafdeling benaderd, een jonge ontwerper was bereid om creatief te experimenteren. We hebben onze visie op de behuizing uiteengezet (na eerst de beste voorbeelden van behuizingen bestudeerd te hebben), en hij heeft het omgevormd tot een kunstwerk. We moesten alleen nog produceren. Trots op ons ontwerp, hebben we partners benaderd. Hun algemeen directeur heeft onmiddellijk onze fantasieën verwoest door gratis op dingen te wijzen die onmogelijk te produceren zijn met de door ons gekozen methode. De behuizing kan geproduceerd worden en zal niet slechter zijn dan die van Apple, maar de kosten ervan zullen drie tot vier keer hoger zijn dan die van alle elektronische onderdelen samen. Na een reeks bewerkingen 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 voor het bereiken van de huidige doelen.

Resultaat van de fase: de eerste batch apparaten, klaar voor de strijd en testen.

En nu komt het moeilijke — de fase van 'beoordelen'. Met ons product bevinden we ons precies op dit punt. We kunnen alleen beoordelen op basis van de resultaten van gebruik door echte klanten en geen enkele veronderstelling werkt hier. We hebben vooral die 'early adopters' nodig om feedback te geven en de veranderingen aan het product door te voeren die daadwerkelijk nodig zijn. De vraag rijst: waar moeten we klanten vandaan halen en hoe overtuigen we ze om deel te nemen aan het experiment?

Van alle mogelijke opties hebben we de klassieke set digitale tools gekozen: een landingspagina en een reclamecampagne op sociale media.

Het proces is al op gang, maar het is nog te vroeg om over resultaten te spreken, hoewel we al reacties hebben ontvangen en bevestiging van veel van onze hypothesen hebben gekregen. Een aangename verrassing was de reactie van vertegenwoordigers uit totaal andere bedrijfssegmenten, veel groter dan de segmenten waarop we hadden gerekend. Het zou dom zijn om nieuwe gegevens te negeren, en op basis van de resultaten van de interviews is besloten om een parallelle lijn LANBIX te lanceren onder de naam LANBIX Enterprise. We hebben ondersteuning toegevoegd voor gedistribueerde infrastructuren, monitoring van Wi-Fi-netwerken met het zoeken en lokaliseren van storingen, en monitoring van de kwaliteit van verbindingen. De grootste interesse in de oplossing werd getoond door servicebedrijven. Bovendien spelen de apparaten die we al hebben ontwikkeld een belangrijke rol in de oplossingen.

Wat gebeurt er daarna

Wat er daarna met de oorspronkelijke LANBIX zal gebeuren, zal blijken uit de resultaten van de campagne. Als onze hypothesen niet worden bevestigd, zullen we, volgens de Lean-methodologie, genadeloos van deze variant afzien of zal het transformeren in iets nieuws, want er is niets erger dan een product te maken dat niemand nodig heeft. Maar het is nu al duidelijk dat het werk dat is verzet niet tevergeefs is geweest en dat er dankzij deze inspanningen een hele tak van parallelle producten is ontstaan waar we actief aan werken. In geval van succes zal LANBIX overgaan van de MVP-fase naar de eindfase en zich ontwikkelen volgens de duidelijke, klassieke wetten van productmarketing.

Ik herhaal, momenteel willen we vroege volgers vinden, bedrijven waarmee we ons product kunnen implementeren om feedback te verzamelen. Als je geïnteresseerd bent in het testen van LANBIX, laat dan een bericht achter in de reacties of privéberichten.

Bron

Bron: habr.com