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

«LANIT-Integratsioonides» on palju loomingulisi töötajaid. Uute toodete ja projektide ideed on õhust lausa haaratud. Kõige huvitavamate välja selgitamine osutub vahel väga keeruliseks. Seetõttu oleme koos jõududena välja töötanud oma meetodi. Kuidas parimaid projekte valida ja neid ellu viia, loe sellest artiklist.

Venemaal ja ka maailmas laiemalt toimuvad mitmed protsessid, mis viivad IT-turu transformatsioonini. Tänu arvutusvõimsuse suurenemisele ja serverite, võrgu- ja muude virtualiseerimistehnoloogiate ilmumisele, ei vajata turul enam suurt hulka „rauda“. Tarnijad eelistavad üha enam töötada otse klientidega. IT-turul õitseb tasuta teenindus igas vormis, alates klassikalisest teenindusest kuni uue laine teenusepakkujatega – „pilveteenuse pakkujatega“. Infraestruktuurisüsteemid ja nende komponendid muutuvad oluliselt lihtsamaks hooldada ja seadistada. Tarkvara kvaliteet kasvab iga aastaga ning integratori ülesanded muutuvad.

Kuidas me töötame ideedega

Toote algatuste suund «LANIT-Integratsioonides» on eksisteerinud juba üle aasta. Meie peamine eesmärk on uute toodete loomine ja nende turule toomine. Esimene samm, millega alustasime, oli toote loomise protsessi korraldamine. Uurisime läbi mitmeid metoodikaid, alates klassikalisest kuni uute trendideni. Siiski ei vastanud ükski neist meie nõudmistele. Seetõttu otsustasime võtta aluseks Lean Startup metoodika ja kohandada seda oma ülesannete jaoks. „Kärbetootmine“ on ettevõtlus teooria, mille lõi Eric Ries. Selle põhialused on põhimõtted, lähenemised ja praktikad, nagu näiteks kärbetootmine, kliendi arendamine ja paindlik arendusmetoodika.

Mis puutub otse toote arendamise juhtimise lähenemisse: me ei hakanud jalgratast leiutama, vaid rakendasime juba olemasoleva arendusmetoodika SCRUM, lisades loomingulisust, ja nüüd võib seda julgelt nimetada SCRUM-WATERFALL-BAN-iks. SCRUM, vaatamata oma paindlikkusele, on üsna range süsteem ja sobib meeskonna haldamiseks, mis vastutab ainult ühe toote/projekti eest. Nagu mõistate, ei eelda klassikaline „integraatorite” äri tehniliste spetsialistide täiskohaga eraldamist ühel projektil (välja arvatud harvadel juhtudel), kuna lisaks toodete kallal töötamisele on kõik hõivatud käimasolevate projektidega. SCRUM-ist võtsime töö jagamise sprindiks, igapäevased aruandlused, retrospektiivid ja rollid. Ülesannete voolu töös kasutasime Kanbanit, mis integreerus suurepäraselt meie olemasolevasse ülesannete jälgimise süsteemi. Oleme korraldanud töö, sujuvalt integreerides end juba olemasolevasse korda.
Enne turule tulekut läbib toode 5 etappi: idee, valik, kontseptsioon, MVP (ühest allpool) ja tootmine.

Idee

Sellel etapil on midagi efemeerset – idee. Ideaalis on see lahendus olemasolevale probleemile või kliendi ülesandele. Ideid on meil küllaga. Algse mõtte kohaselt peaksid need genereerima tehniliste suundade töötajad. Et idee saaks edasi arendamiseks vastu võetud, peab autor täitma „Idee vormistamise šablooni”. Seal on vaid neli küsimust: Mis? Kelleks? Kellele see on vajalik? Ja kui see ei ole meie toode, siis mis siis?

Allikas

Valik

Niikaua kui vormistatud šabloon meieni jõuab, algab töötlemise ja valiku protseduur. Valiku etapp on kõige töömahukam. Selles etapis töötatakse välja probleemide hüpoteesid (ma ei maininud eelnevas lõigus asjata, et ideaalil on idee, mis peaks lahendama kliendi probleemi) ja toote väärtust. Koostatakse hüpotees kasvust, st kuidas meie äri kavatseb kasvada ja areneda. Läbi viidud probleemilised ja ekspertintervjuud võimalike tellijatega, et eeltõestada, et kavatseme toota midagi vajalikku. Vajame vähemalt 10-15 intervjuud, et teha järeldusi toote vajalikusest.

Kui hüpoteesid kinnituvad, viiakse läbi esialgne finantsanalüüs, hinnatakse ligikaudseid investeerimise mahte ja võimalikku tulu investorile. Selle etapi tulemusena sünnib dokument nimega Lean Canvas ja esitatakse juhtkonnale.

Kontseptsioon

Selles etapis filtreeritakse välja umbes 70% ideedest. Kui kontseptsioon saab heakskiidu, algab idee arendamise etapp. Koostatakse tulevase toote funktsionaalsed võimalused, määratletakse rakendusteed ja optimaalsed tehnilised lahendused, ning uuendatakse äriplaani. Selle etapi tulemuseks on tehniline ülesanne arendamiseks ja detailne ärijuhtum. Edu korral liigume MŽP või MVP etappi.

MŽP või MVP

MŽP on minimaalne elujõuline toode. See tähendab, et toode, mis ei ole täielikult välja töötatud, kuid suudab juba pakkuda väärtust ja täita oma funktsiooni. Arenduse sel etapil kogume kindlasti tagasisidet reaalsetelt kasutajatelt ja viime sisse muudatusi.

Tootmine

Ja viimane etapp on tootmine. Sellesse etappi jõuab mitte rohkem kui 5% toodetest. Nendesse 5% kuuluvad ainult kõige olulisemad, vajalikud, elujõulised ja funktsionaalsed tooted.

Meil on palju ideid ja oleme kogunud mahuka portfelli. Uurime iga ideed ja teeme kõik, et see jõuaks lõpule. On väga meeldiv, et kolleegid ei ole jäänud ükskõikseteks meie UUR/E&D suunale ja osalevad aktiivselt toodete ja lahenduste arendamises ja rakendamises.

Kuidas me tegime LANBIX-i

Vaadakem toote loomist reaalse näitena — toode LANBIX. See on „karbis“ tarkvara-riistvara kompleks, mis on mõeldud väikeste IT-infrastruktuuride jälgimiseks ja vastutavate isikute ning ärikasutajate teavitamiseks tõrgetest chatboti kaudu. Peale jälgimise funktsiooni sisaldab LANBIX ka Help Desk funktsionaalsust. See toode on ainulaadne selle turusegmendi jaoks, millele oleme suunatud. See on meie eelis ja meie mure. Kuid kõigest järjest. Ütleksin kohe, et LANBIX on elav toode (st see ei ole oma arengus lõplik ja on järgmises MVP ringis).

Nii et esimene etapp on idee. Idee tekkimiseks on vajalikud probleemid, ja need olid meil, pigem mitte meil, vaid meie tuttavatel. Allpool vaatame mõningaid reaalseid olukordi, mis on juhtunud erinevates äri valdkondades.

Väike haldusettevõte teenindab kahte maja Moskva oblastis. Tööjõud, kellel on arvuti, on umbes 15 inimest. Süsteemihaldur on välitöötaja (nutikas poeg ühest murelikust elanikkonnast). Tundub, et haldusettevõtte tegevus sõltub IT-st vähe, kuid selle äris on omadus — kuus on vaja esitada aruandeid paljudele asutustele. Ettevõtte juhi süsteemivalikul (nagu tavaliselt, mis ühendab mitmeid rolle) jäi vaba koht täitmata. Loomulikult ei juhtunud see äkki — hoiatust oli nähtud juba umbes 2 kuud, aga seda ignoreeriti pidevalt. Aga tuli uuendus, operatsioonisüsteem uuendati ja just siis tekkis probleemuuenduse keskel, kaevates enne „surma” täidetud ketta üle. Arvuti läks tsüklilisse taaskäivitamisse. Samal ajal kui tegeleti probleemiga ja kaevati aruandeid, möödus aruandluse esitamise tähtaeg. Tundus, et tühine tõrge põhjustas mitmeid ebameeldivusi: kahjumeid kohtuvaidlustest kuni haldusvastutuse ja rahaliste kaotusteni.

Allikas   

Sarnane juhtum esines suurel kontsernil, mis ühendab mitmeid väikesi ettevõtteid, kes jagavad ühte tehnikatoe teenust kogu büroo jaoks. Ühes osakonnas läks katki peaarvestaja arvuti. Et see võiks katki minna, oli ammu teada (arvuti töötas kohutavalt aeglaselt ja ülekuumenemine oli häiriv), kuid peaarvestajal ei olnud aega tehnilise toe väljakutse esitamiseks. Loomulikult läks arvuti katki just palgapäeval ja osakonna töötajad jäid paariks päevaks rahata.

Väikesel hulgikaubanduse ettevõttel oli müügisaidi häälestamine, mis töötas välistingimustes. Selle kättesaamatuse teada saime telefoni teel regulaarselt tellijalt. Helistamise hetkel oli veebisait olnud maas juba umbes kolm tundi. Vastutava isiku leidmine saidi eest võttis veel paar tundi, vea kõrvaldamine veel kaks. Seega oli veebisait praktiliselt kogu tööpäeva jooksul kättesaamatu. Ettevõtte kommertsdirektori sõnul maksis see seisak neile umbes 1 miljon rubla.

Ma ise olen sarnase olukorraga silmitsi seisnud, kui läksin polikliinikusse ja pidin minema DMS registratuuri. Arsti juurde mind ei saadetud lihtsa põhjuse tõttu - hommikul oli tugev pingesurve ja pärast avariid ei töötanud nende postiteenus ega mingi teenus, mis suhtles kindlustusega. Minu küsimusele, kus on teie administraatorid, vastati, et admin on neil nädalane külaline ja külastab neid kord nädalas. Ja nüüd (tol hetkel oli kell juba 16:00) ei vasta ta telefonile. Polikliinik oli vähemalt 7 tundi välismaailmast eraldatud ja ei suutnud osutada tasulisi teenuseid.

Mis ühendab kõiki neid juhtumeid? Kõik probleemid oleks olnud võimalik aegsasti ära hoida. Aegse reageerimise korral IT teenindavate inimeste poolt oleks olnud võimalik kahjusid vähendada. See oleks olnud võimalik ka kasutajate poolse varajaste sümptomite õige tõlgendamise korral.

Oleme välja toonud probleemide hüpoteesid:

• olulised rahalised ja reputatsioonikahjud ülevaate madala reageerimiskiirusest IT-infrastruktuuri rikkumistele;
• kasutajate vale tõlgendus varajastest rikkumise sümptomitest.

Mida saab nendega teha tellija ja kuidas vältida sarnaseid olukordi tulevikus? Valikuid ei ole nii palju:

1. kaasata kõrgelt kvalifitseeritud süsteemiadministraator, kes töötab ausalt;
2. anda IT hooldus spetsialiseeritud teenindusettevõttele;
3. ise rakendada rikkumiste jälgimise ja teavitamise süsteem;
4. korraldada kasutajatele/äritegevuse isikutele vabatahtlik IT-oskuste koolitus.

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

Lüüriline kõrvalepõige. Äriturgude IT-teenuste monitooringu erinevad süsteemid on pikka aega kasutuses ja nende kasulikkust ei saa vaidlustada. Olen rääkinud suurte ettevõtete esindajatega, vaadanud, kuidas on üles ehitatud äri ja IT suhteid. Ühe suure masinatootmisettevõtte tehniline direktor usaldas IT-infrastruktuuri hoolduse välisele ettevõttele, kuid jääb siiski kõigest kursis. Tema kabinetis ripub suur ekraan monitooringusüsteemist, millel on IT-teenuste olekute indikaatorid. Süsteemi on sisestatud kõige kriitilisemad teenused. Igal ajal võib tehniline direktor uurida, millises seisukorras on infrastruktuur, mis toimub, kus on probleem, kas vastutavad isikud on teavitatud, ja kas probleem lahendatakse.

Need lood sundisid meie meeskonda mõtlema, kuidas luua optimaalse monitooringusüsteemi väikestele ettevõtetele. Tulemuseks oli LANBIX — monitooringusüsteem, mille suudab üles seada täiesti iga inimene ilma IT teadmiste olemasoluta. Süsteemi peamine ülesanne on sama lihtne nagu kõigil süsteemidel, mille eesmärk on suurendada pidevust ja kättesaadavust — rahaliste ja muude kadude vähendamine juhuslike seisakute korral. Seade on loodud minimeerima aega, mis kulub „minu midagi katkes” ja „probleem on lahendatud” vahel.

Hüpoteeside kinnitamiseks viidi läbi probleemiküsitlusi. Ma ei osanud isegi ette kujutada, kui palju inimesed on valmis rääkima, kui neile mitte müüa. Iga vestlus kestis vähemalt 1,5 tundi ja saime rohkelt teavet, mis on kasulik edasises arenduses.

Kokkuvõte 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 etapi tulemuste põhjal pidime esitama juhtkonnale, kes tegelikult täidab investorite rolli, ärijuhtumi (see sama Lean Canvas) edasise otsuse tegemiseks toote käekäigu kohta.

Algasime turu uurimise ja konkurentsianalüüsiga, et selgitada välja, kes, mida ja, mis peamine, kuidas turul tegutseb.

Selgus järgmine.

1. Turul ei ole meie segmendile (väikeäri) valmis kastisüsteeme monitooringuks, välja arvatud paar-kolm, mille kohta ma ilmselgetel põhjustel rääkida ei saa.
2. Meie peamised konkurendid on, üllatus-üllatus, süsteemiadministraatorid, kellel on isetehtud skriptid ja "täiendused" avatud lähtekoodiga jälgimissüsteemidele.
3. Ilmselgelt on probleem avatud lähtekoodiga jälgimissüsteemide kasutamisel. On olemas süsteem, mis pakub tohutut hulka teavet süsteemi töö ja kohandamise kohta vastavalt oma vajadustele. Minu küsitletud administraatoritest paljud tunnistasid, et neil puuduvad oskused oma ideede elluviimiseks. Ja juhtkonnale selles tunnistamine on neile võimatu töökaotuse kartuse tõttu. Tulemuseks on sulgunud ring.

Seejärel läksime üle oma potentsiaalsete klientide vajaduste analüüsile. Valisime välja väikeste organisatsioonide segmendi, kellel mingil põhjusel ei ole oma IT-osakonda, kus IT eest vastutab kas külastav süsteemiadministraator, vabakutseline tööline või teenusettevõte. Me ei kavatsenud siseneda IT poolt, vaid ettevõtte poolt, pakkudes ettevõtete asutajatele ja omanikele tööriista IT-infrastruktuuri teenuse kvaliteedi tõstmiseks. Tooted, mis peaksid aitama omanikel oma äri kaitsta, tõsi, samas lisab see tööd IT eest vastutavatele inimestele. Toode, mis pakub ettevõtetele tööriista IT toe kvaliteedi kontrollimiseks.

Saadud andmete töötlemise tulemusena sündis esimene nõudmiste nimekiri (mingi jäme taustaloogika) tulevase toote jaoks:

• jälgimissüsteem peab põhinema avatud lähtekoodiga lahendusel ja seega olema odav;
• olema lihtne ja kiire paigaldada;
• ei tohi nõuda spetsiaalseid IT-oskusi, isegi raamatupidaja (ma ei tahtnud kindlasti selle ametigruppi solvangut teha) peaks suutma süsteemi juurutada ja seadistada;
• peab automaatselt tuvastama jälgimisobjektid võrgus;
• peab automaatselt (ideaaljuhul automaatse) installima jälgimisagendid;
• peab võimaldama väliste teenuste jälgimist, vähemalt CRM-süsteemi ja müügisaidi;
• peab teavitama probleemidest nii äripoolt kui ka süsteemiadministraatorit;
• teadete sügavuse ja "keele" tase peab olema erinev administraatori ja äri jaoks;
• süsteem peab olema varustatud oma riistvaraga;
• riistvara peab olema maksimaalselt kergesti kättesaadav.
• Süsteem peab olema maksimaalselt sõltumatu välistest teguritest.

Järgnevalt arvutati investeeringud toote arendamiseks (sealhulgas tehnilise osakonna töötajate tööjõukulu). Valmistati ärimudeli skeem ja loodi toote unit-ökonoomika.

Etapi tulemus:

• kõrgetasemeline toote backlog;
• väljendatud ärimudel või hüpotees, mida tuleb veel praktikas testida.

Liigume järgmisele etapile - kontseptsioonile. Siin siseneme inseneridena oma loomulikku keskkonda. On "soovid", mis dekomponeeritakse komponentide/alam süsteemide/funktsioonideks, seejärel muutuvad need tehnilisteks nõudmisteks/kasutajahüpoteesideks, siis projektiks jne. Ma ei jää detaile välja tooma alternatiivsete lahenduste ettevalmistamise protsessist, vaid liikume kohe nõuete ja valitud rakendusmeetodite 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;
• ei tohi nõuda spetsiifilisi IT-teadmisi. Isegi raamatupidaja peaks olema suuteline süsteemi seadistama ja selle üles seadma.

Pakume eelinstallitud süsteemi, nii et kasutajale jääb vaid seade sisse lülitada ja natuke seadistada, sarnaselt ruuteriga.

Seome seadmega suhtlemise millegagi lihtsaks ja kõigile arusaadavaks.

Loome oma vestlusroboti ühe tuntud sõnumirakenduse jaoks ja suuname kogu suhtlemise süsteemiga sinna.

Süsteem peab:

• automaatne avastamine nõutavate jälgimisobjektide võrgus;
• automaatne jälgimisagentide paigaldamine;
• Küljest peab olema võimalik jälgida väliseid teenuseid, vähemalt CRM-süsteemi ja müügisaidi.

Kirjutame täiustusi jälgimissüsteemile:

• nõuete automaatseks tuvastamiseks;
• automaatseks agentide paigaldamiseks;
• väliste teenuste kättesaadavuse jälgimiseks.

Süsteem peab:

• teavitama probleemidest nii äri kui ka süsteemiadministraatorit;
• olema võimeline jälgima väliseid teenuseid, vähemalt CRM-süsteemi ja müügisaidi. Teavituste sügavus ja «keel» peaks olema erinev administraatori ja äri jaoks.
• Süsteem ei tohi nõuda spetsiifilisi IT-teadmisi, isegi raamatupidaja peab olema suuteline süsteemi seadistama ja üles seadma.

• Lisame erinevaid teatevorme erinevatele kasutajatüüpidele. Need erinevad esituse ja sügavuse poolest. Ärikasutaja saab teate, mis ütleb: "Kõik on hästi, aga Ivanovi arvuti hakkab varsti kokku kukkuma." Halduse kasutaja saab täieliku vea teate, kellel, kuidas ja mis juhtus või võib juhtuda.
• Lisame võimaluse kasutada täiendava vastutava isiku e-posti, et ta saaks rikete korral teate.
• Lisame koostöö väliste teenusepakkujatega, toetudes e-posti saatmisele ettevalmistatud tekstiga, kuna just e-kiri annab aluse incideedi registreerimiseks.
• Kogu suhtlemine süsteemiga toimub läbi vestlusrobotis, suhtlemine käib dialoogilises stiilis.

Täiendamine:

• Lisame funktsiooni "vestlus administraatoriga", et kasutaja saaks administraatorile saata sõnumi probleemist otse.

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

• Võtame valmis ja odava Raspberry PI arvuti.
• Disainime katkematu toitevarustuse plaadi.
• Lisame modemi sõltumatuse tagamiseks kohalikest võrgutingimustest.
• Disainime elegantse korpuse.

Meil on kolm alamsüsteemi, millel on oma nõuded ja nägemused nende rakendamiseks:

• riistvara alamsüsteem;
• jälgimisalamsüsteem;
• kasutajate suhtlemise alamsüsteem.

Riistvara alamsüsteemi jaoks oleme välja töötanud eskiisprojekti. Jah, jah! Rikkudes kõiki agiilsuse reegleid oleme koostanud dokumendi, kuna tootmisettevõtted töötavad ainult dokumentidega. Muudele alamsüsteemidele oleme määranud kasutajad (persona), koostanud kasutajalooge ja kirjutanud arendustegevuse ülesanded.

Selle etapi kontseptsioon lõpeb ja selle tulemuseks on:

• projekt riistvaraplatvormile;
• väljatöötatud nägemus kasutajate lugudena teistele kahele alamsüsteemile;
• programmi osa prototüüp, rakendatud virtuaalmasina kujul;
• riistvara osa prototüüp, mis on teostatud seismana, kus tegelikult testiti riistvaralahendusi;
• testimine, mille viisid läbi meie administraatorid.

Selle etapi probleemid olid peamiselt organisatsioonilised ja seotud inseneride vähese teadlikkusega müügi õiguslikest ja raamatupidamisaspektidest. St, üks asi on välja mõelda, mida ja kuidas müüa, ja täiesti teine asi on sattuda jõhkrasse õiguslikku masinasse: patendid, arendusteemad, bilansisse kandmine, EULA ja palju muud, mida me kui loov inimesed algselt ei arvestanud.

Probleem ei olnud nõnda, vaid pigem raskus, mis oli seotud korpuste projekteerimisega. Meie meeskonnas on ainult insenerid, nii et esimese korpuse «vormis» meie elektroonikaspetsialist akrüülplastist.

Korpus nägi õrnalt öeldes vaieldav välja, eriti kaasaegse tehnika ülelohutanud publiku jaoks. Loomulikult leidus ka «kuliibi» vanema generatsiooni seas selle austajaid — korpus tekitas neis nostalgiat. Otsustasime korpuse uueks valmistamiseks ja projekteerimiseks, kuna vanal korpusel olid lisaks esteetilistele puudustele ka konstruktiivsed — akrüülplast ei talunud seadme kokku- ja lahtivõtmist ning kalduvust lõhkeda. Räägin tootmisest lähemalt.

Ja nüüd oleme lähenemas finišisirgele — MVP. Loomulikult ei ole see veel lõplik seeriatootmise toode, kuid see toob juba kasu ja omab väärtust. Selle etapi peamine eesmärk on käivitada tsükkel «luua-hinnata-õppida». LANBIX on just sellel etapil.

Etapis «luua» oleme loonud seadme, mis täidab lubatud funktsioone. Jah, see pole veel ideaalne ja me jätkame selle kallal töötamist.

Naaseme korpuse valmistamise juurde, st ülesande juurde, kuidas muuta meie seade nostalgiat tekitavast modernseks. Alguses uurisin turgu korpuse tootjate ja tööstusliku disaini teenuste osutajate osas. Esiteks on Venemaa turul korpuseid tootvaid ettevõtteid üsna vähe ning teiseks on tööstusliku disaini hind sellel etapil ülemäära kõrge, umbes 1 miljon rubla.

Disaini osas pöördusime meie turundusosakonda, noor disainer oli valmis loomingulisteks katseteks. Väljendasime oma nägemust korpusest (enne kui uurisime parimaid korpuste näiteid), ning tema tõlkis selle kunstiteoseks. Jäi ainult toota. Me, uhked oma disaini üle, pöördusime partnerite poole. Nende tegevjuht purustas meie fantaasiad koheselt, viidates tasuta asjadele, mida meie valitud viisil toota ei ole võimalik. Korpust saab toota ja see ei jää Apple'ist alla, kuid korpuse maksumus tuleb kolm kuni neli korda kõrgem kui kogu elektrooniline osa. Pärast mitmeid operatsioone ja kokkuleppeid projekteerisime korpuse, mille toomine on võimalik. Jah, see ei ole enam nii ilus, nagu me plaanisime, kuid see on ideaalne meie praeguste eesmärkide saavutamiseks.

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

Ja nüüd kõige keerulisem — etapp "hindamine", ja meie toote puhul oleme just siin punktis. Saame hinnata ainult tegelike klientide kasutamise tulemuste põhjal, põhjendamatud oletused ei toimi. Meil on vaja neid varaseid järgijaid, et saada tagasisidet ja teha tootes need muudatused, mis on tõeliselt vajalikud. Tekib küsimus: kust saada kliente ja kuidas veenda neid eksperimenti osalema?

Kaugusest valisime klassikalise komplekti digitaalseid tööriistu: sihtlehe ja reklaamikampaania sotsiaalmeedias.

Protsess on juba alanud, kuid on liiga vara rääkida tulemustest, kuigi tagasisidet on juba saadud ja me saime kinnitust paljudele meie hüpoteesidele. Meeldis, et reaktsioon oli positiivne osalejate seas täiesti erinevatest ärisegmentidest, palju suurematest, kui me ette kujutasime. Oleks rumal uusi sisendeid ignoreerida ning intervjuude tulemuste põhjal tehti otsus käivitada paralleelne LANBIX’i tooteportfell, mille nimeks sai LANBIX Enterprise. Lisame toe hajutatud infrastruktuuridele, Wi-Fi võrkude jälgimise rike ja lokaliseerimise, sidekanalite kvaliteedi jälgimise. Suurimat huvi lahenduse vastu avaldasid teenindusettevõtted. Samuti mängivad juba meie arendatud seadmed lahenduste toimimises mitte viimast rolli.

Mis saab edasi

Mis juhtub edasi esialgse LANBIX-iga, selgub kampaania tulemuste põhjal. Kui meie hüpoteese ei kinnitata, siis Lean metoodika kohaselt vabaneme sellest halastamatult või see transformeerub millekski uueks, kuna pole midagi hullemat, kui teha toodet, mida keegi ei vaja. Kuid juba praegu võib öelda, et tehtud töö ei ole olnud asjatu ja selle tõttu on tekkinud terve rida paralleelseid tooteid, mille kallal me aktiivselt töötame. Edu korral liigub LANBIX MVP staadiumist lõplikku etappi ja areneb arusaadavate klassikaliste tootenäitamise seaduste järgi.

Kordan, et praegu tahame leida varaseid järgijaid, ettevõtteid, kellele saaksime installida meie toodet tagasiside kogumise eesmärgil. Kui olete huvitatud LANBIX-i testimisest, kirjutage kommentaaridesse või isiklikele sõnumitele.

Allikas

Allikas: habr.com