Kaip dirbame su idėjomis ir kaip gimė LANBIX

„LANIT-Integration“ dirba daug kūrybingų darbuotojų. Idėjos naujiems produktams ir projektams tiesiogine prasme sklando ore. Kartais gali būti labai sunku nustatyti įdomiausius. Todėl kartu sukūrėme savo metodiką. Perskaitykite šį straipsnį, kaip išsirinkti geriausius projektus ir juos įgyvendinti.

Rusijoje ir visame pasaulyje vyksta nemažai procesų, kurie lemia IT rinkos transformaciją. Padidėjus skaičiavimo galiai ir atsiradus serverių, tinklų ir kitoms virtualizacijos technologijoms, rinkai nebereikia didelio kiekio techninės įrangos. Pardavėjai vis labiau nori dirbti su klientais tiesiogiai. IT rinka išgyvena visų formų užsakomųjų paslaugų bumą – nuo ​​klasikinių užsakomųjų paslaugų iki naujos užsakovų bangos – „debesų paslaugų teikėjų“. Infrastruktūros sistemas ir elementus tampa daug lengviau prižiūrėti ir konfigūruoti. Kasmet auga programinės įrangos kokybė, keičiasi integratoriaus užduotys.

Kaip mes dirbame su idėjomis

Produkto paleidimo kryptis „LANIT-integracija“ gyvuoja jau daugiau nei metus. Mūsų pagrindinis tikslas – kurti naujus produktus ir pateikti juos rinkai. Pirmas dalykas, nuo kurio pradėjome, buvo produktų kūrimo proceso organizavimas. Išstudijavome daugybę metodikų – nuo ​​klasikos iki hype. Tačiau nė vienas iš jų neatitiko mūsų poreikių. Tada nusprendėme remtis Lean Startup metodika ir pritaikyti ją savo užduotims. Lean Startup yra verslumo teorija, kurią sukūrė Ericas Riesas. Jis pagrįstas tokių koncepcijų kaip taupi gamyba, klientų vystymas ir lanksti plėtros metodika principais, požiūriais ir praktikomis.

Kalbant apie tiesioginį požiūrį į produkto kūrimo valdymą: mes neišradome dviračio iš naujo, o taikėme jau egzistuojančią kūrimo metodiką. SCRUM, pridedant kūrybiškumo, ir dabar jį galima drąsiai vadinti SCRUM-WATERFALL-BAN. SCRUM, nepaisant savo lankstumo, yra labai nelanksti sistema ir tinka komandai, atsakingai tik už vieną produktą/projektą, valdyti. Kaip suprantate, klasikinis „integracijos“ verslas neapima techninių specialistų skyrimo visą darbo dieną vienam projektui (yra išimčių, bet labai retai), nes be darbo su produktais, visi yra užsiėmę esamais projektais. Iš SCRUM mes perėmėme darbo pasidalijimą į sprintus, kasdienes ataskaitas, retrospektyvas ir vaidmenis. Savo užduočių eigai pasirinkome Kanban ir ji puikiai integravosi į esamą užduočių sekimo sistemą. Savo darbą struktūrizavome sklandžiai integruodamiesi į esamą dalykų tvarką.
Prieš patekdamas į rinką produktas pereina 5 etapus: idėja, atranka, koncepcija, MVP (daugiau informacijos žemiau) ir gamyba.

Idėja

Šiame etape yra kažkas trumpalaikio – idėja. Idealiu atveju idėja išspręsti esamą ar kliento problemą. Idėjų mums netrūksta. Pagal pirminį planą jas turėtų generuoti techninių sričių darbuotojai. Kad idėja būtų priimta toliau plėtoti, autorius turi užpildyti „Idėjos dizaino šabloną“. Yra tik keturi klausimai: kas? Kam? Kam to reikia? O jei ne mūsų produktas, tai kas?

šaltinis

Pasirinkimas

Kai tik mus pasiekia užpildytas šablonas, prasideda apdorojimo ir atrankos procedūra. Atrankos etapas yra pats darbo jėgos imliausias. Šiame etape susiformuoja problemų hipotezės (ne veltui ankstesnėje pastraipoje minėjau, kad idealiu atveju idėja turėtų išspręsti kliento problemą) ir produkto vertė. Susidaro masto hipotezė, t.y. kaip mūsų verslas augs ir klestės. Atliekami problemų ir ekspertų pokalbiai su potencialiais klientais, siekiant gauti preliminarų patvirtinimą, kad gaminsime kažką reikalingo. Norint padaryti išvadą apie produkto poreikį, reikia bent 10-15 interviu.

Jeigu hipotezės pasitvirtina, atliekama preliminari finansinė analizė, įvertinamos apytikslės investicijų apimtys ir galimas investuotojo uždarbis. Šio etapo rezultatas – dokumentas, pavadintas Lean Canvas, pristatomas vadovybei.

Sąvoka

Šiame etape pašalinama apie 70% idėjų. Jeigu koncepcijai pritariama, tada prasideda idėjos kūrimo etapas. Formuojamas būsimo produkto funkcionalumas, nustatomi įgyvendinimo keliai ir optimalūs techniniai sprendimai, atnaujinamas verslo planas. Šio etapo rezultatas – techninė kūrimo specifikacija ir detalus verslo pavyzdys. Jei pasiseks, pereiname į MVP arba MVP etapą.

MVP arba MVP

MVP yra minimalus gyvybingas produktas. Tie. produktas, kuris nėra iki galo išvystytas, bet jau gali atnešti vertę ir atlieka savo funkcionalumą. Šiame kūrimo etape būtina rinkti atsiliepimus iš tikrų vartotojų ir atlikti pakeitimus.

Gamyba

Ir pats paskutinis etapas yra gamyba. Šį etapą pasiekia ne daugiau kaip 5% produktų. Šie 5% apima tik pačius svarbiausius, būtiniausius, gyvybingiausius ir funkcionaliausius produktus.

Turime daug idėjų ir jau surinkome didelį portfelį. Mes analizuojame kiekvieną idėją ir darome viską, kad ji pasiektų galutinį etapą. Labai džiugu, kad mūsų kolegos neliko abejingi mūsų MTEP krypčiai ir aktyviai dalyvauja kuriant bei diegiant produktus ir sprendimus.

Kaip mes sukūrėme LANBIX

Pažiūrėkime, kaip sukurti gaminį naudojant realų pavyzdį – LANBIX produktą. Tai „dėžutės“ programinės ir techninės įrangos sistema, skirta stebėti mažas IT infrastruktūras ir operatyviai įspėti sprendimus priimančius asmenis bei verslo vartotojus apie gedimus, valdomus per pokalbių robotą. Be stebėjimo funkcijos, LANBIX apima pagalbos tarnybos funkciją. Šis produktas yra išskirtinis tam rinkos segmentui, į kurį orientuojamės. Tai ir mūsų pranašumas, ir mūsų skausmas. Bet pirmiausia pirmiausia. Iš karto pasakysiu, kad LANBIX yra gyvas produktas (tai yra, jis nėra galutinis jo kūrimo metu ir yra kitame MVP etape).

Taigi, pirmasis etapas yra idėja. Kad gimtų idėja, reikia problemų, o mes jų turėjome, tiksliau ne mes, o mūsų draugai. Žemiau apžvelgsime keletą realių situacijų, kurios įvyko įvairiose verslo srityse.

Maža valdymo įmonė prižiūri du namus Maskvos srityje. Darbuotojai su kompiuteriais yra apie 15 žmonių. Sistemos administratorius yra lankantis laisvai samdomas darbuotojas (vieno rūpestingo gyventojo protingas sūnus). Atrodytų, valdymo įmonės veikla silpnai priklauso nuo IT, tačiau šio verslo ypatumas – kasmėnesinis atsiskaitymas daugeliui institucijų. Įmonės vadovo sisteminiame diske (kuriame, kaip įprasta, sujungiama daugybė vaidmenų) pritrūko laisvos vietos. Natūralu, kad tai neatsitiko staiga, įspėjimas kabojo apie 2 mėnesius ir buvo nuolat ignoruojamas. Tačiau atėjo naujinimas, OS buvo atnaujinta ir, kaip pasisekė, atnaujinimo viduryje ji užstrigo, prieš „mirtį“ skųsdamasi dėl užimto ​​disko. Kompiuteris buvo cikliškai paleistas iš naujo. Spręsdami problemą ir gaudami ataskaitas praleidome ataskaitų pateikimo terminą. Atrodytų, nereikšmingas gedimas pridarė įvairių rūpesčių: nuo nuostolių iki bylinėjimosi ir administracinės atsakomybės.

šaltinis   

Panašus incidentas įvyko didelėje holdingo kompanijoje, vienijančioje daug mažų įmonių, kurios techninės pagalbos tarnyba buvo teikiama visam biurui. Viename iš skyrių sugedo vyriausiosios buhalterės kompiuteris. Jau seniai buvo žinoma, kad jis gali sugesti (kompiuteris beviltiškai lėtėjo ir įkaisdavo), tačiau vyriausioji buhalterė taip ir nespėjo nusiųsti užklausos techninei pagalbai. Natūralu, kad sugedo būtent atlyginimo dieną, o skyriaus darbuotojai kelias dienas buvo be pinigų.

Smulkios didmeninės prekybos įmonė turėjo pardavimo svetainę, kuri buvo talpinama išorinėje platformoje. Apie jo neprieinamumą sužinojome telefonu iš nuolatinio kliento. Skambučio metu svetainė neveikė apie tris valandas. Prireikė dar poros valandų surasti už svetainę atsakingą asmenį ir dar dvi valandas problemai išspręsti. Atitinkamai, svetainė buvo nepasiekiama beveik visą darbo dieną. Bendrovės komercijos direktoriaus teigimu, šios prastovos jiems kainavo apie 1 mln.

Aš pati susidūriau su panašia situacija, kai atvykau užsirašyti į polikliniką ir turėjau eiti į VHI registraciją. Jie negalėjo manęs nusiųsti pas gydytoją dėl nereikšmingos priežasties - ryte buvo elektros šuolis, o po avarijos neveikė jų pašto paslauga ir tam tikra bendravimo su draudimo kompanija paslauga. Atsakant į mano klausimą, kur yra jūsų administratoriai, man pasakė, kad jų adminas ateina ir lankosi kartą per savaitę. Ir dabar (tuo metu buvo jau 16:00) jis nekelia ragelio. Mažiausiai 7 valandas klinika buvo atskirta nuo išorinio pasaulio ir negalėjo teikti mokamų paslaugų.

Ką bendro turi visi šie atvejai? Absoliučiai visų problemų buvo galima išvengti iš anksto. Laiku sureagavus IT žmonėms, žala galėjo būti sumažinta. Tai būtų įmanoma, jei vartotojai teisingai interpretuotų ankstyvuosius simptomus.

Mes nustatėme problemų hipotezes:

• didelių piniginių ir reputacijos nuostolių dėl mažo reagavimo į IT infrastruktūros gedimus greičio;
• naudotojai neteisingai interpretuoja ankstyvuosius gedimo simptomus.

Ką klientas gali su jais daryti ir kaip išvengti panašių situacijų ateityje? Pasirinkimų nėra daug:

1. samdyti aukštos kvalifikacijos sistemos administratorių ir priversti jį dirbti sąžiningai;
2. IT priežiūrą perduoti specializuotai paslaugų įmonei;
3. savarankiškai diegti stebėjimo ir pranešimų apie gedimus sistemą;
4. teikti mokymus vartotojams/verslo darbuotojams kompiuterinio raštingumo pagrindų.

Apsistokime prie trečiojo varianto. Pasiūlykime stebėjimo sistemą tiems, kurie ja nesinaudoja dėl įvairių priežasčių.

Lyrinis nukrypimas. Įvairios IT paslaugų stebėjimo sistemos įmonių rinkoje naudojamos jau seniai ir dėl jų naudos nesiginčijama. Kalbėjausi su didelių įmonių atstovais, pažiūrėjau, kaip kuriamas verslo ir IT ryšys. Vienos didelės mašinų gamybos įmonės techninis direktorius IT infrastruktūros priežiūrą perdavė išorės įmonei, tačiau jis pats lieka žinoti apie visus reikalus. Jo kabinete kabo didelis stebėjimo sistemos ekranas su IT paslaugų būsenos indikatoriais. Svarbiausi yra įtraukti į sistemą. Technikos direktorius bet kurią akimirką gali sužinoti, kokia yra infrastruktūros būklė, kas vyksta, kur problema, ar pranešta atsakingiems asmenims, ar problema sprendžiama.

Aukščiau išvardytos istorijos privertė mūsų komandą susimąstyti, kaip sukurti optimalią stebėsenos sistemą mažoms įmonėms. To pasekoje gimė LANBIX – stebėjimo sistema, kurią gali diegti absoliučiai bet kas be jokių IT žinių. Pagrindinis sistemos tikslas yra paprastas, kaip ir visų sistemų, kuriomis siekiama padidinti tęstinumą ir prieinamumą – sumažinti piniginius ir kitus nuostolius neplanuotų prastovų atveju. Įrenginys sukurtas taip, kad iki minimumo sumažintų laiką nuo „kažkas sugedo“ iki „problema išspręsta“.

Hipotezėms patvirtinti buvo atlikti probleminiai interviu. Neįsivaizdavau, kiek žmonės norėtų pasakyti, nebandydami jiems parduoti. Kiekvienas pokalbis trukdavo mažiausiai 1,5 valandos, gaudavome daug informacijos, naudingos tolimesniam tobulėjimui.

Apibendrinkime šio etapo rezultatus:

1. yra problemos supratimas,
2. vertės supratimas – yra,
3. Yra sprendimo idėja.

Antrasis etapas buvo išsamesnis. Remdamiesi jo rezultatais, vadovybei, kuri iš esmės atlieka investuotojo vaidmenį, turėjome pateikti verslo pavyzdį (ta pati Lean Canvas), kad būtų priimtas sprendimas dėl tolimesnio produkto likimo.

Pradėjome nuo rinkos tyrimų ir konkurencijos analizės, siekdami išsiaiškinti, kam, ką ir, svarbiausia, kaip jiems sekasi šioje rinkoje.

Paaiškėjo taip.

1. Mūsų segmentui (smulkiajam verslui) rinkoje nėra paruoštų dėžutės stebėjimo sistemų, išskyrus porą ar tris, apie kurias dėl akivaizdžių priežasčių nekalbėsiu.
2. Pagrindiniai mūsų konkurentai, kaip bebūtų keista, yra sistemų administratoriai, turintys namuose parašytus scenarijus ir „priedus“ prie atvirojo kodo stebėjimo sistemų.
3. Yra aiški problema naudojant atvirojo kodo stebėjimo sistemas. Yra sistema, yra didžiulis kiekis informacijos, kaip dirbti ir modifikuoti sistemą pagal savo poreikius. Iš mano kalbintų administratorių daugelis prisipažino, kad neturi pakankamai kompetencijų įgyvendinti savo idėjas savarankiškai. Tačiau jie negali to pripažinti vadovybei, bijodami būti atleisti. Pasirodo, tai užburtas ratas.

Tada perėjome prie potencialių klientų poreikių analizės. Mes nustatėme sau segmentą mažų organizacijų, kurios kažkodėl neturi savo IT paslaugos, kur už IT yra atsakingas arba atvykstantis sistemos administratorius, arba laisvai samdomas darbuotojas, arba paslaugų įmonė. Įeiti ryžosi ne IT, o verslo pusė, siūlanti steigėjams ir įmonių savininkams įrankį IT infrastruktūros paslaugų kokybei gerinti. Produktas, kuris turėtų padėti savininkams apsaugoti savo verslą, tačiau tuo pat metu jis suteiks darbo žmonėms, atsakingiems už IT. Produktas, suteikiantis įmonėms įrankį IT pagalbos kokybei stebėti.

Apdorojant gautus duomenis, gimė pirmasis reikalavimų sąrašas (savotiškas grubus atsilikimas) būsimam produktui:

• stebėjimo sistema turi būti pagrįsta atvirojo kodo sprendimu ir dėl to pigi;
• lengvas ir greitas montavimas;
• neturėtų reikalauti specifinių IT žinių, net buhalteris (jokiu būdu nenorėjau įžeisti šios profesijos atstovų) turėtų sugebėti diegti ir konfigūruoti sistemą;
• turėtų automatiškai aptikti objektus stebėti tinkle;
• turėtų automatiškai (ir idealiu atveju automatiškai) įdiegti stebėjimo agentus;
• turi turėti galimybę stebėti išorines paslaugas, bent jau CRM sistemą ir pardavimo svetainę;
• apie problemas turėtų pranešti tiek verslui, tiek sistemos administratoriui;
• administratoriaus ir įmonės įspėjimų gylis ir „kalba“ turėtų skirtis;
• sistema turi būti tiekiama naudojant atskirą techninę įrangą;
• geležis turi būti kuo prieinamesnė;
• sistema turėtų būti kuo labiau nepriklausoma nuo išorinių veiksnių.

Toliau buvo skaičiuojamos investicijos į produkto kūrimą (įskaitant darbo sąnaudas techninio skyriaus darbuotojams). Parengtas verslo modelio eskizas ir apskaičiuota gaminio vienetinė ekonomika.

Etapo rezultatas:

• aukšto lygio produktų atsilikimas;
• suformuluotas verslo modelis arba masto hipotezė, kuri dar turi būti išbandyta praktiškai.

Pereikime prie kito etapo – koncepcijos. Čia mes, kaip inžinieriai, atsiduriame savo gimtojoje stichijoje. Yra „norų sąrašai“, kurie išskaidomi į komponentus/posistemes/ypatybes, vėliau paverčiami techninėmis specifikacijomis/vartotojų istorijomis, vėliau – projektu ir pan. Smulkiau nesigilinsiu į eilės alternatyvių variantų rengimo procesą, pereikime tiesiai prie reikalavimų ir pasirinktų jų įgyvendinimo būdų.

Reikalavimas
sprendimas

• Tai turėtų būti atvira stebėjimo sistema;

Mes naudojame atvirojo kodo stebėjimo sistemą.

• Sistema turi būti paprasta ir greitai įdiegiama;
• neturėtų reikalauti specifinių IT žinių. Net buhalteris turėtų sugebėti įdiegti ir konfigūruoti sistemą.

Siūlome įdiegtą sistemą, kad vartotojui tereikia įjungti įrenginį ir šiek tiek sukonfigūruoti, panašiai kaip maršrutizatorių.

Sąveiką su įrenginiu uždarykime prie paprasto ir visiems suprantamo.

Parašykime savo pokalbių robotą vienam iš gerai žinomų momentinių pranešimų siuntėjų ir perkelkime į jį visas sąveikas su sistema.

Sistema turėtų:

• automatiškai aptikti objektus, reikalingus stebėjimui tinkle;
• automatiškai įdiegti stebėjimo agentus;
• Gebėti stebėti išorines paslaugas, bent CRM sistemą ir pardavimo svetainę.

Rašome stebėjimo sistemos priedus:

• automatinis objektų aptikimas;
• automatinis agentų diegimas;
• išorinių paslaugų prieinamumo stebėjimas.

Sistema turėtų:

• apie problemas pranešti tiek verslui, tiek sistemos administratoriui;
• mokėti stebėti išorines paslaugas, bent jau CRM sistemą ir pardavimo svetainę. Administratoriaus ir įmonės pranešimų gylis ir „kalba“ turėtų skirtis.
• Sistemai neturėtų būti reikalingos specifinės IT žinios, net buhalteris turi sugebėti įdiegti ir konfigūruoti sistemą.

• Pridėkime skirtingų tipų pranešimus skirtingų tipų naudotojams. Jie skiriasi žingsniu ir gyliu. Verslo vartotojas gaus tokius pranešimus kaip „viskas gerai, bet Ivanovo kompiuteris greitai mirs“. Administratorius gaus išsamų pranešimą apie klaidą, kas, kaip ir kas atsitiko ar gali nutikti.
• Pridėkime galimybę naudotis papildomo atsakingo asmens paštu, kad gedimo atveju jis gautų pranešimą.
• Pridėkime sąveiką su išoriniais paslaugų teikėjais, pagrįstą laiškų siuntimu su iš anksto paruoštu tekstu, nes Tai el. laiškas, dėl kurio įvyko incidentas.
• Visa sąveika su sistema bus sujungta su pokalbių robotu, bendravimas vyksta dialogo stiliumi.

Papildymas:

• Pridėkime „pokalbio su administratoriumi“ funkciją, kad vartotojas galėtų tiesiogiai nusiųsti administratoriui pranešimą, kuriame aprašoma problema.

• Sistema turi būti tiekiama naudojant atskirą techninę įrangą.
• Geležis turi būti prieinama.
• Sistema turi būti kuo labiau nepriklausoma nuo aplinkos.

• Paimkime jau paruoštą ir pigų Raspberry PI kompiuterį.
• Suprojektuosime nepertraukiamo maitinimo plokštę.
• Pridėkime modemą, kad jis būtų nepriklausomas nuo vietinio tinklo būsenos.
• Suprojektuosime gražų pastatą.

Dabar turime tris posistemes su savo reikalavimais ir jų įgyvendinimo vizija:

• techninės įrangos posistemis;
• stebėjimo posistemis;
• vartotojo sąveikos posistemis.

Sukūrėme preliminarų techninės įrangos posistemio projektą. Taip taip! Pažeidę visas agile taisykles, parengėme dokumentą, nes gamyklos dirba su dokumentais. Likusioms posistemėms nustatėme vartotojus (asmenis), parengėme vartotojų istorijas ir parašėme kūrimo užduotis.

Tai užbaigia koncepcijos etapą, o rezultatas yra:

• aparatinės įrangos platformos projektas;
• suformuluota vizija likusių dviejų posistemių vartotojų istorijų forma;
• programinės įrangos prototipas, įgyvendintas kaip virtuali mašina;
• aparatūros prototipas, įgyvendintas stendo pavidalu, kuriame realiai buvo išbandytas techninių sprendimų stiprumas;
• testavimą atliko mūsų administratoriai.

Problemos šiame etape daugiausia buvo organizacinės ir susijusios su inžinierių personalo žinių stoka teisiniais ir apskaitos aspektais pardavimų srityje. Tie. Vienas dalykas yra išsiaiškinti, ką ir kaip parduoti, o visai kas kita – susidurti su negailestinga teisine mašina: patentais, kūrimo užduotimis, registracija, EULA ir daug daugiau, į ką mes, kūrybingi žmonės, iš pradžių neatsižvelgėme.

Problemos dar nebuvo, greičiau buvo sunkumų, susijusių su korpusų dizainu. Mūsų komandą sudaro tik inžinieriai, todėl pirmąjį korpuso variantą iš organinio stiklo „sukūrė“ mūsų elektronikos specialistas.

Kūnas atrodė, švelniai tariant, prieštaringai, ypač visuomenei, sugadintas šiuolaikinių technologijų. Žinoma, tarp vyresnės kartos „Kulibinų“ buvo žinovų – pastatas jiems sukėlė nostalgiškus jausmus. Korpusą nuspręsta gaminti ir suprojektuoti iš naujo, nes senasis, be estetinių trūkumų, turėjo ir konstrukcinių - organinis stiklas gerai neatlaikė įrenginio surinkimo ir išmontavimo, buvo linkęs trūkinėti. Apie korpuso gamybą papasakosiu toliau.

O dabar esame arti finišo – MVP. Žinoma, tai dar nėra galutinis gamybos produktas, bet jau naudingas ir vertingas. Pagrindinis šio etapo tikslas – pradėti ciklą „kurti-vertinti-mokytis“. Būtent tokiame etape yra LANBIX.

„Kurimo“ etape sukūrėme įrenginį, kuris atlieka deklaruotą funkcionalumą. Taip, jis dar nėra tobulas, ir mes toliau prie to dirbome.

Grįžkime prie kėbulo gamybos, t.y. užduočiai pakeisti mūsų įrenginį iš nostalgiško į modernų. Pradžioje naršiau spintų gamintojų ir pramoninio dizaino paslaugų rinką. Pirma, Rusijos rinkoje nėra daug įmonių, gaminančių dėklus, ir, antra, pramoninio dizaino kaina šiame etape yra pernelyg didelė, apie 1 milijoną rublių.

Dėl dizaino jie susisiekė su mūsų rinkodaros skyriumi, jaunoji dizainerė buvo pasiruošusi kūrybiniams eksperimentams. Mes išdėstėme savo korpuso viziją (anksčiau ištyrėme geriausius korpuso konstrukcijos pavyzdžius), o jis savo ruožtu pavertė ją meno kūriniu. Belieka tik jį pagaminti. Mes, didžiuodamiesi savo dizainu, kreipėmės į savo partnerius. Jų generalinis direktorius iškart sugriovė mūsų fantazijas, visiškai nemokamai nurodydamas dalykus, kurių negalima pagaminti mūsų pasirinktu būdu. Korpusas gali būti pagamintas ir jis bus ne prastesnis nei Apple, tačiau dėklo kaina bus tris keturis kartus brangesnė nei visų elektroninių komponentų. Po daugybės operacijų ir patvirtinimų sukūrėme korpusą, kurį galima gaminti. Taip, jis nėra toks gražus, kaip planavome, bet idealiai tinka dabartiniams tikslams pasiekti.

Etapo rezultatas: pirmoji prietaisų partija, paruošta kovai ir bandymams.

O dabar pats sunkiausias yra „įvertinimo“ etapas, o su savo gaminiu esame būtent šioje vietoje. Mes galime vertinti tik remdamiesi realių klientų naudojimo rezultatais ir jokios prielaidos čia neveikia. Mums reikia tų „ankstyvųjų naudotojų“, kad pateiktų atsiliepimus ir padarytų tikrai reikalingus produkto pakeitimus. Kyla klausimas: kur gauti klientų ir kaip įtikinti juos dalyvauti eksperimente?

Iš visų galimų variantų pasirinkome klasikinį skaitmeninių įrankių rinkinį: nukreipimo puslapį ir reklaminę kampaniją socialiniuose tinkluose.

Procesas jau pradėtas, tačiau apie rezultatus kalbėti dar anksti, nors atsakymų jau yra ir sulaukėme daugelio savo hipotezių patvirtinimo. Maloniai nustebino visiškai skirtingų verslo segmentų atstovų reakcija, daug didesnė nei tikėjomės. Būtų kvaila nekreipti dėmesio į naujus pristatymus, o remiantis interviu rezultatais buvo nuspręsta paleisti lygiagrečią LANBIX liniją, pavadintą LANBIX Enterprise. Pridėjome paskirstytų infrastruktūrų palaikymą, Wi-Fi tinklų stebėjimą, trikčių šalinimą ir lokalizavimą bei ryšio kanalų kokybės stebėjimą. Didžiausią susidomėjimą sprendimu išreiškė paslaugų įmonės. Kartu mūsų jau sukurti įrenginiai atlieka svarbų vaidmenį sprendimų veikime.

Kas bus toliau

Kas bus toliau su originaliu LANBIX, paaiškės remiantis akcijos rezultatais. Jei mūsų hipotezės nepasitvirtins, pagal Lean metodiką mes negailestingai jos atsikratysime arba ji bus transformuota į kažką naujo, nes nėra nieko blogiau, kaip pagaminti niekam nereikalingą produktą. Tačiau dabar galime teigti, kad atliktas darbas nenuėjo veltui ir jo dėka atsirado visa atšaka lygiagrečių gaminių, prie kurių aktyviai dirbame. Jei pasiseks, LANBIX pereis iš MVP etapo į galutinį etapą ir vystysis pagal suprantamus klasikinius produktų rinkodaros dėsnius.

Kartoju, dabar norime rasti ankstyvųjų naudotojų, įmonių, kurios galėtų įdiegti mūsų produktą, kad surinktų atsiliepimus. Jei susidomėjote LANBIX testavimu, rašykite į komentarus arba privačias žinutes.

šaltinis

Šaltinis: www.habr.com