🥇Jak pracujeme s nápady a jak se zrodil LANBIX

V LANIT-Integration je mnoho kreativních zaměstnanců. Nápady na nové produkty a projekty doslova visí ve vzduchu. Určit ty nejzajímavější může být někdy velmi obtížné. Proto jsme společně vyvinuli vlastní metodiku. Přečtěte si tento článek o tom, jak vybrat ty nejlepší projekty a realizovat je.

V Rusku i ve světě jako celku probíhá řada procesů, které vedou k transformaci IT trhu. Díky nárůstu výpočetního výkonu a nástupu serverových, síťových a dalších virtualizačních technologií trh již nepotřebuje velké množství hardwaru. Prodejci stále více preferují přímou spolupráci se zákazníky. IT trh zažívá boom outsourcingu ve všech jeho podobách, od klasického outsourcingu až po novou vlnu outsourcingů – „cloud providerů“. Systémy a prvky infrastruktury se mnohem snadněji udržují a konfigurují. Kvalita softwaru každým rokem roste a úkoly integrátora se transformují.

Jak pracujeme s nápady

Směr spuštění produktu v "LANIT-Integrace" existuje již více než rok. Naším hlavním cílem je vytvářet nové produkty a uvádět je na trh. První věcí, se kterou jsme začali, byla organizace procesu vytváření produktů. Prostudovali jsme mnoho metodik, od klasických až po hype. Žádný z nich však nevyhovoval našim potřebám. Poté jsme se rozhodli vzít za základ metodiku Lean Startup a přizpůsobit ji našim úkolům. Lean Startup je teorie podnikání vytvořená Ericem Riesem. Je založen na principech, přístupech a praktikách takových konceptů, jako je štíhlá výroba, zákaznický rozvoj a flexibilní metodika rozvoje.

Pokud jde o přímý přístup k řízení vývoje produktu: nevynalezli jsme znovu kolo, ale použili jsme již existující metodiku vývoje SKRUMÁŽ, přidává kreativitu a nyní to může být bezpečně nazýváno SCRUM-WATERFALL-BAN. SCRUM je i přes svou flexibilitu velmi rigidní systém a je vhodný pro řízení týmu odpovědného pouze za jeden produkt/projekt. Jak víte, klasické „integrační“ podnikání nezahrnuje přidělení technických specialistů na plný úvazek, aby pracovali na jednom projektu (existují výjimky, ale velmi zřídka), protože kromě práce na produktech jsou všichni zaneprázdněni aktuálními projekty. Ze SCRUM jsme převzali rozdělení práce na sprinty, denní reporting, retrospektivy a role. Pro tok úkolů jsme zvolili Kanban a dobře se integroval do našeho stávajícího systému sledování úkolů. Strukturovali jsme naši práci hladkou integrací do stávajícího řádu věcí.
Před vstupem na trh prochází produkt 5 fázemi: nápad, výběr, koncept, MVP (více podrobností níže) a výroba.

Nápad

V této fázi je cosi pomíjivého – nápad. V ideálním případě nápad na vyřešení stávajícího problému nebo problému klienta. O nápady nemáme nouzi. Podle prvotního plánu by je měli generovat pracovníci technických oblastí. Aby mohl být nápad přijat k dalšímu rozvoji, musí autor vyplnit „Šablonu návrhu nápadu“. Existují pouze čtyři otázky: Co? Proč? Kdo to potřebuje? A když ne náš produkt, tak co?

Zdroj

Výběr

Jakmile k nám dorazí vyplněná šablona, začíná procesní a výběrové řízení. Fáze výběru je nejnáročnější na práci. V této fázi se tvoří hypotézy problémů (ne nadarmo jsem v předchozím odstavci zmínil, že v ideálním případě by nápad měl vyřešit problém klienta) a hodnoty produktu. Vytvoří se hypotéza měřítka, tzn. jak bude naše podnikání růst a prosperovat. Problémové a expertní rozhovory jsou vedeny s potenciálními zákazníky, abychom poskytli předběžné potvrzení, že budeme vyrábět něco potřebného. K vyvození závěru o potřebnosti produktu je potřeba alespoň 10-15 rozhovorů.

Pokud se hypotézy potvrdí, provede se předběžná finanční analýza, posoudí se přibližný objem investice a možný zisk investora. V důsledku této fáze se zrodil dokument nazvaný Lean Canvas, který je představen managementu.

Koncepce

V této fázi je eliminováno asi 70 % nápadů. Pokud je koncept schválen, začíná fáze vývoje nápadu. Formuje se funkčnost budoucího produktu, určují se cesty implementace a optimální technická řešení a aktualizuje se obchodní plán. Výsledkem této etapy je technická specifikace pro vývoj a detailní obchodní případ. V případě úspěchu přecházíme do fáze MVP nebo MVP.

MVP nebo MVP

MVP je minimálně životaschopný produkt. Tito. produkt, který není plně vyvinut, ale již může přinášet hodnotu a plní svou funkčnost. Je nezbytné, abychom v této fázi vývoje shromažďovali zpětnou vazbu od skutečných uživatelů a prováděli změny.

Výroba

A úplně poslední fází je výroba. Do této fáze nedosáhne více než 5 % produktů. Těchto 5 % zahrnuje pouze ty nejdůležitější, nezbytné, životaschopné a funkční produkty.

Máme spoustu nápadů a již jsme sestavili rozsáhlé portfolio. Každý nápad analyzujeme a děláme vše pro to, aby se dostal do finální fáze. Je velmi příjemné, že naši kolegové nezůstali lhostejní k našemu R&D směřování a aktivně se podílejí na vývoji a implementaci produktů a řešení.

Jak jsme vyrobili LANBIX

Podívejme se na tvorbu produktu na reálném příkladu – produktu LANBIX. Jedná se o „krabicový“ softwarový a hardwarový systém navržený pro monitorování malých IT infrastruktur a rychlé upozorňování osob s rozhodovací pravomocí a podnikových uživatelů na poruchy řízené prostřednictvím chatbota. Kromě funkce monitorování LANBIX obsahuje funkci Help Desk. Tento produkt je exkluzivní pro segment trhu, na který se zaměřujeme. To je naše výhoda i bolest. Ale nejdřív. Hned řeknu, že LANBIX je živý produkt (to znamená, že ve svém vývoji není konečný a je v dalším kole MVP).

Takže první fází je nápad. Aby se zrodila myšlenka, potřebujete problémy a ty jsme měli my, respektive ne my, ale naši přátelé. Níže se podíváme na několik skutečných situací, ke kterým došlo v různých oblastech podnikání.

Malá správcovská společnost spravuje dva domy v Moskevské oblasti. Personál s PC je cca 15 lidí. Správce systému je hostující nezávislý pracovník (chytrý syn jednoho z pečujících obyvatel). Zdálo by se, že činnost správcovské společnosti je slabě závislá na IT, ale zvláštností tohoto podnikání je měsíční podávání zpráv mnoha úřadům. Na systémovém disku šéfa společnosti (který jako obvykle kombinuje mnoho rolí) došel volný prostor. To se přirozeně nestalo náhle, varování viselo asi 2 měsíce a bylo neustále ignorováno. Ale přišla aktualizace, OS byl aktualizován a podle štěstí uprostřed aktualizace zamrzl a před smrtí si stěžoval na zaneprázdněný disk. Počítač přešel do cyklického restartu. Zatímco jsme řešili problém a dostávali zprávy, zmeškali jsme termín nahlášení. Zdá se, že triviální porucha způsobila různé potíže: od ztrát po soudní spory a administrativní odpovědnost.

Zdroj

K podobnému incidentu došlo ve velké holdingové společnosti, sdružující mnoho malých společností, s jedinou službou technické podpory pro celou kancelář. V jednom z oddělení se porouchal počítač hlavní účetní. Už dlouho se vědělo, že se může rozbít (počítač se zoufale zpomaloval a zahříval), ale hlavní účetní se nikdy nedostal k tomu, aby poslal požadavek na technickou podporu. Přirozeně se to porouchalo přesně v den výplaty a zaměstnanci oddělení byli několik dní bez peněz.

Malý podnik v malém velkoobchodě měl prodejní web, který byl hostován na externím webu. O jeho nedostupnosti jsme se dozvěděli telefonicky od běžného zákazníka. V době hovoru byla stránka asi tři hodiny mimo provoz. Dalších pár hodin trvalo nalezení osoby odpovědné za web a další dvě hodiny, než se problém vyřešil. V důsledku toho byla stránka téměř celý pracovní den nedostupná. Podle obchodního ředitele společnosti je tento výpadek stál asi 1 milion rublů.

Sám jsem se s podobnou situací setkal, když jsem přišel na schůzku na klinice a musel jsem na VHI registraci. K lékaři mě nemohli poslat z triviálního důvodu – ráno došlo k výpadku proudu a po nehodě jim nefungovala pošta a určitá služba pro komunikaci s pojišťovnou. Na můj dotaz, kde jsou vaši admini, mi bylo řečeno, že jejich admin přichází a navštěvuje je jednou týdně. A teď (v tu dobu už bylo 16:00) nezvedá telefon. Minimálně 7 hodin byla klinika odříznuta od okolního světa a nemohla poskytovat placené služby.

Co mají všechny tyto případy společného? Naprosto všem problémům se dalo předejít předem. Díky včasné reakci od lidí z IT by bylo možné škody snížit. To by bylo možné, pokud by uživatelé včasné příznaky správně interpretovali.

Identifikovali jsme problémové hypotézy:

významné finanční ztráty a ztráty pověsti v důsledku nízké rychlosti reakce na chyby v infrastruktuře IT;
nesprávná interpretace časných příznaků poruchy uživateli.

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

najmout vysoce kvalifikovaného správce systému a nechat ho pracovat svědomitě;
outsourcovat údržbu IT specializované servisní společnosti;
nezávisle zavést systém monitorování a hlášení poruch;
poskytovat školení uživatelům/obchodním pracovníkům v základech počítačové gramotnosti.

Pojďme se spokojit s třetí možností. Nabídněme monitorovací systém těm, kteří jej z různých důvodů nepoužívají.

Lyrická odbočka. Různé systémy pro monitorování IT služeb na podnikovém trhu se používají již dlouhou dobu a jejich přínosy nejsou sporné. Mluvil jsem se zástupci velkých firem, podíval se na to, jak se budoval vztah mezi byznysem a IT. Technický ředitel jednoho velkého strojírenského podniku zadal údržbu IT infrastruktury externí firmě, ale sám zůstává o všem v povědomí. V jeho kanceláři visí velká obrazovka monitorovacího systému s indikátory stavu IT služeb. Ty nejkritičtější jsou součástí systému. Technický ředitel může každou chvíli zjistit, v jakém stavu je infrastruktura, co se děje, kde je problém, zda byli upozorněni odpovědní lidé a zda se problém řeší.

Výše uvedené příběhy přiměly náš tým přemýšlet o tom, jak vytvořit optimální monitorovací systém pro malé společnosti. V důsledku toho se zrodil LANBIX - monitorovací systém, který může nasadit úplně každý bez jakýchkoli IT znalostí. Hlavní cíl systému je jednoduchý, jako všechny systémy zaměřené na zvýšení kontinuity a dostupnosti – snížení peněžních a jiných ztrát v případě neplánovaných odstávek. Zařízení je navrženo tak, aby zkrátilo na minimum dobu mezi „něco je rozbité“ a „problém byl vyřešen“.

Pro potvrzení hypotéz byly provedeny problémové rozhovory. Nedokázal jsem si představit, kolik toho budou lidé ochotni říct, aniž by se jim snažili prodat. Každý rozhovor trval minimálně 1,5 hodiny a získali jsme spoustu informací užitečných pro další rozvoj.

Pojďme si shrnout výsledky této fáze:

existuje pochopení problému,
pochopení hodnoty – existuje,
Existuje nápad na řešení.

Druhá etapa byla podrobnější. Na základě jeho výsledků jsme museli předložit managementu, který v podstatě hraje roli investora, obchodní případ (totéž Lean Canvas), aby se rozhodlo o dalším osudu produktu.

Začali jsme průzkumem trhu a analýzou konkurence, abychom zjistili, kdo, co a hlavně jak si na tomto trhu vede.

Ukázalo se následující.

Na trhu nejsou žádné hotové krabicové monitorovací systémy pro náš segment (small business), s výjimkou pár nebo tří, o kterých nebudu z pochopitelných důvodů mluvit.
Našimi hlavními konkurenty jsou kupodivu správci systémů s podomácku psanými skripty a „doplňky“ k open-source monitorovacím systémům.
S používáním open source monitorovacích systémů je jasný problém. Existuje systém, existuje obrovské množství informací o tom, jak pracovat a upravovat systém tak, aby vyhovoval vašim potřebám. Mnozí z administrátorů, se kterými jsem mluvil, přiznali, že nemají dostatek kompetencí k tomu, aby své nápady realizovali sami. To ale vedení ze strachu z propuštění nemohou přiznat. Ukazuje se, že je to začarovaný kruh.

Poté jsme přešli k analýze potřeb našich potenciálních zákazníků. Identifikovali jsme pro sebe segment malých organizací, které z nějakého důvodu nemají vlastní IT službu, kde za IT zodpovídá buď správce příchozího systému, freelancer nebo servisní společnost. Nebyla to IT strana, která se rozhodla vstoupit, ale obchodní strana, která zakladatelům a majitelům firem nabídla nástroj ke zlepšení kvality služeb IT infrastruktury. Produkt, který by měl majitelům pomoci zabezpečit jejich podnikání, ale zároveň přidá práci lidem, kteří jsou za IT zodpovědní. Produkt, který firmám poskytuje nástroj pro sledování kvality IT podpory.

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

monitorovací systém musí být založen na open source řešení a v důsledku toho musí být levný;
snadná a rychlá instalace;
neměl by vyžadovat specifické znalosti v IT, i účetní (v žádném případě jsem nechtěl urazit zástupce této profese) by měl systém umět nasadit a nakonfigurovat;
měl by automaticky detekovat objekty pro monitorování v síti;
by měl automaticky (a ideálně automaticky) instalovat monitorovací agenty;
musí být schopen monitorovat externí služby, alespoň CRM systém a prodejní web;
měli by upozornit na problémy jak firmu, tak správce systému;
stupeň hloubky a „jazyk“ výstrah by se měl lišit pro správce a pro podnik;
systém musí být dodáván na vlastním hardwaru;
železo by mělo být co nejpřístupnější;
systém by měl být co nejvíce nezávislý na vnějších faktorech.

Dále byly kalkulovány investice do vývoje produktu (včetně mzdových nákladů na pracovníky technického oddělení). Byl připraven náčrt obchodního modelu a byla vypočtena jednotková ekonomika produktu.

Výsledek etapy:

produktové nevypořádání na vysoké úrovni;
formulovaný obchodní model nebo hypotéza měřítka, která ještě musí být otestována v praxi.

Přejděme k další fázi – konceptu. Zde se jako inženýři ocitáme ve svém rodném živlu. Existují „seznamy přání“, které jsou rozloženy na komponenty/subsystémy/funkce, poté jsou přeměněny na technické specifikace/příběhy uživatelů, poté na projekt atd. Nebudu se podrobně zabývat procesem přípravy řady alternativních možností, přejděme rovnou k požadavkům a zvoleným metodám jejich realizace.

Poptávka
rozhodnutí

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

Bereme open source monitorovací systém.

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

Nabízíme nainstalovaný systém, takže uživateli stačí zařízení zapnout a trochu nakonfigurovat, podobně jako u routeru.

Uzavřeme interakci se zařízením na něco jednoduchého a srozumitelného pro každého.

Pojďme si napsat vlastního chatbota pro některý ze známých instant messengerů a přenést do něj veškeré interakce se systémem.

Systém by měl:

automaticky detekovat objekty potřebné pro monitorování v síti;
automaticky nainstalovat monitorovací agenty;
Umět sledovat externí služby, minimálně CRM systém a prodejní web.

Píšeme doplňky pro monitorovací systém pro:

automatická detekce objektů;
automatická instalace agentů;
sledování dostupnosti externích služeb.

Systém by měl:

upozornit na problémy firmu i správce systému;
být schopen monitorovat externí služby, minimálně CRM systém a prodejní web. Stupeň hloubky a „jazyk“ oznámení by měl být odlišný pro správce a firmu.
Systém by neměl vyžadovat specifické IT znalosti, dokonce i účetní by měl být schopen systém nasadit a nakonfigurovat.

Přidejme různé typy upozornění pro různé typy uživatelů. Liší se roztečí a hloubkou. Firemní uživatel obdrží oznámení jako „vše je v pořádku, ale Ivanovův počítač brzy zemře“. Administrátor obdrží kompletní zprávu o chybě, kdo, jak a co se stalo nebo mohlo stát.
Přidejme možnost využít poštu další zodpovědné osoby, aby v případě poruchy dostala zprávu.
Přidejme interakci s externími poskytovateli služeb na základě odesílání emailů s předem připraveným textem, protože Je to e-mail, který dal podnět k incidentu.
Veškerá interakce se systémem bude napojena na chatbota, komunikace probíhá dialogovým stylem.

Dodatek:

Přidejme funkci „chat s administrátorem“, aby uživatel mohl poslat administrátorovi zprávu přímo popisující problém.

Systém musí být dodáván na vlastním hardwaru.
Železo musí být k dispozici.
Systém by měl být co nejvíce nezávislý na okolí.

Vezměme si hotový a levný počítač Raspberry PI.
Navrhneme desku zdroje nepřerušitelného napájení.
Přidejme modem, abychom byli nezávislí na stavu místní sítě.
Navrhneme krásnou budovu.

Nyní máme tři subsystémy s vlastními požadavky a vizí pro jejich implementaci:

hardwarový subsystém;
monitorovací subsystém;
podsystém interakce s uživatelem.

Vyvinuli jsme předběžný návrh hardwarového subsystému. Ano ano! Po porušení všech pravidel agilnosti jsme vyvinuli dokument, protože výrobní závody s dokumenty pracují. U zbývajících subsystémů jsme identifikovali uživatele (osoby), připravili uživatelské příběhy a napsali úkoly pro vývoj.

Tím končí fáze konceptu a výsledkem je:

projekt pro hardwarovou platformu;
formulovaná vize ve formě uživatelských příběhů pro zbývající dva subsystémy;
prototyp softwaru implementovaný jako virtuální stroj;
prototyp hardwaru realizovaný ve formě stojanu, kde byla hardwarová řešení skutečně testována na pevnost;
testování prováděné našimi administrátory.

Problémy v této fázi byly většinou organizační a souvisely s nedostatkem znalostí inženýrského personálu v právních a účetních aspektech prodeje. Tito. Jedna věc je přijít na to, co a jak prodávat, a druhá věc je čelit nelítostné právní mašinérii: patenty, vývojářské úkoly, registrace, EULA a mnoho dalšího, s čím jsme jako kreativní lidé zpočátku nepočítali.

Problém zatím nebyl, ale spíše obtíž spojená s návrhem krytů. Náš tým tvoří pouze inženýři, takže první verzi skříně „postavil“ z plexiskla náš specialista na elektroniku.

Karoserie vypadala mírně řečeno kontroverzně, zejména pro veřejnost, rozmazlená moderní technikou. Mezi starší generací „kulibínů“ se samozřejmě našli fajnšmekři - stavba v nich vyvolávala nostalgické pocity. Pouzdro bylo rozhodnuto vyrobit a navrhnout nově, jelikož to staré mělo kromě estetických vad i konstrukční - plexi špatně snášelo montáž a demontáž zařízení a mělo tendenci praskat. O výrobě pouzdra vám povím dále.

A už jsme blízko cíle – MVP. Samozřejmě to ještě není finální produkt výroby, ale už je užitečný a cenný. Hlavním cílem této fáze je spustit cyklus „vytvoř-vyhodnoť-uč se“. Přesně v této fázi se LANBIX nachází.

Ve fázi „vytvoření“ jsme vytvořili zařízení, které provádí deklarované funkce. Ano, ještě to není dokonalé a dál jsme na tom pracovali.

Vraťme se k výrobě karoserie, tzn. k úkolu přeměnit naše zařízení z nostalgického na moderní. Na začátku jsem hledal na trhu výrobce skříní a služby průmyslového designu. Za prvé, na ruském trhu není mnoho společností vyrábějících pouzdra a za druhé, náklady na průmyslový design jsou v této fázi neúměrně vysoké, asi 1 milion rublů.

Pro návrh oslovili naše marketingové oddělení, mladý designér byl připraven na kreativní experimenty. Nastínili jsme naši vizi trupu (předtím jsme studovali nejlepší příklady konstrukce trupu) a on z ní zase udělal umělecké dílo. Zbývá jen vyrobit. My, hrdí na svůj design, jsme se obrátili na naše partnery. Jejich generální ředitel okamžitě rozdrtil naše fantazie tím, že zcela zdarma poukázal na věci, které nelze vyrobit námi zvoleným způsobem. Pouzdro lze vyrobit a nebude o nic horší než Apple, ale náklady na pouzdro budou třikrát až čtyřikrát dražší než všechny elektronické součástky. Po řadě operací a schválení jsme navrhli pouzdro, které lze vyrobit. Ano, není to tak krásné, jak jsme plánovali, ale je to ideální pro dosažení současných cílů.

Výsledek etapy: první várka zařízení připravená k boji a testování.

A nyní je nejtěžší fáze „vyhodnocení“ a s naším produktem jsme přesně v tomto bodě. Hodnotit můžeme pouze na základě výsledků používání reálnými zákazníky a nefungují zde žádné domněnky. Potřebujeme, aby tito „první uživatelé“ poskytli zpětnou vazbu a provedli změny produktu, které jsou skutečně potřeba. Nabízí se otázka: kde získat zákazníky a jak je přesvědčit, aby se experimentu zúčastnili?

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

Proces již byl zahájen, ale je příliš brzy hovořit o výsledcích, ačkoli již existují odpovědi a obdrželi jsme potvrzení mnoha našich hypotéz. Příjemným překvapením byla reakce zástupců zcela jiných segmentů podnikání, mnohem větších, než jsme očekávali. Bylo by pošetilé nové představení ignorovat a na základě výsledků rozhovorů bylo rozhodnuto spustit paralelní řadu LANBIX s názvem LANBIX Enterprise. Přidali jsme podporu pro distribuované infrastruktury, monitorování Wi-Fi sítí s řešením problémů a lokalizací a sledování kvality komunikačních kanálů. Největší zájem o řešení projevily servisní společnosti. Při provozu řešení přitom hrají důležitou roli již vyvinutá zařízení.

Co se stane příště

Co bude dál s původním LANBIXem, se ukáže na základě výsledků kampaně. Pokud se naše hypotézy nepotvrdí, podle metodiky Lean se ho nemilosrdně zbavíme nebo se přemění v něco nového, protože není nic horšího, než vyrobit produkt, který nikdo nepotřebuje. Nyní už ale můžeme říci, že odvedená práce nebyla marná a díky ní se objevila celá větev paralelních produktů, na kterých aktivně pracujeme. V případě úspěchu se LANBIX posune z fáze MVP do fáze konečné a bude se vyvíjet podle srozumitelných klasických zákonitostí produktového marketingu.

Opakuji, nyní chceme najít první osvojitele, společnosti, které mohou nainstalovat náš produkt, abychom získali zpětnou vazbu. Pokud máte zájem LANBIX otestovat, napište do komentářů nebo soukromých zpráv.

Zdroj

Zdroj: www.habr.com

Jak pracujeme s nápady a jak se zrodil LANBIX