🥇Jak pracujemy z pomysłami i jak narodził się LANBIX

W LANIT-Integration pracuje wielu kreatywnych pracowników. Pomysły na nowe produkty i projekty dosłownie wiszą w powietrzu. Czasami zidentyfikowanie tych najciekawszych może być bardzo trudne. Dlatego wspólnie opracowaliśmy własną metodologię. Przeczytaj ten artykuł, jak wybrać najlepsze projekty i je wdrożyć.

W Rosji, jak i na całym świecie, zachodzi szereg procesów prowadzących do transformacji rynku IT. Dzięki wzrostowi mocy obliczeniowej oraz pojawieniu się technologii wirtualizacji serwerów, sieci i innych, rynek nie potrzebuje już dużej ilości sprzętu. Sprzedawcy coraz częściej preferują bezpośrednią współpracę z klientami. Rynek IT przeżywa boom na outsourcing we wszystkich jego formach, od klasycznego outsourcingu po nową falę outsourcerów – „dostawców chmury”. Systemy i elementy infrastruktury stają się znacznie łatwiejsze w utrzymaniu i konfiguracji. Jakość oprogramowania rośnie z roku na rok, a zadania integratora ulegają transformacji.

Jak pracujemy z pomysłami

Kierunek uruchomienia produktu w „LANIT-Integracja” istnieje już od ponad roku. Naszym głównym celem jest tworzenie nowych produktów i wprowadzanie ich na rynek. Pierwszą rzeczą, od której zaczęliśmy, było uporządkowanie procesu tworzenia produktów. Przestudiowaliśmy wiele metodologii, od klasycznych po modne. Jednak żaden z nich nie spełniał naszych potrzeb. Następnie postanowiliśmy przyjąć za podstawę metodologię Lean Startup i dostosować ją do naszych zadań. Lean Startup to teoria przedsiębiorczości stworzona przez Erica Riesa. Opiera się na zasadach, podejściach i praktykach takich koncepcji, jak Lean Manufacturing, rozwój klienta i elastyczna metodologia rozwoju.

Jeśli chodzi o bezpośrednie podejście do zarządzania rozwojem produktu: nie wymyśliliśmy koła na nowo, ale zastosowaliśmy istniejącą już metodologię rozwoju SCRUM, dodając kreatywności i teraz śmiało można to nazwać SCRUM-WATERFALL-BAN. SCRUM pomimo swojej elastyczności jest systemem bardzo sztywnym i nadaje się do zarządzania zespołem odpowiedzialnym tylko za jeden produkt/projekt. Jak rozumiesz, klasyczny biznes „integracyjny” nie polega na przydzielaniu pełnoetatowych specjalistów technicznych do pracy nad jednym projektem (są wyjątki, ale niezwykle rzadkie), ponieważ oprócz pracy nad produktami wszyscy są zajęci bieżącymi projektami. Ze SCRUM-u przenieśliśmy podział pracy na sprinty, codzienne raportowanie, retrospektywy i role. Wybraliśmy Kanban do naszego przepływu zadań i dobrze zintegrowaliśmy go z naszym istniejącym systemem śledzenia zadań. Ustrukturyzowaliśmy naszą pracę, płynnie integrując się z istniejącym porządkiem rzeczy.
Przed wejściem na rynek produkt przechodzi przez 5 etapów: pomysł, selekcja, koncepcja, MVP (więcej szczegółów poniżej) i produkcja.

Pomysł

Na tym etapie jest coś efemerycznego – pomysł. Idealnie pomysł na rozwiązanie istniejącego problemu lub problemu klienta. Pomysłów nam nie brakuje. Według wstępnego planu powinny one być generowane przez pracowników obszarów technicznych. Aby pomysł został przyjęty do dalszego rozwoju, autor musi wypełnić „Szablon projektu pomysłu”. Są tylko cztery pytania: Co? Po co? Kto tego potrzebuje? A jeśli nie nasz produkt, to co?

źródło

Wybór

Gdy tylko wypełniony szablon dotrze do nas, rozpoczyna się procedura przetwarzania i selekcji. Etap selekcji jest najbardziej pracochłonny. Na tym etapie powstają hipotezy dotyczące problemów (nie bez powodu wspomniałem w poprzednim akapicie, że w idealnym przypadku pomysł powinien rozwiązać problem klienta) i wartości produktu. Formułowana jest hipoteza skali, tj. jak nasza firma będzie się rozwijać i prosperować. Z potencjalnymi klientami przeprowadzamy wywiady problemowe i eksperckie, aby uzyskać wstępne potwierdzenie, że będziemy produkować coś potrzebnego. Wyciągnięcie wniosku o potrzebie produktu wymaga co najmniej 10-15 rozmów.

Jeżeli hipotezy się potwierdzą, przeprowadzana jest wstępna analiza finansowa, oceniany jest przybliżony wolumen inwestycji i możliwe zyski inwestora. W wyniku tego etapu rodzi się dokument o nazwie Lean Canvas, który jest prezentowany kierownictwu.

Koncepcja

Na tym etapie eliminuje się około 70% pomysłów. Jeśli koncepcja zostanie zatwierdzona, rozpoczyna się etap opracowania pomysłu. Kształtuje się funkcjonalność przyszłego produktu, ustala się ścieżki wdrożenia i optymalne rozwiązania techniczne, aktualizuje biznes plan. Efektem tego etapu jest specyfikacja techniczna opracowania i szczegółowe uzasadnienie biznesowe. Jeśli się powiedzie, przechodzimy do etapu MVP lub MVP.

MVP czy MVP

MVP to minimalnie opłacalny produkt. Te. produkt, który nie jest w pełni rozwinięty, ale może już wnieść wartość i realizuje swoją funkcjonalność. Konieczne jest, abyśmy na tym etapie rozwoju zebrali opinie od rzeczywistych użytkowników i dokonali zmian.

Produkcja

Ostatnim etapem jest produkcja. Do tego etapu dociera nie więcej niż 5% produktów. Te 5% obejmuje tylko najważniejsze, niezbędne, opłacalne i funkcjonalne produkty.

Mamy mnóstwo pomysłów i zgromadziliśmy już obszerne portfolio. Analizujemy każdy pomysł i robimy wszystko, aby dotarł do końcowego etapu. Bardzo miło jest, że nasi współpracownicy nie pozostali obojętni na nasz kierunek badań i rozwoju i wzięli czynny udział w rozwoju i wdrażaniu produktów i rozwiązań.

Jak stworzyliśmy LANBIX

Przyjrzyjmy się tworzeniu produktu na prawdziwym przykładzie – produkcie LANBIX. Jest to „pudełkowy” system programowo-sprzętowy przeznaczony do monitorowania małych infrastruktur IT i szybkiego ostrzegania decydentów oraz użytkowników biznesowych o awariach kontrolowanych za pomocą chatbota. Oprócz funkcji monitorowania LANBIX zawiera funkcję Help Desk. Ten produkt jest przeznaczony wyłącznie dla segmentu rynku, na który jesteśmy ukierunkowani. To jest zarówno nasza zaleta, jak i nasz ból. Ale najpierw sprawy. Od razu powiem, że LANBIX jest produktem żywym (to znaczy nie jest finalny w swoim rozwoju i jest w kolejnej rundzie MVP).

Zatem pierwszym etapem jest pomysł. Aby pomysł narodził się, potrzebne są problemy, a my je mieliśmy, a właściwie nie my, ale nasi przyjaciele. Poniżej przyjrzymy się kilku realnym sytuacjom, które miały miejsce w różnych obszarach biznesu.

Mała firma zarządzająca utrzymuje dwa domy w regionie moskiewskim. Personel dysponujący komputerami to około 15 osób. Administrator systemu jest przyjezdnym freelancerem (inteligentnym synem jednego z troskliwych mieszkańców). Wydawać by się mogło, że działalność spółki zarządzającej jest słabo uzależniona od IT, jednak specyfiką tej działalności jest comiesięczne raportowanie do wielu organów. Na dysku systemowym szefa firmy (który jak zwykle łączy wiele ról) zabrakło wolnego miejsca. Oczywiście nie stało się to nagle, ostrzeżenie wisiało przez około 2 miesiące i było stale ignorowane. Ale nadeszła aktualizacja, system operacyjny został zaktualizowany i, na szczęście, zawiesił się w trakcie aktualizacji, narzekając przed „śmiercią” na zajęty dysk. Komputer przeszedł cykliczny restart. Rozwiązując problem i otrzymując raporty, nie dotrzymaliśmy terminu zgłoszenia. Wydawałoby się, że banalna awaria spowodowała różne problemy: od strat po spory sądowe i odpowiedzialność administracyjną.

źródło

Podobny incydent miał miejsce w dużym holdingu, skupiającym wiele małych firm, posiadającym jedną usługę wsparcia technicznego dla całego biura. W jednym z działów zepsuł się komputer głównego księgowego. Już od dawna było wiadomo, że może się zepsuć (komputer rozpaczliwie zwalniał i się nagrzewał), ale główny księgowy ani razu nie zabrał się za wysłanie zgłoszenia do pomocy technicznej. Oczywiście zepsuło się dokładnie w dniu wypłaty, a pracownicy działu przez kilka dni byli bez pieniędzy.

Mała firma zajmująca się drobnym handlem hurtowym posiadała witrynę sprzedażową, która była hostowana na platformie zewnętrznej. O jego niedostępności dowiedzieliśmy się telefonicznie od stałego klienta. W momencie wezwania strona była niedostępna od około trzech godzin. Znalezienie osoby odpowiedzialnej za witrynę zajęło kolejne kilka godzin, a naprawienie problemu kolejne dwie. W związku z tym strona była niedostępna przez prawie cały dzień roboczy. Według dyrektora handlowego firmy ten przestój kosztował ich około 1 miliona rubli.

Sama spotkałam się z podobną sytuacją, gdy przyszłam na wizytę do kliniki i musiałam udać się do rejestracji VHI. Z błahego powodu nie mogli mnie wysłać do lekarza - rano był skok napięcia, a po wypadku nie działała ich poczta i pewna usługa komunikacji z ubezpieczycielem. W odpowiedzi na moje pytanie, gdzie są twoi administratorzy, powiedziano mi, że ich administrator przychodzi i odwiedza ich raz w tygodniu. A teraz (wtedy była już 16:00) nie odbiera telefonu. Przez co najmniej 7 godzin klinika była odcięta od świata zewnętrznego i nie mogła świadczyć płatnych usług.

Co łączy wszystkie te przypadki? Absolutnie wszystkim problemom można było zapobiec z wyprzedzeniem. Dzięki szybkiej reakcji informatyków szkody można było zmniejszyć. Byłoby to możliwe, gdyby wczesne objawy zostały prawidłowo zinterpretowane przez użytkowników.

Zidentyfikowaliśmy hipotezy problemowe:

znaczne straty pieniężne i reputacyjne wynikające z małej szybkości reakcji na awarie infrastruktury IT;
błędną interpretację wczesnych objawów nieprawidłowego działania przez użytkowników.

Co klient może z nimi zrobić i jak uniknąć podobnych sytuacji w przyszłości? Nie ma wielu opcji:

zatrudnić wysoko wykwalifikowanego administratora systemu i sprawić, by pracował sumiennie;
zlecić konserwację IT wyspecjalizowanej firmie serwisowej;
samodzielnie wdrożyć system monitorowania i raportowania usterek;
zapewniać szkolenia użytkownikom/personelowi biznesowemu w zakresie podstaw obsługi komputera.

Zdecydujmy się na trzecią opcję. Zaproponujmy system monitoringu tym, którzy z różnych powodów z niego nie korzystają.

Dygresja liryczna. Różne systemy monitorowania usług IT na rynku przedsiębiorstw są stosowane od dawna, a ich zalety nie podlegają dyskusji. Rozmawiałem z przedstawicielami dużych firm, przyglądałem się, jak budowana jest relacja biznes-IT. Dyrektor techniczny jednego z dużych przedsiębiorstw zajmujących się budową maszyn zlecił utrzymanie infrastruktury IT firmie zewnętrznej, ale sam jest na bieżąco ze wszystkimi sprawami. W jego biurze wisi duży ekran systemu monitorującego ze wskaźnikami stanu usług IT. Te najbardziej krytyczne są uwzględnione w systemie. W każdej chwili dyrektor techniczny może dowiedzieć się, jaki jest stan infrastruktury, co się dzieje, gdzie leży problem, czy powiadomiono odpowiedzialne osoby i czy problem jest w trakcie rozwiązywania.

Powyższe historie skłoniły nasz zespół do zastanowienia się, jak stworzyć optymalny system monitorowania dla małych firm. W rezultacie narodził się LANBIX – system monitorowania, który może wdrożyć absolutnie każdy, bez żadnej wiedzy informatycznej. Główny cel systemu jest prosty, jak wszystkich systemów mających na celu zwiększenie ciągłości i dostępności - ograniczenie strat pieniężnych i innych w przypadku nieplanowanych przestojów. Urządzenie zostało zaprojektowane tak, aby do minimum skrócić czas pomiędzy „coś jest zepsute” a „problem został naprawiony”.

W celu potwierdzenia postawionych hipotez przeprowadzono wywiady problemowe. Nie mogłem sobie wyobrazić, ile ludzie byliby skłonni powiedzieć, nie próbując im tego sprzedać. Każda rozmowa trwała minimum 1,5 godziny, a my otrzymywaliśmy wiele informacji przydatnych do dalszego rozwoju.

Podsumujmy wyniki tego etapu:

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

Drugi etap był bardziej szczegółowy. Na podstawie jego wyników musieliśmy przedstawić zarządowi, który w istocie pełni rolę inwestora, business case (sam Lean Canvas), aby podjąć decyzję o przyszłych losach produktu.

Zaczęliśmy od badań rynku i analizy konkurencji, aby dowiedzieć się, kto, co i co najważniejsze, jak radzi sobie na tym rynku.

Okazało się, co następuje.

Dla naszego segmentu (małego biznesu) nie ma na rynku gotowych systemów monitoringu pudełkowego, z wyjątkiem kilku, trzech, o których z oczywistych względów nie będę się wypowiadał.
Co dziwne, naszymi głównymi konkurentami są administratorzy systemów z samodzielnie napisanymi skryptami i „dodatkami” do systemów monitorowania typu open source.
Istnieje wyraźny problem korzystania z systemów monitorowania typu open source. Jest system, jest ogromna ilość informacji jak pracować i modyfikować system pod swoje potrzeby. Spośród administratorów, z którymi rozmawiałam, wielu przyznało, że nie mają wystarczających kompetencji, aby samodzielnie realizować swoje pomysły. Nie mogą jednak przyznać się do tego kierownictwu ze strachu przed zwolnieniem. Okazuje się, że jest to błędne koło.

Następnie przeszliśmy do analizy potrzeb naszych potencjalnych klientów. Zidentyfikowaliśmy dla siebie segment małych organizacji, które z jakiegoś powodu nie posiadają własnego serwisu IT, gdzie za IT odpowiada albo przychodzący administrator systemu, freelancer, albo firma usługowa. Na wejście nie zdecydowała się strona IT, ale strona biznesowa, oferując założycielom i właścicielom firm narzędzie do podnoszenia jakości obsługi infrastruktury IT. Produkt, który powinien pomóc właścicielom zabezpieczyć swój biznes, ale jednocześnie doda pracy osobom odpowiedzialnym za IT. Produkt zapewniający przedsiębiorstwom narzędzie do monitorowania jakości wsparcia IT.

W wyniku przetworzenia otrzymanych danych powstała pierwsza lista wymagań (rodzaj zgrubnego backlogu) na przyszły produkt:

system monitorowania musi być oparty na rozwiązaniu open source i co za tym idzie tani;
łatwy i szybki w montażu;
nie powinien wymagać specjalistycznej wiedzy z zakresu IT, nawet księgowy (w żadnym wypadku nie chciałem urazić przedstawicieli tego zawodu) powinien umieć wdrożyć i skonfigurować system;
powinien automatycznie wykrywać obiekty do monitorowania w sieci;
powinien automatycznie (a najlepiej automatycznie) zainstalować agenty monitorujące;
musi mieć możliwość monitorowania usług zewnętrznych, co najmniej systemu CRM i serwisu sprzedażowego;
powinien powiadomić o problemach zarówno firmę, jak i administratora systemu;
stopień szczegółowości i „język” alertów powinien być różny dla administratora i firmy;
system musi być dostarczony na własnym sprzęcie;
żelazo powinno być jak najbardziej dostępne;
system powinien być jak najbardziej niezależny od czynników zewnętrznych.

Następnie obliczono inwestycje w rozwój produktu (uwzględniając koszty pracy pracowników działu technicznego). Przygotowano szkic modelu biznesowego i obliczono ekonomikę jednostkową produktu.

Wynik etapu:

wysoki poziom rejestru produktu;
sformułowany model biznesowy lub hipoteza skali, która nie została jeszcze przetestowana w praktyce.

Przejdźmy do kolejnego etapu – koncepcji. Tutaj jako inżynierowie odnajdujemy się w swoim rodzimym żywiole. Istnieją „listy życzeń”, które są rozkładane na komponenty/podsystemy/funkcje, następnie przekształcane w specyfikacje techniczne/historie użytkowników, a następnie w projekt itp. Nie będę się szczegółowo rozwodzić nad procesem przygotowania szeregu alternatywnych opcji, przejdźmy od razu do wymagań i wybranych sposobów ich realizacji.

Wymóg
decyzja

Powinien to być otwarty system monitorowania;

Stosujemy system monitorowania typu open source.

System powinien być prosty i szybki w instalacji;
nie powinno wymagać szczególnej wiedzy informatycznej. Nawet księgowy powinien być w stanie wdrożyć i skonfigurować system.

Oferujemy zainstalowany system, dzięki któremu użytkownik musi jedynie włączyć urządzenie i trochę je skonfigurować, podobnie jak router.

Zamknijmy interakcję z urządzeniem do czegoś prostego i zrozumiałego dla każdego.

Napiszmy własnego chatbota dla jednego ze znanych komunikatorów i przenieśmy na niego całą interakcję z systemem.

System powinien:

automatycznie wykrywa obiekty wymagane do monitorowania w sieci;
automatycznie instaluj agenty monitorujące;
Być w stanie monitorować usługi zewnętrzne, przynajmniej system CRM i stronę sprzedażową.

Piszemy dodatki do systemu monitoringu dla:

automatyczne wykrywanie obiektów;
automatyczna instalacja agentów;
monitorowanie dostępności usług zewnętrznych.

System powinien:

powiadamiaj o problemach zarówno firmę, jak i administratora systemu;
móc monitorować usługi zewnętrzne, przynajmniej system CRM i stronę sprzedażową. Stopień szczegółowości i „język” powiadomień powinien być różny dla administratora i firmy.
System nie powinien wymagać specjalistycznej wiedzy informatycznej, nawet księgowy powinien być w stanie wdrożyć i skonfigurować system.

Dodajmy różne typy powiadomień dla różnych typów użytkowników. Różnią się wysokością i głębokością. Użytkownik biznesowy otrzyma powiadomienia typu „wszystko jest w porządku, ale komputer Iwanowa wkrótce padnie”. Administrator otrzyma pełną wiadomość o błędzie, kto, jak i co się stało lub mogło się wydarzyć.
Dodajmy do tego możliwość skorzystania z poczty dodatkowej osoby odpowiedzialnej, aby w razie awarii otrzymała wiadomość.
Dodajmy do tego interakcję z zewnętrznymi usługodawcami polegającą na wysyłaniu maili z wcześniej przygotowanym tekstem, bo To właśnie e-mail był przyczyną zdarzenia.
Wszelka interakcja z systemem będzie połączona z chatbotem, komunikacja odbywa się w stylu dialogu.

Dodanie:

Dodajmy funkcjonalność „czatu z administratorem”, aby użytkownik mógł bezpośrednio wysłać do administratora wiadomość opisującą problem.

System musi być dostarczony na własnym sprzęcie.
Żelazo musi być dostępne.
System powinien być jak najbardziej niezależny od otoczenia.

Weźmy gotowy i tani komputer Raspberry PI.
Zaprojektujemy płytkę zasilacza awaryjnego.
Dodajmy modem, aby był niezależny od stanu sieci lokalnej.
Zaprojektujemy piękny budynek.

Mamy obecnie trzy podsystemy z własnymi wymaganiami i wizją ich wdrożenia:

podsystem sprzętowy;
podsystem monitorujący;
podsystem interakcji użytkownika.

Opracowaliśmy wstępny projekt podsystemu sprzętowego. Tak tak! Po naruszeniu wszystkich zasad zwinności opracowaliśmy dokument, ponieważ zakłady produkcyjne pracują z dokumentami. Dla pozostałych podsystemów dokonaliśmy identyfikacji użytkowników (osób), przygotowaliśmy historie użytkowników oraz napisaliśmy zadania rozwojowe.

Na tym kończy się etap koncepcyjny, a rezultatem jest:

projekt na platformę sprzętową;
sformułowana wizja w formie historyjek użytkownika dla pozostałych dwóch podsystemów;
prototyp oprogramowania zaimplementowany jako maszyna wirtualna;
prototyp okucia, zrealizowany w formie stanowiska, na którym faktycznie sprawdzono wytrzymałość rozwiązań okuć;
testy przeprowadzone przez naszych administratorów.

Problemy na tym etapie miały głównie charakter organizacyjny i wynikały z braku wiedzy kadry inżynierskiej w zakresie prawno-księgowych aspektów sprzedaży. Te. Co innego wiedzieć, co i jak sprzedać, a co innego stawić czoła bezwzględnej machinie prawnej: patenty, zadania rozwojowe, rejestracja, umowa EULA i wiele innych, których my, kreatywni ludzie, początkowo nie braliśmy pod uwagę.

Nie było jeszcze problemu, ale raczej trudność związana z konstrukcją obudów. Nasz zespół składa się wyłącznie z inżynierów, dlatego pierwsza wersja obudowy została „zbudowana” z pleksi przez naszego elektronika.

Ciało wyglądało, delikatnie mówiąc, kontrowersyjnie, zwłaszcza dla publiczności, zepsutej przez nowoczesną technologię. Wśród starszego pokolenia „Kulibinów” nie brakowało oczywiście koneserów – budynek budził w nich nostalgię. Postanowiono wyprodukować i zaprojektować obudowę od nowa, gdyż stara oprócz wad estetycznych miała także wady konstrukcyjne - plexi źle znosiła montaż i demontaż urządzenia i miała tendencję do pękania. O produkcji obudowy opowiem dalej.

I już jesteśmy blisko mety – MVP. Oczywiście nie jest to jeszcze finalny produkt produkcyjny, ale już jest użyteczny i wartościowy. Głównym celem tego etapu jest uruchomienie cyklu „twórz – oceniaj – ucz się”. To jest dokładnie etap, na którym znajduje się LANBIX.

Na etapie „tworzenia” stworzyliśmy urządzenie realizujące założoną funkcjonalność. Tak, nie jest to jeszcze idealne i nadal nad tym pracujemy.

Wróćmy do wykonania korpusu, tj. do zadania przekształcenia naszego urządzenia z nostalgicznego na nowoczesne. Na początku przeszukałem rynek pod kątem producentów szaf i usług projektowania przemysłowego. Po pierwsze, na rynku rosyjskim nie ma wielu firm produkujących obudowy, a po drugie, koszt wzornictwa przemysłowego na tym etapie jest zaporowo wysoki, około 1 miliona rubli.

W sprawie projektu zwrócili się do naszego działu marketingu, młody projektant był gotowy na kreatywne eksperymenty. My nakreśliliśmy naszą wizję kadłuba (po wcześniejszym zapoznaniu się z najlepszymi przykładami konstrukcji kadłuba), a on z kolei zamienił go w dzieło sztuki. Pozostaje tylko go wyprodukować. Dumni ze swojego projektu zwróciliśmy się do naszych partnerów. Ich CEO od razu zmiażdżył nasze fantazje, wskazując całkowicie bezpłatnie rzeczy, których nie dałoby się wyprodukować w wybrany przez nas sposób. Obudowa może zostać wyprodukowana i nie będzie gorsza od Apple, ale koszt obudowy będzie trzy do czterech razy droższy niż wszystkie elementy elektroniczne. Po szeregu operacji i atestów zaprojektowaliśmy obudowę, która może zostać wyprodukowana. Tak, nie jest tak piękny, jak planowaliśmy, ale jest idealny do osiągnięcia bieżących celów.

Efekt etapu: pierwsza partia urządzeń gotowa do walki i testów.

I teraz najtrudniejszy jest etap „oceny”, a z naszym produktem jesteśmy dokładnie w tym momencie. Możemy oceniać jedynie na podstawie wyników użytkowania przez prawdziwych klientów i żadne założenia się tutaj nie sprawdzają. Potrzebujemy tych „wczesnych użytkowników”, którzy przekażą opinie i wprowadzą zmiany w produkcie, które są naprawdę potrzebne. Rodzi się pytanie: skąd pozyskać klientów i jak ich przekonać do wzięcia udziału w eksperymencie?

Ze wszystkich możliwych opcji wybraliśmy klasyczny zestaw narzędzi cyfrowych: stronę docelową i kampanię reklamową w sieciach społecznościowych.

Proces został już rozpoczęty, ale jest za wcześnie, aby mówić o wynikach, chociaż są już odpowiedzi i otrzymaliśmy potwierdzenie wielu naszych hipotez. Miłym zaskoczeniem była reakcja przedstawicieli zupełnie innych segmentów biznesowych, znacznie większa niż się spodziewaliśmy. Głupotą byłoby ignorowanie nowych prezentacji, dlatego na podstawie wyników rozmów zdecydowano o uruchomieniu równoległej linii LANBIX o nazwie LANBIX Enterprise. Dodaliśmy obsługę infrastruktur rozproszonych, monitorowanie sieci Wi-Fi wraz z rozwiązywaniem problemów i lokalizacją oraz monitorowanie jakości kanałów komunikacyjnych. Największe zainteresowanie rozwiązaniem wyraziły firmy usługowe. Jednocześnie opracowane przez nas urządzenia odgrywają ważną rolę w działaniu rozwiązań.

Co się później stanie

To, co stanie się dalej z oryginalnym LANBIXem, stanie się jasne na podstawie wyników kampanii. Jeśli nasze hipotezy się nie potwierdzą, zgodnie z metodologią Lean, bezlitośnie się go pozbędziemy lub zamienimy go w coś nowego, bo nie ma nic gorszego niż wyprodukowanie produktu, którego nikt nie potrzebuje. Ale teraz możemy powiedzieć, że włożona praca nie poszła na marne i dzięki niej pojawiła się cała gama równoległych produktów, nad którymi aktywnie pracujemy. Jeśli się powiedzie, LANBIX przejdzie z etapu MVP do etapu końcowego i będzie się rozwijać zgodnie ze zrozumiałymi, klasycznymi prawami marketingu produktu.

Powtarzam, teraz chcemy znaleźć pierwszych użytkowników, firmy, które mogą zainstalować nasz produkt w celu zebrania opinii. Jeśli jesteś zainteresowany przetestowaniem LANBIX-a, napisz w komentarzach lub wiadomościach prywatnych.

źródło

Źródło: www.habr.com

Jak pracujemy z pomysłami i jak narodził się LANBIX