🥇Si punojmë me idetë dhe si lindi LANBIX

Në "LANIT-Integrime" ka shumë punonjës krijues. Idetë për produkte dhe projekte të reja duket se janë kudo. Ndonjëherë është shumë e vështirë të identifikosh ato më interesante. Prandaj, ne zhvilluam metodologjinë tonë me përpjekje të përbashkëta. Si të përzgjedhim projektet më të mira dhe t'i realizojmë ato, lexoni në këtë artikull.

Në Rusi, por gjithashtu në botë, po ndodhin një sërë procesesh që çojnë në transformimin e tregut të TI. Falë rritjes së kapacitetit llogaritës dhe shfaqjes së teknologjive të virtualizimit server, rrjet dhe të tjera, tregu nuk ka më nevojë për shumë "harduer". Shumë shpesh, ofruesit preferojnë të punojnë drejtpërdrejt me klientët. Në tregun e TI po lulëzon outsourcing-u në të gjitha format e tij, duke filluar nga outsourcing tradicional deri te ofruesit e rinj të valë - "ofruesit e cloud". Sistemat dhe elementet infrastrukturore bëhen ndjeshëm më të thjeshtë për t'u dëshmuar dhe konfiguruar. Cilësia e softuerit rritet çdo vit dhe detyrat e integratorit transformohen.

Si punojmë me idetë

Drejtimi i startup-ve produktore në "LANIT-Integrime" ka ekzistuar për më shumë se një vit. Qëllimi ynë kryesor është krijimi i produkteve të reja dhe nxjerrja e tyre në treg. E para që bëmë ishte organizimi i procesit të krijimit të produkteve. Ne shqyrtuam shumë metodologji, duke filluar nga të klasiket dhe duke përfunduar te ato virale. Megjithatë, asnjëra prej tyre nuk i përgjigjej kërkesave tona. Atëherë ne vendosëm të marrim si bazë metodologjinë Lean Startup dhe ta adaptojmë për nevojat tona. "Startup-i i hollë" është një teori sipërmarrjeje e krijuar nga Eric Ries. Ajo bazohet në principe, qasje dhe praktika të koncepteve si prodhimi i hollë, zhvillimi i klientit dhe metodologjia e zhvillimit të fleksibël.

Sa i përket qasjes ndaj menaxhimit të zhvillimit të produktit: ne nuk shpikëm një biçikletë të re, por aplikuam një metodologji ekzistuese zhvillimi SCRUM, duke i shtuar krijimtari, dhe tani e quajmë me guxim SCRUM-WATERFALL-BAN. SCRUM, pavarësisht fleksibilitetit të tij, është një sistem tepër i rreptë dhe është i përshtatshëm për menaxhimin e një ekipi që merret vetëm me një produkt/projekt. Siç e kuptoni, biznesi klasik "integrues" nuk parashikon ndarjen e specialistëve teknikë në përkushtim të plotë për të punuar mbi një projekt (përjashtime ndodhin, por shumë rrallë), pasi përveç punës mbi produktet, të gjithë janë të angazhuar në projektet aktuale. Nga SCRUM ne morëm ndarjen e punës në sprint-e, raportimin e përditshëm, retrospektivat dhe rolet. Për të punuar me fluksin e detyrave, ne zgjodhëm Kanban, i cili u integrua shumë mirë me sistemin tonë të përcjelljes së detyrave. Ne organizuam punën, duke u integruar gradualisht në rregullin e tanishëm.
Para se të dalë në treg, produkti kalon nëpër 5 faza: ide, përzgjedhje, koncept, MЖP (më poshtë detajet) dhe prodhim.

Ideja

Në këtë fazë ka diçka efemere - ideja. Ideali është një zgjidhje për një problem ose çështje të klientit. Ne nuk kemi mungesë idesh. Fillimisht, ato duhet të gjenerohen nga punonjësit e drejtimeve teknike. Për të pranuar që ideja të kalojë në zhvillim të mëtejshëm, autori duhet të plotësojë "Formatin e paraqitjes së idesë". Aty ka vetëm katër pyetje: Çfarë? Pse? Kujt i nevojitet kjo? Nëse jo produkti ynë, atëherë çfarë?

Burimi

Përzgjedhja

Sapo forma e plotësuar mbërrin te ne, fillon procedura e përpunimit dhe përzgjedhjes. Faza e përzgjedhjes është më e punës kërkuese. Në këtë fazë krijohen hipotezat e problemeve (nuk e thashë kot më sipër që idealisht ideja duhet të zgjidhë një problem të klientit) dhe vlera e produktit. Formulohet hipoteza e shkallës, dmth. si do të rritet dhe të përparojë biznesi ynë. Kryhen intervista me probleme dhe ekspertë me klientë të mundshëm për të konfirmuar paraprakisht se ne po planifikojmë të prodhojmë diçka të nevojshme. Nevojiten 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ë financiare paraprake, vlerësohet volumi i përafërt i investimeve dhe fitimi i mundshëm për investitorin. Si rezultat i kësaj faze, lind një dokument me emrin Lean Canvas dhe i paraqitet menaxhmentit.

Koncepsi

Në këtë fazë, rreth 70% e idesh janë të larguara. Nëse koncepti miratohet, nis faza e zhvillimit të idesë. Krijohen funksionalitetet e mundshme të produktit të ardhshëm, përcaktohen rrugët e realizimit dhe zgjidhjet teknike optimale, përditësohet plani i biznesit. Rezultati i kësaj faze është një kërkesë teknike për zhvillim dhe një rast të detajuar biznesi. Në rast suksesi - kalojmë në fazën e MЖP ose MVP.

MЖP ose MVP

MVP — është një produkt minimalisht i jetueshëm. Pra, është një produkt që nuk është ndalur së zhvilluari deri në fund, por që tashmë mund të sjellë vlerë dhe të kryejë funksionin e vet. Në këtë fazë të zhvillimit, ne domosdoshmërisht mbledhim feedback nga përdoruesit e vërtetë dhe bëjmë ndryshime.

Prodhimi

Faza e fundit — prodhimi. Më shumë se 5% e produkteve arrijnë në këtë fazë. Në këto 5% përfshihen vetëm produktet më të rëndësishme, të nevojshme, jetueshme dhe funksionale.

Ne kemi shumë ide, tashmë kemi mbledhur një portofol të gjerë. Ne analizojmë secilën ide dhe bëjmë gjithçka që ajo të arrijë në fazën përfundimtare. Shumë e këndshme është që kolegët nuk janë mbetur indiferentë ndaj drejtimit tonë R&D dhe marrin pjesë aktive në zhvillimin dhe zbatimin e produkteve dhe zgjidhjeve.

Si e bëmë LANBIX

Le të shqyrtojmë krijimin e produktit përmes një shembulli real — produktit LANBIX. Ky është një kompleks softueriko-harduerik "të paketuar", i destinuar për monitorimin e infrastrukturave të vogla IT dhe njoftimin e shpejtë të personave përgjegjës dhe përdoruesve të biznesit për defekte, me menaxhim përmes një chatbot. Përveç funksionit të monitorimit, LANBIX përfshin gjithashtu funksionalitetin Help Desk. Ky produkt është ekskluziv për segmentin e tregut që synojmë. Kjo është dhe avantazhi, dhe problematika jonë. Por do të flasim për këtë më vonë. Le të themi menjëherë se LANBIX — është një produkt "i gjallë" (pra, ai nuk është përfundimtar në zhvillimin e tij dhe është në një cikël të ri MVP).

Pra, faza e parë — ideja. Për të lindur një ide, nevojiten probleme, dhe ato i kishim, më saktësisht, jo vetëm ne, por edhe njohësit tanë. Më poshtë do të shqyrtojmë disa situata reale të ndodhur në fusha të ndryshme biznesi.

Një kompani menaxhuese e vogël shërben dy ndërtesa në Podmoskovje. Stafi i punonjësve që kanë PC është rreth 15 persona. Administratori i sistemit — një freelancer që vjen herë pas here (biri i zgjuar i njërit prej banorëve të shqetësuar). Duke parë nga jashtë, aktiviteti i kompanisë duket se ka pak të bëjë me IT-në, por karakteristika e këtij biznesi — raportimi mujor para shumë institucioneve. Në diskun sistemor të drejtorit të kompanisë (si zakonisht, duke kombinuar shumë role) ka përfunduar hapësira e lirë. Natyrisht, kjo nuk ka ndodhur papritur, paralajmërimi ka qenë në ekran për rreth 2 muaj dhe është injoruar vazhdimisht. Por erdhi një përditësim, sistemi operativ u përditësua dhe si për të qenë fatkeqësi, ngeci gjatë përditësimit, duke ankuar para "vdekjes" për diskun e zënë. Kompjuteri e kaloi në një rreth të ciklit të rinisjes. Ndërsa merreshin me problemin dhe nxirrnin raportet, humbën afatin për dorëzimin e raportit. Duke parë nga jashtë, një defekt i vogël shkaktoi probleme të ndryshme: nga humbje financiare deri në procedura gjyqësore dhe përgjegjësi administrative.

Burimi

Një rast i ngjashëm ndodhi në një holding të madh, i cili bashkon shumë kompani të vogla, me një shërbim të vetëm të mbështetjes teknike për të gjithë zyrën. Në një nga departamentet, kompjuteri i shefit të kontabilitetit doli jashtë funksionit. Ishte e qartë se ai mund të prishej, pasi kompjuteri kishte filluar të ngadalësohet dhe të mbante nxehtësi, por shefi i kontabilitetit nuk kishte pasur kohë të dërgonte një kërkesë për mbështetje. Natyrisht, ai u prish në ditën e pagave dhe punonjësit e departamentit qëndruan disa ditë pa pagesa.

Një biznes i vogël i tregtisë me shumicë kishte një faqe shitje që u përcaktua në një platformë të jashtme. Për papeshimin e saj, ata u informuan nga një klient i përhershëm përmes telefonit. Në momentin e telefonatës, faqja kishte qenë e papërshkueshme për rreth tre orë. Kërkimi për personin përgjegjës për faqen mori edhe disa orë, dhe riparimi i defektit — edhe dy. Si pasojë, pothuajse tërë ditën punuese faqja ishte e papërshkueshme. Sipas drejtorit tregtar të kompanisë, ky ndalim i punës u kushtoi atyre rreth 1 milion rubla.

Unë vetë kam kaluar një situatë të ngjashme, kur shkuan në një takim në poliklinikë dhe duhet të përfundoja në regjistraturën e DMS. Ata nuk mund të më dërgonin tek mjeku për një arsye banale – në mëngjes kishte pasur një rritje tensioni, dhe pas këtij incidenti shërbimi i tyre postës dhe një shërbim për kontakt me sigurimin nuk punonin. Kur e pyeta, ku janë administratorët tuaj, më thanë se administratori i tyre vjen herë pas here dhe viziton çdo javë. Dhe tani (në atë moment ishte tashmë ora 16:00) ai nuk po përgjigjej në telefon. Të paktën 7 orë poliklinika ishte e ndarë nga bota e jashtme dhe nuk mund të ofronte shërbime të paguara.

Çfarë bashkon të gjitha këto raste? Të gjitha problemet mund të ishin parandaluar me kohë. Me një reagim të duhur nga njerëzit që ofrojnë IT, mund të ishte ulur dëmshpërblimi i shkaktuar. Kjo do të ishte e mundur gjithashtu dhe në interpretimin e duhur të simptomave të hershme nga përdoruesit.

Ne identifikuam hipotezat e problemeve:

humbje të rëndësishme financiare dhe reputacionale për shkak të shpejtësisë së ulët të reagimit ndaj defekteve në infrastrukturën IT;
keqinterpretimi i simptomave të hershme të defekteve nga përdoruesit.

Çfarë mund të bëjë porositësi me to dhe si të shmangen situata të tillë në të ardhmen? Ka disa mundësi:

të marrë një administrator sistemi të kualifikuar dhe ta detyrojë atë të punojë me përgjegjësi;
të japë shërbimin IT një kompanie të specializuar;
të implementojë vetë një sistem monitorimi dhe njoftimi për defekte;
të zhvillojë trajnime për përdoruesit/personalin e biznesit në bazat e kompjuterizimit.

Të ndalojmë në mundësinë e tretë. Le të propozoni një sistem monitorimi për ata që nuk e përdorin atë për shkak të arsyeve të ndryshme.

Një shkëputje lirik. Sistemet e ndryshme të monitorimit të shërbimeve IT në tregun enterprise janë përdorur prej kohësh dhe përfitimet e tyre nuk vihen në dyshim. Kam biseduar me përfaqësues të kompanive të mëdha, kam parë se si janë ndërtuar marrëdhëniet midis biznesit dhe IT. Drejtori teknik i një kompanie të madhe të prodhimit të makinave ia kaloi shërbimin IT një kompanie të jashtme, por mbetet në dijeni për të gjitha çështjet. Në zyrën e tij ka një ekran të madh të sistemit të monitorimit me indikatorë të gjendjes së shërbimeve IT. Në sistem janë të regjistruara më kritiket. Në çdo moment, drejtori teknik mund të mësojë se në çfarë gjendjeje është infrastruktura, çfarë po ndodh, në cilën pjesë është problemi, a janë njoftuar njerëzit përgjegjës, a po zgjidhet problemi.

Të gjitha historitë e pranishme e bënë ekipin tonë të mendojë se si të krijojmë një sistem optimal monitorimi për kompanitë e vogla. Si rezultat, lindi LANBIX — një sistem monitorimi që mund të zbatohet nga kushdo pa njohuri në fushën IT. Qëllimi kryesor i sistemit është i thjeshtë, ashtu si të gjithë sistemet që janë të orientuara për të rritur vazhdimësinë dhe disponueshmërinë — të reduktohen humbjet financiare dhe të tjera në rastin e pezullimeve të paplanifikuara. Pajisja ka për qëllim të reduktojë në minimum kohën midis "kam diçka që u prish" dhe "problemi është zgjidhur".

Për të konfirmuar hipotezat, u zhvilluan intervista problematike. Nuk mund ta imagjinoja sa shumë njerëz janë të gatshëm të flasin kur nuk përpiqesh t'u shesësh diçka. Secila bisedë zgjati të paktën 1.5 orë dhe morëm shumë informacion të dobishëm për zhvillimin e mëtejshëm.

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

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

Hapi i dytë ishte më i detajuar. Nga rezultatet e tij ne duhej të paraqesim menaxhmentit, që në thelb vepron si investitor, një rast biznesi (ai i njohur si Lean Canvas) për të marr vendimin në lidhje me fatin e mëtejshëm të produktit.

Filluam me hulumtimin e tregut dhe analizën e konkurencës me qëllim të zbulojmë se kush, çfarë dhe, mbi të gjitha, si po vepron në këtë treg.

Doli ky përfundim.

Në treg nuk ka sisteme të gatshme monitorimi për segmentin tonë (biznes të vogla), përveç disa-të-tre, për të cilat për arsye të qarta nuk do të flas.
Konkurrentët tanë kryesorë, çuditërisht, janë administratorët e sistemit me skriptet dhe "modifikimet" e tyre për sistemet e monitorimit me kod të hapur.
Ka një problem të qartë me përdorimin e sistemeve të monitorimit me kod të hapur. Ekziston një sistem, ka një sasi të madhe informacioni mbi funksionimin dhe përmirësimin e sistemit sipas nevojave. Nga administratorët e marrë intervista, shumë pranuan se nuk kishin kompetenca të mjaftueshme për të realizuar idetë e tyre vetë. Dhe nuk mund të pranojnë këtë me menaxhmentin për shkak të frikës nga largimi nga puna. Kështu formohet një cikël i mbyllur.

Më pas kaluam në analizimin e nevojave të mundshme të klientëve tanë. Ne përzgjedhëm përvijimin e organizatave të vogla, që për disa arsye nuk kanë shërbimin e vet IT, ku për IT përgjigjen ose një administrator sistem me qira, ose një freelancer, ose një kompani shërbimi. Vendosëm të hynim nga ana e biznesit që të ofronim themeluesve dhe pronarëve të biznesit 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ë bizneset e tyre, por megjithatë do t'i shtojë punë njerëzve që janë përgjegjës për IT. Një produkt që i ofron biznesit një mjet kontrolli mbi cilësinë e mbajtjes së IT.

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

sistemi i monitorimit duhet të jetë i bazuar në një zgjidhje me burim të hapur dhe si pasojë të jetë i lirë;
të jetë i thjeshtë dhe i shpejtë për t'u instaluar;
nuk duhet të kërkojë njohuri specifike në IT, madje edhe një kontabilist (me asnjë mënyrë nuk dua të ofendoj përfaqësuesit e këtij profesioni) duhet të jetë në gjendje të zbuloj dhe konfiguroj sistemin;
duhet të zbulojë automatikisht objektet për monitorim në rrjet;
duhet të instalohet automatikisht (dhe idealisht automatikisht) agjentët e monitorimit;
duhet të ketë mundësinë për të monitoruar shërbime të jashtme, të paktën një sistem CRM dhe një faqe shitur;
duhet të njoftojë për problemet 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ë harduerin e tij;
hardueri duhet të jetë sa më i qasshëm;
sistemi duhet të jetë sa më i pavarur nga faktorët e jashtëm.

Më pas janë llogaritur investimet për zhvillimin e produktit (duke përfshirë kostot e punës së punonjësve të departamentit teknik). Është përgatitur një skicë e modelit të biznesit dhe është llogaritur ekonomika unitare e produktit.

Rezultati i këtij faze:

një backlog i nivelit të lartë të produktit;
një model biznesi i formuluar ose hipotezë shkallë, që mbetet për t'u verifikuar në praktikë.

Le të kalojmë në fazën tjetër - konceptin. Këtu ne si inxhinierë hyjmë në fushën tonë të njohur. Ka ‘dëshira’ që dekompozohen në komponente / nën-sisteme / veçori, më pas ato kthehen në TËZ / historitë e përdoruesit, pastaj në projekt etj. Nuk do të ndalem në procesin e përgatitjes së një sërë opsionesh alternative, le të kalojmë direkt në kërkesat dhe metodat e zgjedhura për zbatimin e tyre.

Kërkesa
Zgjidhja

Kjo duhet të jetë një sistem monitorimi i hapur;

Të marim një sistem monitorimi me burim 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ë zbuloj dhe konfiguroj sistemin.

Propozojme një sistem të instaluar, që përdoruesi të ketë vetëm për të aktivizuar pajisjen dhe të bëjë pak konfigurim, ashtu siç bëhet me një router.

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

Të shkruajmë një chatbot për një nga mesazherët e njohur dhe të orientojmë gjithë ndërveprimin me sistemin në të.

Sistemi duhet të:

zbulojë automatikisht objektet e nevojshme për monitorim në rrjet;
të instalohet automatikisht agjentët e monitorimit;
të ketë mundësinë për të monitoruar shërbime të jashtme, të paktën një sistem CRM dhe një faqe shitur.

Të shkruajmë shtesa për sistemin e monitorimit për:

zbulesën automatike të objekteve;
instalimin automatike të agjentëve;
monitorimin e disponueshmërisë së shërbimeve të jashtme.

Sistemi duhet të:

të njoftojë për problemet si biznesin ashtu edhe administratorin e sistemit;
të ketë mundësinë për të monitoruar shërbime të jashtme, të paktën një sistem CRM dhe një faqe shitur. Niveli i thellësisë dhe ‘gjuha’ e njoftimeve duhet të jetë e ndryshme për administratorin dhe biznesin.
Sistemi nuk duhet të kërkojë njohuri specifike në IT, madje edhe një kontabilist duhet të jetë në gjendje të zbuloj dhe konfiguroj sistemin.

Të shtojmë lloje të ndryshme njoftimesh për lloje të ndryshme përdoruesish. Ato ndryshojnë në mënyrën e dorëzimit dhe thellësinë. Përdoruesi i biznesit do të marrë njoftime si ‘gjithçka është mirë, por kompjuteri i Ivanovit do të vdesë së shpejti.’ Administratorët do të marrin një njoftim të plotë të gabimit, për kë, si dhe çfarë ndodhi ose mund të ndodhi.
Të shtojmë mundësinë e përdorimit të emailit të një personi përgjegjës shtesë, në mënyrë që në rast defekti ai të marrë një mesazh.
Të shtojmë ndërveprimin me ofruesit e jashtëm të shërbimeve mbi bazën e dërgimit të email-it me tekst të paraparë, pasi email-i i jep bazën për hapjen e një incidenti.
Të mbyllim gjithë ndërveprimin me sistemin në një chatbot, komunikimi zhvillohet në stilin e dialogut.

Shtesë:

të shtojmë funksionalitetin e ‘bisedës me administratorin’, që përdoruesi të mund t'i dërgojë administratorit një mesazh me përshkrimin e problemit direkt.

Sistemi duhet të ofrohet në harduerin e tij.
Hardueri duhet të jetë i qasshëm.
Sistemi duhet të jetë sa më i pavarur nga ambienti.

Të marrim një kompjuter të gatshëm dhe të lirë Raspberry PI.
Të projektojmë një pllakë për furnizimin me energji të pandërprerë.
Të shtojmë një modem për pavarësinë nga gjendja e rrjetit lokal.
Të projektojmë një kabinet të bukur.

Kemi katër nën-sisteme me kërkesat dhe vizionin e tyre të realizimit:

nën-sistemi i harduerit;
nën-sistemi i monitorimit;
nën-sistemi i ndërveprimit me përdoruesin.

Për sistemin e harduerit, ne krijuam një projekt të skicimit. Po, po! Duke shkelur të gjitha rregullat e metodologjisë Agile, ne zhvilluam një dokument, sepse prodhuesit punojnë pikërisht me dokumente. Për sistemet e tjera, ne identifikuam përdoruesit (persona), përgatitëm histori përdoruesish dhe shkruam detyra për zhvillim.

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

projekti për platformën e harduerit;
vizioni është formuluar në formën e historive të përdoruesve për dy sistemet e tjera;
prototipi i pjesës software, i realizuar si një virtual machine;
prototipi i pjesës harduerike, i realizuar si një shtand, ku ishin testuar zgjidhjet harduerike për qëndrushmëri;
testimi, i kryer nga administratoret tanë.

Problemet në këtë fazë ishin kryesisht organizative dhe lidhen me nivelin e pamjaftueshëm të aftësive të inxhinierëve në aspektet ligjore dhe kontabël të shitjeve. Pra, është një gjë të ideosh se çfarë dhe si të shesësh, dhe krejt tjetër të përballesh me një makineri ligjore të pashkëputur: patentat, detyrat për zhvillim, grumbullimin në bilanc, EULA dhe shumë çfarë, që ne si njerëz krijues në fillim nuk e morëm parasysh.

Ishte akoma një pengesë, më shumë sesa një problem, e lidhur me projektimin e kasave. Në ekipin tonë ishin vetëm inxhinierë, prandaj varianti i parë i kasës 'u formua' nga akriliku nga specialisti ynë për elektronikën.

Kasa dukej, me fjalë të tjera, e diskutueshme, sidomos për publikun e krijuar nga teknologjia moderne. Gjithsesi, gjetëm disa vlerësues mes 'artisanëve' të brezit të vjetër — kasa u dha atyre ndjenja nostalgjie. U vendos të prodhohet dhe projektohet nga e para kasa, pasi e vjetra, përveç mangësive estetike, kishte gjithashtu mangësi strukturore — akriliku e kishte të vështirë montimin dhe çmontimin e aparaturës dhe prirej të çante. Për prodhimin e kasës, do të tregoj më tej.

Dhe ja, ne kemi arritur afër vijës së finishit — MVP. Sigurisht, ky akoma nuk është produkti përfundimtar, por ai tashmë po sjell dobi dhe ka vlerë. Qëllimi kryesor i kësaj faze është fillimi i ciklit 'krijo-vlerëso-mëso'. Pikërisht në këtë fazë ndodhet LANBIX.

Në fazën 'krijo', ne krijuam një pajisje që kryen funksionin e deklaruar. Po, ajo akoma nuk është perfekte, dhe ne vazhduam të punojmë mbi të.

Kthehemi te prodhimi i kasës, pra në detyrën për të kthyer pajisjen tonë nga një diçka që shkakton ndjenja nostalgjie në një produkt modern. Fillimisht, unë hulumtova tregun për prodhuesit e kasave dhe shërbimeve të dizajnit industrial. Së pari, kompanitë që prodhojnë kasa në tregun rus janë tejet të pakta, dhe së dyti, çmimi i dizajnit industrial në këtë fazë është tepër i lartë, rreth 1 milion rubla.

Për dizajnin, iu drejtua departamentit tonë të marketingut, një dizajner i ri ishte i gatshëm për eksperimente krijuese. Ne shpjeguam vizionin tonë për kasën (pas një shqyrtimi të mostrave më të mira të ndërtimit të kasave), dhe ai, në anën e tij, e shndërroi atë në një vepër arti. Ngeli vetëm të prodhohet. Ne, të mburrur nga dizajni ynë, iu drejtua partnerëve tanë. Drejtori i përgjithshëm i tyre menjëherë shkatërroi fantazitë tona, duke treguar falas se çfarë nuk mund të prodhohej në mënyrën që kishim zgjedhur. Kasa mund të prodhohej, dhe do të ishte jo më keq se ajo e Apple, por çmimi i saj do të ishte tri deri katër herë më i lartë se të gjithë komponentet elektronike. Pas një serie operacionesh dhe miratimesh, ne projektuam një kasë që mund të prodhohej. Po, tashmë nuk është aq e bukur sa e planifikuam, por është ideale për arritjen e qëllimeve aktuale.

Rezultati i fazës: një grumbull i parë pajisjesh, gati për provat dhe testet.

Dhe tani vjen faza më e vështirë — faza 'vlerëso', dhe ne jemi pikërisht në këtë pikë me produktin tonë. Ne mund të vlerësojmë vetëm sipas rezultateve të përdorimit nga klientët realë dhe nuk ka asnjë supozim këtu që funksionon. Na duhen ato 'njerëz të parë' për të dhëna kthimi dhe për të bërë ndryshimet e nevojshme në produkt. Pyetja është: ku ta gjejmë klientelën dhe si t'i bindim ata të marrin pjesë në eksperiment?

Nga të gjitha mundësitë, ne zgjodhëm paketën klasike të mjeteve digjitale: një landing page dhe një fushatë reklamuese në rrjetet sociale.

Procesi ka filluar, por është ende herët për të folur për rezultatet, megjithatë kemi filluar të marrim reagime dhe kemi konfirmimin e shumë hipotezave tona. Një surprizë e këndshme ishte reagimi i përfaqësuesve nga segmente të tjera biznesi, shumë më të mëdhenj se ata për të cilët ishim duke shpresuar. Do të ishte budallallëk të injoronim informacionet e reja, dhe sipas rezultateve të intervistave të kryera morëm vendim për të nisur një linjë paralele LANBIX me emrin LANBIX Enterprise. Shtuam mbështetje për infrastrukturat e shpërndara, monitorimin e rrjeteve Wi-Fi me kërkimin dhe lokalizimin e defekteve, si dhe monitorimin e cilësisë së kanaleve të komunikimit. Interesi më i madh për zgjidhjen u shpreh nga kompanitë shërbimi. Në të njëjtën kohe, pajisjet që kemi zhvilluar tashmë luajnë një rol të rëndësishëm në zgjidhjet tona.

Çfarë do të ndodhë më pas

Çfarë do të ndodhë me LANBIX-in e origjinalit do të bëhet e njohur pas rezultateve të fushatës. Në rast se hipotezat tona nuk konfirmohen, sipas metodologjisë Lean, do ta heqim atë pa mëshirë ose do të transformohet në diçka të re, pasi nuk ka gjë më të keqe se të bësh një produkt që askush nuk e ka nevojë. Por tani mund të themi se puna e bërë nuk është e kotë, dhe falë saj është krijuar një linjë e tërë produktesh paralel, mbi të cilat ne po punojmë aktivisht. Nëse gjithçka shkon mirë, LANBIX do të kalojë nga faza MVP në fazën përfundimtare dhe do të zhvillohet sipas rregullave klasike të marketingut të produktit.

Përsëris, tani ne duam të gjejmë ndjekës të hershëm, kompani që mund të instalojnë produktin tonë për të mbledhur feedback. Nëse jeni të interesuar të testoni LANBIX, shkruani në komentet ose mesazhet personale.

Burimi

Burimi: habr.com

Si si punojmë me idetë dhe si lindi LANBIX