Kuidas me töötame ideedega ja kuidas LANBIX sündis

«Lanit-Integratsioonides» on palju loovaid töötajaid. Uute toodete ja projektide ideed on peaaegu käega katsutavad. Parimate ideede leidmine võib olla tõeliselt keeruline. Seetõttu oleme üheskoos välja töötanud oma meetodi. Kuidas valida parimaid projekte ja neid ellu viia, lugege käesolevast artiklist.

Venemaal ja ülemaailmselt toimuvad mitmed protsessid, mis viivad IT-turu transformatsioonini. Tänu arvutusvõimsuse suurenemisele ning serverite, võrgu ja muude virtualiseerimistehnoloogiate tekkimisele on turg lõpetanud vajaduse suurte „raudade” järele. Tootjad eelistavad üha enam töötada otse klientidega. IT-turul õitseb kõikvõimalik allhange, alates klassikalisest allhangest kuni uue laine allhangeteni - „pilveteenuse pakkujateni”. Infrastruktuurisüsteemid ja -komponendid muutuvad hooldamiselt ja seadistamiselt tõeliselt lihtsamaks. Tarkvara kvaliteet kasvab igal aastal ja integreerija ülesanded muutuvad.

Kuidas me töötame ideedega

Toote alustamise suund «Lanit-Integratsioonides» oleme tegutsenud rohkem kui aasta. Meie põhieesmärk on uute toodete loomine ja nende turule toomine. Alustasime toote loomise protsessi korraldamisest. Uurisime mitmeid metoodikaid, alustades klassikalisest ja lõpetades trendikatega. Kuid ükski neist ei vastanud meie vajadustele. Seetõttu otsustasime aluseks võtta Lean Startup metoodika ja kohandada seda oma ülesannete jaoks. „Lean Startup” on ettevõtlusteooria, mille on loonud Eric Ries. Selle aluseks on põhimõtted, lähenemisviisid ja praktika sellistes kontseptsioonides nagu säästlik tootmine, kliendiarendus ja paindlik arendustegevus.

Mis puutub toote arenduse juhtimise lähenemisviisi, siis me ei hakanud jalgratast leiutama, vaid kasutasime juba olemasolevat arendusmetoodikat. SCRUM, lisades loomingut, ja nüüd võib teda julgelt nimetada SCRUM-WATERFALL-BAN. SCRUM, vaatamata oma paindlikkusele, on väga range süsteem, mis sobib juhtima meeskonda, mis vastutab ainult ühe toote/projekti eest. Nagu te mõistate, ei eelda klassikaline „integraatorlik” äri spetsialistide täiskohaga jaotamist ühele projekti (erandeid esineb, kuid äärmiselt harva), kuna kõik on hõivatud jooksvaid projekte tehes. SCRUM-ist võtsime töö jagamise sprinditeks, igapäevase aruandluse, retrospektiivid ja rollid. Ülesannete voogudega töötamiseks valisime Kanbani, mis integreerus suurepäraselt meie olemasolevasse ülesannete jälgimise süsteemi. Oleme ülesehitust kohandanud, sujuvalt integreerudes juba olemasolevasse korra.
Enne turule laskmist läbivad tooted 5 etappi: idee, valik, kontseptsioon, MVP (lisainfot — allpool) ja tootmine.

Idee

Sellel etapil on olemas midagi efemeerset – idee. Ideaalis on see olemasoleva probleemi või kliendi ülesande lahendamise idee. Meil pole ideede puudust. Algse kavandi kohaselt peaksid need genereerima tehniliste valdkondade töötajad. Et idee saaks järgmisse arendusse, peab autor täitma "Idee vormistamise mall". Seal on neli küsimust: Mis? Miks? Kellele see vajalik on? Ja kui see ei ole meie toode, siis mis see on?

Allikas

Valik

Niipea, kui vormistatud mall meie poole jõuab, algab töötlemise ja valikuprotsess. Valikute müügi etapp on kõige töömahukam. Selle etapi jooksul koostatakse probleemihüpoteesid (ma ei maininud eelnevas lõigus asjatult, et idee peaks ideaalis lahendama kliendi probleemi) ja toote väärtus. Koostatakse arengu hüpotees, st kuidas meie äri plaanib kasvada ja õitseda. Teostatakse probleemide ja ekspertide intervjuud potentsiaalsete tellijatega, et esialgu kinnitada, et kavatseme toota midagi vajalikku. Nõutav on vähemalt 10-15 intervjuud, et teha järeldus toote vajalikuse kohta.

Kui hüpoteesid kinnituvad, tehakse eelseisev finantsanalüüs, hinnatakse investeeringute mahtu ja võimalikke tulu investorerile. Selle etapi tulemusena valmib dokument nimega Lean Canvas, mis esitatakse juhtkonnale.

Kontseptsioon

Selles etapis filtreeritakse umbes 70% ideedest välja. Kui kontseptsioon kiidetakse heaks, algab idee väljatöötamise etapp. Kujundatakse tulevase toote funktsionaalsus, määratakse rakendusviisid ja optimaalsed tehnilised lahendused ning ajakohastatakse äriplaani. Selle etapi tulemus on tehniline spetsifikatsioon arendamiseks ja detailne ärijuhtum. Kui kõik sujub – liigume edasi MŽP või MVP staadiumisse.

MŽP või MVP

MŽP on minimaalne elujõuline toode. See tähendab, et toode ei ole täielikult välja töötatud, kuid juba toob väärtust ja täidab oma funktsionaalsust. Arenduse selle etapi jooksul kogume kindlasti tagasisidet tegelikelt kasutajatelt ja teeme muudatusi.

Tootmine

Ja viimane etapp on tootmine. Sellesse etappi jõuab vähem kui 5% toodetest. Nendesse 5% kuuluvad vaid kõige olulisemad, vajalikud, elujõulised ja funktsionaalsed tooted.

Meil on palju ideid, oleme kogunud mahuka portfelli. Üksikasjalikult uurime iga ideed ja teeme kõik võimaliku, et see jõuaks lõppstaadiumisse. On väga meeldiv, et kolleegid ei jäänud meie R&D suunaga ükskõikseks ja osalevad aktiivselt toodete ja lahenduste arenduses ning rakendamises.

Kuidas me tegime LANBIX-i

Vaatame toote loomist reaalsete näidete põhjal — tootest LANBIX. See on „kastis“ tark- ja riistvarakompleks, mis on mõeldud väikeste IT-infrastruktuuride jälgimiseks ja vastutavatele isikutele ja äri kasutajatele probleemidest teavitamiseks chat-boti kaudu. Lisaks jälgimisfunktsioonile sisaldab LANBIX ka Help Deski funktsionaalsust. See toode on eksklusiivne turusegmendile, kuhu me sihime. See on nii meie eelis kui ka meie valus koht. Kuid kõigest järgemööda. Ütlen kohe, et LANBIX on elav toode (st see ei ole oma arengus lõplik ja on järgmise MVP ringis).

Nii et, esimene etapp on idee. Idee sündimiseks on vajalikud probleemid, ja meil neid oli, täpsemalt mitte meil, vaid meie tuttavatel. Allpool vaatleme mitmeid reaalseid olukordi, mis on toimunud erinevates äri valdkondades.

Väike juhtimisettevõte teenindab kahte maja Moskva oblastis. Töötajate, kel on arvuti, arv on umbes 15. Süsteemihaldur on vabakutseline (nutikas poeg ühest kaastundlikust elanikust). Tundub, et haldusettevõtte tegevus sõltub IT-st vähe, kuid selle äri eripära on igakuised aruanded paljudele asutustele. Ettevõtte juhi süsteemide ketas (nagu tavaliselt paljude rollide kombinatsioonis) oli vaba ruumi lõppenud. Muidugi ei juhtunud see ootamatult, hoiatus oli olnud seadistatud peaaegu 2 kuud ja pidevalt ignoreeritud. Kuid siis saabus värskendus, operatsioonisüsteem uuendati ja nagu halva õnne osas hangus see uuendamise keskel, kurtes enne "surma" okupeeritud ketta üle. Arvuti hakkas tsüklisse taaskäivituma. Probleemi lahendamiseks ja aruannete leidmiseks unustasime aruannete esitamise tähtaja. Tundus, et tühine riknemine oli põhjustanud erinevaid ebamugavusi: kahjudest kuni kohtuvaidlemise ja haldusvastutuseni.

Allikas   

Sarnane juhtum leidis aset suure kontserni puhul, mis koondab mitmeid väikeseid ettevõtteid, saavutades ühtse tehnilise toe teenuse kogu kontorile. Ühes osakonnas tõrkus pea raamatupidaja arvuti. Et tema viga oli juba ammu teada (arvuti töötas äärmiselt aeglaselt ja kuumenes), polnud pea raamatupidajal kuidagi võimalik teha tehnilise toe taotlust. Loomulikult tõrkus see just palgapäeval, ja osakonna töötajad istusid mitu päeva rahata.

Väikesel suuremahulisel kaubandusel oli müügisait, mis oli hostitud välisel platvormil. Selle kättesaamatuse kohta said nad teate regulaarselt tellijalt telefoni teel. Kõne hetkel oli sait juba umbes kolm tundi maas. Vastutava isiku leidmine võttis veel paar tundi, rikke kõrvaldamiseks veel kaks. Seetõttu oli sait praktiliselt kogu tööpäeva vältel kättesaamatu. Ettevõtte kommertsdirektori sõnul maksis see neile umbes 1 miljon rubla.

Ma olen ise silmitsi seisnud sarnase olukorraga, kui läksin kliinikusse ja pidin minema DMS registratuurisse. Arsti juurde mind ei saadetud labane põhjus - hommikul oli pinge tõus, ja pärast avariid ei töötanud nende postiteenus ja mingisugune kindlustusega suhtlemise teenus. Minu küsimusele, kus on teie administraatorid, vastati, et administraator on neil tulev ja külastab neid kord nädalas. Ja praegu (siis oli kell juba 16:00) ei vasta ta telefonile. Polikliinik oli vähemalt 7 tundi maailmast ära lõigatud ja ei saanud pakkuda tasulisi teenuseid.

Mis ühendab kõiki neid juhtumeid? Kõik probleemid oleks saanud ette ennetada. Ajal, mil IT-alaseid teenuseid osutavad inimesed olid õigeaegselt reageerivad, oleks saadud vähendada põhjustatud kahju. See oleks olnud võimalik ka varaste sümptomite õige tõlgendamise korral kasutajate poolt.

Oleme välja toonud probleemihüpoteesid:

• olulised rahalised ja mainekahjud madala reageerimiskiirusest IT-infrastruktuuri riketel;
• vale varaste sümptomite tõlgendamine kasutajate poolt.

Mida saab tellija nende jaoks teha ja kuidas selliseid olukordi tulevikus vältida? Valikuid ei ole palju:

1. palgata kõrge kvalifikatsiooniga süsteemiadministraator ja sundida teda tõsiselt tööle;
2. delegeerida IT hooldus spetsialiseeritud teenusepakkujale;
3. ise rakendada rikete jälgimise ja teavitamise süsteemi;
4. viia läbi kasutajate/äspersonali koolitus digitaalsete oskuste põhitõdedes.

Peame kolmandal variandil. Pakume jälgimissüsteemi neile, kes seda erinevatel põhjustel ei kasuta.

Lüüriline kõrvalepõige. Erinevad IT-teenuste jälgimise süsteemid on ettevõtete turul ammu kasutusel ja nende kasulikkust ei ole võimalik vaidlustada. Olen rääkinud suurte ettevõtete esindajatega ja vaadanud, kuidas äri ja IT omavahel suhtlevad. Ühe suure masinaehitusettevõtte tehniline direktor on usaldanud IT-infrastruktuuri haldamise välisele ettevõttele, kuid ise jääb ta kõigest teadlikuks. Tema kabinetis on suur ekraan IT-teenuste seisundi jälgimise süsteemist. Süsteemi on sisestatud kõige kriitilisemad teenused. Iga hetk võib tehniline direktor kontrollida, millises seisukorras on infrastruktuur, mis toimub, kus on probleem, kas vastutavad isikud on teavitatud ja kas probleemi lahendamisega tegeletakse.

Nimetatud lood panid meie meeskonna mõtlema, kuidas luua optimaalse jälgimissüsteemi väikestele ettevõtetele. Tulemuseks on LANBIX — jälgimissüsteem, mille saab üles seada igaüks, kellel puuduvad IT-teenused. Süsteemi põhieesmärk on lihtne, nagu kõik süsteemid, mis on suunatud pidevuse ja kättesaadavuse suurendamisele – rahaliste ja muude kahjude vähendamine planeerimata seisakute korral. Seade on mõeldud vähendama aega fraaside vahel "minu asi on katki" ja "probleem on lahendatud".

Hüpoteeside kinnitamiseks viidi läbi probleemintervjuud. Ma ei osanud ette kujutada, kui palju inimesed on valmis rääkima, kui neid mitte müüa. Iga vestlus kestis vähemalt 1,5 tundi ja saime hulganisti teavet, mis on edasiste arendustööde jaoks kasulik.

Kokkuvõtteks selle etapi tulemustest:

1. probleemi mõistmine — on olemas,
2. väärtuse mõistmine — on olemas,
3. lahenduse idee — on olemas.

Teine etapp oli detailsem. Selle tulemuste põhjal pidime esitama juhtkonnale, kes tegelikult täidab investori rolli, äriplaani (see sama Lean Canvas), et teha otsust toote edasise saatuse kohta.

Alustasime turu uuringuga ja konkurentsianalüüsiga, et selgitada välja, kes, mida ja, mis kõige tähtsam, kuidas selles turul teeb.

Selgus järgnev.

1. Turul puuduvad valmis paketid meie sihtrühmale (väikeettevõtted), välja arvatud paar-kolm, mille kohta ma arusaadavatel põhjustel rääkida ei saa.
2. Meie peamised konkurendid on kummaliselt piisavalt süsteemi administraatorid, kes kasutavad enda kirjutatud skripte ja täiustusi avatud lähtekoodiga jälgimissüsteemide jaoks.
3. On ilmne probleem avatud lähtekoodiga jälgimissüsteemide kasutamisel. Süsteem olemas, teavet süsteemi töö ja kohandamise kohta on tohutult. Minu küsitletud administraatoritest paljud tunnistasid, et neil ei ole piisavalt oskusi oma ideede elluviimiseks. Ja juhtkonnale selle tunnistamine on nende jaoks keeruline töötuks jäämise kartuse tõttu. Niisiis, tulemuseks on suletud ring.

Seejärel alustasime meie potentsiaalsete klientide vajaduste analüüsiga. Määrasime endale väikeste organisatsioonide segmendi, kellel mingil põhjusel pole oma IT-osakonda, kus IT eest vastutab kas välistatud süsteemihaldur, vabakutseline või teenusepakkuja. Me otsustasime läheneda mitte IT-küljelt, vaid äri küljelt, pakkudes äri asutajatele ja omanikele tööriista IT-infrastruktuuri teenindamise kvaliteedi parandamiseks. Toode, mis peaks aitama omanikel kaitsta oma äri, ent samas toob see siiski rohkem tööd neile, kes IT eest vastutavad. Toode, mis annab ärile tööriista IT-tugiteenuste kvaliteedi kontrollimiseks.

Saadud andmete töötluse tulemusena valmis esimene nõuete nimekiri (teatud määral toote järeltegevuse esialgne plaan):

• monitooringusüsteem peab põhinema avatud lähtekoodiga lahendusel, mis tähendab, et see on odav;
• lihtne ja kiire installida;
• ei tohiks nõuda spetsiifilisi IT-teadmisi, isegi raamatupidaja (ei tahtnud mingil juhul selle ametigruppi solvata) peaks olema suuteline süsteemi käivitama ja seadistama;
• peaks automaatselt avastama võrgus jälgitavad objekte;
• peaks automaatselt (ideaalis automaatse) installima jälgimisagente;
• peaks olema võimeline jälgima väliseid teenuseid, sealhulgas vähemalt CRM-süsteemi ja müügilehte;
• peaks teavitama probleeme nii äri kui ka süsteemiadministraatori kohta;
• teavituste sügavus ja 'keel' peaks olema erinev administraatori ja äri jaoks;
• süsteem peaks olema varustatud oma riistvaraga;
• riistvara peab olema maksimaalselt kergesti kättesaadav;
• süsteem peab olema maksimaalselt sõltumatu välistest teguritest.

Edasi arvutati investeeringud toote arendamisse (sealhulgas tehnilise osakonna töötajate tööjõukulu). Koostati ärimudeli skeem ja arvutati toote ühenoomika.

Etapi tulemus:

• ülevaatlik toote backlog;
• ettevõtte ärimudel või mastaapi hüpotees, mida tuleb veel praktikas testida.

Liigume järgmisele etapile — kontseptsioonidele. Siin, inseneridena, satume oma elemendi. On „soove”, mis dekomponeeritakse komponentide/alamsüsteemide/omaduste järgi, seejärel muutuvad need tehnilisteks ülesanneteks/kasutajate lugudeks, seejärel projektilooks jne. Ma ei jää detailideni, kuidas ette valmistada alternatiivsete variantide kogumit, vaid liikume kohe nõudmiste ja valitud lahenduste juurde.

Nõue
Lahendus

• See peab olema avatud jälgimissüsteem;

Võtame avatud lähtekoodiga jälgimissüsteemi.

• Süsteem peab olema lihtne ja kiire paigaldada;
• ta ei tohi nõuda spetsiifilisi IT-oskusi. Isegi raamatupidaja peaks olema suuteline süsteemi käivitama ja seadistama.

Pakume installitud süsteemi, et kasutajal jääks vaid seade sisse lülitada ja seda veidi seadistada, sarnaselt ruuteriga.

Piirame seose seadmega millegagi lihtsaks ja igale arusaadavaks.

Loome oma vestlusroboti ühele tuntud suhtlusrakendusele ja suuname kogu suhtluse süsteemiga sellele.

Süsteem peab:

• automaatselt tuvastama võrku jälgitavad objektid;
• automaatselt installeerima jälgimisagente;
• omama võimalust jälgida välisteenuseid, sealhulgas vähemalt CRM-süsteemi ja müügilehte.

Loome täiendusi jälgimissüsteemile:

• automaatseks objektide tuvastamiseks;
• automaatseks agentide installeerimiseks;
• väliste teenuste kättesaadavuse jälgimiseks.

Süsteem peab:

• teavitama probleemidest nii äri kui ka süsteemi administraatorit;
• omama võimalust jälgida välisteenuseid, sealhulgas vähemalt CRM-süsteemi ja müügilehte. Teavituste sügavus ja "keel" peaksid olema erinevad administraatori ja äri jaoks.
• Süsteem ei tohi nõuda spetsiifilisi teadmisi IT valdkonnas, isegi raamatupidaja peaks olema võimeline süsteemi seadistama ja käivitama.

• Lisame erinevad teavitustüübid erinevatele kasutajatüüpidele. Need erinevad esituse ja üksikasjalikkuse poolest. Ärikasutaja saab teate, nagu 'kõik on hästi, kuid Ivanovi arvuti sureb peagi'. Administrator saab täieliku veateate, kellele, kuidas ja mis juhtus või võib juhtuda.
• Lisame võimaluse kasutada täiendava vastutava isiku e-posti, et tal oleks saadaval teade, kui midagi katki läheb.
• Lisame interaktsiooni välistelt teenusepakkujatelt, saates e-kirju ettevalmistatud tekstiga, kuna just elektrooniline kiri annab aluse sündmuse registreerimiseks.
• Kogu interaktsioon süsteemiga suuname vestlusroboti, suhtlemine toimub dialoogilises vormis.

Täiendamine:

• Lisame funktsionaalsuse 'vestlus administratoriga', et kasutaja saaks administraatorile otse probleemikirjelduse saata.

• Süsteem peab olema varustatud oma riistvaraga.
• Riistvara peab olema kergesti kätte saadav.
• Süsteem peab olema maksimaalselt sõltumatu keskkonnast.

• Valime odava ja valmis arvuti Raspberry PI.
• Projitseerime toitekatkestuste vältimise plaadi.
• Lisame modemi, et tagada sõltumatust kohaliku võrgu seisundist.
• Kujundame ilusa korpuse.

Meil on kolm alamsüsteemi, milles igaühel on oma nõuded ja visioon nende rakendamiseks:

• riistvara alamsüsteem;
• monitooringu alamsüsteem;
• kasutaja interaktsiooni alamsüsteem.

Riistvara alamsüsteemi jaoks oleme välja töötanud skeemiprojekti. Jah, tõesti! Kõiki agiliseerimise reegleid rikkudes töötasime välja dokumendi, sest tootmisettevõtted töötavad just dokumentide alusel. Ülejäänud alamsüsteemide puhul määrasime kasutajad (persoonid), koostasime kasutajaloosid ja kirjutasime arendustegevuste ülesandeid.

Käesolev kontseptsiooni etapp lõpeb ning selle tulemuseks on:

• projekt riistvaraplatvormile;
• välja töötatud visioon kasutajalugude kujul ülejäänud kahe alamsüsteemi jaoks;
• tarkvara osa prototüüp, mis on realiseeritud virtuaalmasina kujul;
• riistvara osa prototüüp, mis on realiseeritud katsetusennakuna, kus kontrolliti riistvaralahenduste tugevust;
• testimine, mille viisid läbi meie administraatorid.

Selles etapis olid probleemid enamasti organisatsioonilised ning seotud inseneriteadmiste puudulikkusega müügi juriidilistes ja raamatupidamisalastes aspektides. Ehk tead, mis ja kuidas müüa, on üks asi, aga teine on silmitsi seista halastamatu juriidilise masinaga: patentide, arendusteate, bilansi kasutuselevõtu, EULA ja paljuga muuga, mida me loomeinimestena algselt ei arvestanud.

See ei olnud veel probleem, pigem oli see raskus, mis oli seotud korpuste projekteerimisega. Meie meeskonnas on ainult insenerid, seega lõi meie elektroonikaspetsialist esialgse korpuse orgaanilisest klaasist.

Korpus nägi, pehmelt öeldes, vastuoluline välja, eriti publiku jaoks, kes on harjunud kaasaegse tehnikaga. Loomulikult leidus austajaid ka vanema generatsiooni "kulibinide" seas — korpus tekitas neis nostalgilisi tundeid. Otsustati korpus uuesti valmistada ja projekteerida, kuna vanal, pealtnäha esteetilisest puudusest oli veel konstruktiivne — orgaaniline klaas talus halvasti seadme kokkupanekut ja lahtivõtmist ning tahtis praguneda. Korpuse tootmisest räägin edasi.

Nüüd oleme lähedal lõppfinaalile — MVP. Loomulikult pole see veel lõplik seeria toode, kuid see pakub juba kasu ja väärtust. Selle etapi peamine eesmärk on käivitada tsükkel "luua-hinnata-õppida". Just selles etapis on LANBIX.

Etapis "luua" oleme loonud seadme, mis täidab deklareeritud funktsionaalsust. Jah, see pole veel ideaalne, ja me jätkame selle kallal töötamist.

Naaseme korpuse valmistamise juurde, st ülesande juurde, milleks on meie seadme muutmine nostalgilist tunnet tekitavast modernseks. Alguses uurisin turgu korpuse tootjate ja tööstusliku disaini teenuste osutajate osas. Esiteks on Venemaa turul korpuste tootjaid väga vähe, ja teiseks on tööstusliku disaini hind antud etapis ülemäära kõrge, umbes 1 miljon rubla.

Kujunduse osas pöördusime oma turundusosakonna poole, noor disainer oli loominguliste katsetuste jaoks valmis. Jagasime oma nägemust korpusest (eelnevalt uurides parimaid korpuseehituse näiteid), ja tema muutis selle omakorda kunstiteoseks. Jäi ainult toota. Olles oma disaini üle uhked, pöördusime partnerite poole. Nende tegevjuht hävitas meie unistused hetkega, osutades täiesti tasuta asjadele, mida meie valitud viisil toota ei olnud võimalik. Korpust on võimalik toota, ja see ei jää Apple'ile alla, kuid korpuse hind on sel juhul kolm-neli korda kallim kui kogu elektrooniline sisu. Pärast mitmeid operatsioone ja kooskõlastusi projekteerisime korpuse, mida on võimalik toota. Jah, see ei ole enam nii ilus kui algselt plaanisime, kuid see on ideaalne praeguste eesmärkide saavutamiseks.

Etapi tulemus: esimene partii seadmeid, valmis lahinguks ja katsetamiseks.

Ja nüüd tuleb kõige keerulisem etapp — etapp "hindamine", ja meie toote puhul oleme just selles etapis. Saame hindama vaid tõeliste klientide kasutamise tulemuste järgi ning siin ei aita mingid oletused. Me vajame neid varajasi järgijaid, et tagasisidet anda ja tootesse neid muudatusi tuua, mis tõeliselt vajalikud on. Küsimus on: kust leida kliente ja kuidas neid veenda eksperimendis osalema?

Kõigist võimalikest variantidest valisime klassikalise komplekti digitaalseid tööriistu: maandumislehe ja reklaamikampaania sotsiaalmeedias.

Protsess on juba käimas, kuid veel on vara rääkida tulemustest, kuigi tagasisidet on juba saabunud ja me oleme saanud kinnitust paljude meie hüpoteeside kohta. Meie jaoks oli meeldiv üllatus reaktsioon esindajate poolt täiesti erinevatelt äri segmentidelt, mis on palju suuremad kui need, millele me lootnud olime. Oleks loll ignoreerida uusi sisendeid, ja intervjuude põhjal tehtud otsuste tulemusena astusime samme paralleelse LANBIX Enterprise sarja käivitamiseks. Oleme lisanud toetuse jaotatud infrastruktuuridele, Wi-Fi-võrkude jälgimise, otsimise ja tõrgete lokaliseerimise, sidekanalite kvaliteedi jälgimise. Suurimat huvi lahenduse vastu on väljendanud teenindusettevõtted. Samuti mängivad meie juba välja töötatud seadmed lahendustes olulist rolli.

Mis järgmiseks?

Edasi minnes selgub, mis saab LANBIX-ist, sõltuvalt kampaania tulemustest. Kui meie hüpoteesid ei saa kinnitust, rakendame Lean-metoodika kohaselt rangeid meetmeid, et neist lahti saada või muudame toote millegi uueks, sest pole midagi hullemat kui valmistada toode, mis pole kellelegi vajalik. Kuid juba praegu võib öelda, et tehtud töö ei ole olnud asjatuks ning selle tulemusena on tekkinud uus paralleelsete toodete rida, mille kallal me aktiivselt töötame. Edu korral liigub LANBIX MVP faasist edasi lõppfaasi ja areneb tuntud klassikaliste toote turustusprintsiipide järgi.

Kordan, et soovime praegu leida varajasi järgijaid, ettevõtteid, kellele meie toodet paigaldada tagasiside kogumise eesmärgil. Kui teid huvitab LANBIX-i testimine, kirjutage kommentaaridesse või otseisese sõnumitesse.

Allikas

Allikas: habr.com