LANIT-Integrationis on palju loomingulisi töötajaid. Ideed uute toodete ja projektide jaoks ripuvad sõna otseses mõttes õhus. Mõnikord võib olla väga raske leida kõige huvitavamaid. Seetõttu töötasime koos välja oma metoodika. Sellest artiklist saate teada, kuidas valida parimad projektid ja need ellu viia.
Venemaal ja maailmas tervikuna toimub mitmeid protsesse, mis viivad IT-turu ümberkujunemiseni. Tänu arvutusvõimsuse kasvule ning serveri-, võrgu- ja muude virtualiseerimistehnoloogiate esilekerkimisele ei vaja turg enam suurt hulka riistvara. Müüjad eelistavad üha enam otse klientidega koostööd teha. IT-turg kogeb kõigis selle vormides allhangete buumi, alates klassikalisest allhangest kuni uue allhanke laineni – pilvepakkujateni. Infrastruktuurisüsteeme ja elemente on palju lihtsam hooldada ja seadistada. Tarkvara kvaliteet kasvab iga aastaga ja integraatori ülesanded muutuvad.
Kuidas me ideedega töötame
Toote käivitamise suund on olnud juba üle aasta. Meie peamine eesmärk on luua uusi tooteid ja tuua need turule. Esimese asjana alustasime toodete loomise protsessi korraldamisega. Oleme uurinud paljusid metoodikaid, alates klassikast kuni hype'ini. Ükski neist ei vastanud aga meie vajadustele. Seejärel otsustasime võtta aluseks Lean Startup metoodika ja kohandada seda oma ülesannetega. Lean Startup on Eric Riesi loodud ettevõtlusteooria. See põhineb selliste kontseptsioonide põhimõtetel, lähenemisviisidel ja praktikatel nagu säästlik tootmine, kliendiarendus ja paindlik arendusmetoodika.
Mis puudutab otsest lähenemist tootearenduse juhtimisele: me ei leiutanud jalgratast uuesti, vaid rakendasime juba olemasolevat arendusmetoodikat , lisades loovust ja nüüd võib seda julgelt nimetada SCRUM-WATERFALL-BANiks. SCRUM on oma paindlikkusest hoolimata väga jäik süsteem ning sobib vaid ühe toote/projekti eest vastutava meeskonna juhtimiseks. Nagu aru saate, ei hõlma klassikaline integratsiooniäri täiskohaga tehniliste spetsialistide määramist ühe projekti kallale (on erandeid, kuid äärmiselt harva), kuna lisaks toodetega töötamisele on kõik hõivatud jooksvate projektidega. SCRUMilt võtsime tööjaotuse sprintideks, igapäevaseks aruandluseks, tagasivaateks ja rollideks. Valisime oma ülesannete vooks Kanbani ja see integreerus hästi meie olemasolevasse ülesannete jälgimise süsteemi. Struktureerisime oma tööd, integreerides sujuvalt olemasolevasse asjade järjekorda.
Enne turule sisenemist läbib toode 5 etappi: idee, valik, kontseptsioon, MVP (täpsemalt allpool) ja tootmine.
Mõte
Selles etapis on midagi efemeerset – idee. Ideaalis idee olemasoleva probleemi või kliendiprobleemi lahendamiseks. Meil ideedest puudust pole. Esialgse plaani järgi peaksid need genereerima tehniliste alade töötajad. Idee edasiarendamiseks vastuvõtmiseks peab autor täitma “Ideekujunduse malli”. Küsimusi on ainult neli: mida? Milleks? Kellele seda vaja on? Ja kui mitte meie toode, siis mis?
Valik
Niipea kui täidetud mall meieni jõuab, algab töötlemise ja valiku protseduur. Valikuetapp on kõige töömahukam. Selles etapis kujunevad hüpoteesid probleemidest (eelmises lõigus ei maininud asjata, et ideaalis peaks idee lahendama kliendi probleemi) ja toote väärtusest. Moodustub mastaabihüpotees, s.t. kuidas meie äri areneb ja õitseb. Potentsiaalsete klientidega viiakse läbi probleemi- ja ekspertintervjuud, et saada esialgne kinnitus, et hakkame midagi vajalikku tootma. Toote vajalikkuse kohta järelduse tegemiseks kulub vähemalt 10-15 intervjuud.
Kui hüpoteesid saavad kinnitust, tehakse esialgne finantsanalüüs, hinnatakse ligikaudset investeeringu mahtu ja investori võimalikku tulu. Selle etapi tulemusena sünnib dokument nimega Lean Canvas, mis esitatakse juhtkonnale.
Mõiste
Selles etapis kaotatakse umbes 70% ideedest. Kui kontseptsioon on heaks kiidetud, algab idee arendamise etapp. Moodustatakse tulevase toote funktsionaalsus, määratakse juurutusteed ja optimaalsed tehnilised lahendused ning uuendatakse äriplaani. Selle etapi tulemuseks on arenduse tehniline kirjeldus ja üksikasjalik ärijuht. Edu korral liigume edasi MVP või MVP etappi.
MVP või MVP
MVP on minimaalselt elujõuline toode. Need. toode, mis pole lõpuni välja arendatud, kuid suudab juba väärtust tuua ja täidab oma funktsionaalsust. Selles arendusetapis on hädavajalik koguda tagasisidet tegelikelt kasutajatelt ja teha muudatusi.
Производство
Ja kõige viimane etapp on tootmine. Sellesse etappi jõuab mitte rohkem kui 5% toodetest. See 5% sisaldab ainult kõige olulisemaid, vajalikke, elujõulisemaid ja funktsionaalsemaid tooteid.
Meil on palju ideid ja oleme juba kokku pannud mahuka portfelli. Analüüsime iga ideed ja teeme kõik, et see jõuaks lõppfaasi. On väga meeldiv, et meie kolleegid ei jäänud meie teadus- ja arendustegevuse suuna suhtes ükskõikseks ning löövad aktiivselt kaasa toodete ja lahenduste väljatöötamisel ja juurutamisel.
Kuidas me LANBIXit tegime
Vaatame toote loomist reaalse näite – LANBIX toote – abil. See on "karbis" tarkvara- ja riistvarasüsteem, mis on mõeldud väikeste IT-infrastruktuuride jälgimiseks ning otsustajate ja ärikasutajate viivitamatuks hoiatamiseks vestlusroti kaudu juhitavatest riketest. Lisaks jälgimisfunktsioonile sisaldab LANBIX Help Desk funktsiooni. See toode on eksklusiivne meie sihitavale turusegmendile. See on nii meie eelis kui ka valu. Aga kõigepealt asjad kõigepealt. Ütlen kohe, et LANBIX on elav toode (see tähendab, et see pole oma arenduses lõplik ja on järgmises MVP voorus).
Niisiis, esimene etapp on idee. Idee sündimiseks on vaja probleeme ja need olid meil, õigemini mitte meil, vaid meie sõpradel. Allpool vaatleme mitmeid tegelikke olukordi, mis esinesid erinevates ärivaldkondades.
Väike haldusfirma haldab kahte maja Moskva piirkonnas. Arvutitega töötajaid on umbes 15 inimest. Süsteemiadministraator on külas vabakutseline (ühe hooliva elaniku tark poeg). Näib, et fondivalitseja tegevus on nõrgalt IT-st sõltuv, kuid selle äri eripära on igakuine aruandlus paljudele ametiasutustele. Ettevõtte juhi süsteemikettal (mis, nagu tavaliselt, ühendab palju rolle) on vaba ruum otsa saanud. Loomulikult ei juhtunud see ootamatult, hoiatus rippus umbes 2 kuud ja seda eirati pidevalt. Kuid saabus värskendus, OS-i värskendati ja õnne korral see keset värskendust hangus, kurtes enne surma hõivatud ketta üle. Arvuti läks tsüklilisele taaskäivitusse. Probleemi lahendamise ja aruannete saamise ajal jäime teatamise tähtajast mööda. Näib, et tühine rike on põhjustanud mitmesuguseid probleeme: alates kahjudest kuni kohtuvaidluste ja haldusvastutuseni.
Sarnane juhtum leidis aset ühes suures, paljusid väikeettevõtteid ühendavas valdusettevõttes, kus kogu kontorit hõlmas ühtne tehnilise toe teenus. Ühes osakonnas läks katki pearaamatupidaja arvuti. See, et see võib katki minna, oli teada juba ammu (arvuti aeglustas meeleheitlikult ja kuumenes), kuid pearaamatupidaja ei jõudnud kordagi tehnilisele toele päringut saata. Loomulikult läks see täpselt palgapäeval katki ja osakonna töötajad olid mitu päeva ilma rahata.
Väikesel hulgimüügiga tegeleval väikeettevõttel oli müügiveebisait, mida majutati välisel saidil. Selle kättesaamatusest saime telefoni teel teada püsikliendilt. Kõne ajal oli sait maas olnud umbes kolm tundi. Saidi eest vastutava isiku leidmiseks kulus veel paar tundi ja probleemi lahendamiseks kulus veel kaks tundi. Seetõttu ei olnud sait peaaegu kogu tööpäeva saadaval. Ettevõtte kommertsdirektori sõnul läks see seisak neile maksma umbes miljon rubla.
Ise puutusin kokku sarnase olukorraga, kui tulin kliinikusse vastuvõtule ja pidin minema VHI registreerimisele. Nad ei saanud mind triviaalsel põhjusel arsti juurde saata - hommikul oli voolu tõus ja pärast õnnetust ei töötanud nende postiteenus ja teatud teenus kindlustusseltsiga suhtlemiseks. Vastuseks minu küsimusele, kus teie adminnid on, öeldi mulle, et nende admin käib ja külastab neid kord nädalas. Ja nüüd (kell oli sel ajal juba 16:00) ta telefoni ei võta. Vähemalt 7 tundi oli kliinik välismaailmast ära lõigatud ega saanud tasulisi teenuseid osutada.
Mis on kõigil neil juhtumitel ühist? Absoluutselt kõiki probleeme oleks saanud ennetada. IT-inimeste õigeaegse reageerimisega oleks saanud kahju vähendada. See oleks võimalik, kui kasutajad tõlgendaksid varaseid sümptomeid õigesti.
Oleme tuvastanud probleemi hüpoteesid:
- märkimisväärsed rahalised ja mainekahjud IT-infrastruktuuri tõrgetele reageerimise madala kiiruse tõttu;
- rikke varajaste sümptomite valesti tõlgendamine kasutajate poolt.
Mida saab klient nendega teha ja kuidas edaspidi sarnaseid olukordi vältida? Valikuid pole palju:
- palgata kõrgelt kvalifitseeritud süsteemiadministraator ja panna ta kohusetundlikult tööle;
- tellida IT-hooldus spetsialiseeritud teenindusettevõttelt;
- iseseisvalt juurutada seire- ja riketest teatamise süsteemi;
- pakkuda kasutajatele/äripersonalile arvutioskuse aluste koolitust.
Leppigem kolmanda variandiga. Pakume seiresüsteemi neile, kes seda erinevatel põhjustel ei kasuta.
Lüüriline kõrvalepõige. Erinevaid IT-teenuste jälgimise süsteeme ettevõtete turul on kasutatud pikka aega ja nende eeliste üle ei vaielda. Rääkisin suurettevõtete esindajatega, vaatasin, kuidas loodi äri ja IT suhe. Ühe suure masinaehitusettevõtte tehniline direktor on andnud IT-taristu hooldamise allhanke korras välisfirmale, kuid ise jääb kõigega kursis. Tema kabinetis ripub suur seiresüsteemi ekraan IT-teenuste oleku indikaatoritega. Kõige kriitilisemad on süsteemi kaasatud. Tehniline direktor saab iga hetk teada, mis seis on taristu, mis toimub, kus on probleem, kas vastutavaid inimesi on teavitatud ja kas probleem on lahendatud.
Eelpool loetletud lood panid meie meeskonna mõtlema, kuidas luua väikeettevõtetele optimaalne seiresüsteem. Selle tulemusena sündis LANBIX – seiresüsteem, mida saab kasutusele võtta absoluutselt igaüks ilma igasuguste IT-teadmisteta. Süsteemi põhieesmärk on lihtne, nagu kõik süsteemid, mille eesmärk on suurendada järjepidevust ja käideldavust – vähendada rahalisi ja muid kahjusid ettenägematute seisakute korral. Seade on loodud nii, et see vähendab ajavahemikku "midagi on katki" ja "probleem on lahendatud" vahel.
Hüpoteeside kinnitamiseks viidi läbi probleemintervjuud. Ma ei kujutanud ette, kui palju inimesed oleksid nõus rääkima, proovimata neile müüa. Iga vestlus kestis vähemalt 1,5 tundi ning saime palju edasiseks arenguks kasulikku infot.
Võtame selle etapi tulemused kokku:
- on probleemist arusaam,
- väärtuse mõistmine - on olemas,
- Idee lahenduseks on olemas.
Teine etapp oli üksikasjalikum. Selle tulemuste põhjal pidime sisuliselt investori rolli täitvale juhtkonnale esitama ärijuhtumi (sama Lean Canvas), et teha otsus toote edasise saatuse kohta.
Alustasime turu-uuringute ja konkurentsianalüüsiga, et saada teada, kellel, mida ja mis kõige tähtsam, kuidas neil sellel turul läheb.
Selgus järgmine.
- Meie segmendi (väikeettevõte) jaoks pole turul ühtegi valmis karbiga varustatud jälgimissüsteemi, välja arvatud paar-kolm, millest ma arusaadavatel põhjustel ei räägi.
- Meie peamised konkurendid on kummalisel kombel süsteemiadministraatorid, kellel on kodus kirjutatud skriptid ja avatud lähtekoodiga seiresüsteemide "lisandmoodulid".
- Avatud lähtekoodiga seiresüsteemide kasutamisel on selge probleem. Süsteem on olemas, infot selle kohta, kuidas töötada ja süsteemi oma vajadustele vastavaks muuta, on tohutult. Administraatoritest, keda intervjueerisin, tunnistasid paljud, et neil pole piisavalt kompetentse oma ideede iseseisvaks elluviimiseks. Kuid nad ei saa seda vallandamise kartuses juhtkonnale tunnistada. Selgub, et see on nõiaring.
Seejärel asusime edasi oma potentsiaalsete klientide vajaduste analüüsimisele. Oleme enda jaoks tuvastanud segmendi väikestest organisatsioonidest, millel mingil põhjusel puudub oma IT-teenus, kus IT eest vastutab kas sissetulev süsteemiadministraator, vabakutseline või teenindusettevõte. Sisenemist ei otsustanud IT-pool, vaid äripool, pakkudes asutajatele ja ettevõtete omanikele vahendit IT-taristuteenuse kvaliteedi parandamiseks. Toode, mis peaks aitama omanikel oma äri kindlustada, kuid samas lisab tööd IT eest vastutavatele inimestele. Toode, mis pakub ettevõtetele tööriista IT-toe kvaliteedi jälgimiseks.
Saadud andmete töötlemise tulemusena sündis tulevase toote jaoks esimene nõuete loend (omamoodi jäme mahajäämus):
- seiresüsteem peab põhinema avatud lähtekoodiga lahendusel ja sellest tulenevalt odav;
- lihtne ja kiire paigaldada;
- ei tohiks nõuda spetsiifilisi IT-alaseid teadmisi, isegi raamatupidaja (ma ei tahtnud kuidagi selle eriala esindajaid solvata) peaks suutma süsteemi juurutada ja seadistada;
- peaks automaatselt tuvastama objektid võrgus jälgimiseks;
- peaks automaatselt (ja ideaaljuhul automaatselt) installima jälgimisagendid;
- peab suutma jälgida välisteenuseid, vähemalt CRM-süsteemi ja müügiveebi;
- peaks probleemidest teavitama nii ettevõtet kui ka süsteemiadministraatorit;
- hoiatuste sügavus ja „keel” peaksid administraatori ja ettevõtte jaoks olema erinevad;
- süsteem peab olema varustatud eraldi riistvaraga;
- raud peaks olema võimalikult ligipääsetav;
- süsteem peaks olema välistest teguritest võimalikult sõltumatu.
Järgmisena arvutati välja investeeringud tootearendusse (sh tehnikaosakonna töötajate tööjõukulud). Koostati ärimudeli eskiis ja arvutati toote ühikuökonoomika.
Etapi tulemus:
- kõrgetasemeline toodete mahajäämus;
- sõnastatud ärimudel või mastaabihüpotees, mida tuleb veel praktikas testida.
Liigume edasi järgmise etapi juurde – kontseptsiooni juurde. Siin me inseneridena leiame end oma emakeelest. On olemas “soovide nimekirjad”, mis lammutatakse komponentideks/allsüsteemideks/funktsioonideks, seejärel muudetakse need tehnilisteks spetsifikatsioonideks/kasutajalugudeks, seejärel projektiks jne. Ma ei peatu üksikasjalikult mitmesuguste alternatiivsete võimaluste ettevalmistamise protsessil; liigume otse nõuete ja nende rakendamiseks valitud meetodite juurde.
Nõudlus
otsus
- See peaks olema avatud seiresüsteem;
Kasutame avatud lähtekoodiga seiresüsteemi.
- Süsteem peaks olema lihtne ja kiiresti paigaldatav;
- ei tohiks nõuda spetsiifilisi IT-teadmisi. Isegi raamatupidaja peaks suutma süsteemi juurutada ja konfigureerida.
Pakume installitud süsteemi, et kasutajal oleks vaja ainult seade sisse lülitada ja veidi seadistada sarnaselt ruuteriga.
Lõpetagem seadmega suhtlemine millekski lihtsaks ja kõigile arusaadavaks.
Kirjutame ühele tuntud kiirsõnumitoojale oma vestlusroti ja kanname kõik süsteemiga seotud suhtlused sellele üle.
Süsteem peaks:
- tuvastab automaatselt võrgus jälgimiseks vajalikud objektid;
- installige automaatselt jälgimisagendid;
- Suuda jälgida välisteenuseid, vähemalt CRM süsteemi ja müügiveebi.
Kirjutame seiresüsteemi lisandmooduleid:
- automaatne objekti tuvastamine;
- agentide automaatne paigaldamine;
- välisteenuste kättesaadavuse jälgimine.
Süsteem peaks:
- teavitama probleemidest nii ettevõtet kui ka süsteemiadministraatorit;
- suutma jälgida välisteenuseid, vähemalt CRM-süsteemi ja müügiveebi. Teatiste sügavus ja „keel” peaksid administraatori ja ettevõtte jaoks olema erinevad.
- Süsteem ei tohiks nõuda spetsiifilisi IT-teadmisi, isegi raamatupidaja peaks suutma süsteemi juurutada ja konfigureerida.
- Lisame erinevat tüüpi kasutajate jaoks erinevat tüüpi märguandeid. Need erinevad kõrguse ja sügavuse poolest. Ärikasutaja saab teateid nagu "kõik on korras, aga Ivanovi arvuti sureb varsti." Administraator saab täieliku teate vea kohta, kes, kuidas ja mis juhtus või võib juhtuda.
- Lisame võimaluse kasutada täiendava vastutava isiku posti, et rikke korral saaks ta teate.
- Lisame väliste teenusepakkujatega suhtlemise, mis põhineb eelnevalt ettevalmistatud tekstiga meilide saatmisel, sest Juhtumi põhjuseks on meil.
- Kogu suhtlus süsteemiga ühendatakse vestlusbotiga, suhtlus toimub dialoogistiilis.
täiendus:
- Lisame “vestle administraatoriga” funktsiooni, et kasutaja saaks saata administraatorile otse probleemi kirjeldava sõnumi.
- Süsteem peab olema varustatud eraldi riistvaraga.
- Raud peab olema saadaval.
- Süsteem peaks olema keskkonnast võimalikult sõltumatu.
- Võtame valmis ja odava Raspberry PI arvuti.
- Projekteerime katkematu toiteploki.
- Lisame modemi, mis ei sõltu kohaliku võrgu olekust.
- Projekteerime ilusa hoone.
Meil on nüüd kolm allsüsteemi, millel on oma nõuded ja nägemus nende rakendamiseks:
- riistvara alamsüsteem;
- seire allsüsteem;
- kasutaja interaktsiooni alamsüsteem.
Töötasime välja riistvara alamsüsteemi eelprojekti. Jah Jah! Olles rikkunud kõiki agiilsuse reegleid, töötasime välja dokumendi, kuna tootmisettevõtted töötavad dokumentidega. Ülejäänud alamsüsteemide puhul tuvastasime kasutajad (isikud), koostasime kasutajalood ja kirjutasime arendamiseks ülesandeid.
See lõpetab kontseptsiooni etapi ja tulemus on:
- riistvaraplatvormi projekt;
- sõnastatud nägemus kasutajalugude kujul ülejäänud kahe allsüsteemi kohta;
- tarkvara prototüüp, mis on realiseeritud virtuaalmasinana;
- statiivi kujul realiseeritud riistvara prototüüp, kus riistvaralahenduste tugevust reaalselt testiti;
- meie administraatorite poolt läbi viidud testimine.
Probleemid selles etapis olid enamasti korralduslikud ja seotud inseneritöötajate puudulike teadmistega müügi juriidilistes ja raamatupidamislikes aspektides. Need. Üks asi on aru saada, mida ja kuidas müüa, ja hoopis teine asi on silmitsi seista halastamatu õigusmasinaga: patendid, arendusülesanded, registreerimine, EULA ja palju muud, millega me loomeinimestena esialgu ei arvestanud.
Probleemi veel ei olnud, vaid pigem raskusi, mis olid seotud korpuste disainiga. Meie meeskond koosneb ainult inseneridest, seega "ehitas" korpuse esimese versiooni pleksiklaasist meie elektroonikaspetsialist.
Moodsa tehnikaga rikutud kere nägi eriti avalikkuse jaoks välja pehmelt öeldes vastuoluline. “Kulibinite” vanema põlvkonna seas leidus muidugi asjatundjaid - hoone tekitas neis nostalgilisi tundeid. Korpus otsustati valmistada ja kujundada uuesti, kuna vanal oli lisaks esteetilistele vigadele ka konstruktsioonilisi - pleksiklaas ei talunud hästi seadme kokku- ja lahtivõtmist ning kippus pragunema. Räägin teile korpuse valmistamisest edasi.
Ja nüüd oleme lähedal finišijoonele – MVP. Loomulikult pole see veel lõpptoodang, kuid see on juba kasulik ja väärtuslik. Selle etapi põhieesmärk on käivitada tsükkel "loo-hinnda-õpi". Täpselt selles etapis on LANBIX.
Loomise etapis lõime seadme, mis täidab deklareeritud funktsioone. Jah, see pole veel täiuslik ja me jätkasime sellega tööd.
Tuleme tagasi kere valmistamise juurde, st. ülesandeks muuta meie seade nostalgilisest kaasaegseks. Alguses uurisin kapitootjate ja tööstusdisainiteenuste turgu. Esiteks ei ole Venemaa turul palju ümbriseid tootvaid ettevõtteid ja teiseks on tööstusdisainilahenduse maksumus praeguses etapis liiga kõrge, umbes 1 miljon rubla.
Nad võtsid disaini osas ühendust meie turundusosakonnaga, noor disainer oli loomingulisteks katseteks valmis. Visandasime oma nägemuse kerest (olles eelnevalt uurinud parimaid laevakere ehituse näiteid) ja tema omakorda tegi sellest kunstiteose. Jääb vaid see toota. Meie, olles uhked oma disaini üle, pöördusime oma partnerite poole. Nende tegevjuht purustas kohe meie fantaasiad, osutades täiesti tasuta asjadele, mida meie valitud viisil toota ei saa. Korpust saab toota ja see pole Apple'i omast halvem, kuid korpuse maksumus on kolm kuni neli korda kallim kui kõik elektroonilised komponendid. Pärast mitmeid toiminguid ja kinnitusi oleme kavandanud korpuse, mida saab toota. Jah, see pole nii ilus, kui plaanisime, kuid see on ideaalne praeguste eesmärkide saavutamiseks.
Etapi tulemus: esimene partii seadmeid, mis on lahinguks ja testimiseks valmis.
Ja nüüd on kõige keerulisem “hindamise” etapp ja oma tootega oleme täpselt selles punktis. Saame hinnata ainult tegelike klientide kasutustulemuste põhjal ja siinkohal ei tööta ükski oletus. Meil on vaja neid "varaseid kasutajaid", et nad annaksid tagasisidet ja teeksid tootes muudatusi, mis on tõesti vajalikud. Tekib küsimus: kust saada kliente ja kuidas veenda neid katses osalema?
Kõigist võimalikest valikutest valisime välja klassikalise digitööriistade komplekti: maandumislehe ja reklaamikampaania sotsiaalvõrgustikes.
Protsess on juba käima lükatud, kuid tulemustest on veel vara rääkida, kuigi vastuseid juba on ja paljudele oma hüpoteesidele oleme saanud kinnitust. Meeldiv üllatus oli täiesti erinevate ärisegmentide esindajate reaktsioon, palju suurem, kui ootasime. Oleks rumal uusi tutvustusi ignoreerida ning intervjuude tulemuste põhjal otsustati käivitada paralleelne LANBIX liin nimega LANBIX Enterprise. Oleme lisanud hajutatud infrastruktuuride toe, Wi-Fi võrkude jälgimise koos tõrkeotsingu ja lokaliseerimisega ning sidekanalite kvaliteedi jälgimise. Lahenduse vastu tundsid suurimat huvi teenindusettevõtted. Samas on meie poolt juba välja töötatud seadmetel oluline roll lahenduste toimimises.
Mis saab edasi
Mis saab edasi algse LANBIXiga, selgub kampaania tulemuste põhjal. Kui meie hüpoteesid ei leia kinnitust, siis Lean metoodika järgi vabaneme sellest halastamatult või muudetakse see millekski uueks, sest pole midagi hullemat, kui teha toodet, mida keegi ei vaja. Nüüd aga võib öelda, et tehtud töö ei olnud asjata ja tänu sellele on ilmunud terve haru paralleeltooteid, millega aktiivselt tegeleme. Edu korral liigub LANBIX MVP etapist lõppfaasi ja areneb tooteturunduse mõistetavate klassikaliste seaduste järgi.
Kordan, nüüd tahame leida varaseid kasutuselevõtjaid, ettevõtteid, kes saavad meie toote installida, et tagasisidet koguda. Kui oled huvitatud LANBIXi testimisest, kirjuta kommentaaridesse või privaatsõnumitesse.
Allikas: www.habr.com