🥇Hogyan dolgozunk az ötletekkel, és hogyan született meg a LANBIX

A "Lanit-Integrációk" sok kreatív munkatárssal rendelkezik. Az új termékek és projektek ötletei szó szerint a levegőben lebegnek. Néha nagyon nehéz megállapítani, melyek a legérdekesebbek. Ezért közös erőfeszítéssel kidolgoztuk a saját módszerünket. A legjobb projektek kiválasztásáról és megvalósításukról ebben a cikkben olvashat.

Oroszországban és a világ más részein egy sor folyamat zajlik, amelyek átalakítják az IT-piacot. A számítási kapacitások növekedésének és a szerver, hálózati és egyéb virtualizációs technológiák megjelenésének köszönhetően a piac elvesztette szükségét a sok "vasra". A gyártók egyre inkább közvetlenül szeretnek a megrendelőkkel dolgozni. Az IT-piacon virágzik az outsourcing minden formája, a klasszikus outsourcingtól kezdve a új hullámos outsourcerekig - a "felhőszolgáltatókig". Az infrastruktúrák és elemek karbantartása és beállítása lényegesen egyszerűbbé vált. A szoftver minősége évről évre nő, és az integrátor feladatai átalakulnak.

Hogyan dolgozunk az ötletekkel

Termékindítási irány a "Lanit-Integrációkban" már több mint egy éve létezik. Fő célunk új termékek létrehozása és piacra dobásuk. Az első lépés, amivel kezdtük, a termékek létrehozásának folyamatának megszervezése volt. Számos módszertant átnéztünk, a klasszikusoktól kezdve a divatosokig. Azonban egyik sem felelt meg a kérdéseinknek. Ekkor úgy döntöttünk, hogy a Lean Startup módszertant vesszük alapul, és annak érdekében alkalmazzuk, hogy a saját feladatainkhoz igazítsuk. A „Becslő Startup” - Eric Ries által kidolgozott vállalkozási elmélet. Alapját olyan elvek, megközelítések és gyakorlatok alkotják, mint a lean termelés, ügyfélfejlesztés és agilis fejlesztési módszertan.

A termékfejlesztési megközelítésünkkel kapcsolatban: nem akartunk kerékpárt feltalálni, hanem már létező fejlesztési módszertant alkalmaztunk SCRUM, kreatív hozzáadásával most már bátran nevezhetjük SCRUM-WATERFALL-BAN-nak. A SCRUM, a rugalmassága ellenére, egy nagyon rigorózus rendszer, amely csak egy termék/projekt kezelésére alkalmas csapat számára ideális. Ahogy sejthető, a klasszikus „integrátori” üzletág nem teszi lehetővé a technikai szakemberek teljes munkaidős kiemelését egyetlen projekt számára (vannak kivételek, de ezek rendkívül ritkák), mivel a termékek munkája mellett mindenki a folyamatban lévő projekteken dolgozik. A SCRUM-ból átvettük a munkát sprintekre való felosztását, a napi jelentéseket, a retrospektívákat és a szerepeket. A feladatok áramlásának kezeléséhez a Kanban-t választottuk, amely remekül integrálódott a meglévő feladatkezelő rendszerünkbe. A munkát úgy alakítottuk ki, hogy zökkenőmentesen illeszkedjünk a már létező rendbe.
A termék a piacra lépés előtt 5 szakaszon megy keresztül: ötlet, kiválasztás, koncepció, MЖП (további részletek lent) és gyártás.

Ötlet

A jelenlegi szakaszban van valami efemer — az ötlet. Ideális esetben egy meglévő probléma vagy ügyfélfeladat megoldásának ötlete. Nincs hiányunk ötletekből. A kezdeti elképzelés szerint ezeket a technikai irányultságú munkatársaknak kell generálniuk. Ahhoz, hogy az ötlet további fejlesztésre kerüljön, az ötletgazdának ki kell töltenie az „Ötletformázási sablont”. Ott csupán négy kérdés szerepel: Mi? Miért? Kinek szükséges? Ha nem a mi termékünk, akkor miért?

Forrás

Kiválasztás

Amint a kitöltött sablon eljut hozzánk, megkezdődik a feldolgozási és kiválasztási eljárás. A kiválasztás szakasza a legmunkaigényesebb. Ebben a fázisban a problémahipotézisek megalapozása zajlik (nem véletlenül említettem az előző bekezdésben, hogy ideálisan az ötletnek meg kell oldania az ügyfél problémáját) és a termék értékének kialakítása. Kialakul a mérethatás hipotézise, azaz hogyan kíván növekedni és virágozni a vállalkozásunk. Probléma- és szakértői interjúkat tartunk potenciális megrendelőkkel, hogy előzetes bizonyosságot nyerjünk arról, hogy tényleg szükséges valamit előállítanunk. Legalább 10-15 interjúra van szükség ahhoz, hogy következtetést vonhassunk le a termék szükségességéről.

Ha a hipotézisek igazolódnak, prelimináris pénzügyi elemzést végzünk, megbecsüljük a várható befektetési összeget és a lehetséges hozamot a befektető számára. E szakasz eredményeként megszületik a Lean Canvas nevű dokumentum, amelyet a vezetőségnek bemutatunk.

Koncepció

Ezen a szakaszban az ötletek körülbelül 70%-át elvetjük. Ha a koncepciót jóváhagyják, megkezdődik az ötlet kidolgozása. Formálódnak a jövőbeli termék funkcionális lehetőségei, meghatározódnak a megvalósítási útvonalak és az optimális technikai megoldások, aktualizálódik az üzleti terv. Ennek a szakasznak az eredménye a fejlesztési műszaki leírás és a részletes üzleti eset. Siker esetén átmegyünk a MŽP vagy MVP szakaszába.

MŽP vagy MVP

A MŽP egy minimálisan életképes termék. Azaz egy olyan termék, amely nincs teljesen kidolgozva, de már értéket adhat, és a funkcióit ellátja. E fejlesztési szakasz során kötelező visszajelzéseket gyűjteni a valós felhasználóktól és módosításokat végezni.

Gyártás

És az utolsó szakasz — a gyártás. E szakaszba csak a termékek legfeljebb 5%-a jut el. Ezek az 5%-ba csak a legfontosabb, szükséges, életképes és funkcionális termékek tartoznak.

Sok ötletünk van, már egy széles portfóliót összegyűjtöttünk. Minden ötletet áttekintünk, és mindent megteszünk, hogy elérjük a végső szakaszt. Nagyon öröm látni, hogy a kollégák nem maradtak közömbösek a kutatás-fejlesztés iránt, és aktívan részt vesznek a fejlesztésben és a termékek, megoldások megvalósításában.

Hogyan készítettük a LANBIX-et

Vizsgáljuk meg a termék létrehozását egy valós példa alapján — a LANBIX termék. Ez egy "dobozos" szoftver- és hardverkomplexum, amely kisebb IT infrastruktúrák monitorozására és a felelős személyek, valamint az üzleti felhasználók számára a hibákról történő gyors értesítésére szolgál, chatboton keresztül történő irányítással. A monitorozási funkció mellett a LANBIX Help Desk funkciót is tartalmaz. Ez a termék exkluzív arra a piaci szegmensre, amelyre fókuszálunk. Ez a mi előnyünk és a mi búnk. De mindent a helyén. Rögtön elmondom, hogy a LANBIX egy élő termék (azaz nem végleges a fejlődésében, és a következő MVP körforgásban van).

Tehát az első szakasz — az ötlet. Ahhoz, hogy ötlet szülessen, problémákra van szükség, és nekünk voltak problémáink, pontosabban nem nekünk, hanem az ismerőseinknek. Az alábbiakban néhány valós helyzetet vizsgálunk meg, amelyek különböző üzleti területeken történtek.

Egy kisebb ingatlankezelő cég két lakóépületet üzemeltet Moszkva környékén. Körülbelül 15 alkalmazott dolgozik számítógéppel. A rendszergazda egy alkalmi szabadúszó (az egyik lelkes lakó okos fia). Úgy tűnhet, hogy az ingatlankezelő cég tevékenysége gyengén függ az IT-től, de az üzlet különlegessége a havi jelentések készítése a sok különböző hatóság felé. A cégvezető rendszerdiskje (ahogy az lenni szokott, sok szerepet betöltve) tele lett. Természetesen ez nem hirtelen történt, a figyelmeztetés körülbelül 2 hónapig ott lógott, és folyamatosan figyelmen kívül hagyták. De megérkezett egy frissítés, az operációs rendszer frissült, és éppen a frissítés közepén fagyott le, panaszkodva a „halála” előtt a megtelt lemez miatt. A gép ciklikus újraindításba került. Amíg a problémát kezelték és előkeresték a jelentéseket, lekésték a jelentési határidőt. Úgy tűnt, hogy egy banális hiba különféle kellemetlenségek forrásává vált: anyagi veszteségektől a bírósági eljárásokig és közigazgatási felelősségig.

Forrás

Hasonló eset történt egy nagy holdingnál, amely számos kis céget tömörít, egy központi technikai támogató szolgálattal az egész iroda számára. Az egyik osztály főkönyvelőjének számítógépe meghibásodott. Már régóta tudták, hogy gond van vele (a gép kétségbeesetten lassult és felforrósodott), de a főkönyvelő soha nem jutott el oda, hogy bejegyzést küldjön a technikai támogatásnak. Természetesen pont a fizetés napján romlott el, így az osztály munkatársai néhány napig pénz nélkül maradtak.

Egy kis kereskedelmi vállalkozásnak, amely kiskereskedelemmel foglalkozik, leállt az eladási oldala, amely egy külső platformon hostolt. A folyamatról egy állandó megrendelőtől értesültek telefonon. A hívás idején a weboldal már körülbelül három órája elérhetetlen volt. Az oldalért felelős személy keresésére még egy pár óra eltelt, a hiba elhárítására pedig további kettő. Ennek következtében gyakorlatilag az egész munkanap alatt a weboldal elérhetetlen volt. A vállalat kereskedelmi igazgatója szerint ez az állásidő körülbelül 1 millió rubelbe került nekik.

Én is hasonló helyzetbe kerültem, amikor elmentem egy egészségügyi rendelőbe, és be kellett volna mennem a DMC regisztrációs irodájába. Az orvoshoz nem tudtak elküldeni egy banális ok miatt – reggel feszültségingadozás volt, és a baleset után az ő levelezőszolgáltatásuk és egy telefonos kapcsolat az biztosítóval nem működött. Amikor megkérdeztem, hol vannak az adminjaik, azt mondták, hogy az adminjuk alkalmi, és hetente egyszer látogatja őket. És most (abban az időpontban már 16:00 volt) nem veszi fel a telefont. Legalább 7 órán keresztül a rendelő ki volt zárva a külvilágból, és nem tudtak szolgáltatásokat nyújtani.

Mi köti össze ezeket az eseteket? Az összes probléma előre megakadályozható lett volna. A megfelelő időben történő reagálással az IT-t szolgáltató emberek részéről csökkenteni lehetett volna a kárt. Ez lehetséges lett volna a felhasználók korai tüneteinek helyes értelmezése esetén is.

Kiválasztottuk a problémák hipotéziseit:

jelentős pénzügyi és reputációs veszteségek a IT-infrastruktúrában előforduló hibákra adott alacsony reakciósebesség miatt;
a felhasználók részéről a hibák korai tüneteinek helytelen értelmezése.

Mit tehet a megrendelő ezekkel, és hogyan kerülhetjük el az ilyen helyzeteket a jövőben? Nincs sok lehetőség:

magasan képzett rendszergazdát felvenni és rábízni, hogy lelkiismeretesen végezze a munkáját;
Az IT karbantartását egy szakosodott szolgáltató cégre bízni;
saját magunk bevezetni egy monitorozó és figyelmeztető rendszert a hibákra;
elvégezni a felhasználók/biznisz személyzet alapvető számítástechnikai képzését.

Maradjunk a harmadik lehetőségnél. Javasoljunk monitorozó rendszert azoknak, akik különböző okok miatt nem használják.

Lírai kitérő. Különböző IT-szolgáltatás-figyelő rendszereket régóta használnak a vállalati piacon, és hasznuk vitathatatlan. Beszéltem nagyvállalatok képviselőivel, és megnéztem, hogyan épülnek fel a vállalkozás és az IT közötti kapcsolatok. Egy nagy gépipari vállalat műszaki igazgatója az IT-infrastruktúra karbantartását egy külső cégre bízta, de ő maga folyamatosan tájékozott marad az eseményekről. Irodájában egy nagy kijelzőn látható a figyelőrendszer, amely mutatja az IT-szolgáltatások állapotát. A rendszerbe a legkritikusabb elemeket vezették be. Bármikor a műszaki igazgató megtudhatja, hogy milyen állapotban van az infrastruktúra, mi történik, hol van probléma, értesítve lettek-e a felelős személyek, és folyamatban van-e a probléma megoldása.

A felsorolt történetek arra késztették csapatunkat, hogy elgondolkodjunk, hogyan hozhatnánk létre egy optimális figyelőrendszert a kisvállalatok számára. Ennek eredményeként megszületett a LANBIX — egy figyelőrendszer, amelyet bárki telepíthet IT-tudás nélkül. A rendszer alapvető feladata egyszerű, mint minden olyan rendszeré, ami a folytonosság és elérhetőség növelésére irányul: pénzügyi és egyéb veszteségek csökkentése nem tervezett leállások esetén. A célja, hogy a lehető legkisebbre csökkentse az időt a „valami elromlott” és a „probléma megoldva” között.

A hipotézisek megerősítése érdekében problémainterjúkat végeztünk. El sem tudtam képzelni, mennyi mindent hajlandók az emberek elmondani, ha nem próbálunk nekik eladni. Minden beszélgetés legalább 1,5 órán át tartott, és számos, a további fejlesztéshez hasznos információt gyűjtöttünk.

Összegzés ennek a szakasznak az eredményeiről:

a probléma megértése — megvan,
az érték megértése — megvan,
a megoldási ötlet — megvan.

A második szakasz részletesebb volt. Az eredmények alapján be kellett mutatnunk a vezetőségnek, amely lényegében befektetői szerepet tölt be, egy üzleti esetet (az a Lean Canvas), hogy döntést hozzanak a termék további sorsáról.

A piac és a versenytársak kutatásával kezdtük, hogy kiderítsük, ki mit, és ami a legfontosabb, hogyan csinál ezen a piacon.

A következőket állapítottuk meg.

A piacon nincs kész dobozos monitorozó rendszer a mi szegmensünkre (kisvállalkozások), kivéve néhányat, amelyekről érthető okokból nem fogok beszélni.
Furcsa módon a fő konkurenseink a rendszergazdák, akik egyedi írású szkripteket és „kiegészítéseket” használnak nyílt forráskódú monitorozó rendszerekhez.
Nyilvánvaló probléma van a nyílt forráskódú monitorozó rendszerek használatával. Létezik egy rendszer, rengeteg információ áll rendelkezésre a rendszer működéséről és testreszabásáról. Az általam megkérdezett rendszergazdák közül sokan bevallották, hogy hiányzik a tudásuk ahhoz, hogy saját maguk valósítsák meg elképzeléseiket. Azt pedig, hogy a vezetőségnek ezt elmondják, nem merik, mert félnek a kirúgástól. Így hát egy ördögi kör alakul ki.

Ezután áttértünk a potenciális megrendelőink igényeinek elemzésére. Kiválasztottunk egy kicsi szervezetekből álló szegmenst, akik valamilyen okból nem rendelkeznek saját IT-üzemeltetéssel; a számítástechnikai feladatok ellátását vagy egy külsős rendszergazda, vagy egy szabadúszó, vagy egy szolgáltató cég végzi. Nem az IT, hanem az üzleti oldalról akartunk belépni, olyan eszközt kínálva az alapítóknak és a vállalkozás tulajdonosainak, amely javítja az IT-infrastruktúra szolgáltatásainak színvonalát. Ez a termék, amely segíti a tulajdonosokat a vállalkozásuk biztonságának megőrzésében, ugyanakkor több munkát ad azoknak, akik az IT-ért felelnek. Ez a termék lehetőséget ad az üzlet számára az IT támogatásának minőségének ellenőrzésére.

A begyűjtött adatok feldolgozása nyomán megszületett az első követelménylista (valamilyen durva backlog) a jövőbeli termékhez:

a monitorozó rendszernek nyílt forráskódú megoldáson kell alapulnia, így olcsónak kell lennie;
egyszerűnek és gyorsan telepíthetőnek kell lennie;
nem követelhet speciális IT tudást, még egy könyvelőnek is (ezzel a szakmával szemben nem akartam sértő lenni) képesnek kell lennie a rendszer telepítésére és beállítására;
automatikusan kell felfedeznie a monitorozandó objektumokat a hálózaton;
automatikusan (ideális esetben automatikusan) telepítenie kell a monitorozó ágenseket;
képesnek kell lennie külső szolgáltatások, legalább CRM-rendszerek és értékesítési weboldalak monitorozására;
figyelmeztetnie kell a problémákra a vállalkozást és a rendszergazdát egyaránt;
a figyelmeztetések mélysége és „nyelve” eltérő kell, hogy legyen a rendszergazda és az üzlet számára;
a rendszernek saját hardveren kell érkeznie;
a hardvernek a lehető legelérhetőbbnek kell lennie;
A rendszernek a lehető legkevésbé kell függenie a külső tényezőktől.

Továbbá kiszámították a termékfejlesztéshez szükséges befektetéseket (beleértve a műszaki osztály munkatársainak munkaidő-becslését). Elkészült egy üzleti modell vázlata és a termék egység-gazdasága is ki lett számítva.

A szakasz eredménye:

magas szintű termék backlog;
formált üzleti modell vagy skálahipotézis, amelyet még ellenőrizni kell a gyakorlatban.

Lépjünk a következő szakaszra – a koncepcióra. Itt mérnökként a jól megszokott közegünkben vagyunk. Vannak "igények", amelyeket alkotóelemekre / alrendszerekre / funkciókra bontunk, amelyeket továbbá műszaki követelményekre / felhasználói történetekre alakítunk, majd projektbe és így tovább. Nem akarok túlságosan részletezni a különböző alternatívák kidolgozásának folyamatát, térjünk át az igényekre és a választott megvalósítási módokra.

Követelmény
Megoldás

Egy nyílt monitoring rendszernek kell lennie;

Fogjunk egy nyílt forráskódú monitoring rendszert.

A rendszernek egyszerűnek és gyorsnak kell lennie a telepítés során;
nem igényelhet specifikus IT tudást. Még egy könyvelőnek is képesnek kell lennie a rendszer telepítésére és beállítására.

Ajánlunk egy előtelepített rendszert, hogy a felhasználónak csak be kelljen kapcsolnia az eszközt és egy kicsit beállítania, hasonlóan, mint egy routernél.

Korlátozzuk az interakciót az eszközzel valami egyszerűre és érthetőre mindenki számára.

Készítünk egy chatbotot egy ismert üzenetküldő alkalmazáshoz, és az egész interakciót átvisszük rá.

A rendszernek a következőket kell tudnia:

automatikusan észlelni a monitorozásra szánt objektumokat a hálózaton;
automatikusan telepíteni a monitoring ügynököket;
Lehetősége legyen külső szolgáltatások monitorozására, legalább a CRM rendszert és az értékesítési weboldalt.

Kiegészítőket írunk a monitoring rendszerhez a következőkben:

automatikus objektumészlelés;
automatikus ügynökkételepítés;
a külső szolgáltatások elérhetőségének monitorozása.

A rendszernek a következőket kell tudnia:

értesítenie kell a problémákról a vállalkozást és a rendszergazdát egyaránt;
lehetősége legyen a külső szolgáltatások monitorozására, legalább a CRM rendszert és az értékesítési weboldalt. Az értesítések mélysége és "nyelve" eltérő kell legyen az adminisztrátorok és az üzlet számára.
A rendszernek nem kell specifikus IT tudást igényelnie, még egy könyvelőnek is képesnek kell lennie a rendszer telepítésére és beállítására.

Különböző értesítési típusokat adunk hozzá a különböző felhasználói csoportok számára. Ezek eltérnek a megfogalmazásukban és a részletességükben. Az üzleti felhasználó olyan értesítéseket kap, mint például: „minden rendben van, de Ivanov számítógépe hamarosan meghal”. Az adminisztrátor teljes hibajelentést kap arról, hogy ki, mit és hogyan történt, vagy mi történhet.
Lehetővé tesszük, hogy egy további felelős személy e-mail címét is használhassák, hogy esetleges meghibásodás esetén értesítést kapjon.
Külső szolgáltatókkal való interakciót adunk hozzá e-mail küldésével, előre megírt szöveggel, mivel az elektronikus levél adja meg az alapot egy incidens rögzítéséhez.
Az összes interakciót csevegőbotra tereljük, a kommunikáció párbeszédes stílusban zajlik.

Kiegészítés:

Hozzáadunk egy „adminisztrátorral való csevegés” funkciót, hogy a felhasználó közvetlenül tudjon üzenetet küldeni az adminisztrátornak a probléma leírásával.

A rendszernek saját hardverrel kell rendelkeznie.
A hardvernek elérhetőnek kell lennie.
A rendszernek maximálisan függetlennek kell lennie a környezettől.

Egy kész és olcsó Raspberry PI számítógépet fogunk használni.
Megtervezzük az energiaszükséglet folyamatos biztosítására szolgáló áramkört.
Modemet adunk hozzá a helyi hálózati állapottól való függetlenség érdekében.
Megtervezzük a szép házat.

Három alrendszert hoztunk létre, mindegyik saját követelményeivel és megvalósítási elképzeléseivel:

hardver alrendszer;
monitoring alrendszer;
felhasználói interakciós alrendszer.

A hardver alrendszerhez elkészítettük a vázlatos tervet. Igen! Megsértve az összes agilis szabályt, készítettünk egy dokumentumot, mert a gyártók éppen ezek alapján dolgoznak. A többi alrendszerhez felhasználókat (személyeket) választottunk ki, felhasználói történeteket készítettünk, és fejlesztési feladatokat írtunk.

Ezzel a koncepció szakasz véget ér, és az eredménye a következő lett:

a hardverplatformra vonatkozó projekt;
megfogalmazott vízió a másik két alrendszer felhasználói történetei formájában;
a programrészt prototípus formájában, virtuális gépként valósítottuk meg;
a hardver rész prototípusa, amelyet egy állvány formájában valósítottunk meg, ahol az hardvermegoldásokat teszteltük;
tesztelés, amelyet adminisztrátoraink végeztek.

A problémák ezen a szinten nagyrészt szervezési jellegűek voltak, és összefüggésben álltak a mérnöki csapat jogi és számviteli aspektusainak elégtelen ismeretével az értékesítés terén. Más szóval, egy dolog kitalálni, hogy mit és hogyan kell eladni, és teljesen más szembenézni a könyörtelen jogi gépezettel: szabadalmak, fejlesztési megbízások, mérlegre vétel, EULA és sok más, amit mi kreatív emberek eredetileg nem vettünk figyelembe.

Még nem problémáról, inkább a házak tervezésével kapcsolatos nehézségről volt szó. A csapatunkban csak mérnökök vannak, ezért az első ház prototípusát akrilüvegből készítette el elektronikai szakértőnk.

A ház, finoman szólva, vitathatóan nézett ki, különösen a modern technológia által elkényeztetett közönség számára. Természetesen akadtak közöttük olyanok, akik a „kúlíbins” idősebb generációjából értékelték – a ház nosztalgikus érzéseket ébresztett bennük. Úgy döntöttünk, hogy újra elkészítjük és megtervezzük a házat, mivel a régi nemcsak esztétikai hiányosságokkal rendelkezett, hanem szerkezetiakkal is – az akrilüveg rosszul bírta a készülék összeszerelését és szétszerelését, és hajlamos volt repedésekre. A ház gyártásáról később mesélek.

Íme, közel kerültünk a célegyeneshez – MVP. Ez természetesen még nem a végleges sorozatgyártású termék, de már hasznot hoz és értéket képvisel. Ennek a szakasznak a fő célja a „létrehozás-értékelés-tanulás” ciklus elindítása. Ezen a szakaszon van a LANBIX.

A „létrehozás” szakaszban elkészítettük a készüléket, amely a meghatározott funkciót ellátja. Igen, még nem tökéletes, de tovább dolgozunk rajta.

Visszatérünk a ház készítéséhez, tehát ahhoz a feladathoz, hogy eszközünket, amely nosztalgikus érzéseket vált ki, modernné alakítsuk. Eleinte átnéztem a piacot a házgyártókkal és ipari formatervezési szolgáltatásokkal kapcsolatban. Először is, Oroszországban nagyon kevés olyan cég van, amely házakat gyárt, másrészt pedig az ipari formatervezés költsége ebben a szakaszban rendkívül magas, körülbelül 1 millió rubel.

A design request was directed to our marketing department; a young designer was ready for creative experimentation. We laid out our vision for the case (having previously studied the best examples of casing construction), and he transformed it into a work of art. All that remained was to produce it. Proud of our design, we turned to our partners. Their CEO immediately shattered our fantasies, pointing out issues that made our chosen production method impossible, completely free of charge. The case could be produced, and it would be no worse than Apple's, but the cost of the case would be three to four times higher than all the electronic components combined. After a series of operations and approvals, we designed a case that could actually be produced. Yes, it’s not as beautiful as we had planned, but it is ideal for achieving our current goals.

Stage result: the first batch of devices ready for action and testing.

And now the most challenging part—the evaluation stage, and our product is right at this point. We can only assess it based on the results of use by actual customers, and no assumptions work here. We need those 'early adopters' to provide feedback and make the necessary changes to the product. The question arises: how do we find customers and convince them to participate in the experiment?

Out of all the possible options, we chose a classic set of digital tools: a landing page and an advertising campaign on social media.

The process has already started, but it’s too early to talk about results, although we have already received feedback and confirmed many of our hypotheses. A pleasant surprise was the reaction of representatives from entirely different business segments, much larger than those we had anticipated. It would be foolish to ignore these new inputs, and based on the results of the conducted interviews, we decided to launch a parallel line called LANBIX Enterprise. We added support for distributed infrastructures, Wi-Fi network monitoring with fault detection and localization, and monitoring of communication channel quality. The greatest interest in the solution was expressed by service companies. At the same time, the devices we had already developed play a significant role in these solutions.

Mi következik

Mi vár ránk az eredeti LANBIX-szel? A kampány eredményei világossá teszik. Ha nem igazolódnak a hipotéziseink, a Lean módszertan szerint könyörtelenül megszabadulunk tőle, vagy valami újra alakulunk, mert nincs rosszabb, mint egy olyan terméket készíteni, amire senkinek sincs szüksége. De már most elmondható, hogy az elvégzett munka nem volt hiábavaló, és ennek köszönhetően egy teljes párhuzamos termékág létrejött, amelyen aktívan dolgozunk. Sikerek esetén a LANBIX az MVP szakaszból végső szakaszba lép, és a klasszikus termékmarketing törvényei szerint fejlődik.

Megismétlem, most korai követőket szeretnénk találni, olyan cégeket, akikhez be tudjuk állítani a termékünket a visszajelzések gyűjtése céljából. Ha érdekli a LANBIX tesztelése, írjon a hozzászólásokban vagy személyes üzenetekben.

Forrás

Forrás: habr.com