🥇Jak pracujeme s nápady a jak vznikl LANBIX

Ve "LANIT-Integraci" máme mnoho kreativních zaměstnanců. Nápady na nové produkty a projekty doslova visí ve vzduchu. Někdy je velmi obtížné vybrat ty nejzajímavější. Proto jsme společnými silami vyvinuli naši vlastní metodiku. Jak vybrat nejlepší projekty a realizovat je, si přečtěte v tomto článku.

V Rusku i ve světě obecně probíhá několik procesů, které vedou k transformaci IT trhu. Díky nárůstu výpočetních výkonů a objevení technologií serverové, síťové a jiné virtualizace přestal trh potřebovat velké množství "železa". Dodavatelé stále častěji dávají přednost přímé spolupráci se zákazníky. Na IT trhu vzkvétá outsourcing ve všech jeho formách, počínaje klasickým outsourcingem a konče novou vlnou outsourcerů – "cloudovými poskytovateli". Infrastrukturní systémy a prvky se stávají podstatně jednoduššími na údržbu a nastavení. Kvalita softwaru roste každý rok a úkoly integrátora se transformují.

Jak pracujeme s nápady

Produktové startupové zaměření v „LANIT-Integraci“ existuje již více než rok. Naším hlavním cílem je vytváření nových produktů a jejich uvedení na trh. První, co jsme začali, bylo organizovat samotný proces tvorby produktů. Prostudovali jsme mnoho metodologií, od klasických až po trendy. Žádná z nich však nevyhovovala našim požadavkům. Tak jsme se rozhodli vzít za základ metodologii Lean Startup a přizpůsobit ji našim potřebám. „Běžný startup“ – teorie podnikání, kterou vytvořil Eric Ries. Jejím základem jsou principy, přístupy a praxe takových konceptů, jako je štíhlá výroba, customer development a flexibilní metodologie vývoje.

Pokud jde přímo o přístup k řízení vývoje produktu: nevynalézali jsme kolo, ale využili jsme již existující metodologii vývoje SCRUM, přidáním kreativity, a nyní ji lze směle nazvat SCRUM-WATERFALL-BAN. SCRUM, i přes svou flexibilitu, je velmi rigidní systém a hodí se pro řízení týmu, který odpovídá pouze za jeden produkt/projekt. Jak chápete, klasický „integrační“ byznys nepředpokládá vyčlenění technických specialistů na plný úvazek pro práci na jednom projektu (výjimky existují, ale velmi zřídka), protože kromě práce na produktech jsou všichni zaměstnaní na aktuálních projektech. Z SCRUMu jsme převzali dělení práce na sprinty, každodenní reportování, retrospektivy a role. Pro práci s tokem úkolů jsme zvolili Kanban, který se skvěle integroval do našeho stávajícího systému sledování úkolů. Práci jsme uspořádali plynule, integrujíc se do již existujícího pořádku věcí.
Než se produkt dostane na trh, prochází pěti fázemi: nápad, výběr, koncept, MŽP (podrobnosti — níže) a výroba.

Nápad

V této fázi je něco efemérního – nápad. Ideálně nápad na řešení existujícího problému nebo úkolu klienta. Nápadů máme dostatek. Podle původního záměru by je měli generovat zaměstnanci technických oborů. Aby byl nápad přijat do dalšího vývoje, autor musí vyplnit „Šablonu pro zpracování nápadu“. Tam jsou pouze čtyři otázky: Co? Proč? Komu to potřebuje? A pokud to není náš produkt, co tedy?

Zdroj

Výběr

Jakmile se vyplněná šablona dostane k nám, začne procedura zpracování a selekce. Fáze výběru je nejpráci náročnější. V této fázi dochází k formulaci hypotéz problémů (ne nadarmo jsem v předchozím odstavci zmínil, že ideálně by nápad měl řešit problém klienta) a hodnoty produktu. Formuje se hypotéza měřítka, tj. jak se náš byznys chystá růst a prospívat. Provádějí se problematické a expertní rozhovory s potenciálními zákazníky pro předběžné potvrzení toho, že se chystáme vyrábět něco potřebného. Je zapotřebí alespoň 10-15 rozhovorů, abychom došli k závěru o potřebnosti produktu.

Pokud jsou hypotézy potvrzeny, provádí se předběžná finanční analýza, odhaduje se přibližný objem investic a možný zisk investora. V důsledku této fáze vzniká dokument s názvem Lean Canvas a je předložen vedení.

Koncept

V této fázi se odfiltruje přibližně 70 % nápadů. Pokud je koncept schválen, začne fáze rozpracování myšlenky. Formulují se funkční možnosti budoucího produktu, určují se cesty realizace a optimální technická řešení, aktualizuje se obchodní plán. Výsledkem této fáze je technické zadání pro vývoj a podrobný obchodní případ. V případě úspěchu přecházíme do fáze MŽP nebo MVP.

MŽP nebo MVP

MŽP je minimálně životaschopný produkt. Tedy produkt, který není plně dokončen, ale již může přinášet hodnotu a plní své funkce. V této fázi vývoje sbíráme zpětnou vazbu od skutečných uživatelů a provádíme změny.

Výroba

A poslední fáze — výroba. Tohoto stádiu dosáhne ne více než 5 % produktů. Do těchto 5 % patří pouze ty nejdůležitější, potřebné, životaschopné a funkční produkty.

Máme mnoho nápadů, již jsme nasbírali objemné portfolio. Analyzujeme každý nápad a děláme vše pro to, aby se dostal do finální fáze. Je velmi potěšující, že kolegové nezůstali lhostejní k našemu R&D směru a aktivně se účastní vývoje, realizace produktů a řešení.

Jak jsme vytvořili LANBIX

Podívejme se na vytvoření produktu na skutečném příkladu — produktu LANBIX. Je to 'boxované' hardwarově-softwarové řešení určené pro monitorování malých IT infrastruktur a okamžité informování odpovědných osob a obchodních uživatelů o poruchách s řízením přes chat-bota. Kromě funkce monitorování zahrnuje LANBIX také funkci Help Desk. Tento produkt je exkluzivní pro segment trhu, na který se zaměřujeme. To je naše výhoda i naše bolest. Ale o všem postupně. Hned řeknu, že LANBIX je živý produkt (tj. není definitivní ve svém vývoji a nachází se na další úrovni MVP).

A tak, první fáze — myšlenka. Aby vznikla myšlenka, jsou potřeba problémy, a ty jsme měli, přesněji řečeno, naši známí. Níže prozkoumáme několik skutečných situací, které se staly v různých oblastech podnikání.

Malá správcovská společnost spravuje dva domy v Moskevské oblasti. Počet zaměstnanců s počítačem činí přibližně 15 osob. Systémový administrátor je externí freelancer (bystrý syn jednoho z angažovaných nájemníků). Na první pohled se může zdát, že činnost správcovské společnosti má jen slabou vazbu na IT, ale specifikum tohoto podnikání je měsíční vykazování před mnoha institucemi. Na systémovém disku šéfa společnosti (který obvykle kombinuje mnoho rolí) došlo k vyčerpání volného místa. Samozřejmě, že se to nestalo náhle, varování se objevovalo asi 2 měsíce a bylo neustále ignorováno. Avšak přišlo aktualizace, operační systém se obnovil a, jak na potvoru, zamrzl uprostřed aktualizace, stěžujíc si před „smrtí“ na obsazený disk. Počítač se ocitl v nekonečné smyčce restartování. Když se řešily problémy a vytahovaly zprávy, zmeškali termín pro podání vykazování. Na první pohled banální porucha se stala příčinou různých nepříjemností: od ztrát až po soudní řízení a správní odpovědnost.

Zdroj

Podobný případ se stal ve velkém holdingu, který sdružuje mnoho malých firem, s centralizovanou technickou podporou pro celou kancelář. V jednom z oddělení se rozbil počítač hlavní účetní. To, že se může rozbít, bylo známo už dlouho (počítač zoufale zpomaloval a přehříval se), ale ruce hlavní účetní se nějak nedostávaly k tomu, aby poslaly žádost o podporu. Samozřejmě, že se rozbil zrovna v den výplaty, a zaměstnanci oddělení několik dní seděli bez peněz.

Malý podnik zabývající se maloobchodním prodejem měl výpadek prodejního webu, který byl hostován na externí platformě. O jeho nedostupnosti se dozvěděli telefonicky od stálého zákazníka. V okamžiku telefonátu byl web nedostupný již asi tři hodiny. Hledání osoby odpovědné za web zabralo ještě pár hodin, oprava závady další dvě. V důsledku toho byl web prakticky celý pracovní den nedostupný. Podle obchodního ředitele společnosti je tato prostoj stála přibližně 1 milion rublů.

Sám jsem se setkal s podobnou situací, když jsem přišel na návštěvu do polikliniky a měl jsem se dostat na registraci DMS. K lékaři mě nemohli poslat z banálního důvodu – ráno došlo k přepětí a po této havárii jejich poštovní služba a určená služba pro komunikaci se pojišťovnou nefungovaly. Na moji otázku, kde jsou vaši administrátoři, mi bylo řečeno, že administrátor k nim přichází jednou týdně. A teď (v tu chvíli bylo už 16:00) neodpovídá na telefon. Minimálně 7 hodin byla poliklinika odříznuta od vnějšího světa a nemohla poskytovat placené služby.

Co spojuje všechny tyto případy? Všechny problémy bylo možné předem předejít. Při včasné reakci ze strany IT služeb by bylo možné snížit způsobenou škodu. To by bylo možné i při správné interpretaci raných příznaků ze strany uživatelů.

Identifikovali jsme hypotézy problémů:

významné finanční a reputační ztráty kvůli nízké rychlosti reakce na poruchy v IT infrastruktuře;
nesprávná interpretace raných příznaků poruchy ze strany uživatelů.

Co s nimi může udělat zákazník a jak se v budoucnu vyhnout podobným situacím? Možností není mnoho:

získat vysoce kvalifikovaného systémového administrátora na plný úvazek a donutit ho pracovat poctivě;
předat údržbu IT specializované servisní společnosti;
sami implementovat systém sledování a upozorňování na poruchy;
uskutečnit školení uživatelů/biznesových pracovníků o základech počítačové gramotnosti.

Zastavíme se u třetí možnosti. Pojďme nabídnout systém sledování těm, kteří jej z různých důvodů nepoužívají.

Lyrické odbočení. Různé systémy monitorování IT služeb na enterprise trhu se používají již dlouho a jejich přínos není zpochybňován. Mluvil jsem se zástupci velkých společností a sledoval, jak jsou nastaveny vztahy mezi byznysem a IT. Technický ředitel jednoho velkého strojírenského podniku svěřil údržbu IT infrastruktury externí firmě, ale sám zůstává v obraze. Ve své kanceláři má velkou obrazovku monitorovacího systému se stavy indikátorů IT služeb. Do systému jsou zavedeny ty nejkritičtější. Kdykoli může technický ředitel zjistit, v jakém stavu je infrastruktura, co se děje, kde je problém, zda byli informováni odpovědní lidé a zda se problém řeší.

Zmiňované příběhy přiměly náš tým zamyslet se nad tím, jak vytvořit optimální monitoringový systém pro malé firmy. Výsledkem se stal LANBIX — monitorovací systém, který může nasadit skutečně kdokoli bez znalosti IT. Hlavním cílem systému je jednoduché, jak je to u všech systémů zaměřených na zajištění kontinuity a dostupnosti — snížení finančních a dalších ztrát v případě neplánovaných výpadků. Zařízení má za úkol minimalizovat čas mezi „mám nějaký problém“ a „problém je vyřešen“.

Pro ověření hypotéz byla provedena problémová interview. Nedokázal jsem si představit, kolik toho lidé jsou ochotni říct, pokud se nesnažíte jim něco prodat. Každý rozhovor trval minimálně 1,5 hodiny a získali jsme spoustu informací, které byly užitečné pro další vývoj.

Shrňme výsledek této fáze:

pochopení problému — je,
pochopení hodnoty — je,
nápad na řešení — je.

Druhá fáze byla podrobnější. Na základě jejích výsledků jsme měli předložit vedení, které prakticky vykonává roli investora, obchodní plán (ten správný Lean Canvas), aby se rozhodlo o dalším osudu produktu.

Začali jsme výzkumem trhu a konkurenční analýzou s cílem zjistit, kdo, co a, co je nejdůležitější, jak na tomto trhu funguje.

Zjistilo se následující.

Na trhu neexistují hotové krabicové monitorovací systémy pro náš segment (malé podniky), kromě pár, o kterých nebudu z pochopitelných důvodů hovořit.
Našimi hlavními konkurenty, jak se zdá, jsou systémoví administrátoři s vlastnoručně psanými skripty a "vylepšeními" k systémům monitorování s otevřeným zdrojovým kódem.
Jasně se ukazuje problém s používáním systémů monitorování s otevřeným zdrojovým kódem. Existuje systém, je zde obrovské množství informací o práci a úpravách systému podle vlastních potřeb. Mnoho oslovených administrátorů přiznalo, že jim chybí kompetence na realizaci svých plánů. A přiznat to vedení se bojí kvůli strachu z propuštění. Vzniká tak zakletý kruh.

Poté jsme přešli k analýze potřeb našich potenciálních zákazníků. Vymezili jsme si segment malých organizací, z nějakého důvodu nemající vlastní IT oddělení, kde se o IT stará buď externí systémový administrátor, nebo freelancer, nebo servisní firma. Rozhodli jsme se přistoupit k věci ne z pohledu IT, ale z pohledu podnikání, nabízející zakladatelům a vlastníkům podniků nástroj pro zlepšení kvality obsluhy IT infrastruktury. Produkt, který by měl pomoci vlastníkům zabezpečit jejich byznys, ačkoli zároveň přidá práci lidem, kteří za IT odpovídají. Produkt, který poskytuje podnikání nástroj pro kontrolu kvality IT podpory.

V důsledku zpracování získaných dat se zrodil první seznam požadavků (jakýsi hrubý backlog) na budoucí produkt:

systém monitorování musí být založen na řešení s otevřeným zdrojovým kódem a tudíž levným;
musí být jednoduchý a rychlý na instalaci;
neměl by vyžadovat specifické IT znalosti, dokonce ani účetní (ani v nejmenším nechtěl urazit zástupce této profese) by měl být schopen systém nasadit a nastavit;
má automaticky detekovat objekty pro monitorování v síti;
musí automatizovaně (a ideálně automaticky) instalovat monitorovací agenty;
musí mít možnost monitorování externích služeb, minimálně CRM systém a prodejní web;
musí upozorňovat na problémy jak byznys, tak systémové administrátory;
hloubka a "jazyk" upozornění musí být různé pro administrátora a byznys;
systém musí být dodáván na vlastním hardwaru;
hardware musí být co nejdostupnější;
Systém by měl být maximálně nezávislý na vnějších faktorech.

Dále byly vypočteny investice do vývoje produktu (včetně pracovních nákladů zaměstnanců technického oddělení). Byl vypracován návrh obchodního modelu a spočítána jednotková ekonomika produktu.

Výsledek etapy:

vysoceúrovňový backlog produktu;
formulovaný obchodní model nebo hypotéza o měřítku, kterou je ještě třeba ověřit v praxi.

Přejdeme k další etapě — konceptu. Zde se jako inženýři dostáváme do naší vlasti. Existují „přání“, která se dekomponují na komponenty/podsysémy/funkce, poté se promění v technické specifikace/použivatelské příběhy, a dále v projekt atd. Nebudu se podrobněji zabývat procesem přípravy množství alternativních variant, přejděme rovnou k požadavkům a vybraným způsobům jejich realizace.

Požadavek
Řešení

Měla by to být otevřená monitorovací systém;

Bereme monitorovací systém s otevřeným zdrojovým kódem.

Systém by měl být jednoduchý a rychlý na instalaci;
neměl by vyžadovat specifické znalosti v IT. I účetní by měl být schopen systém nasadit a nastavit.

Nabízíme předinstalovaný systém, aby uživateli stačilo pouze zapnout zařízení a trochu ho nastavit, podobně jako u routeru.

Udržme interakci s zařízením na něčem jednoduchém a srozumitelném pro všechny.

Napíšeme svého chatbota pro jeden z známých messengerů a veškerou interakci se systémem přivedeme na něj.

Systém by měl:

automaticky detekovat objekty určené k monitorování v síti;
automaticky instalovat monitorovací agenty;
Mít možnost monitorování externích služeb, minimálně CRM systému a prodejního webu.

Píšeme dodatky pro monitorovací systém ohledně:

automatického detekování objektů;
automatické instalaci agentů;
monitorování dostupnosti externích služeb.

Systém by měl:

informovat o poruchách jak podnik, tak systémového administrátora;
Mít možnost monitorování externích služeb, minimálně CRM systému a prodejního webu. Úroveň hloubky a „jazyk“ oznámení by měl být různý pro administrátora a podnik.
Systém nesmí vyžadovat specifické znalosti v IT, i účetní by měl být schopen systém nasadit a nastavit.

Přidáme různé typy oznámení pro různé typy uživatelů. Liší se způsobem podání a hloubkou. Obchodní uživatel obdrží oznámení ve formátu "všechno je v pořádku, ale počítač Ivana brzy zemře". Správce obdrží úplné chybové hlášení, kdo, jak a co se stalo nebo může stát.
Přidáme možnost použití e-mailu dodatečné odpovědné osoby, aby v případě poruchy obdržela zprávu.
Přidáme integraci s externími poskytovateli služeb na základě zasílání e-mailů s předem připraveným textem, protože právě e-mail zakládá vznik incidentu.
Všechny interakce se systémem uzavřeme na chatbot, komunikace probíhá ve stylu dialogu.

Doplňující informace:

přidáme funkčnost "chatu se správcem", aby uživatel mohl přímo poslat správci zprávu s popisem problému.

Systém by měl být dodáván na vlastním hardwaru.
Hardware by měl být dostupný.
Systém by měl být co nejvíce nezávislý na prostředí.

Zvolíme hotový a levný počítač Raspberry PI.
Navrhneme desku pro nepřerušované napájení.
Přidáme modem pro nezávislost na stavu místní sítě.
Navrhneme hezký kryt.

Máme tři pod systémy se svými požadavky a viděním jejich realizace:

pod systém hardwaru;
pod systém monitorování;
pod systém uživatelské interakce.

Pro pod systém hardwaru jsme vypracovali skicový projekt. Ano, ano! Porušili jsme všechna pravidla agilního přístupu, protože výrobci pracují právě s dokumenty. Pro ostatní pod systémy jsme určili uživatele (persony), připravili uživatelské příběhy a napsali úkoly pro vývoj.

Na tomto etapě koncept končí a jeho výsledkem jsou:

projekt na hardwarovou platformu;
formulovaný vizi ve formě uživatelských příběhů pro další dvě pod systémy;
prototyp softwarové části realizovaný ve formě virtuálního stavu;
prototyp hardwarové části realizovaný ve formě stojanu, kde jsme vlastně testovali odolnost hardwarových řešení;
testování provedené našimi administrátory.

Problémy v této fázi byly většinou organizační a souvisely s nedostatečnými znalostmi inženýrského týmu v právních a účetních aspektech prodeje. Tedy, je jedna věc vymyslet, co a jak prodávat, a úplně jiná věc se setkat s neúprosným právním aparátem: patenty, zadání na vývoj, přehodnocení, EULA a mnoha jinými věcmi, které jsme jako tvůrčí lidé původně nezohlednili.

Ještě to nebyl problém, spíše obtíž, která souvisela s návrhem skříně. V našem týmu byli pouze inženýři, takže první verzi skříně „vytvořil“ z akrylu náš odborník na elektroniku.

Skříň vypadala, mírně řečeno, sporně, zejména pro publikum zvyklé na moderní technologie. Samozřejmě se našli obdivovatelé mezi „kuličkami“ starší generace — skříň v nich vzbudila nostalgické pocity. Bylo rozhodnuto vyrobit a navrhnout skříň znovu, protože stará měla kromě estetických nedostatků také konstrukční — akryl špatně snášel montáž a demontáž zařízení a měl tendenci se trhat. O výrobě skříně povím více dále.

A jsme na konci — MVP. Samozřejmě, že to ještě není konečný sériový produkt, ale už přináší užitek a má hodnotu. Hlavním cílem této fáze je spuštění cyklu „vytvořit – zhodnotit – poučit se“. Právě v této fázi se nachází LANBIX.

Ve fázi „vytvořit“ jsme vytvořili zařízení, které plní deklarovaný funkční cíl. Ano, není ještě dokonalé a my na něm pokračujeme v práci.

Vracíme se k výrobě skříně, tedy k úkolu proměnit naše zařízení z nostalgií vzbuzujícího do moderního. Na začátku jsem prozkoumal trh ohledně výrobců skříní a poskytovatelů služeb průmyslového designu. Zaprvé, firem, které vyrábějí skříně, je na ruském trhu velmi málo, a zadruhé, náklady na průmyslový design v této fázi jsou nepřiměřeně vysoké, kolem 1 milionu rublů.

Na design jsme se obrátili na naše oddělení marketingu, mladý designér byl připraven na kreativní experimenty. Vyjádřili jsme svou vizi korpusu (předem jsme prostudovali nejlepší vzorky konstrukce korpusů) a on ji na oplátku přetvořil na umělecké dílo. Zůstávalo už jen vyrobit. My, pyšní na svůj design, jsme oslovili naše partnery. Jejich generální ředitel okamžitě zbořil naše fantazie a zcela zdarma nám ukázal na věci, které nelze vyrobit zvoleným způsobem. Korpus vyrobit lze a nebude horší než u Apple, ale cena korpusu bude třikrát až čtyřikrát vyšší než celá elektronická výplň. Po řadě operací a schvalování jsme navrhli korpus, který může být vyroben. Ano, už není tak krásný, jak jsme plánovali, ale je ideální pro dosažení aktuálních cílů.

Výsledek fáze: první dávka zařízení, připravených k boji a testům.

A teď to nejtěžší — fáze "ocenit", a s naším produktem jsme přesně v tomto bodě. Můžeme hodnotit pouze podle výsledků používání skutečnými zákazníky a žádné předpoklady tu nefungují. Potřebujeme právě ty "brzké následovníky" pro poskytnutí zpětné vazby a provedení těch změn v produktu, které jsou opravdu nutné. Vzniká otázka: kde brát zákazníky a jak je přesvědčit, aby se zúčastnili experimentu?

Ze všech možných variant jsme vybrali klasickou sadu digitálních nástrojů: landing page a reklamní kampaň na sociálních sítích.

Proces už byl zahájen, ale zatím je brzy hovořit o výsledcích, i když reakce už jsou a my jsme dostali potvrzení mnoha našich hypotéz. Příjemným překvapením byla reakce zástupců zcela jiných segmentů byznysu, mnohem větší než ty, na které jsme spoléhali. Bylo by hloupé ignorovat nové vstupy, a na základě výsledků provedených rozhovorů bylo rozhodnuto o spuštění paralelní řady LANBIX nazvané LANBIX Enterprise. Přidali jsme podporu distribuovaných infrastruktur, monitoring Wi-Fi sítí s vyhledáváním a lokalizací chyb, monitoring kvality komunikačních kanálů. Největší zájem o řešení projevily servisní společnosti. Přitom už vyvinutá zařízení hrají v pracovních řešeních nemalou roli.

Co se bude dít dál

Co se bude dít dál s původním LANBIX — ukáže čas na základě výsledků kampaně. Pokud naše hypotézy nebudou potvrzeny, podle metodologie Lean se ho zbavíme, nebo se transformuje na něco nového, protože není nic horšího než vytvářet produkt, který nikomu není potřeba. Ale už nyní je jasné, že vykonaná práce nebyla zbytečná a díky ní vznikla celá řada paralelních produktů, na kterých aktivně pracujeme. V případě úspěchu LANBIX přejde ze stádií MVP do konečné fáze a bude se vyvíjet podle známých klasických zákonů produktového marketingu.

Ještě jednou, nyní hledáme rané následovníky, firmy, kterým můžeme nasadit náš produkt za účelem sběru zpětné vazby. Pokud máte zájem o testování LANBIX, napište do komentářů nebo osobních zpráv.

Zdroj

Zdroj: habr.com