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

A LANIT-Integrationnél sok kreatív alkalmazott dolgozik. Az új termékekre és projektekre vonatkozó ötletek szó szerint a levegőben lógnak. Néha nagyon nehéz lehet azonosítani a legérdekesebbeket. Ezért közösen kidolgoztuk a saját módszertanunkat. Olvassa el ezt a cikket a legjobb projektek kiválasztásáról és végrehajtásáról.

Oroszországban és a világ egészében számos olyan folyamat zajlik, amelyek az IT-piac átalakulásához vezetnek. A számítási teljesítmény 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 piacnak már nincs szüksége nagy mennyiségű hardverre. A szállítók egyre inkább szívesebben dolgoznak közvetlenül az ügyfelekkel. Az IT-piacon az outsourcing minden formája fellendülést él meg, a klasszikus outsourcingtól az új outsourcing-hullámig – a „felhőszolgáltatókig”. Az infrastrukturális rendszerek és elemek sokkal könnyebben karbantarthatók és konfigurálhatók. A szoftverek minősége évről évre növekszik, és átalakulnak az integrátor feladatai is.

Hogyan dolgozunk ötletekkel

A termék indítási iránya be "LANIT-integráció" már több mint egy éve létezik. Fő célunk új termékek létrehozása és piacra vitele. Az első dolog, amivel elkezdtük, a termékek létrehozásának folyamatának megszervezése volt. Számos módszert tanulmányoztunk, a klasszikustól a hype-ig. Azonban egyik sem felelt meg az igényeinknek. Aztán úgy döntöttünk, hogy a Lean Startup módszertant vesszük alapul, és adaptáljuk a feladatainkhoz. A Lean Startup egy vállalkozáselmélet, amelyet Eric Ries alkotott meg. Olyan koncepciók elvein, megközelítésein és gyakorlatain alapul, mint a lean gyártás, az ügyfélfejlesztés és a rugalmas fejlesztési módszertan.

Ami a termékfejlesztési menedzsment közvetlen megközelítését illeti: nem találtuk fel újra a kereket, hanem egy már meglévő fejlesztési módszertant alkalmaztunk. DULAKODÁS, kreativitást adva, és most már nyugodtan nevezhetjük SCRUM-WATERFALL-BAN-nak. A SCRUM rugalmassága ellenére nagyon merev rendszer, és csak egy termékért/projektért felelős csapat menedzselésére alkalmas. Amint megérti, a klasszikus „integrációs” üzlet nem jelenti azt, hogy teljes munkaidős műszaki szakembereket rendelnek egy projekthez (vannak kivételek, de rendkívül ritkán), mivel a termékeken való munka mellett mindenki az aktuális projektekkel van elfoglalva. A SCRUM-tól átvettük a munkamegosztást sprintekre, napi jelentésekre, visszatekintésekre és szerepekre. Feladatfolyamunkhoz a Kanbant választottuk, és jól integrálódott meglévő feladatkövető rendszerünkbe. Munkánkat úgy strukturáltuk, hogy zökkenőmentesen integrálódtunk a dolgok meglévő rendjébe.
A piacra lépés előtt egy termék 5 szakaszon megy keresztül: ötlet, kiválasztás, koncepció, MVP (részletek lent) és gyártás.

Ötlet

Ebben a szakaszban van valami mulandó – egy ötlet. Ideális esetben egy ötlet egy meglévő probléma vagy ügyfélprobléma megoldására. Ötletekben nincs hiányunk. Az eredeti terv szerint ezeket a műszaki területek dolgozóinak kell előállítania. Ahhoz, hogy egy ötletet továbbfejlesztésre elfogadhassunk, a szerzőnek ki kell töltenie az „Ötlettervező sablont”. Csak négy kérdés van: Mi? Miért? Kinek kell ez? És ha nem a mi termékünk, akkor mi?

Forrás

Kiválasztás

Amint az elkészült sablon megérkezik hozzánk, megkezdődik a feldolgozás és a kiválasztási procedúra. A kiválasztási szakasz a legmunkaigényesebb. Ebben a szakaszban kialakulnak a problémák hipotézisei (nem hiába említettem az előző bekezdésben, hogy ideális esetben egy ötletnek meg kell oldania az ügyfél problémáját) és a termék értékéről. Skálahipotézis alakul ki, azaz. hogyan fog növekedni és virágozni a vállalkozásunk. Probléma- és szakértői interjúkat készítünk a potenciális ügyfelekkel, hogy előzetes megerősítést adjunk arról, hogy valami szükségeset fogunk gyártani. Legalább 10-15 interjúra van szükség ahhoz, hogy következtetést vonjunk le a termék szükségességéről.

Ha a hipotézisek beigazolódnak, előzetes pénzügyi elemzést végeznek, felmérik a befektetés hozzávetőleges mennyiségét és a befektető lehetséges bevételeit. Ennek a szakasznak az eredményeként megszületik a Lean Canvas nevű dokumentum, amelyet a vezetőség elé tárnak.

koncepció

Ebben a szakaszban az ötletek körülbelül 70%-a megszűnik. Ha a koncepciót jóváhagyják, akkor kezdődik az ötletfejlesztési szakasz. Kialakul a leendő termék funkcionalitása, meghatározzák a megvalósítási utakat és az optimális műszaki megoldásokat, aktualizálják az üzleti tervet. Ennek a szakasznak az eredménye egy fejlesztési műszaki specifikáció és egy részletes üzleti eset. Siker esetén továbblépünk az MVP vagy MVP szakaszba.

MVP vagy MVP

Az MVP egy minimálisan életképes termék. Azok. nem teljesen kifejlesztett, de már értéket tudó, funkcionalitását teljesítő termék. Elengedhetetlen, hogy a fejlesztés ezen szakaszában visszajelzéseket gyűjtsünk valódi felhasználóktól, és változtatásokat hajtsunk végre.

Termelés

És a legutolsó szakasz a gyártás. A termékek legfeljebb 5%-a éri el ezt a szakaszt. Ez az 5% csak a legfontosabb, szükséges, életképes és működőképes termékeket tartalmazza.

Rengeteg ötletünk van, és máris egy terjedelmes portfóliót állítottunk össze. Minden ötletet elemezünk, és mindent megteszünk annak érdekében, hogy a végső szakaszba kerüljön. Nagyon örülök, hogy kollégáink nem maradtak közömbösek K+F irányunk iránt, és aktívan részt vesznek a termékek, megoldások fejlesztésében és megvalósításában.

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

Nézzük meg egy termék létrehozását egy valós példa – a LANBIX termék – felhasználásával. Ez egy „dobozos” szoftver- és hardverrendszer kis informatikai infrastruktúrák figyelésére, valamint a döntéshozók és az üzleti felhasználók azonnali figyelmeztetésére a chatboton keresztül vezérelt meghibásodásokról. A felügyeleti funkción kívül a LANBIX tartalmaz Help Desk funkciót is. Ez a termék kizárólag az általunk megcélzott piaci szegmens számára készült. Ez előnyünk és fájdalmunk is egyben. De először a dolgok. Azonnal leszögezem, hogy a LANBIX egy élő termék (azaz nem végleges a fejlesztésben, és az MVP következő fordulójában van).

Tehát az első szakasz az ötlet. Ahhoz, hogy egy ötlet megszülethessen, problémákra van szükség, és nekünk voltak, vagy inkább nem nekünk, hanem a barátainknak. Az alábbiakban megvizsgálunk néhány valós helyzetet, amelyek az üzleti élet különböző területein fordultak elő.

Egy kis alapkezelő cég két házat tart fenn a moszkvai régióban. A PC-s személyzet körülbelül 15 fő. A rendszergazda egy látogató szabadúszó (az egyik gondoskodó lakó okos fia). Úgy tűnik, hogy az alapkezelő társaság tevékenységei gyengén függenek az informatikától, de ennek az üzletnek a sajátossága, hogy havi jelentéseket készít sok hatóságnak. A cég vezetőjének rendszerlemezén (amely szokás szerint sok szerepkört egyesít) elfogyott a szabad hely. Természetesen ez nem hirtelen történt, a figyelmeztetés körülbelül 2 hónapig lógott, és folyamatosan figyelmen kívül hagyták. Ám érkezett egy frissítés, frissítették az operációs rendszert, és szerencsére a frissítés közepén lefagyott, „halál előtt” panaszkodva a foglalt lemezre. A számítógép ciklikus újraindításba került. Amíg a probléma elhárítása és a bejelentések beszerzése zajlott, lekéstük a bejelentési határidőt. Úgy tűnik, hogy egy triviális meghibásodás különféle problémákat okozott: a veszteségektől a peres eljárásokig és az adminisztratív felelősségig.

Forrás

Hasonló incidens történt egy nagy holdingnál, amely sok kis céget egyesített, egyetlen műszaki támogatási szolgáltatással az egész irodára. Az egyik osztályon elromlott a főkönyvelő számítógépe. Régóta ismert volt, hogy elromolhat (a számítógép kétségbeesetten lassult és felmelegedett), de a főkönyvelő soha nem jutott el addig, hogy kérést küldjön a műszaki támogatásnak. Természetesen pontosan fizetésnapon tönkrement, az osztály dolgozói több napig pénz nélkül maradtak.

Egy kiskereskedelmi kisvállalkozásnak volt értékesítési weboldala, amelyet egy külső oldalon tároltak. Elérhetetlenségéről telefonon értesültünk egy törzsvásárlótól. A hívás időpontjában az oldal körülbelül három órája nem működött. További néhány órába telt, amíg megtalálták a webhelyért felelős személyt, és további két órába telt a probléma megoldása. Ennek megfelelően az oldal szinte az egész munkanapon nem volt elérhető. A cég kereskedelmi igazgatója szerint ez az állásidő körülbelül 1 millió rubelbe került.

Én magam is találkoztam hasonló helyzettel, amikor időpontért jöttem a klinikára, és be kellett mennem a VHI-be. Triviális okból nem tudtak orvoshoz küldeni - reggel áramemelkedés volt, és a baleset után a postaszolgáltatásuk és a biztosítótársasággal való kommunikáció bizonyos szolgáltatása nem működött. Arra a kérdésemre, hogy hol vannak az adminok, azt mondták, hogy az adminjuk hetente egyszer jön és meglátogatja őket. És most (akkor már 16:00 volt) nem veszi fel a telefont. A klinika legalább 7 órán keresztül el volt zárva a külvilágtól, és nem tudott fizetős szolgáltatásokat nyújtani.

Mi a közös ezekben az esetekben? Abszolút minden probléma megelőzhető lett volna előre. Az informatikusok időben történő reagálásával a kár csökkenthető lett volna. Ez akkor lehetséges, ha a felhasználók helyesen értelmeznék a korai tüneteket.

Problémahipotéziseket azonosítottunk:

jelentős pénzbeli és hírnévveszteség az IT infrastruktúra hibáira való gyors reagálás miatt;
a hibás működés korai tüneteinek félreértelmezése a felhasználók részéről.

Mit tehet velük az ügyfél, és hogyan kerülheti el a hasonló helyzeteket a jövőben? Nincs sok lehetőség:

magasan képzett rendszergazdát fogadjon fel, és tegye rá lelkiismeretes munkára;
az informatikai karbantartást kiszervezni egy erre szakosodott szolgáltató cégnek;
önállóan bevezeti a felügyeleti és hibajelentési rendszert;
képzést biztosít a felhasználóknak/üzleti személyzetnek a számítógépes ismeretek alapjairól.

Foglalkozzunk a harmadik lehetőséggel. Ajánljunk felügyelő rendszert azoknak, akik különböző okok miatt nem használják.

Lírai kitérő. A vállalati piacon az informatikai szolgáltatások figyelésére már régóta alkalmaznak különféle rendszereket, amelyek előnyei nem vitathatók. Nagyvállalatok képviselőivel beszélgettem, megnéztem, hogyan épült fel az üzlet és az IT kapcsolata. Az egyik nagy gépgyártó cég műszaki igazgatója külső cégre bízta az informatikai infrastruktúra karbantartását, de ő maga továbbra is mindennel tisztában van. Irodájában egy nagyméretű felügyeleti rendszer képernyő lóg az informatikai szolgáltatások állapotát jelző mutatókkal. A legkritikusabbak benne vannak a rendszerben. A műszaki igazgató bármikor tájékozódhat, hogy milyen állapotban van az infrastruktúra, mi történik, hol a probléma, értesítették-e a felelősöket, megoldódik-e a probléma.

A fent felsorolt történetek arra késztették csapatunkat, hogy elgondolkodjanak azon, hogyan alakítsunk ki egy optimális monitoring rendszert a kisvállalkozások számára. Ennek eredményeként megszületett a LANBIX – egy olyan felügyeleti rendszer, amelyet informatikai ismeretek nélkül abszolút bárki telepíthet. A rendszer fő célja egyszerű, mint minden rendszernek, amely a folytonosság és a rendelkezésre állás növelését célozza – a pénzbeli és egyéb veszteségek csökkentését nem tervezett leállások esetén. Az eszközt úgy tervezték, hogy minimálisra csökkentse a „valami elromlott” és „a probléma megoldódott” közötti időt.

A hipotézisek megerősítésére problémainterjúkat készítettem. El sem tudtam képzelni, mennyit lennének hajlandóak az emberek elmondani anélkül, hogy megpróbálnának eladni nekik. Minden beszélgetés legalább 1,5 óráig tartott, és sok, a további fejlődéshez hasznos információt kaptunk.

Foglaljuk össze ennek a szakasznak az eredményeit:

megvan a probléma megértése,
az érték megértése – van,
Van egy ötlet a megoldásra.

A második szakasz részletesebb volt. Eredményei alapján egy üzleti esetet (ugyanaz a Lean Canvast) kellett bemutatnunk a menedzsmentnek, aki lényegében a befektető szerepét tölti be, hogy döntést hozhasson a termék további sorsáról.

Piackutatással és versenyelemzéssel kezdtük, hogy megtudjuk, kinek, mit és ami a legfontosabb, hogyan teljesít ezen a piacon.

A következő derült ki.

A mi szegmensünknek (kisvállalkozásoknak) nincsenek kész dobozos megfigyelő rendszerek a piacon, egy-két kivételével, amiről nyilvánvaló okokból nem is beszélek.
Fő versenytársaink, furcsa módon, a rendszergazdák, akik házilag írt szkriptekkel és „kiegészítőkkel” rendelkeznek a nyílt forráskódú megfigyelőrendszerekhez.
Egyértelmű probléma van a nyílt forráskódú felügyeleti rendszerek használatával. Van egy rendszer, hatalmas mennyiségű információ van arról, hogyan kell dolgozni és módosítani a rendszert az Ön igényei szerint. Az általam megkérdezett adminisztrátorok közül többen beismerték, hogy nem rendelkeznek elegendő kompetenciával elképzeléseik önálló megvalósításához. De ezt nem tudják bevallani a vezetőségnek, mert félnek az elbocsátástól. Kiderül, hogy ez egy ördögi kör.

Ezután áttértünk potenciális ügyfeleink igényeinek elemzésére. Meghatároztuk magunknak a kis szervezetek egy szegmensét, amelyek valamilyen oknál fogva nem rendelkeznek saját informatikai szolgáltatással, ahol vagy egy bejövő rendszergazda, egy szabadúszó, vagy egy szolgáltató cég felel az informatikáért. Nem az informatikai oldal döntött a belépés mellett, hanem az üzleti oldal, amely eszközt kínál az alapítóknak és a cégtulajdonosoknak az IT infrastruktúra-szolgáltatás minőségének javítására. Egy olyan termék, amelynek segítenie kell a tulajdonosokat vállalkozásuk biztosításában, ugyanakkor munkával jár az IT-ért felelős emberek számára. Olyan termék, amely eszközt biztosít a vállalkozások számára az informatikai támogatás minőségének nyomon követésére.

A beérkezett adatok feldolgozása eredményeként megszületett az első követelménylista (egyfajta durva lemaradás) a leendő termékkel kapcsolatban:

a monitoring rendszernek nyílt forráskódú megoldáson kell alapulnia, és ennek eredményeként olcsónak kell lennie;
könnyen és gyorsan telepíthető;
ne igényeljen speciális informatikai ismereteket, még egy könyvelőnek (semmiképpen sem akartam megbántani e szakma képviselőit) képesnek kell lennie a rendszer telepítésére és konfigurálására;
automatikusan észlelnie kell a hálózaton megfigyelhető objektumokat;
automatikusan (és ideális esetben automatikusan) telepítenie kell a megfigyelő ügynököket;
képesnek kell lennie a külső szolgáltatások, legalább egy CRM rendszer és egy értékesítő weboldal figyelésére;
értesítenie kell mind a vállalkozást, mind a rendszergazdát a problémákról;
a figyelmeztetések mélységének és „nyelvének” eltérőnek kell lennie az adminisztrátor és a vállalkozás számára;
a rendszert saját hardveren kell szállítani;
a vasnak a lehető legjobban hozzáférhetőnek kell lennie;
a rendszernek a lehető legfüggetlenebbnek kell lennie a külső tényezőktől.

Ezt követően a termékfejlesztési beruházások kiszámítására került sor (beleértve a műszaki osztály dolgozóinak munkaerőköltségét). Elkészült az üzleti modell vázlata és kiszámították a termék egységgazdaságosságát.

A szakasz eredménye:

magas szintű termékhátralék;
megfogalmazott üzleti modell vagy skálahipotézis, amelyet a gyakorlatban még tesztelni kell.

Térjünk át a következő szakaszra - a koncepcióra. Itt mi, mérnökök, natív elemünkben találjuk magunkat. Léteznek „kívánságlisták”, amiket komponensekre/alrendszerekre/szolgáltatásokra bontanak, majd technikai specifikációkká/felhasználói történetekké, majd projektté stb. Nem foglalkozom részletesen az alternatív lehetőségek tömbjének elkészítésének folyamatával, térjünk át közvetlenül a követelményekre és a megvalósításukhoz választott módszerekre.

Követelmény
döntés

Nyílt monitoring rendszernek kell lennie;

Nyílt forráskódú felügyeleti rendszert alkalmazunk.

A rendszernek egyszerűnek és gyorsan telepíthetőnek kell lennie;
nem igényel speciális informatikai ismereteket. Még egy könyvelőnek is képesnek kell lennie a rendszer üzembe helyezésére és konfigurálására.

Telepített rendszert kínálunk, hogy a felhasználónak csak a készüléket kelljen bekapcsolnia és egy kicsit konfigurálnia, hasonlóan egy routerhez.

Zárjuk le az eszközzel való interakciót valami egyszerűre és mindenki számára érthetőre.

Írjunk saját chatbotot az egyik jól ismert azonnali üzenetküldőnek, és vigyük át rá a rendszerrel folytatott összes interakciót.

A rendszernek:

automatikusan észleli a megfigyeléshez szükséges objektumokat a hálózaton;
automatikusan telepíti a megfigyelő ügynököket;
Legyen képes külső szolgáltatások figyelésére, legalább egy CRM rendszerre és egy értékesítő weboldalra.

A felügyeleti rendszerhez kiegészítőket írunk:

automatikus tárgyérzékelés;
ügynökök automatikus telepítése;
külső szolgáltatások elérhetőségének ellenőrzése.

A rendszernek:

értesítse mind a vállalkozást, mind a rendszergazdát a problémákról;
képes legyen külső szolgáltatások figyelésére, legalább egy CRM rendszerre és egy értékesítő weboldalra. Az értesítések mélységének és „nyelvének” eltérőnek kell lennie az adminisztrátor és a vállalkozás számára.
A rendszer nem igényel speciális informatikai ismereteket, még egy könyvelőnek is képesnek kell lennie a rendszer telepítésére és konfigurálására.

Adjunk hozzá különböző típusú értesítéseket a különböző típusú felhasználók számára. Különböznek a magasságban és a mélységben. Az üzleti felhasználók olyan értesítéseket kapnak, mint „minden rendben van, de Ivanov számítógépe hamarosan meghal”. A rendszergazda teljes körű üzenetet kap a hibáról, ki, hogyan és mi történt vagy történhet.
Adjuk hozzá egy további felelős személy leveleinek használatának lehetőségét, hogy meghibásodás esetén üzenetet kapjon.
Adjuk hozzá a külső szolgáltatókkal való interakciót az előre elkészített szövegű e-mailek küldése alapján, mert Az e-mail az incidens oka.
Minden interakció a rendszerrel egy chatbothoz kapcsolódik, a kommunikáció párbeszédes stílusban történik.

kiegészítésére:

Adjuk hozzá a „csevegés a rendszergazdával” funkciót, hogy a felhasználó közvetlenül küldhessen üzenetet a rendszergazdának, amelyben leírja a problémát.

A rendszert saját hardveren kell szállítani.
A vasnak rendelkezésre kell állnia.
A rendszernek a lehető legnagyobb mértékben függetlennek kell lennie a környezettől.

Vegyünk egy kész és olcsó Raspberry PI számítógépet.
Szünetmentes tápegységet tervezünk.
Adjunk hozzá egy modemet, hogy független legyen a helyi hálózat állapotától.
Gyönyörű épületet tervezünk.

Jelenleg három alrendszerünk van, amelyek saját követelményeikkel és megvalósításukkal rendelkeznek:

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

Kidolgoztuk a hardver alrendszer előzetes tervét. Igen igen! Az agilis minden szabályát megszegve dokumentumot dolgoztunk ki, mivel a gyártó üzemek dokumentumokkal dolgoznak. A fennmaradó alrendszereknél azonosítottuk a felhasználókat (személyeket), elkészítettük a felhasználói történeteket, és feladatokat írtunk a fejlesztéshez.

Ezzel a koncepció szakasza lezárult, és az eredmény:

projekt hardverplatformhoz;
jövőképet fogalmazott meg felhasználói történetek formájában a fennmaradó két alrendszer számára;
virtuális gépként megvalósított szoftver prototípus;
a hardver prototípusa, állvány formájában megvalósítva, ahol ténylegesen tesztelték a hardvermegoldások szilárdságát;
adminisztrátoraink által végzett tesztelést.

A problémák ebben a szakaszban leginkább szervezési jellegűek voltak, és a mérnökök ismeretének hiányával kapcsolatosak az értékesítés jogi és számviteli vonatkozásaiban. Azok. Egy dolog kitalálni, hogy mit és hogyan adjunk el, és egy másik dolog egy kíméletlen jogi gépezet előtt állni: szabadalmak, fejlesztési feladatok, regisztráció, EULA és még sok minden, amivel mi, kreatív emberek kezdetben nem vettünk számításba.

Probléma még nem, inkább nehézség adódott a burkolatok kialakításához. Csapatunk csak mérnökökből áll, így a tok első változatát elektronikai szakemberünk plexiből „építette meg”.

A test enyhén szólva is ellentmondásosnak tűnt, különösen a közvélemény számára, amelyet a modern technológia rontott el. Természetesen voltak ínyencek a „Kulibins” idősebb generációja között – az épület nosztalgikus érzéseket váltott ki belőlük. A ház újbóli legyártása és tervezése mellett döntöttek, mivel a régiben az esztétikai hibákon kívül szerkezeti hibák is voltak - a plexi nem tűrte jól a készülék össze- és szétszerelését, és hajlamos volt megrepedni. A tok gyártásáról a továbbiakban mesélek.

És most közel vagyunk a célhoz - MVP. Természetesen ez még nem egy végtermék, de már hasznos és értékes. Ennek a szakasznak a fő célja a „teremtés-értékelés-tanulás” ciklus elindítása. Pontosan ebben a szakaszban van a LANBIX.

A „létrehozás” szakaszban létrehoztunk egy eszközt, amely végrehajtja a deklarált funkcionalitást. Igen, még nem tökéletes, és tovább dolgoztunk rajta.

Térjünk vissza a test gyártásához, i.e. arra a feladatra, hogy a készülékünket nosztalgikusból modernné alakítsuk. Kezdetben a szekrénygyártók és az ipari formatervezési szolgáltatások piacát jártam körbe. Először is, nincs sok cég, amely tokokat gyárt az orosz piacon, másrészt az ipari formatervezés költsége ebben a szakaszban rendkívül magas, körülbelül 1 millió rubel.

Megkeresték marketing osztályunkat a tervezéssel, a fiatal tervező készen állt a kreatív kísérletekre. Felvázoltuk a hajótestről alkotott elképzelésünket (korábban tanulmányoztuk a hajótest építésének legjobb példáit), ő pedig műalkotássá alakította. Már csak az előállítása van hátra. Terveinkre büszkén fordultunk partnereinkhez. A vezérigazgatójuk azonnal leverte a fantáziánkat azzal, hogy teljesen ingyenesen rámutatott olyan dolgokra, amelyeket a mi választott módon nem lehet előállítani. A tok legyártható, és semmivel sem lesz rosszabb, mint az Apple-é, de a tok ára három-négyszer drágább lesz, mint az összes elektronikus alkatrészé. Sorozatos műveletek és jóváhagyások után egy legyártható házat terveztünk. Igen, nem olyan szép, mint terveztük, de ideális a jelenlegi célok eléréséhez.

A szakasz eredménye: az első köteg eszközök harcra és tesztelésre készen.

És most a legnehezebb az „értékelés” szakasz, és termékünkkel pontosan ezen a ponton vagyunk. Csak a valós vásárlók általi használat eredményei alapján tudunk értékelni, és itt semmilyen feltételezés nem működik. Szükségünk van azokra a „korai alkalmazókra”, hogy visszajelzést adjanak, és végrehajtsák a valóban szükséges változtatásokat a terméken. Felmerül a kérdés: honnan szerezzünk vásárlókat, és hogyan lehet őket meggyőzni, hogy vegyenek részt a kísérletben?

Az összes lehetséges lehetőség közül a digitális eszközök klasszikus készletét választottuk: nyitóoldalt és hirdetési kampányt a közösségi hálózatokon.

A folyamat már elindult, de még korai eredményekről beszélni, pedig már vannak válaszok, és számos hipotézisünkre megerősítést kaptunk. Kellemes meglepetés volt a teljesen más üzleti szegmensek képviselőinek reakciója, sokkal nagyobb, mint amire számítottunk. Bolondság lenne figyelmen kívül hagyni az új bevezetőket, és az interjúk eredménye alapján úgy döntöttek, hogy LANBIX Enterprise néven elindítanak egy párhuzamos LANBIX vonalat. Hozzáadtuk az elosztott infrastruktúrák támogatását, a Wi-Fi hálózatok figyelését hibaelhárítással és lokalizációval, valamint a kommunikációs csatornák minőségének felügyeletét. A legnagyobb érdeklődést a szolgáltató cégek fejezték ki a megoldás iránt. A megoldások működésében ugyanakkor fontos szerepet játszanak a már általunk kifejlesztett eszközök.

Mi fog ezután történni

Hogy mi lesz ezután az eredeti LANBIX-szal, az a kampány eredményei alapján derül ki. Ha hipotéziseink nem igazolódnak be, a Lean módszertan szerint kíméletlenül megszabadulunk tőle, vagy valami újdonsággá alakul át, mert nincs rosszabb, mint olyan terméket készíteni, amire senkinek nincs szüksége. Most azonban elmondhatjuk, hogy az elvégzett munka nem volt hiábavaló, és ennek köszönhetően párhuzamos termékek egész ága jelent meg, amelyeken aktívan dolgozunk. Siker esetén a LANBIX az MVP szakaszból a végső szakaszba lép, és a termékmarketing érthető klasszikus törvényei szerint fog fejlődni.

Ismétlem, most szeretnénk korai alkalmazókat találni, olyan cégeket, amelyek telepíthetik termékünket, hogy visszajelzéseket gyűjtsenek. Ha érdekel a LANBIX tesztelése, írj kommentben vagy privát üzenetben.

Forrás

Forrás: will.com

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