🥇Hoe ons met idees werk, en hoe LANBIX gebore is

Daar is baie kreatiewe werknemers by LANIT-Integrasie. Idees vir nuwe produkte en projekte hang letterlik in die lug. Dit kan soms baie moeilik wees om die interessantstes te identifiseer. Daarom het ons saam ons eie metodologie ontwikkel. Lees hierdie artikel oor hoe om die beste projekte te kies en te implementeer.

In Rusland, en in die wêreld as 'n geheel, vind 'n aantal prosesse plaas wat lei tot die transformasie van die IT-mark. Danksy die toename in rekenaarkrag en die opkoms van bediener-, netwerk- en ander virtualisasietegnologieë het die mark nie meer 'n groot hoeveelheid hardeware nodig nie. Verkopers verkies toenemend om direk met kliënte te werk. Die IT-mark beleef ’n oplewing in uitkontraktering in al sy vorme, van klassieke uitkontraktering tot die nuwe vlaag uitkontrakteerders – “wolkverskaffers”. Infrastruktuurstelsels en -elemente word baie makliker om te onderhou en op te stel. Die kwaliteit van sagteware groei elke jaar en die take van die integreerder word getransformeer.

Hoe ons met idees werk

Produk opstart rigting in "LANIT-integrasie" bestaan al meer as 'n jaar. Ons hoofdoel is om nuwe produkte te skep en na die mark te bring. Die eerste ding waarmee ons begin het, was die organisering van die proses om produkte te skep. Ons het baie metodologieë bestudeer, van klassiek tot hype. Nie een van hulle het egter aan ons behoeftes voldoen nie. Toe het ons besluit om die Lean Startup-metodologie as basis te neem en dit by ons take aan te pas. The Lean Startup is 'n teorie van entrepreneurskap wat deur Eric Ries geskep is. Dit is gebaseer op die beginsels, benaderings en praktyke van konsepte soos skraal vervaardiging, klantontwikkeling en buigsame ontwikkelingsmetodologie.

Wat die direkte benadering tot produkontwikkelingsbestuur betref: ons het nie die wiel herontdek nie, maar 'n reeds bestaande ontwikkelingsmetodologie toegepas skrum, wat kreatiwiteit byvoeg, en nou kan dit veilig SCRUM-WATERVAL-VERBAND genoem word. SCRUM, ten spyte van sy buigsaamheid, is 'n baie rigiede stelsel en is geskik vir die bestuur van 'n span wat verantwoordelik is vir slegs een produk/projek. Soos u verstaan, behels die klassieke "integrasie"-besigheid nie die toewys van voltydse tegniese spesialiste om aan een projek te werk nie (daar is uitsonderings, maar uiters selde), aangesien almal, benewens om aan produkte te werk, besig is met huidige projekte. Van SCRUM het ons die verdeling van werk in naellope, daaglikse verslaggewing, terugblikke en rolle geneem. Ons het Kanban gekies vir ons taakvloei en dit het goed geïntegreer in ons bestaande taakopsporingstelsel. Ons het ons werk gestruktureer deur naatloos in die bestaande orde van dinge te integreer.
Voordat 'n produk die mark betree, gaan 'n produk deur 5 stadiums: idee, keuse, konsep, MVP (meer besonderhede hieronder) en produksie.

Idee

Op hierdie stadium is daar iets kortstondigs – ’n idee. Ideaal gesproke 'n idee om 'n bestaande probleem of kliëntprobleem op te los. Ons het geen tekort aan idees nie. Volgens die aanvanklike plan moet hulle gegenereer word deur werknemers van tegniese gebiede. Om 'n idee vir verdere ontwikkeling aanvaar te kan word, moet die skrywer die "Idee-ontwerpsjabloon" invul. Daar is net vier vrae: Wat? Vir wat? Wie het dit nodig? En indien nie ons produk nie, wat dan?

Bron

Keuse

Sodra die voltooide sjabloon ons bereik, begin die verwerkings- en keuringsprosedure. Die seleksie stadium is die mees arbeidsintensiewe. Op hierdie stadium word hipoteses van probleme gevorm (dit was nie verniet dat ek in die vorige paragraaf genoem het dat ideaal gesproke 'n idee 'n kliënt se probleem moet oplos nie) en die waarde van die produk. 'n Skaalhipotese word gevorm, m.a.w. hoe ons besigheid gaan groei en floreer. Probleem- en deskundige onderhoude word met potensiële kliënte gevoer om voorlopige bevestiging te gee dat ons iets gaan produseer wat nodig is. Dit neem ten minste 10-15 onderhoude om 'n gevolgtrekking te maak oor die behoefte aan die produk.

As die hipoteses bevestig word, word 'n voorlopige finansiële ontleding uitgevoer, die benaderde volume van belegging en die belegger se moontlike verdienste word beoordeel. As gevolg van hierdie stadium word 'n dokument genaamd Lean Canvas gebore en aan die bestuur voorgelê.

konsep

Op hierdie stadium word ongeveer 70% van idees uitgeskakel. As die konsep goedgekeur word, begin die idee-ontwikkelingstadium. Die funksionaliteit van die toekomstige produk word gevorm, implementeringspaaie en optimale tegniese oplossings word bepaal, en die sakeplan word bygewerk. Die resultaat van hierdie stadium is 'n tegniese spesifikasie vir ontwikkeling en 'n gedetailleerde besigheidsgeval. Indien suksesvol, beweeg ons aan na die MVP- of MVP-stadium.

MVP of MVP

MVP is 'n minimum lewensvatbare produk. Dié. 'n produk wat nie ten volle ontwikkel is nie, maar reeds waarde kan bring en sy funksionaliteit uitvoer. Dit is noodsaaklik dat ons in hierdie stadium van ontwikkeling terugvoer van regte gebruikers insamel en veranderinge aanbring.

Produksie

En die heel laaste stadium is produksie. Nie meer as 5% van die produkte bereik hierdie stadium nie. Hierdie 5% sluit slegs die belangrikste, nodigste, lewensvatbare en funksionele produkte in.

Ons het baie idees en het reeds 'n lywige portefeulje saamgestel. Ons ontleed elke idee en doen alles om te verseker dat dit die finale stadium bereik. Dit is baie aangenaam dat ons kollegas nie onverskillig gebly het oor ons R&D-rigting nie en aktief deelgeneem het aan die ontwikkeling en implementering van produkte en oplossings.

Hoe ons LANBIX gemaak het

Kom ons kyk na die skep van 'n produk deur 'n werklike voorbeeld te gebruik - die LANBIX-produk. Dit is 'n "boks" sagteware en hardeware stelsel wat ontwerp is vir die monitering van klein IT-infrastruktuur en om besluitnemers en besigheidsgebruikers dadelik te waarsku oor wanfunksies wat deur 'n kletsbot beheer word. Benewens die moniteringsfunksie, sluit LANBIX Helpdesk-funksionaliteit in. Hierdie produk is eksklusief vir die marksegment wat ons teiken. Dit is beide ons voordeel en ons pyn. Maar eerste dinge eerste. Ek sal dadelik sê dat LANBIX 'n lewende produk is (dit wil sê, dit is nie finaal in sy ontwikkeling nie en is by die volgende rondte van MVP).

Dus, die eerste fase is die idee. Vir 'n idee om gebore te word, het jy probleme nodig, en ons het dit gehad, of eerder nie ons nie, maar ons vriende. Hieronder sal ons kyk na verskeie werklike situasies wat voorgekom het in verskillende areas van besigheid.

'n Klein bestuursmaatskappy hou twee huise in die Moskou-streek in stand. Die personeel met rekenaars is ongeveer 15 mense. Die stelseladministrateur is 'n besoekende vryskut (die slim seun van een van die omgee-inwoners). Dit wil voorkom asof die aktiwiteite van die bestuursmaatskappy swak van IT afhanklik is, maar die eienaardigheid van hierdie besigheid is maandelikse verslagdoening aan baie owerhede. Die stelselskyf van die hoof van die maatskappy (wat, soos gewoonlik, baie rolle kombineer) het nie meer vrye spasie nie. Dit het natuurlik nie skielik gebeur nie; die waarskuwing het vir ongeveer 2 maande gehang en is voortdurend geïgnoreer. Maar 'n opdatering het aangekom, die bedryfstelsel is opgedateer en, soos die geluk dit wou hê, het dit in die middel van die opdatering gevries en voor "dood" gekla oor 'n besige skyf. Die rekenaar het in 'n sikliese herlaai gegaan. Terwyl ons besig was om die probleem uit te sorteer en verslae te kry, het ons die rapporteringsperdatum gemis. Dit wil voorkom asof 'n onbenullige wanfunksie verskeie probleme veroorsaak het: van verliese tot litigasie en administratiewe aanspreeklikheid.

Bron

'n Soortgelyke voorval het plaasgevind in 'n groot beheermaatskappy, wat baie klein maatskappye verenig het, met 'n enkele tegniese ondersteuningsdiens vir die hele kantoor. In een van die departemente het die rekenaar van die hoofrekenmeester onklaar geraak. Dit was al lankal bekend dat dit kon breek (die rekenaar het desperaat stadiger en warm geword), maar die hoofrekenmeester het nooit daarby uitgekom om 'n versoek aan tegniese ondersteuning te stuur nie. Natuurlik het dit presies op betaaldag gebreek, en die departement se werknemers was vir 'n paar dae sonder geld.

'n Klein besigheid in klein groothandel het 'n verkoopswebwerf gehad wat op 'n eksterne platform aangebied is. Ons het telefonies by 'n gereelde klant gehoor van die onbeskikbaarheid daarvan. Ten tyde van die oproep was die perseel sowat drie uur lank af. Dit het nog 'n paar uur geneem om die persoon wat verantwoordelik is vir die webwerf te vind, en nog twee om die probleem op te los. Gevolglik was die webwerf vir byna die hele werksdag onbeskikbaar. Volgens die maatskappy se kommersiële direkteur het hierdie stilstand hulle sowat 1 miljoen roebels gekos.

Ek het self 'n soortgelyke situasie teëgekom toe ek vir 'n afspraak by die kliniek gekom het en na die VHI-registrasie moes gaan. Hulle kon my om 'n onbenullige rede nie dokter toe stuur nie - daar was 'n kragstuwing in die oggend, en na die ongeluk het hul posdiens en 'n sekere diens om met die versekeringsmaatskappy te kommunikeer nie gewerk nie. In antwoord op my vraag, waar is jou admins, is ek meegedeel dat hul admin hulle een keer per week kom besoek. En nou (destyds was dit al 16:00) tel hy nie die foon op nie. Vir minstens 7 uur was die kliniek van die buitewêreld afgesny en kon nie betaalde dienste lewer nie.

Wat het al hierdie gevalle in gemeen? Absoluut alle probleme kon vooraf voorkom gewees het. Met tydige reaksie van die IT-mense kon die skade verminder gewees het. Dit sou moontlik wees as die vroeë simptome korrek deur gebruikers geïnterpreteer word.

Ons het probleemhipoteses geïdentifiseer:

aansienlike geldelike en reputasieverliese as gevolg van die lae spoed van reaksie op foute in die IT-infrastruktuur;
verkeerde interpretasie van vroeë simptome van 'n wanfunksie deur gebruikers.

Wat kan die kliënt met hulle doen, en hoe om soortgelyke situasies in die toekoms te vermy? Daar is nie baie opsies nie:

huur 'n hoogs gekwalifiseerde stelseladministrateur en laat hom pligsgetrou werk;
uitkontrakteer IT-instandhouding aan 'n gespesialiseerde diensmaatskappy;
onafhanklik 'n monitering- en foutrapporteringstelsel te implementeer;
verskaf opleiding aan gebruikers/besigheidspersoneel in die basiese beginsels van rekenaargeletterdheid.

Kom ons vestig ons op die derde opsie. Kom ons bied 'n moniteringstelsel aan diegene wat dit om verskeie redes nie gebruik nie.

Liriese afwyking. Verskeie stelsels vir die monitering van IT-dienste in die ondernemingsmark word al lank gebruik, en die voordele daarvan is nie in dispuut nie. Ek het met verteenwoordigers van groot maatskappye gepraat, gekyk hoe die verhouding tussen besigheid en IT gebou is. Die tegniese direkteur van een groot masjienbouonderneming het die instandhouding van die IT-infrastruktuur aan 'n eksterne maatskappy uitgekontrakteer, maar hy bly self op hoogte van alle sake. In sy kantoor hang ’n groot moniteringstelselskerm met aanwysers van die status van IT-dienste. Die mees kritieke is by die stelsel ingesluit. Die tegniese direkteur kan enige oomblik uitvind wat die stand van die infrastruktuur is, wat gebeur, waar die probleem is, of die verantwoordelike mense in kennis gestel is, en of die probleem opgelos word.

Die verhale hierbo het ons span laat dink oor hoe om 'n optimale moniteringstelsel vir klein maatskappye te skep. As gevolg hiervan is LANBIX gebore - 'n moniteringstelsel wat deur absoluut enigiemand sonder enige IT-kennis ontplooi kan word. Die hoofdoel van die stelsel is eenvoudig, soos alle stelsels wat daarop gemik is om kontinuïteit en beskikbaarheid te verhoog - om geldelike en ander verliese te verminder in die geval van onbeplande stilstand. Die toestel is ontwerp om die tyd tussen "iets is stukkend" en "die probleem is reggestel" tot 'n minimum te verminder.

Om die hipoteses te bevestig, is probleemonderhoude gevoer. Ek kon nie dink hoeveel mense bereid sou wees om te vertel sonder om aan hulle te probeer verkoop nie. Elke gesprek het minstens 1,5 uur geduur, en ons het baie inligting ontvang wat nuttig was vir verdere ontwikkeling.

Kom ons som die resultate van hierdie stadium op:

daar is 'n begrip van die probleem,
begrip van waarde - daar is,
Daar is 'n idee vir 'n oplossing.

Die tweede fase was meer gedetailleerd. Op grond van die resultate daarvan, moes ons 'n sakesaak (dieselfde Lean Canvas) aan die bestuur, wat in wese die rol van 'n belegger speel, voorlê om 'n besluit oor die toekomstige lot van die produk te neem.

Ons het begin met marknavorsing en mededingende ontleding om uit te vind wie, wat en, bowenal, hoe hulle in hierdie mark vaar.

Dit het die volgende geblyk.

Daar is geen klaargemaakte boksmoniteringstelsels op die mark vir ons segment (klein besigheid), met die uitsondering van 'n paar of drie, waaroor ek om ooglopende redes nie sal praat nie.
Ons vernaamste mededingers is, vreemd genoeg, stelseladministrateurs met tuisgeskrewe skrifte en "byvoegings" tot oopbronmoniteringstelsels.
Daar is 'n duidelike probleem met die gebruik van oopbronmoniteringstelsels. Daar is 'n stelsel, daar is 'n groot hoeveelheid inligting oor hoe om te werk en die stelsel aan te pas om by jou behoeftes te pas. Van die administrateurs met wie ek onderhoude gevoer het, het baie erken dat hulle nie genoeg bevoegdhede het om hul idees op hul eie te implementeer nie. Maar hulle kan dit nie aan die bestuur erken nie uit vrees vir afdanking. Dit blyk 'n bose kringloop te wees.

Ons het toe aanbeweeg om die behoeftes van ons potensiële kliënte te ontleed. Ons het vir onsself 'n segment van klein organisasies geïdentifiseer wat om een of ander rede nie hul eie IT-diens het nie, waar óf 'n inkomende stelseladministrateur, 'n vryskut óf 'n diensmaatskappy vir IT verantwoordelik is. Dit was nie die IT-kant wat besluit het om toe te tree nie, maar die sakekant, wat stigters en sake-eienaars 'n hulpmiddel bied om die gehalte van IT-infrastruktuurdiens te verbeter. 'n Produk wat eienaars behoort te help om hul besigheid te beveilig, maar dit sal terselfdertyd werk bydra vir die mense wat vir IT verantwoordelik is. 'n Produk wat besighede 'n hulpmiddel bied om die kwaliteit van IT-ondersteuning te monitor.

As gevolg van die verwerking van die ontvangde data, is die eerste lys vereistes ('n soort rowwe agterstand) vir die toekomstige produk gebore:

die moniteringstelsel moet gebaseer wees op 'n oopbronoplossing en gevolglik goedkoop;
maklik en vinnig om te installeer;
moet nie spesifieke kennis in IT vereis nie, selfs 'n rekenmeester (op geen manier wou ek verteenwoordigers van hierdie beroep aanstoot gee nie) moet die stelsel kan ontplooi en konfigureer;
moet outomaties voorwerpe vir monitering op die netwerk opspoor;
moet outomaties (en ideaal gesproke outomaties) moniteringsagente installeer;
moet eksterne dienste kan monitor, ten minste 'n CRM-stelsel en 'n verkoopswebwerf;
moet beide die besigheid en die stelseladministrateur van probleme in kennis stel;
die graad van diepte en "taal" van waarskuwings moet verskillend wees vir die administrateur en die besigheid;
die stelsel moet op sy eie hardeware voorsien word;
yster moet so toeganklik as moontlik wees;
die stelsel moet so onafhanklik as moontlik van eksterne faktore wees.

Vervolgens is beleggings in produkontwikkeling bereken (insluitend arbeidskoste vir werknemers van die tegniese afdeling). 'n Skets van die besigheidsmodel is voorberei en die eenheidsekonomie van die produk is bereken.

Stadium resultaat:

hoëvlak produkagterstand;
'n geformuleerde sakemodel of skaalhipotese wat nog in die praktyk getoets moet word.

Kom ons gaan aan na die volgende fase – konsep. Hier bevind ons, as ingenieurs, onsself in ons inheemse element. Daar is “wenslyste” wat in komponente/substelsels/kenmerke ontbind word, dan word dit omskep in tegniese spesifikasies/gebruikerstories, dan in 'n projek, ens. Ek sal nie in detail stilstaan oor die proses om 'n verskeidenheid alternatiewe opsies voor te berei nie; kom ons gaan reguit na die vereistes en die gekose metodes vir die implementering daarvan.

Vraag
besluit

Dit moet 'n oop moniteringstelsel wees;

Ons neem 'n oopbron-moniteringstelsel.

Die stelsel moet eenvoudig en vinnig wees om te installeer;
moet nie spesifieke IT-kennis vereis nie. Selfs 'n rekenmeester behoort die stelsel te kan ontplooi en opstel.

Ons bied 'n geïnstalleerde stelsel sodat die gebruiker net die toestel hoef aan te skakel en dit 'n bietjie te konfigureer, soortgelyk aan 'n router.

Kom ons sluit die interaksie met die toestel tot iets eenvoudig en verstaanbaar vir almal.

Kom ons skryf ons eie kletsbot vir een van die bekende kitsboodskappers en dra alle interaksies met die stelsel daarna oor.

Die stelsel moet:

bespeur outomaties voorwerpe wat benodig word vir monitering op die netwerk;
installeer outomaties moniteringsagente;
In staat wees om eksterne dienste te monitor, ten minste 'n CRM-stelsel en 'n verkoopswebwerf.

Ons skryf byvoegings vir die moniteringstelsel vir:

outomatiese voorwerpopsporing;
outomatiese installering van agente;
monitering van die beskikbaarheid van eksterne dienste.

Die stelsel moet:

beide die besigheid en die stelseladministrateur van probleme in kennis stel;
eksterne dienste, ten minste 'n CRM-stelsel en 'n verkoopswebwerf, te kan monitor. Die graad van diepte en "taal" van kennisgewings moet verskil vir die administrateur en die besigheid.
Die stelsel behoort nie spesifieke IT-kennis te vereis nie; selfs 'n rekenmeester moet die stelsel kan ontplooi en konfigureer.

Kom ons voeg verskillende tipes kennisgewings by vir verskillende tipes gebruikers. Hulle verskil in toonhoogte en diepte. 'n Besigheidsgebruiker sal kennisgewings ontvang soos "alles is reg, maar Ivanov se rekenaar sal binnekort sterf." Die administrateur sal 'n volledige boodskap ontvang oor die fout, wie, hoe en wat gebeur het of kan gebeur.
Kom ons voeg die vermoë by om die pos van 'n bykomende verantwoordelike persoon te gebruik, sodat hy in die geval van 'n onklaarraking 'n boodskap sal ontvang.
Kom ons voeg interaksie met eksterne diensverskaffers by wat gebaseer is op die stuur van e-posse met vooraf voorbereide teks, want Dit is die e-pos wat aanleiding gee tot die voorval.
Alle interaksie met die stelsel sal aan 'n kletsbot gekoppel word; kommunikasie word in 'n dialoogstyl uitgevoer.

vul:

Kom ons voeg die funksionaliteit van "klets met die administrateur" by sodat die gebruiker 'n boodskap aan die administrateur kan stuur wat die probleem direk beskryf.

Die stelsel moet op sy eie hardeware voorsien word.
Yster moet beskikbaar wees.
Die stelsel moet so onafhanklik as moontlik van die omgewing wees.

Kom ons neem 'n klaargemaakte en goedkoop Raspberry PI rekenaar.
Ons sal 'n ononderbroke kragtoevoerbord ontwerp.
Kom ons voeg 'n modem by om onafhanklik te wees van die toestand van die plaaslike netwerk.
Ons sal 'n pragtige gebou ontwerp.

Ons het nou drie substelsels met hul eie vereistes en visie vir die implementering daarvan:

hardeware substelsel;
monitering substelsel;
gebruiker interaksie substelsel.

Ons het 'n voorlopige ontwerp vir die hardeware-substelsel ontwikkel. Ja ja! Nadat ons al die reëls van ratsheid oortree het, het ons 'n dokument ontwikkel, want vervaardigingsaanlegte werk met dokumente. Vir die oorblywende substelsels het ons gebruikers (persone) geïdentifiseer, gebruikersstories voorberei en take vir ontwikkeling geskryf.

Dit sluit die konsepfase af, en die resultaat is:

projek vir 'n hardeware platform;
geformuleerde visie in die vorm van gebruikersverhale vir die oorblywende twee subsisteme;
'n sagteware prototipe geïmplementeer as 'n virtuele masjien;
'n prototipe van die hardeware, geïmplementeer in die vorm van 'n staander, waar die hardeware-oplossings eintlik vir sterkte getoets is;
toetse uitgevoer deur ons administrateurs.

Die probleme op hierdie stadium was meestal organisatories en het verband gehou met die gebrek aan kennis van die ingenieurspersoneel in die wetlike en rekeningkundige aspekte van verkope. Dié. Dit is een ding om uit te vind wat en hoe om te verkoop, en 'n heel ander ding om voor 'n genadelose regsmasjien te staan te kom: patente, ontwikkelingstake, registrasie, EULA en nog baie meer wat ons as kreatiewe mense nie aanvanklik in ag geneem het nie.

Daar was nog nie 'n probleem nie, maar eerder 'n probleem wat verband hou met die ontwerp van die omhulsels. Ons span bestaan slegs uit ingenieurs, so die eerste weergawe van die kas is deur ons elektroniese spesialis van pleksiglas “gebou”.

Die liggaam het, om dit sagkens te stel, omstrede gelyk, veral vir die publiek, bederf deur moderne tegnologie. Daar was natuurlik fynproewers onder die ouer geslag "Kulibins" - die gebou het nostalgiese gevoelens by hulle ontlok. Daar is besluit om die kas nuut te vervaardig en te ontwerp, aangesien die ou een, benewens estetiese gebreke, ook strukturele foute gehad het - die pleksiglas het nie die montering en demontage van die toestel goed verdra nie en was geneig om te kraak. Ek sal jou verder vertel van die vervaardiging van die saak.

En nou is ons naby die wenstreep – MVP. Dit is natuurlik nog nie 'n finale produksieproduk nie, maar dit is reeds nuttig en waardevol. Die hoofdoel van hierdie stadium is om die "skep-evalueer-leer"-siklus van stapel te stuur. Dit is presies die stadium waarop LANBIX is.

Op die "skep" stadium het ons 'n toestel geskep wat die verklaarde funksionaliteit uitvoer. Ja, dit is nog nie perfek nie, en ons het voortgegaan om daaraan te werk.

Kom ons keer terug na die vervaardiging van die liggaam, d.w.s. tot die taak om ons toestel van nostalgies na modern te transformeer. Aan die begin het ek die mark gesoek vir kabinetvervaardigers en industriële ontwerpdienste. Eerstens is daar nie baie maatskappye wat sake op die Russiese mark vervaardig nie, en tweedens is die koste van industriële ontwerp op hierdie stadium buitensporig hoog, ongeveer 1 miljoen roebels.

Hulle het ons bemarkingsafdeling gekontak vir die ontwerp; die jong ontwerper was gereed vir kreatiewe eksperimente. Ons het ons visie van die romp uiteengesit (nadat ons voorheen die beste voorbeelde van rompkonstruksie bestudeer het), en hy het dit op sy beurt in 'n kunswerk verander. Al wat oorbly is om dit te produseer. Ons, trots op ons ontwerp, het ons tot ons vennote gewend. Hul uitvoerende hoof het dadelik ons fantasieë verpletter deur heeltemal gratis dinge uit te wys wat nie op ons gekose manier vervaardig kon word nie. Die tas kan vervaardig word, en dit sal nie erger as Apple s’n wees nie, maar die koste van die tas sal drie tot vier keer duurder wees as al die elektroniese komponente. Na 'n reeks operasies en goedkeurings het ons 'n behuising ontwerp wat vervaardig kan word. Ja, dit is nie so mooi soos ons beplan het nie, maar dit is ideaal om huidige doelwitte te bereik.

Resultaat van die stadium: die eerste groep toestelle gereed vir geveg en toetsing.

En nou is die moeilikste ding die "evalueer" stadium, en met ons produk is ons presies op hierdie punt. Ons kan slegs evalueer op grond van die resultate van gebruik deur regte kliënte en geen aannames werk hier nie. Ons het daardie "vroeë aannemers" nodig om terugvoer te gee en die veranderinge aan die produk aan te bring wat werklik nodig is. Die vraag ontstaan: waar om kliënte te kry en hoe om hulle te oortuig om aan die eksperiment deel te neem?

Van al die moontlike opsies het ons 'n klassieke stel digitale hulpmiddels gekies: bestemmingsbladsy en advertensieveldtog op sosiale netwerke.

Die proses is reeds van stapel gestuur, maar dit is te vroeg om oor resultate te praat, hoewel daar reeds reaksies is en ons bevestiging van baie van ons hipoteses ontvang het. ’n Aangename verrassing was die reaksie van verteenwoordigers van heeltemal verskillende sakesegmente, baie groter as dié wat ons verwag het. Dit sal dwaas wees om die nuwe inleidings te ignoreer, en op grond van die resultate van die onderhoude is besluit om 'n parallelle LANBIX-lyn genaamd LANBIX Enterprise bekend te stel. Ons het ondersteuning bygevoeg vir verspreide infrastruktuur, monitering van Wi-Fi-netwerke met foutsporing en lokalisering, en monitering van die kwaliteit van kommunikasiekanale. Diensmaatskappye het die grootste belangstelling in die oplossing uitgespreek. Terselfdertyd speel die toestelle wat ons reeds ontwikkel het 'n belangrike rol in die werking van die oplossings.

Wat sal volgende gebeur

Wat volgende met die oorspronklike LANBIX gaan gebeur, sal duidelik word op grond van die resultate van die veldtog. As ons hipoteses nie bevestig word nie, sal ons volgens die Lean metodologie genadeloos daarvan ontslae raak of dit sal omskep word in iets nuuts, want daar is niks erger as om 'n produk te maak wat niemand nodig het nie. Maar nou kan ons sê dat die werk wat gedoen is nie tevergeefs was nie en danksy dit het 'n hele tak van parallelle produkte verskyn, waaraan ons aktief werk. Indien suksesvol, sal LANBIX van die MVP-stadium na die finale stadium beweeg en volgens die verstaanbare klassieke wette van produkbemarking ontwikkel.

Ek herhaal, nou wil ons vroeë aannemers vind, maatskappye wat ons produk kan installeer om terugvoer in te samel. As jy belangstel om LANBIX te toets, skryf in die kommentaar of privaat boodskappe.

Bron

Bron: will.com

Hoe ons met idees werk en hoe LANBIX gebore is