🥇Jak pracujemy nad pomysłami i jak powstał LANBIX

W „LANIT-Integracje” pracuje wielu kreatywnych pracowników. Pomysły na nowe produkty i projekty dosłownie unoszą się w powietrzu. Często bardzo trudno jest wyłonić te najciekawsze. Dlatego wspólnie opracowaliśmy naszą metodę. Jak wybrać najlepsze projekty i je zrealizować, przeczytaj w tym artykule.

W Rosji, a także na świecie, dzieje się szereg procesów, które prowadzą do transformacji rynku IT. Dzięki wzrostowi mocy obliczeniowych oraz pojawieniu się technologii serwerowej, sieciowej i innej wirtualizacji, rynek przestał potrzebować dużej ilości „sprzętu”. Wykonawcy coraz częściej wolą współpracować bezpośrednio z klientami. Na rynku IT rozwija się outsourcing w różnych jego formach, począwszy od klasycznego outsourcingu a kończąc na nowej fali wykonawców – „dostawcach chmurowych”. Systemy infrastrukturalne i ich elementy stają się znacznie prostsze w obsłudze i konfiguracji. Jakość oprogramowania rośnie z każdym rokiem, a zadania integratora się transformują.

Jak pracujemy z pomysłami

Kierunek startupów produktowych w „LANIT-Integracje” istnieje już od ponad roku. Naszym głównym celem jest tworzenie nowych produktów i wprowadzanie ich na rynek. Pierwszym krokiem, który podjęliśmy, było zorganizowanie samego procesu tworzenia produktów. Przeczytaliśmy wiele metodologii, zaczynając od klasycznych i kończąc na modnych. Jednak żadna z nich nie odpowiadała naszym potrzebom. Wówczas postanowiliśmy wziąć za podstawę metodologię Lean Startup i dostosować ją do naszych zadań. „Lean Startup” to teoria przedsiębiorczości stworzona przez Erica Riesa. Oparta jest na zasadach, podejściach i praktykach takich koncepcji jak lean manufacturing, customer development i zwinna metodologia tworzenia.

Jeśli chodzi o sam podejście do zarządzania rozwojem produktu: nie wymyśliliśmy roweru, lecz zastosowaliśmy już istniejącą metodologię rozwoju SCRUM, dodając kreatywność, można teraz śmiało nazwać ją SCRUM-WATERFALL-BAN. SCRUM, mimo swojej elastyczności, jest bardzo sztywnym systemem, odpowiednim do zarządzania zespołem odpowiedzialnym tylko za jeden produkt/projekt. Jak rozumiesz, klasyczny „integratorski” biznes nie przewiduje przydzielania specjalistów technicznych na pełny etat do pracy nad jednym projektem (wyjątki się zdarzają, ale są bardzo rzadkie), ponieważ poza pracą nad produktami wszyscy są zajęci bieżącymi projektami. Z SCRUM wzięliśmy podział pracy na sprinty, codzienną sprawozdawczość, retrospektywy i role. Do pracy z przepływem zadań wybraliśmy Kanban, który doskonale zintegrował się z naszym istniejącym systemem śledzenia zadań. Uporządkowaliśmy pracę, płynnie integrując się w już istniejący porządek rzeczy.
Zanim produkt trafi na rynek, przechodzi 5 etapów: pomysł, selekcja, koncepcja, MГП (więcej szczegółów - poniżej) oraz produkcja.

Idea

Na tym etapie mamy coś efemerycznego – pomysł. W idealnym przypadku to pomysł na rozwiązanie istniejącego problemu lub zadania klienta. Nie brakuje nam pomysłów. Zgodnie z początkową koncepcją powinny być one generowane przez pracowników działów technicznych. Aby pomysł mógł zostać zaakceptowany do dalszego rozwoju, autor musi wypełnić „Szablon do zgłaszania pomysłu”. Są tam tylko cztery pytania: Co? Po co? Komu to potrzebne? A jeśli to nie nasz produkt, to co?

Źródło

Selekcja

Gdy wypełniony szablon trafi do nas, rozpoczyna się procedura przetwarzania i selekcji. Etap selekcji jest najbardziej pracochłonny. Na tym etapie następuje formułowanie hipotez problemów (nie bez powodu w poprzednim akapicie wspomniałem, że idealnie pomysł powinien rozwiązywać problem klienta) oraz wartości produktu. Formułowana jest hipoteza skali, tzn. jak nasz biznes ma zamiar rosnąć i prosperować. Przeprowadza się wywiady problemowe i eksperckie z potencjalnymi klientami w celu wstępnego potwierdzenia, że zamierzamy produkować coś potrzebnego. Wymagane jest przeprowadzenie co najmniej 10-15 wywiadów, aby wyciągnąć wnioski o użyteczności produktu.

Jeśli hipotezy zostaną potwierdzone, dokonuje się wstępnej analizy finansowej, ocenia się przybliżony zakres inwestycji oraz możliwe zyski inwestora. W wyniku tego etapu powstaje dokument o nazwie Lean Canvas i jest prezentowany kierownictwu.

Koncepcja

Na tym etapie odrzuca się około 70% pomysłów. Jeśli koncepcja zostanie zatwierdzona, rozpoczyna się faza opracowywania pomysłu. Formułowane są funkcjonalności przyszłego produktu, określane są drogi realizacji i optymalne rozwiązania techniczne oraz aktualizowany jest plan biznesowy. Efektem tego etapu jest specyfikacja techniczna dla rozwoju oraz szczegółowy biznesplan. W przypadku sukcesu przechodzimy do etapu MŻP lub MVP.

MŻP lub MVP

MŻP to minimalny produkt gotowy do życia. Tzn. produkt, który nie jest jeszcze w pełni dopracowany, ale już może przynosić wartość i realizować swoje funkcje. Na tym etapie rozwoju obowiązkowo zbieramy feedback od rzeczywistych użytkowników i wprowadzamy zmiany.

Produkcja

Ostatni etap to produkcja. Do tego etapu dociera nie więcej niż 5% produktów. W te 5% wchodzą tylko najważniejsze, potrzebne, żywotne i funkcjonalne produkty.

Mamy wiele pomysłów, już zebrany został obszerny portfel. Analizujemy każdy pomysł i robimy wszystko, aby dotarł do finałowego etapu. Bardzo miło, że koledzy nie pozostali obojętni na nasze kierunki R&D i aktywnie uczestniczą w opracowywaniu i wdrażaniu produktów oraz rozwiązań.

Jak stworzyliśmy LANBIX

Rozważmy stworzenie produktu na rzeczywistym przykładzie — produkt LANBIX. Jest to „pudełkowy” kompleks sprzętowo-programowy, przeznaczony do monitorowania małych infrastruktur IT i szybkiego informowania odpowiedzialnych osób oraz użytkowników biznesowych o usterkach z zarządzaniem przez chatbota. Oprócz funkcji monitorowania LANBIX zawiera funkcjonalność Help Desk. Produkt ten jest ekskluzywny dla segmentu rynku, na który się ukierunkowaliśmy. To nasza przewaga, ale i ból. Ale wszystko po kolei. Od razu powiem, że LANBIX to żywy produkt (tzn. nie jest zakończony w swoim rozwoju i znajduje się na kolejnym etapie MVP).

A więc, pierwsza faza — pomysł. Aby pomysł mógł się zrodzić, potrzebne są problemy, a te mieliśmy, właściwie nie my, a nasi znajomi. Poniżej rozważymy kilka rzeczywistych sytuacji, które miały miejsce w różnych dziedzinach biznesu.

Mała firma zarządzająca obsługuje dwa budynki w obwodzie moskiewskim. Zespół pracowników używających komputerów liczy około 15 osób. Administrator systemu to freelancer, który przychodzi (bystry syn jednego z zaangażowanych mieszkańców). Można by pomyśleć, że działalność firmy zarządzającej niewiele zależy od IT, ale specyfika tego biznesu to miesięczne raportowanie dla wielu instytucji. Na dysku systemowym kierownika firmy (który zazwyczaj pełni wiele ról) skończyło się miejsce. Naturalnie, to nie zdarzyło się nagle, ostrzeżenie wisiało przez około 2 miesiące i było ciągle ignorowane. Jednak pojawiła się aktualizacja, system operacyjny się zaktualizował i, jak na złość, zawiesił się w trakcie aktualizacji, narzekając przed „śmiercią” na zajęty dysk. Komputer wszedł w cykliczne ponowne uruchamianie. Gdy zajmowali się problemem i szukali raportów, przekroczyli termin składania dokumentów. Wydawałoby się, że drobna usterka stała się przyczyną różnych nieprzyjemności: od strat finansowych po postępowania sądowe i odpowiedzialność administracyjną.

Źródło

Podobny przypadek zdarzył się w dużym holdingu łączącym wiele małych firm, z jedną wspólną obsługą techniczną dla całego biura. W jednym z działów zepsuł się komputer głównego księgowego. To, że może się zepsuć, było wiadomo od dawna (komputer desperacko się zaciął i przegrzewał), ale głównemu księgowemu w żaden sposób nie udało się wysłać zgłoszenia do wsparcia technicznego. Naturalnie, zepsuł się akurat w dniu wypłaty, a pracownicy działu przez kilka dni siedzieli bez pieniędzy.

W małej firmie zajmującej się handlem hurtowym padła strona sprzedażowa, która była hostowana na zewnętrznej platformie. O jej niedostępności dowiedziano się przez telefon od stałego klienta. W momencie telefonu strona nie działała już od około trzech godzin. Na poszukiwanie osoby odpowiedzialnej za stronę poszło jeszcze kilka godzin, na usunięcie usterki — dwa kolejne. W związku z tym, praktycznie przez cały dzień roboczy strona była niedostępna. Według słów dyrektora handlowego firmy, ten przestój kosztował ich około 1 miliona rubli.

Sam doświadczyłem podobnej sytuacji, gdy przyszedłem na wizytę w przychodni i musiałem trafić do rejestracji DMS. Nie mogli mnie odesłać do lekarza z banalnego powodu – rano nastąpił skok napięcia, a po awarii ich serwis pocztowy oraz pewien serwis do kontaktu z ubezpieczycielem nie działały. Na moje pytanie, gdzie są wasze administratory, powiedziano mi, że admin przychodzi raz w tygodniu. A teraz (w tamtym momencie była już 16:00) nie odbierał telefonu. Przychodnia była odcięta od zewnętrznego świata przez co najmniej 7 godzin i nie mogła świadczyć płatnych usług.

Co łączy wszystkie te przypadki? Absolutnie wszystkie problemy można było wcześniej zapobiec. Przy odpowiedniej reakcji ze strony osób obsługujących IT można było zminimalizować wyrządzone szkody. Byłoby to możliwe również przy poprawnej interpretacji wczesnych symptomów ze strony użytkowników.

Wydzieliliśmy hipotezy problemów:

znaczne straty finansowe i reputacyjne z powodu niskiej szybkości reakcji na usterki w infrastrukturze IT;
niepoprawna interpretacja wczesnych symptomów usterki przez użytkowników.

Co może zrobić z tym klient, i jak unikać podobnych sytuacji w przyszłości? Opcji nie jest wiele:

zatrudnić wysoko wykwalifikowanego administratora systemów na pełny etat i zmusić go do rzetelnej pracy;
przekazać obsługę IT wyspecjalizowanej firmie serwisowej;
samodzielnie wdrożyć system monitorowania i powiadamiania o usterkach;
przeprowadzić szkolenie dla użytkowników/personelu biznesowego w zakresie podstawowej obsługi komputera.

Zatrzymujemy się na trzeciej opcji. Proponujemy system monitorowania tym, którzy go nie stosują z różnych powodów.

Liryczne dygresje. Różne systemy monitorowania usług IT na rynku enterprise są używane od dawna, a ich wartość jest niekwestionowana. Rozmawiałem z przedstawicielami dużych firm, obserwowałem, jak są zorganizowane relacje między biznesem a IT. Dyrektor techniczny jednego z dużych przedsiębiorstw inżynieryjnych powierzył zarządzanie infrastrukturą IT zewnętrznej firmie, ale sam pozostaje na bieżąco ze wszystkimi sprawami. W swoim biurze ma duży ekran systemu monitorowania z wskaźnikami stanu usług IT. W systemie zostały uwzględnione najbardziej krytyczne. W każdej chwili dyrektor techniczny może sprawdzić, w jakim stanie jest infrastruktura, co się dzieje, w którym miejscu występuje problem, czy odpowiedzialne osoby zostały powiadomione, czy problem jest rozwiązywany.

Wszystkie te historie skłoniły naszą drużynę do zastanowienia się, jak stworzyć optymalny system monitorowania dla małych firm. W rezultacie powstał LANBIX - system monitorowania, który może wprowadzić dosłownie każda osoba bez wiedzy w zakresie IT. Głównym celem systemu jest prosta zasada, jak w każdym systemie ukierunkowanym na zwiększenie ciągłości i dostępności - zmniejszenie strat finansowych i innych w przypadku nieplanowanych przestojów. Urządzenie ma na celu maksymalne skrócenie czasu pomiędzy „coś mi się zepsuło” a „problem został rozwiązany”.

W celu potwierdzenia hipotez przeprowadzono wywiady problemowe. Nie mogłem sobie wyobrazić, ile ludzi jest gotowych powiedzieć, jeśli nie próbuję im sprzedawać. Każda rozmowa trwała co najmniej 1,5 godziny, i uzyskaliśmy mnóstwo informacji, które były użyteczne do dalszego rozwoju.

Podsumowując wyniki tego etapu:

zrozumienie problemu - jest,
zrozumienie wartości - jest,
pomysł na rozwiązanie - jest.

Drugi etap był bardziej szczegółowy. Na podstawie jego wyników mieliśmy przedstawić kierownictwu, które pełni rolę inwestora, biznesplan (ten sam Lean Canvas) w celu podjęcia decyzji dotyczącej przyszłości produktu.

Zaczęliśmy od badania rynku i analizy konkurencji, aby ustalić, kto, co i, co najważniejsze, jak działa w tym segmencie rynku.

Okazało się, że.

Na rynku nie ma gotowych systemów monitorowania w pudełku dla naszego segmentu (małych firm), za wyjątkiem kilku, o których z oczywistych powodów nie będę mówić.
Nasi główni konkurenci, co może się wydawać zaskakujące, to administratorzy systemów z samodzielnie napisanymi skryptami i „ulepszeniami” do systemów monitorowania z otwartym kodem źródłowym.
Jest oczywisty problem z używaniem systemów monitorowania z otwartym kodem źródłowym. Istnieje system, jest ogromna ilość informacji na temat pracy i dostosowywania systemu do własnych potrzeb. Wśród ankietowanych przeze mnie administratorów wielu przyznało, że brakuje im kompetencji do realizacji pomysłów własnymi siłami. A przyznać się do tego kierownictwu nie mogą z powodu obawy przed zwolnieniem. Tworzy się więc błędne koło.

Następnie przeszliśmy do analizy potrzeb naszych potencjalnych klientów. Wyodrębniliśmy segment małych organizacji, które z jakiegoś powodu nie mają własnej służby IT, gdzie za IT odpowiada lub przychodzący administrator systemów, lub freelancer, lub firma serwisowa. Zdecydowaliśmy się podejść do tematu nie od strony IT, a od strony biznesu, oferując założycielom i właścicielom biznesów narzędzie do poprawy jakości obsługi infrastruktury IT. Produkt, który ma pomóc właścicielom zabezpieczyć swój biznes, jednak w tym samym czasie doda pracy osobom odpowiedzialnym za IT. Produkt, który dostarcza biznesowi narzędzie do kontroli jakości wsparcia IT.

W wyniku przetwarzania zebranych danych powstała pierwsza lista wymagań (pewien wstępny backlog) dotyczących przyszłego produktu:

system monitorowania musi być oparty na rozwiązaniu z otwartym kodem źródłowym, a zatem tanim;
prosty i szybki w instalacji;
nie powinien wymagać specyficznej wiedzy w IT, nawet księgowy (ani w żadnym razie nie chciałem obrazić przedstawicieli tego zawodu) powinien być w stanie zainstalować i skonfigurować system;
powinien automatycznie wykrywać obiekty do monitorowania w sieci;
powinien automatycznie (a w idealnym przypadku automatycznie) instalować agentów monitorowania;
powinien mieć możliwość monitorowania zewnętrznych usług, przynajmniej systemu CRM i strony sprzedażowej;
powinien powiadamiać zarówno biznes, jak i administratora systemu o awariach;
głębokość i "język" powiadomień powinny być różne dla administratora i biznesu;
system powinien być dostarczany na własnym sprzęcie;
sprzęt powinien być maksymalnie dostępny;
System should be as independent as possible from external factors.

Next, investments for product development were calculated (including labor costs of the technical department employees). A sketch of the business model was prepared and the unit economics of the product was calculated.

Result of the stage:

high-level product backlog;
formulated business model or scale hypothesis that still needs to be tested in practice.

Let's move on to the next stage — the concept. Here, as engineers, we enter our native element. There are 'wants' that are decomposed into components/subsystems/features, which then turn into technical specifications/user stories, then into the project, and so on. I won’t go into detail on the process of preparing a set of alternative options; let's go straight to the requirements and selected methods for their implementation.

Requirement
Rozwiązanie

It must be an open monitoring system;

We take an open-source monitoring system.

The system should be easy and quick to install;
it should not require specific IT knowledge. Even an accountant should be able to deploy and configure the system.

We offer a pre-installed system so that the user only needs to turn on the device and configure it a bit, similar to a router.

Let's keep the interaction with the device simple and understandable for everyone.

We'll write our chat-bot for one of the popular messengers and direct all interaction with the system to it.

The system should:

automatically detect the required monitoring objects in the network;
automatically install monitoring agents;
Have the capability to monitor external services, at least CRM systems and the sales website.

We write add-ons for the monitoring system for:

automatic detection of objects;
automatic installation of agents;
monitoring the availability of external services.

The system should:

notify about malfunctions to both the business and the system administrator;
have the capability to monitor external services, at least CRM systems and the sales website. The depth and 'language' of notifications should be different for the admin and the business.
The system should not require specific IT knowledge; even an accountant should be able to deploy and configure the system.

Dodamy różne rodzaje powiadomień dla różnych typów użytkowników. Różnią się one formą i głębokością. Użytkownik biznesowy otrzyma powiadomienie typu „wszystko w porządku, ale komputer Kowalskiego niedługo się zepsuje”. Administrator otrzyma pełną wiadomość o błędzie, mówiącą, kto, jak i co się stało lub może się stać.
Dodamy możliwość korzystania z e-maila dodatkowej osoby odpowiedzialnej, aby w przypadku awarii otrzymała ona wiadomość.
Dodamy integrację z zewnętrznymi dostawcami usług na podstawie wysyłania e-maili z wcześniej przygotowanym tekstem, ponieważ to właśnie e-mail stanowi podstawę do założenia incydentu.
Cała interakcja z systemem zostanie zamknięta w czacie-bocie, a komunikacja będzie prowadzona w stylu dialogowym.

Uzupełnienie:

Dodamy funkcję „czatu z administratorem”, aby użytkownik mógł wysłać administratorowi wiadomość z opisem problemu bezpośrednio.

System musi być dostarczany na własnym sprzęcie.
Sprzęt musi być dostępny.
System musi być maksymalnie niezależny od otoczenia.

Weźmiemy gotowy i tani komputer Raspberry PI.
Zaprojektujemy płytę zasilania UPS.
Dodamy modem, aby być niezależnym od stanu lokalnej sieci.
Zaprojektujemy estetyczną obudowę.

Mamy trzy podsystemy z własnymi wymaganiami i wizjami ich realizacji:

podsystem sprzętowy;
podsystem monitorowania;
podsystem interakcji z użytkownikami.

Dla podsystemu sprzętowego opracowaliśmy szkic projektu. Tak, tak! Łamiąc wszystkie zasady zwinności, stworzyliśmy dokument, ponieważ fabryki działają właśnie z dokumentami. Dla pozostałych podsystemów określiliśmy użytkowników (osoby), przygotowaliśmy historie użytkowników i napisaliśmy zadania do opracowania.

Na tym etapie koncept kończy się, a jego rezultatem są:

projekt na platformę sprzętową;
sformułowana wizja w postaci historii użytkowników dla pozostałych dwóch podsystemów;
prototyp części programowej, zrealizowany w postaci wirtualnej maszyny;
prototyp części sprzętowej, zrealizowany w postaci stanowiska, na którym testowano wytrzymałość rozwiązań sprzętowych;
testy przeprowadzone przez naszych administratorów.

W tym etapie problemy były głównie organizacyjne i związane z niedostateczną wiedzą inżynierów w aspekcie prawnym i księgowym sprzedaży. Okazuje się, że wymyślenie, co i jak sprzedawać, to jedno, a zmierzenie się z bezwzględną machiną prawną, obejmującą patenty, zadania projektowe, ujęcie w bilansie, EULA i wiele innych kwestii, których jako twórcze osoby początkowo nie uwzględniliśmy — to całkiem co innego.

Nie był to jeszcze problem, a raczej trudność związana z projektowaniem obudów. W naszej drużynie są tylko inżynierowie, więc pierwszy wariant obudowy „stworzył” z pleksi nasz specjalista od elektroniki.

Obudowa wyglądała, delikatnie mówiąc, kontrowersyjnie, zwłaszcza dla publiczności przyzwyczajonej do nowoczesnych technologii. Znalazły się, oczywiście, osoby z pokolenia „kulińskich”, które doceniły ją — obudowa wzbudziła w nich nostalgiczne uczucia. Zdecydowano się na zaprojektowanie obudowy na nowo, ponieważ stara, oprócz estetycznych niedoskonałości, miała także konstrukcyjne — pleksi słabo znosiło montaż i demontaż urządzenia i było podatne na pęknięcia. O produkcji obudowy opowiem dalej.

I oto zbliżamy się do linii mety — MVP. Oczywiście, to jeszcze nie gotowy produkt seryjny, ale już przynosi korzyści i ma wartość. Głównym celem tego etapu jest uruchomienie cyklu „stwórz-ocenij-naucz się”. Właśnie na tym etapie znajduje się LANBIX.

Na etapie „stwórz” stworzyliśmy urządzenie, które wykonuje zadane funkcje. Tak, jeszcze nie jest idealne, a my wciąż nad nim pracujemy.

Wracamy do produkcji obudowy, czyli do zadania przekształcenia naszego urządzenia z nostalgicznego w nowoczesne. Na początku sprawdziłem rynek pod kątem producentów obudów i usług designu przemysłowego. Po pierwsze, na rosyjskim rynku jest niewiele firm produkujących obudowy, a po drugie, koszt designu przemysłowego na tym etapie jest niezmiernie wysoki, około 1 miliona rubli.

Projektowanie zlecono naszemu działowi marketingu, młody projektant był gotowy na twórcze eksperymenty. Przedstawiliśmy naszą wizję obudowy (wcześniej analizując najlepsze przykłady budowy obudów), a on z kolei zamienił ją w dzieło sztuki. Pozostało tylko wyprodukować. Z dumą z naszym projektem zwróciliśmy się do partnerów. Ich dyrektor generalny natychmiast zburzył nasze fantazje, całkowicie za darmo wskazując na rzeczy, które są niemożliwe do wyprodukowania wybranym przez nas sposobem. Obudowę można wyprodukować, i będzie nie gorsza niż u Apple, ale koszt jej produkcji będzie trzy lub cztery razy wyższy niż cała elektronika. Po serii działań i uzgodnień zaprojektowaliśmy obudowę, która może zostać wyprodukowana. Tak, już nie jest tak piękna, jak planowaliśmy, ale jest idealna do osiągnięcia bieżących celów.

Wynik etapu: pierwsza partia urządzeń gotowych do walki i testów.

A teraz najtrudniejszy etap — "ocena", i z naszym produktem jesteśmy właśnie w tym punkcie. Możemy oceniać tylko na podstawie wyników używania przez realnych klientów i żadne przypuszczenia tu nie działają. Potrzebujemy tych „wczesnych naśladowców”, aby uzyskać informacje zwrotne i wprowadzić te zmiany w produkcie, które są naprawdę potrzebne. Pojawia się pytanie: skąd wziąć klientów i jak ich przekonać do udziału w eksperymencie?

Spośród wszystkich możliwych opcji wybraliśmy klasyczny zestaw narzędzi cyfrowych: landing page i kampanię reklamową w mediach społecznościowych.

Proces już się rozpoczął, ale wciąż za wcześnie, aby mówić o wynikach, chociaż już otrzymaliśmy opinie i potwierdzenie wielu naszych hipotez. Miłym zaskoczeniem była reakcja przedstawicieli zupełnie innych segmentów biznesu, znacznie większych niż te, na które liczyliśmy. Ignorowanie nowych danych byłoby głupotą, a na podstawie przeprowadzonych wywiadów podjęto decyzję o uruchomieniu równoległej linii LANBIX pod nazwą LANBIX Enterprise. Dodaliśmy wsparcie dla rozproszonych infrastruktur, monitoring sieci Wi-Fi z lokalizacją i usuwaniem usterek, monitoring jakości łączy. Największe zainteresowanie rozwiązaniem wyrazili przedstawiciele firm serwisowych. Przy tym już opracowane przez nas urządzenia odgrywają niepoślednią rolę w realizacji rozwiązań.

Co będzie dalej

Co będzie dalej z pierwotnym LANBIX – stanie się jasne na podstawie wyników kampanii. W przypadku braku potwierdzenia naszych hipotez, zgodnie z metodologią Lean, bezlitośnie się go pozbędziemy lub przekształcimy w coś nowego, bo nic nie jest gorsze niż tworzenie produktu, który nikomu nie jest potrzebny. Ale już teraz można powiedzieć, że wykonana praca nie poszła na marne i dzięki niej powstała cała gałąź równoległych produktów, nad którymi aktywnie pracujemy. W przypadku sukcesu LANBIX przejdzie z etapu MVP do etapu końcowego i będzie rozwijać się zgodnie z klasycznymi zasadami marketingu produktowego.

Powtarzam, teraz chcemy znaleźć wczesnych zwolenników, firmy, którym możemy zainstalować nasz produkt w celu zbierania opinii. Jeśli jesteś zainteresowany przetestowaniem LANBIX, pisz w komentarzach lub wiadomościach prywatnych.

Źródło

Źródło: habr.com