🥇Si punojmë me idetë, dhe si lindi LANBIX

Në «LANIT-Integra» ka shumë punonjës krijues. Idetë për produkte dhe projekte të reja pothuajse fluturojnë në ajër. Të identifikosh ato më interesante ndonjëherë mund të jetë shumë e vështirë. Prandaj, ne zhvilluam metodologjinë tonë me përpjekjet tona të përbashkëta. Si të selektosh projektet më të mira dhe si t'i realizosh ato, mëso në këtë artikull.

Në Rusi, dhe gjithashtu në botë në përgjithësi, po ndodhin një sërë procesesh që po çojnë në transformimin e tregut të IT. Falë rritjes së fuqive kompjuterike dhe shfaqjes së teknologjive të virtualizimit serverik, rrjetor dhe të tjera, tregu ka ndalur së paturi nevojë për një sasi të madhe 'hardueri'. Vendet e teknologjisë po preferojnë gjithnjë e më shumë të punojnë drejtpërdrejt me klientët. Në tregun e IT-së, outsourcing-u po lulëzon në të gjitha manifestimet e tij, duke filluar nga outsourcing-u klasik dhe duke përfunduar tek profesionistët e rinj – 'ofruesit e cloud'. Sistematikë infrastrukturore dhe elementët bëhen shumë më të thjeshtë për t'u mbajtur dhe konfiguruar. Cilësia e software-it po rritet çdo vit dhe detyrat e integratorit po transformohen.

Si punojmë me idetë

Drejtimi i startup-it produktor në «LANIT-Integra» ka ekzistuar për më shumë se një vit. Qëllimi ynë kryesor është krijimi i produkteve të reja dhe sjellja e tyre në treg. E para që filluam, ishte organizimi i procesit të krijimit të produkteve. Ne kemi studiuar shumë metodologji, duke filluar nga ato klasike deri te ato më moderne. Megjithatë, asnjëra prej tyre nuk përputhej me kërkesat tona. Atëherë ne vendosëm të marrim si bazë metodologjinë Lean Startup dhe ta adaptojmë për nevojat tona. 'Startup-i i kursyer' është një teori sipermarrjeje e krijuar nga Eric Ries. Në themel të saj qëndrojnë parimet, qasjet dhe praktikat e konceptesh të tilla si prodhimi i kursyer, zhvillimi i klientit dhe metodologjia fleksibël e zhvillimit.

Sa i përket qasjes së menaxhimit të zhvillimit të produktit: ne nuk shpikëm rrotën, por aplikuam një metodologji ekzistuese të zhvillimit SCRUM, duke shtuar kreativitet, tani mund të quhet me guxim SCRUM-WATERFALL-BAN. SCRUM, megjithëse ka fleksibilitet, është një sistem shumë i rreptë dhe i përshtatshëm për menaxhimin e një ekipi që përgjigjet vetëm për një produkt/projekt. Siç e kuptoni, biznesi klasik i "integratorëve" nuk parashikon ndarjen e specialistëve teknikë për kohë të plotë për të punuar në një projekt (përjashtime ndodhin, por shumë rrallë), duke qenë se përveç punës mbi produktet, të gjithë janë të angazhuar në projektet aktuale. Nga SCRUM morëm ndarjen e punës në sprintet, raportimin e përditshëm, retrospektivat dhe rolet. Për të punuar me fluksin e detyrave, zgjodhëm Kanban, dhe ai u integrua shkëlqyeshëm në sistemin tonë ekzistues të ndjekjes së detyrave. E organizuam punën, duke u integruar qetësisht në rendin e tashëm.
Para se të dalë në treg, një produkt kalon nëpër 5 etapa: ide, përzgjedhje, koncept, MVP (më shumë - më poshtë) dhe prodhim.

Ideja

Në këtë fazë ka diçka eterike – ideja. Idealisht, ideja e një zgjidhjeje për një problem apo detyrë të klientit. Nuk kemi mungesë idesh. Sipas konceptit fillestar, ato duhet të gjenerohen nga punonjësit e drejtimeve teknike. Për të pranuar idenë për zhvillim të mëtejshëm, autori duhet të plotësojë "Shabllonin e formës për ide". Aty ka vetëm katër pyetje: Çfarë? Pse? Kush e ka nevojë këtë? Dhe nëse nuk është produkti ynë, atëherë çfarë?

Burimi

Përzgjedhja

Sapo shablloni i plotësuar arrin tek ne, fillon procedura e përpunimit dhe përzgjedhjes. Faza e përzgjedhjes është më e punës shumë. Në këtë etapë formohen hipotezat e problemeve (nuk e kam përmendur pa arsye në paragrafin e mëparshëm se, idealisht, ideja duhet të zgjidhë problemin e klientit) dhe vlera e produktit. Formohet hipoteza e shkallës, dmth. si do të rritet dhe të lulëzojë biznesi ynë. Realizohen intervista problematike dhe ekspertësh me klientë potencialë për një konfirmim paraprak se jemi duke prodhuar diçka të nevojshme. Duhet të realizohen të paktën 10-15 intervista për të nxjerrë një përfundim mbi nevojshmërinë e produktit.

Nëse hipotezat konfirmohen, bëhet një analizë paraprake financiare, vlerësohet përllogaritja e investimeve sipas asaj çfarë pritet të fitohet. Si rezultat i kësaj etape, lind dokumenti i quajtur Lean Canvas dhe paraqitet për drejtimin.

Koncepci

Në këtë fazë, rreth 70% e ideve filtrohen. Nëse koncepti miratohet, fillon faza e zhvillimit të ideve. Formohen funksionalitetet e produktit të ardhshëm, përcaktohen mënyrat e realizimit dhe zgjidhjet teknike optimale, si dhe azhurnohet plani biznesor. Rezultati i kësaj faze është dokumentacioni teknik për zhvillimin dhe një rast të detajuar biznesor. Në rast suksesi, kalojmë në fazën MЖП ose MVP.

MЖП ose MVP

MЖП është produkti minimal jetësor. Pra, është një produkt i cili nuk është zhvilluar plotësisht, por që tashmë mund të sjellë vlerë dhe funksionalitetin e tij e çon deri në fund. Patjetër që në këtë fazë të zhvillimit, mbledhim reagime nga përdoruesit realë dhe bëjmë ndryshime.

Prodhimi

Dhe faza e fundit është prodhimi. Në këtë fazë arrijnë jo më shumë se 5% e produkteve. Në këto 5% përfshihen vetëm produktet më të rëndësishme, të nevojshme, jetësore dhe funksionale.

Ne kemi shumë ide, kemi mbledhur një portofol të gjerë. Ne çmojmë çdo ide dhe bëjmë gjithçka që ajo të arrijë në fazën përfundimtare. Është shumë e këndshme që kolegët nuk kanë mbetur indiferentë ndaj departamentit tonë të R&D dhe marrin pjesë aktivisht në zhvillimin dhe implementimin e produkteve dhe zgjidhjeve.

Si e zhvilluam LANBIX

Le të shqyrtojmë krijimin e produktit në një shembull real — produkti LANBIX. Ky është një kompleks programor-pajisje “i paketuar”, i destinuar për monitorimin e infrastrukturave të vogla IT dhe njoftimin në kohë të personave përgjegjës dhe përdoruesve të biznesit për problemet me menaxhimin përmes një chatbot-i. Përveç funksionit të monitorimit, LANBIX përfshin gjithashtu funksionalitetin Help Desk. Ky produkt është ekskluziv për segmentin e tregut në të cilin jemi fokusuar. Kjo është një avantazh tonë, por gjithashtu një dhimbje. Por gjithçka në radhë. Të them të drejtat, LANBIX është një produkt i gjallë (dmth, nuk është përfundimtar në zhvillimin e tij dhe ndodhet në një cikël tjetër MVP).

Pra, faza e parë është ideja. Që të lindë një ide, duhen probleme, dhe këto probleme i kishim, më saktë, mike tona. Më poshtë do të shqyrtojmë disa situata reale, të ndodhura në fusha të ndryshme të biznesit.

Një kompani menaxhuese e vogël shërben dy ndërtesa në Podmoskvi. Stafi i punonjësve që kanë PC është rreth 15 persona. Administratori i sistemit është një freelancer që punon nga jashtë (djali i mençur i njërit prej banorëve të angazhuar). Duket se aktiviteti i kompanisë menaxhuese ka një varësi të vogël nga IT, por karakteristika e këtij biznesi është raportimi mujor përpara shumë institucioneve. Në diskun sistemor të udhëheqësit të kompanisë (si zakonisht, që kombinon shumë rol), ka mbaruar hapësira e lirë. Natyrisht, kjo nuk ndodhi papritur; paralajmërimi kishte qëndruar për rreth 2 muaj dhe ishte injoruar vazhdimisht. Por e mori një update, sistemi u përditësua dhe, si për ironi, ngeci në mes të përditësimit, duke u ankuar para "vdekjes" për diskun e zënë. Kompjuteri hyri në një cikël rimëkëmbjeje. Ndërsa po merreshin me problemin dhe po nxirreshin raportet, humbën afatin për dorëzimin e raporteve. Duket se një defekt trivial u bë shkak për një sërë shqetësimesh: nga humbjet deri te mosmarrëveshjet ligjore dhe përgjegjësinë administrative.

Burimi

Një rast i ngjashëm ndodhi në një grup të madh, i cili bashkon shumë kompani të vogla, me një shërbim të vetë teknik të mbështetjes për të gjithë zyrën. Në një nga departamentet, kompjuteri i kryetarit të llogarive u prish. Ishte e njohur prej kohësh që ai do të ndalej (kompjuteri ngadalë dhe nxehej), por kryetari i llogarive nuk kishte mundësi t'i dërgonte një kërkesë shërbimit të mbështetjes. Natyrisht, ai u prish në ditën e pagës, dhe punonjësit e departamentit qëndruan disa ditë pa para.

Një biznes i vogël me tregti me shumicë ka pësuar një rënie të faqes së tij të shitjes, e cila ishte hostuar në një platformë të jashtme. E morën vesh për mungesën e saj përmes telefonit nga një klient i rregullt. Në momentin e telefonatës, faqja kishte qenë e papërdorur për rreth tri orë. Kërkimi për personin përgjegjës për faqen e internetit mori disa orë, dhe zgjidhja e defektit zgjati edhe dy të tjera. Si rezultat, faqja ishte e papërdorur për pothuajse të gjithë ditën e punës. Sipas menaxherit tregtar të kompanisë, ky ndalesë i kushtoi rreth 1 milion rubla.

Unë vetë kam hasur një situatë të ngjashme kur shkova për një vizitë në poliklinikë dhe duhej të shkoja në regjistrat e DMS. Nuk mund të më dërgonin te mjeku për një arsye banale - në mëngjes kishte pasur një rritje tensioni dhe pas aksidentit, shërbimi i tyre postak ishte ndalur dhe një shërbim për lidhjen me sigurimin nuk funksiononte. Kur pya, ku janë administratorët tuaj, më thanë se administratori është një person i ardhshëm dhe viziton ata një herë në javë. Dhe tani (në atë moment ora ishte tashmë 16:00) ai nuk e merrte telefonin. Të paktën 7 orë, poliklinika kishte qenë e shkëputur nga bota e jashtme dhe nuk mund të ofronte shërbime të paguara.

Çfarë i bashkon të gjitha këto raste? Të gjitha problemet mund të ishin parandaluar më parë. Me një reagim të duhur nga njerëzit që shërbejnë IT-në, dëmi i shkaktuar mund të ishte reduktuar. Kjo do të ishte e mundur gjithashtu me një interpretim të saktë të simptomave të hershme nga përdoruesit.

Kemi identifikuar hipotezat e problemeve:

humoriste të konsiderueshme financiare dhe reputacioni për shkak të shpejtësisë së ulët të reagimit ndaj defekteve në infrastrukturën IT;
interpretimi i gabuar i simptomave të hershme të defektit nga përdoruesit.

Çfarë mund të bëjë klienti me to dhe si të shmangin situata të tilla në të ardhmen? Mundësitë nuk janë aq të shumta:

të marrë një administrator sistemi shumë të kualifikuar në punë dhe ta detyrojë atë të punojë me ndershmëri;
të jashtësojë shërbimet IT në një kompani të specializuar;
të implementojë një sistem monitorimi dhe njoftimi për defektet vetë;
të organizojë trajnime për përdoruesit/personalin e biznesit në bazat e pëlqimit të kompjuterit.

Shqyrtojmë opsionin e tretë. Le të ofrojmë një sistem monitorimi për ata që nuk e përdorin për shkak të arsyeve të ndryshme.

Një devijim lirik. Sistemet e ndryshme të monitorimit të shërbimeve IT në tregun enterprise janë përdorur prej kohësh, dhe dobia e tyre nuk vlerësohet. Kam biseduar me përfaqësues të kompanive të mëdha, kam parë si janë ndërtuar marrëdhëniet midis biznesit dhe IT. Drejtori teknik i një kompanie të madhe të inxhinierisë mekanike i ka besuar shërbimin e infrastrukturës IT një kompanie të jashtme, por ai vetë mbetet i informuar për të gjitha çështjet. Në zyrën e tij ka një ekran të madh të sistemit të monitorimit me tregues të gjendjes së shërbimeve IT. Në sistem janë regjistruar më kritikët. Në çdo moment, drejtori teknik mund të mësojë se në çfarë gjendjeje është infrastruktura, çfarë po ndodh, në cilën pjesë është problemi, nëse janë të njoftuar njerëzit përgjegjës, dhe nëse problemi po zgjidhet.

Historitë e përmendura na bënë të mendojmë për mënyrën se si të krijojmë një sistem optimal monitorimi për kompanitë e vogla. Si rezultat, lindi LANBIX — një sistem monitorimi që mund të instalohet nga çdokush pa njohuri në fushën e IT. Qëllimi kryesor i sistemit është i thjeshtë, si të gjithë sistemet që kanë për qëllim të rritin vazhdimësinë dhe disponueshmërinë — të reduktojnë humbjet financiare dhe të tjera në rast të ndërprerjeve të paplanifikuara. Pajisja është krijuar për të minimizuar në maksimum kohën mes "kam diçka që është thyer" dhe "problemi është zgjidhur."

Për të konfirmuar hipotezat, u zhvilluan intervista problematike. Nuk mund ta imagjinoja se sa shumë janë të gatshëm njerëzit të flasin, nëse nuk përpiqesh t'u shesësh atyre diçka. Çdo bisedë zgjati të paktën 1.5 orë, dhe ne morëm një sasi të madhe informacioni, të dobishëm për zhvillimin e ardhshëm.

Le të përmbledhim rezultatin e këtij faze:

kuptimi i problemit — ekziston,
kuptimi i vlerës — ekziston,
ideja për zgjidhje — ekziston.

Faza e dytë ishte më e detajuar. Në përfundim, ne duhej të paraqisnim drejtësisë, e cila në thelb luan rolin e investitorit, një rast biznesi (ai i famshëm Lean Canvas) për të marrë një vendim për fatin e mëtejshëm të produktit.

Nisëm me hulumtimin e tregut dhe analizën konkuruese me qëllim të zbulojmë se kush, çfarë dhe, më e rëndësishmja, si po vepron në këtë treg.

Doli se sa vijon.

Në treg nuk ka sisteme monitorimi të gatshme për segmentin tonë (bizneset e vogla), përveç disa disa, për të cilat për arsye të njohura nuk do flas.
Konkurrentët tanë kryesorë, ashtu siç duket, janë administratorët e sistemeve me skripte të shkruara vetë dhe "modifikime" për sistemet e monitorimit me kod burimor të hapur.
Problemi i dukshëm me përdorimin e sistemeve të monitorimit me kod burimor të hapur është evident. Ekziston një sistem, ka një sasi të madhe informacioni mbi funksionimin dhe përmirësimin e sistemit sipas nevojave. Nga administratorët që kam intervistuar, shumë pranuan se u mungonin kompetencat për të realizuar idetë e tyre vetë. Dhe nuk mund të pranojnë këtë me drejtuesit për shkak të frikës nga pushimi. Kështu krijohet një qëndrim i mbyllur.

Pastaj kaluam në analizën e nevojave të klientëve tanë potencialë. Ne identifikuam një segment të organizatave të vogla, që për disa arsye nuk kanë shërbim IT të brendshëm, ku IT merret nga një administrator sistemi i përkohshëm, një freelancer ose një kompani shërbimi. Vendosëm të hyjmë jo nga këndvështrimi IT, por nga ai i biznesit, duke ofruar themeluesve dhe pronarëve të bizneseve një mjet për të përmirësuar cilësinë e shërbimit të infrastrukturës IT. Një produkt që duhet t'i ndihmojë pronarëve të sigurojnë biznesin e tyre, por në të njëjtën kohë do t'i shtojë punë njerëzve që janë përgjegjës për IT. Një produkt që ofron biznesit një mjet për kontrollin e cilësisë së mbështetjes IT.

Si rezultat i përpunimit të të dhënave të marra, lindi lista e parë e kërkesave (një bllok i përafërt) për produktin e ardhshëm:

sistemi i monitorimit duhet të bazohet në një zgjidhje me kod burimor të hapur dhe për rrjedhojë të jetë i lirë;
të jetë i thjeshtë dhe i shpejtë në instalim;
nuk duhet të kërkojë njohuri specifike në IT, madje as një accountant (nuk dua në asnjë mënyrë të fyjë përfaqësuesit e kësaj profesioni) duhet të jetë në gjendje të vendosë dhe konfigurojë sistemin;
duhet të zbulojë automatikisht objektet për monitorim në rrjet;
duhet të instalohet automatikisht (idealisht automatikisht) agjentët e monitorimit;
duhet të ketë mundësi për monitorimin e shërbimeve të jashtme, të paktën sistemin CRM dhe faqen e shitjes;
duhet të njoftojë për çështje si biznesin ashtu edhe administratorin e sistemit;
niveli i thellësisë dhe "gjuha" e njoftimeve duhet të jetë e ndryshme për administratorin dhe biznesin;
sistemi duhet të ofrohet në pajisjet tona;
pajisjet duhet të jenë sa më të aksesueshme.
sistemi duhet të jetë maksimalisht i pavarur nga faktorët e jashtëm.

Më pas u llogaritën investimet për zhvillimin e produktit (duke përfshirë kostot e punës së punonjësve të departamentit teknik). U përgatit një skicë e modelit të biznesit dhe u llogarit ekonomika e njësisë së produktit.

Rezultati i fazës:

backlog-u i lartë i produktit;
modeli i biznesit i formuluar ose hipoteza e shkallës, e cila duhet ende të verifikohet në praktikë.

Të kalojmë në fazën tjetër — konceptin. Këtu si inxhinierë ne hyjmë në mjedisin tonë të njohur. Ka "dëshira", të cilat decompozohen në komponentë/subsistema/features, pastaj ato shndërrohen në kërkesa teknike/historitë e përdoruesve, pastaj në projekt etj. Nuk do të ndalem shumë në procesin e përgatitjes së një grupi alternativash, do të kalojmë direkt në kërkesat dhe metodat e zgjedhura për zbatimin e tyre.

Kërkesa
Zgjidhja

Duhet të jetë një sistem i hapur monitorimi;

Merrni një sistem monitorimi me kod të hapur.

Sistemi duhet të jetë i thjeshtë dhe i shpejtë për t'u instaluar;
nuk duhet të kërkojë njohuri specifike në IT. Edhe një kontabilist duhet të jetë në gjendje të zbatojë dhe konfigurojë sistemin.

Propozojmë një sistem të instaluar, në mënyrë që përdoruesi të ketë vetëm për të aktivizuar pajisjen dhe pak të konfigurojë, në mënyrë të ngjashme me një router.

Të lidhim ndërveprimin me pajisjen në diçka të thjeshtë dhe të kuptueshme për të gjithë.

Do të shkruajmë chatbot-in tonë për një nga mesazherët e njohur dhe do ta regjistrojmë të gjithë ndërveprimin me sistemin mbi të.

Sistemi duhet të:

zgjidh automatikisht objektet që duhen monitoruar në rrjet;
instaloni automatikisht agentët e monitorimit;
kemi mundësinë e monitorimit të shërbimeve të jashtme, si minimumi sistemet CRM dhe faqen e internetit të shitjes.

Shkruajmë shtesa për sistemin e monitorimit për:

zbulimin automatik të objekteve;
instalimin automatik të agentëve;
monitorimin e disponueshmërisë së shërbimeve të jashtme.

Sistemi duhet të:

të njoftojë për defektet si biznesin ashtu edhe administratorin e sistemit;
të ketë mundësinë e monitorimit të shërbimeve të jashtme, si minimumi sistemet CRM dhe faqen e internetit të shitjes. Gradimi i thellësisë dhe "gjuha" e njoftimeve duhet të jetë e ndryshme për adminin dhe biznesin.
Sistemi nuk duhet të kërkojë njohuri specifike në IT, edhe një kontabilist duhet të jetë në gjendje të zbatojë dhe konfigurojë sistemin.

Do të shtojmë lloje të ndryshme njoftimesh për lloje të ndryshme përdoruesish. Ato ndryshojnë në mënyrën e paraqitjes dhe thellësinë. Përdoruesi biznesor do të marrë njoftime si 'gjithçka është në rregull, por kompjuteri i Ivanovit do të dështojë së shpejti'. Administratorët do të marrin një mesazh të plotë për gabimin, se kush, si dhe çfarë ndodhi ose mund të ndodhë.
Do të shtojmë mundësinë e përdorimit të postës elektronike të një personi të ngarkuar shtesë, në mënyrë që në rast defekti ai të marrë një njoftim.
Do të shtojmë ndërveprimin me ofrues të jashtëm shërbimesh përmes dërgimit të email-eve me një tekst të paracaktuar, pasi email-i është ai që ofron bazën për regjistrimin e një incidenti.
Të gjitha ndërveprimet me sistemin do të centralizohen në një chat-bot, ku komunikimi do të zhvillohet në stilin e dialogut.

Për të ndryshuar konfigurimin, nuk është e nevojshme të dërgoni trupin e kërkesës në formatin

do të shtojmë funksionalitetin 'bisedë me administratorin', në mënyrë që përdoruesi të mund të dërgojë një mesazh administratorit me përshkrimin e problemit direkt.

Sistemi duhet të ofrohet në pajisjet e tij të veta.
Pajisjet duhet të jenë të disponueshme.
Sistemi duhet të jetë sa më i pavarur nga ambienti.

Do të marrim një kompjuter të përfunduar dhe të lirë, Raspberry PI.
Do të projektojmë një pllakë të furnizimit të pandërprerë me energji.
Do të shtojmë një modem për pavarësi nga gjendja e rrjetit lokal.
Do të projektojmë një kasë të bukur.

Kemi tri nën-sisteme me kërkesat dhe vizionin e tyre për realizim:

nën-sistemi i pajisjeve harduerike;
nën-sistemi i monitorimit;
nën-sistemi i ndërveprimit me përdoruesit.

Për nën-sistemin e pajisjeve harduerike, ne kemi zhvilluar një projekt skicë. Po, po! Duke shkelur të gjitha rregullat e agjilit, ne kemi zhvilluar një dokument, sepse fabrikat prodhuese punojnë pikërisht me dokumente. Për nën-sistemat e tjera, ne kemi identifikuar përdoruesit (persona), përgatitëm historitë e përdoruesve dhe shkruam detyrat për zhvillim.

Në këtë fazë koncepti përfundon, dhe rezultati i tij ishte:

projekti për platformën harduerike;
vizioni i formulueshëm në formën e historive të përdoruesve për dy nën-sistemat e tjera;
prototipi i pjesës software, i realizuar në formën e një makine virtuale;
prototipi i pjesës harduerike, i realizuar në formën e një stende, ku u provuan zgjidhjet harduerike;
testimi i kryer nga administratorët tanë.

Problemet në këtë fazë ishin kryesisht organisatorike dhe lidhen me mungesën e aftësive të inxhinierëve në aspektet ligjore dhe financiare të shitjeve. Domethënë, është një gjë të imagjinosh se çfarë dhe si të shitet, dhe krejt ndryshe të përballesh me një makinë ligjore të pa mëshirshme: patentat, detyrat për zhvillim, regjistrimin e pasurisë, EULA dhe shumë aspekte të tjera që ne si njerëz krijues fillimisht nuk i morëm parasysh.

Nuk ishte ende një problem, sa një pengesë e lidhur me dizajnimin e trupave. Në ekipin tonë kemi vetëm inxhinierë, prandaj versioni i parë i trupit u krijua nga plexiglas nga specialisti ynë në elektronikë.

Trupi dukej, të themi, të paktën diskutueshëm, sidomos për publikun e priviligjuar me teknologji moderne. Sigurisht që u gjetën disa adhurues mes "kulibinëve" të brezit më të vjetër — trupi u shkaktoi atyre ndjenja nostalgjike. U vendos të prodhohet dhe projektohet një trup i ri, pasi ai i vjetër, përveç problemeve estetike, kishte edhe ato konstruktive — plexiglas nuk i përballonte mirë montimin dhe çmontimin e pajisjes dhe prirej të thyhej. Do flas më tej për prodhimin e trupit.

Dhe ja ku jemi afër finish-it — MVP. Sigurisht, kjo ende nuk është produkti përfundimtar i serisë, por ai tashmë sjell dobi dhe paraqet vlerë. Qëllimi kryesor i këtij etapi është të nisë ciklin "krijo-vlerëso-mëso". Pikërisht në këtë fazë ndodhet LANBIX.

Në fazën "krijo", ne krijuam një pajisje që plotëson funksionin e shpallur. Po, ajo ende nuk është perfekte dhe ne vazhduam të punojmë mbi të.

Kthehemi në prodhimin e trupit, domethënë, në detyrën për ta shndërruar pajisjen tonë nga një gjë që ngjall ndjenja nostalgjike në një moderne. Fillimisht, unë kontrollova tregun për prodhues trupash dhe për ofrimin e shërbimeve të dizajnit industrial. Së pari, kompanitë që prodhojnë trupa në tregun rus janë shumë të pakta, dhe së dyti, kostoja e dizajnit industrial në këtë fazë është jashtëzakonisht e lartë, rreth 1 milion rubla.

Për dizajnin, u drejtuam në departamentin tonë të marketingut, një dizajner i ri ishte i gatshëm për eksperimente krijuese. Ne paraqitëm vizionin tonë për karrocën (pas studimit të mostrave më të mira të ndërtimit të karrocave), dhe ai nga ana e tij e shndërroi atë në një vepër arti. Mbetej vetëm të prodhohej. Ne, krenarë për dizajnin tonë, iu drejtua partnerëve tanë. Drejtori i përgjithshëm i tyre shkatërroi menjëherë fantazitë tona, duke treguar plotësisht falas për gjërat që nuk mund të prodhoheshin sipas mënyrës që kishim zgjedhur. Karroca mund të prodhohet, dhe do të jetë jo më keq se e Apple-it, por kostoja e karrocës do të jetë tre deri në katër herë më e lartë se e gjithë elektronika. Pas një serie operacionesh dhe miratimesh, ne projektuam një karrocë që mund të prodhohej. Po, tashmë nuk është aq e bukur sa e kishim planifikuar, por është ideale për të arritur qëllimet aktuale.

Rezultati i fazës: partia e parë e pajisjeve, të gatshme për luftë dhe prova.

Dhe tani vjen faza më e vështirë — faza 'vlerësoni', dhe me produktin tonë jemi pikërisht në këtë pikë. Mund ta vlerësojmë vetëm sipas rezultateve të përdorimit nga klientët realë dhe asnjë supozim këtu nuk funtionon. Na nevojiten ato "në fillim ndjekësit" për të ofruar feedback dhe për të bërë ato ndryshime në produkt që janë vërtet të nevojshme. Shkon pyetja: si t'i gjejmë klientët dhe si t'i bindim ata të marrin pjesë në eksperiment?

Nga të gjitha opsionet e mundshme, ne zgjodhëm një set klasik të mjeteve digjitale: një landing dhe një fushatë reklamimi në rrjetet sociale.

Procesi tashmë ka filluar, por është ende herët për të folur për rezultatet, megjithatë ka pasur reagime dhe kemi marrë konfirmimin e shumë hipotezave tona. Një surprizë e këndshme ishte reagimi i përfaqësuesve nga segmente të tjera të biznesit, shumë më të mëdha se ato për të cilat kishim shpresuar. Do të ishte budallallëk të injoronim të dhënat e reja, dhe si rezultat i intervistave të kryera, u mor vendimi për të lançuar një linjë paralele LANBIX me emrin LANBIX Enterprise. Ne shtuam mbështetje për infrastrukturat e shpërndara, monitorimin e rrjeteve Wi-Fi me gjetjen dhe lokalizimin e defekteve, monitorimin e cilësisë së kanaleve të komunikimit. Interesi më i madh për zgjidhjen u shpreh nga kompanitë e shërbimeve. Në të njëjtën kohë, pajisjet që i kishim zhvilluar tashmë luajnë një rol të rëndësishëm në zgjidhjen e problemeve.

Çfarë do të ndodhë më pas

Çfarë do të ndodhë më pas me LANBIX-in origjinal do të bëhet e qartë sipas rezultateve të fushatës. Në rast se hipotezat tona nuk konfirmohen, sipas metodologjisë Lean, do t'i japim fund pa mëshirë ose ai do të transformohet në diçka të re, sepse nuk ka gjë më të keqe se të bësh një produkt që askujt nuk i nevojitet. Por tashmë mund të themi se puna e bërë nuk është e kotë dhe përmes saj ka lindur një degë e tërë produktesh paralele, mbi të cilat ne po punojmë aktivisht. Në rast suksesi, LANBIX do të kalojë nga faza MVP në fazën përfundimtare dhe do të zhvillohet sipas ligjeve të njohura klasike të marketingut të produkteve.

Po e përsëris, tani ne duam të gjejmë ndjekës të hershëm, kompani të cilëve mund të ulen produktin tonë me qëllim të mbledhjes së feedback-ut. Nëse jeni të interesuar të provoni LANBIX, shkruani në komente ose mesazhe personale.

Burimi

Burimi: habr.com

Si si punojmë me idetë dhe si lindi LANBIX