Szybka wycena!

Aleksander Dytko - RST Software

Aleksander
Dytko
+48 532 626 248

Bez prostych odpowiedzi - Podcast Bez prostych odpowiedzi - Podcast
Bez prostych odpowiedzi - Podcast

#1 - Dopracowywać czy konfrontować? Czyli o tym, jak wdrażać produkty IT na rynek.

Jak wdrażać produkty IT na rynek?

 

Dopracowywać czy konfrontować?

 

Kiedy masz pomsył na produkt lub aplikację z pewnością staniesz przed wyborem momentu, kiedy pokazać go światu. Z jednej strony chcesz, aby był dopracowany, a z drugiej goni Cię czas i poczucie, że przegapisz swój moment.A zatem kiedy jest odpowiedni moment, na wdrożenie produktu na rynek? – Nie mamy prostej odpowiedzi, ale opowiemy Ci, co wiemy z naszych doświadczeń. Poznajcie historię śmiałego produktu, który czekał na swój moment.

 

Gościem odcinka jest Aleksander Dytko – Business Development Executive w RST Software Masters, który od kilku lat pomaga klientom budować i wdrażać aplikacje i opowie o tym, jak się to robi dzisiaj.

W RST Software Masters jako Business Development Executive pomaga klientom budować i wdrażać aplikacje, które spełniają ich cele. Praktyk Value Based Selling. Koncentruje się na tym, by maksymalnie szybko dostarczać klientom wartość biznesową.

Aleksander Dytko
Gość odcinka

Aleksander Dytko

Humanista z nałogiem technologicznym, entuzjasta rzeczy pięknych i niekoniecznie funkcjonalnych. Developer, grafik, animator. Lubi ołówki i orzeszki w pikantnej skorupce.

Robert Zatycki
Gospodarz podcastu

Robert Zatycki

Wszystkie odcinki znajdziesz na:

Minuta po minucie, czyli o czym rozmawiamy

00:00 | Historia produktu, który poniósł klęskę, choć pracowano nad jego pierwszą wersją przez lata

 

02:45 | Intro, Zapowiedź gościa odcinka, Aleksandra Dytko – Business Development Executive w RST Software Masters

 

04:22 | Dlaczego ważne jest szybkie wprowadzenie produktu na rynek?

 

06:55 | Historia MVP zbudowanego szybko na platformie No-Code w celu przetestowania pomysłu biznesowego

 

10:38 | Czym jest iteracja i wartość biznesowa, dostarczana w każdej iteracji?

 

11:49 | Jak dowiedzieć się czego potrzebują użytkownicy? Co zrobić, jeśli okaże się, że nie ma zapotrzebowania na nasze rozwiązanie? Dlaczego warto zbudować prototyp i PoC

 

16:35 | Jak powinny wyglądać role w projekcie? Interesariusze, product owner, zespół developerski.

 

23:03 | Czy podejście zwinne jest tylko dla startupów? Co z dużymi firmami?

 

Podcast Czas

Transkrypcja nagrania

 

 

ROBERT ZATYCKI

Mniej więcej dziesięć lat temu pracowałem w zespole deweloperskim który budował nowy serwis społecznościowy. Jak pewnie pamiętacie, to mniej więcej dziesięć lat temu był wielki boom na tego typu projekty. Grono, Nasza Klasa, MySpace, Golden Line, Linkedin… no i oczywiście Facebook. Wtedy też zrodził się pomysł stworzenia nowego serwisu społecznościowego, ale adresowanego dla pewnej grupy zawodowej. Powstała koncepcja tego projektu, powstał zespół deweloperski, który miał go budować. Plany były bardzo śmiałe, bo punktem odniesienia był właśnie Facebook, ale nowy projekt oprócz tych oczywistych społecznościowych funkcjonalności miał go przewyższać specyficznymi narzędziami stworzonymi specjalnie dla potrzeb –tak nam się wtedy wydawało – tej szerokiej branży zawodowej. Projekt powstawał przez kilka lat w zacisznym gronie pomysłodawców i deweloperów. Zupełnie niedostępny dla świata i przyszłych użytkowników. Oczywiście stale obserwowaliśmy rynek dlatego nasz projekt był wciąż zmieniany, ulepszany, przebudowywany – bo zmieniały się przecież trendy, zmieniały się technologie, a kiedy po kilku latach pracy wreszcie wyszedł z cienia, to okazało się, że wcale nie jest tak atrakcyjny i przydatny jak tego oczekiwano przychodząc, z pomysłem na niego. Bo w niektórych miejscach był już przestarzały, a w innych zwyczajnie nieużyteczny. Bo jego potencjalni użytkownicy po prostu nie mieli takich potrzeb, jakie zakładaliśmy i nie chcieli z niego korzystać. Kilkuletnia praca zakończyła się fiaskiem – stratą pieniędzy i ogromnej energii, którą wszyscy w ten projekt składaliśmy.

 

ROBERT ZATYCKI

Dlaczego się nie udało? Tu nie ma prostej odpowiedzi. – Bo projekt był zbyt ambitny? Bo trwał za długo bez udziału użytkowników i konfrontacji z rynkiem? Albo zmieniły się gusta, nawyki użytkowników? Zmieniły się technologie, standardy? Bo starano się stworzyć kompletny produkt, który w warunkach ciągle zmieniającego się świata nigdy nie nadążał i trzeba było go wciąż rozbudowywać i zmieniać? A przez te rozbudowy ciągnął  za sobą taki dług technologiczny, którego nie można było w żaden sposób spłacić.A może przyjęto założenie, że tylko skończony i gotowy serwis może konkurować z tymi które już są na rynku?

 

ROBERT ZATYCKI

Dzisiaj możemy się już tylko zastanawiać i stawiać kolejne pytania w podcaście „Bez prostych odpowiedzi”, czyli audycji o technologiach IT, których nie da się streścić w dwóch zdaniach, bo albo są albo zbyt złożone, albo sposobów na ich użycie jest wiele. Dlatego prezentuję tu różne spojrzenia na zagadnienia techniczne czy biznesowe i rozmawiam ze specjalistami. A oni dzielą się wiedzą, doświadczeniem i swoim punktem widzenia. Więc nawet jeśli nie znajdziesz tu prostej odpowiedz,i to znajdziesz inspirację i poszerzysz swoje horyzonty. Serdecznie zapraszam!

 

ROBERT ZATYCKI

Moim gościem jest Olek Dytko, który pomaga klientom przekuwać pomysły na działające aplikacje i bardziej rozbudowane systemy, przy wsparciu rozmaitych technologii. On się na tym dobrze zna.

 

ALEKSANDER DYTKO

Dzięki za zaproszenie. Tak, jak powiedziałeś, od kilku lat zajmuję się pracą z osobami technicznymi i biznesowymi tak, żeby budować systemy, które spełniają ich cele. Dzisiaj chętnie podzielę się moim doświadczeniem w tym zakresie, szczególnie w tym obszarze budowy systemów, które dosyć szybko są wprowadzane na rynek i testowane z użytkownikami.

 

ROBERT ZATYCKI

Czyli zupełnie inaczej niż w mojej historii sprzed kilku lat! Dlatego dzisiaj spróbujemy razem z Olkiem znaleźć odpowiedzi na pytanie – dlaczego tak ważne jest szybkie wprowadzenie produktu na rynek? Jak się do tego zabrać?

 

ALEKSANDER DYTKO

Usłyszałem w tej historii dwie takie rzeczy. Pierwsza – od strony zarządzania projektem i podejścia do tego projektu, a druga część tego problemu, to była ta część technologiczna, bo widzę, że tutaj są dwie takie strony, po których coś zostało zrobione w inny sposób, niż zrobiliśmy to dzisiaj mając tę wiedzę.

 

ROBERT ZATYCKI

No właśnie jak zrobilibyśmy to dzisiaj?

 

ALEKSANDER DYTKO

Dzisiaj, po tych kilkunastu latach od kiedy podejście zwinne często nazywane i kojarzone ze Scrumem jest na rynku, zaczęlibyśmy od tego, żeby mieć taką długofalową wizję rozwiązania, ale żeby nie wchodzić w szczegóły od samego początku. Żeby nie utknąć, tak jak w  tej twojej historii, na kilka lat. Najpierw budując wymagania biznesowe, później developując to,  bez zdarzenia na rynek.

 

ROBERT ZATYCKI

Ale wyobraź sobie że myśmy ten projekt tworzyli w Scrumie, a właściwie uczyliśmy się Scruma pracując przy tym projekcie, tylko wszystkie nowe funkcjonalności zostawały w zespole i czekały na sposobność, aż cały projekt będzie zupełnie gotowy.

 

ALEKSANDER DYTKO

Czyli zakładamy sobie, że od dzisiaj zaczynamy projekt, ale dopiero za trzy lata pokażemy go pierwszy raz użytkownikom, bo chcemy żeby był jak najlepszy. Po pierwsze jak najlepszej jakości, ale też żeby te ficzery były jak najbardziej dopasowane do tego co jest według nas na rynku.

 

ROBERT ZATYCKI

No dokładnie tak było! Wtedy czekaliśmy, aż wszystkie założenia i funkcjonalności znajdą się w odpowiednich miejscach.

 

ALEKSANDER DYTKO

A dzisiaj zrobilibyśmy to trochę inaczej. Czyli określamy długofalową wizję rozwiązania, ale później pracujemy w krótkich iteracjach tak, żeby jak najszybciej dowozić wartość biznesową i zderzać ją z rynkiem.

 

ROBERT ZATYCKI

A co to jest ta wartość biznesowa w takim raczkującym produkcie?

 

ALEKSANDER DYTKO

W takim raczkującym produkcie – tutaj kłania nam się podejście MVP, czyli Minimum Viable Product – jest to taki produkt, który spełnia pewną potrzebę biznesową w minimalnym stopniu pod względem funkcjonalności.

 

ROBERT ZATYCKI

Eric Rise, twórca nowatorskiej swego czasu metody Lean startup powiedział, że minimalnym opłacanym produktem jest taka wersja nowego produktu, która umożliwia zespołowi zebranie maksymalnej ilości potwierdzonych, czyli prawdziwych, informacji o klientach, przy najmniejszym wysiłku. Może masz na to jakiś przykład?

 

ALEKSANDER DYTKO

Odpowiem historię jednego z klientów, która według mnie pokazuje, jak można to dosyć szybko zrobić małym kosztem, żeby przetestować czy ten produkt jest interesujący i czy użytkownicy chcą z niego korzystać. To jest klient z Wielkiej Brytanii i wymyślił sobie, że w czasach pandemii, bo to było w zeszłym roku, brakuje ludziom właśnie takiego kontaktu społecznego z innymi członkami pewnej społeczności, w której wcześniej uczestniczyli. No i postanowił to przenieść do online’u. Żeby nie budować platformy od zera i zanim nie przetestuje tej idei, czy tego pomysłu na rynku, nie chciał wydawać aż tak dużo pieniędzy, żeby to zrobić. Więc zaczął od zbudowania tej platformy na takim systemie który jest lowcodowy czy nocodowy, który nazywa się Bubble i tam można zbudować z gotowych komponentów pewną aplikację. Jest to w modelu subskrypcyjnym, więc dosyć tanio można to zrobić. I po zbudowaniu tej platformy zaczął ją reklamować i zaczął proponować klientom tak, żeby sprawdzić czy ten produkt jest w ogóle wartościowy i czy on może przynieść realną wartość biznesową dla klientów.

 

ALEKSANDER DYTKO

Pod tą wartością biznesową rozumiemy odnowienie kontaktów społecznych w takiej rzeczywistości wirtualnej

 

ROBERT ZATYCKI

Czyli nieco inaczej niż w naszym przypadku. Myśmy nie testowali tego rozwiązania z użytkownikami, a jedynie liczyliśmy na to, że oni będą chcieli z tego korzystać.

 

ALEKSANDER DYTKO

Więc przetestował to podejście. I kiedy użytkownicy zaczęli z tego korzystać, było coraz więcej użytkowników i pytali o nowe funkcjonalności, plus duże firmy zaczęły się tym interesować tak, żeby zorganizować takie wirtualne miejsce spotkań. Wtedy zaczął myśleć o tym, żeby to zrobić w innym podejściu, czyli w takim podejściu Custom software development tak, żeby zbudować platformę, która jest dedykowana właśnie do tego celu.  Wtedy zaczęliśmy z nim pracować, by zbudować – by trochę przenieść te funkcjonalności, które już wcześniej miał na tej platformie Bubble, ale też zbudować pewne możliwości, których tam nie mógł osiągnąć.

 

ROBERT ZATYCKI

No to żebyśmy dobrze zrozumieli. Klient zrobił szybkie podejście do tematu. Na początku skorzystał z taniego i dostępnego rozwiązania po to, żeby przekonać się czy ten jego pomysł ma w ogóle sens i czy warto w niego inwestować. Sprawdził, że działa, sprawdził co działa i dopiero z tą wiedzą zaczął budować docelową architekturę. Tak to takie nieco inne podejście?

 

ALEKSANDER DYTKO

Takie podejście build – measure – learn było jak najszybciej zakończone. Czyli najpierw budujemy pewną część funkcjonalności, później testujemy ją na rynku razem z użytkownikami tak żeby dowiedzieć się, czy to jest coś co spełnia ich potrzeby, czy to spełnia ich cele. Następnie na tym się uczymy i w kolejnej iteracji, bo to zamyka się w takim ładnym kółku kolejnej iteracji,  w ramach tych wniosków które wyciągnęliśmy z poprzedniej iteracji, już implementujemy te zmiany w systemie. Tutaj, w tym podejściu z winnym i w takim podejściu żeby szybko zderzyć funkcjonalności z użytkownikami, bardzo szybko testujemy to, co zbudowaliśmy tak, żeby nie marnować dni czy tygodni na to, żeby inwestować w coś, co nie jest wartościowe.

 

Powiedzmy tu chociaż ogólnie, co to takiego ta iteracja. Otóż przy podejściu iteracyjnym pracujemy nad fragmentami systemu w pewnych odcinkach czasu – najczęściej stałych i krótkich – i po każdym takim zakończonym odcinku powinniśmy dostać działający, i to podkreślę – działający – kawałek systemu. I nieważne w tym momencie, czy chodzi o przyrost nowych funkcjonalności, czy o dopracowanie już tych, które istnieją, bo to temat na inny odcinek. A mówiąc ogólnie chodzi o jakąś realną wartość dostarczoną w krótkim czasie.

 

ALEKSANDER DYTKO

 Klient dostaje realną wartość biznesową. Ponieważ na początku w jego koncepcji chce realizować pewną ścieżkę użytkownika, która albo wcześniej nie była do wykonania albo angażowała duże zasoby, bo trzeba było to zrobić w różnych systemach. Ewentualnie było to w świecie offlineowym i teraz trzeba przenieść tą ścieżkę użytkownika do świata onlinenowego. Więc to co dla mnie stoi za spełnieniem potrzeby biznesowej  jest dostarczenie czegoś, czego klient potrzebuje.

 

ROBERT ZATYCKI

A jak sprawdza się to czy tego czego potrzebuje klient, czy tego samego potrzebują użytkownicy?

 

ALEKSANDER DYTKO

Tutaj możemy się posłużyć kompetencjami, które mają zwykle uxowcy, czyli User Experience Designer, którzy mają kompetencje product designeowe, tak żeby określić, czym w ogóle ma być ten produkt na takim początkowym stadium rozwoju. I wtedy, przynajmniej my, stosujemy takie dwa warsztaty. Albo to jest Product Vision Workshop albo to jest Scoping Session.

 

ROBERT ZATYCKI

No i czego możemy się dzięki temu dowiedzieć?

 

ALEKSANDER DYTKO

Na tym warsztacie określamy sobie,  w zależności od tego, na jakim etapie jest klient, który chce zbudować pewien produkt – to znaczy, jakie rzeczy, czy jakie funkcjonalności ma już określone. I dookreślamy te rzeczy, które z naszego doświadczenia przydają się już od samego początku. Jednym z takich wyników warsztatów jest określenie proto person, czyli takich fikcyjnych osób, które będą korzystały z naszego produktu – określone według grupy demograficznej, czyli wiek, wykształcenie, liczba dzieci – jeśli to jest ważne ten produkt dotyka tej materii. I określenie jakie są główne bolączki tego użytkownika na dzień dzisiejszy? Jakie są cele tego użytkownika? I tutaj w zależności od wizji produktu spełniamy albo cele użytkownika, albo rozwiązujemy te bolączki, które mam na dzisiaj.

 

ROBERT ZATYCKI

Czyli szukamy odpowiedzi na pytanie, kim jest ten użytkownik końcowy?

 

ALEKSANDER DYTKO

To zależy od tego jaki jest produkt i jaką potrzebę ma spełniać ten produkt.  Albo  jaką bolączkę ma niwelować ten produkt.

 

ROBERT ZATYCKI

A co w sytuacji kiedy z tych badań wyjdzie, że tych użytkowników nie ma, albo jest ich bardzo mało?

 

ALEKSANDER DYTKO

Odpowiedział bym, że albo zmieniamy swoją wizję produktu – czyli robimy pivota, chociaż pivot jest bardzo mocno kojarzony z tym, że już wyprodukowaliśmy jakiś system czy aplikację.

 

ROBERT ZATYCKI

Pivot, czyli co? Odwrócenie kierunku?

 

ALEKSANDER DYTKO

Tak. Mamy pewną wizję, ale ona nie działa w środowisku startupowym  jest bardzo często używane takie pojęcie, że produkt nie zażarł, czyli nie złapaliśmy trakcji, nie mamy użytkowników, którzy z tego chcą korzystać. No i musimy zatrzymać się na chwilę, trochę zabić swoje dziecko, którym jest produkt i pójść w inną stronę. Ta strona może być określona na podstawie tego, co już się nauczyliśmy, czyli z czego użytkownicy chcą korzystać. Jakie mają cele, a nie widzieliśmy ich na początku i zmieniamy ten produkt dostosowując do nowej wizji i nowego celu.

 

ROBERT ZATYCKI

Ok. Czyli te wszystkie skomplikowane odpowiedzi możemy uzyskać stosując tę metodę MVP, kiedy zbudujemy sobie jakiś prototyp i sprawdzimy czy ten nasz produkt ma sens czy po prostu go nie ma?

 

ALEKSANDER DYTKO

Dokładnie! Tutaj dotknąłeś jeszcze nowego pojęcia, czyli prototyp. Trochę idąc szerzej, tak patrząc na naszych klientów, albo w początkowym stadium rozwoju projektu chcą przetestować pewną hipotezę. Czyli, czy dana technologia, jeśli to jest produkt technologiczny, będzie nadawała się do spełnienia tego celu?  Na przykład połączenia dwóch systemów i zarządzania nimi. Albo chcemy przetestować, jak ten produkt finalny może wyglądać na takim małym skrawku, na przykład, jednego procesu.

 

ROBERT ZATYCKI

No i jak się do tego zabrać?

 

ALEKSANDER DYTKO

W tym pierwszym podejściu, czyli przy testowaniu pewnej hipotezy np. czy dana technologia pasuje do tego, co chcemy osiągnąć. Mówimy tutaj o takim podejściu POC, czyli proof of concept. Sprawdzamy, czy da się coś zrobić? Jest to w miarę szybkie, w miarę tanie i już po kilku dniach czy kilku tygodniach mamy odpowiedź, czy idziemy w tę stronę, czy jednak musimy użyć innego narzędzia albo inaczej to rozwiązać.

 

ROBERT ZATYCKI

A podejście drugie?

 

ALEKSANDER DYTKO

W drugim podejściu czyli prototypie, określamy sobie jaką ścieżką użytkownika ma ten użytkownik przejść, czyli co ma zostać wykonane i to robimy też w ramach kilku tygodniowych prac, tak żeby przetestować jak na tym skrawku systemu to będzie działać, to będzie wyglądać. Później możemy to rozwinąć do MVP, podłączając na przykład zewnętrzne systemy, integrując je z tym kawałkiem aplikacji i w kolejnych iteracjach rozbudowując je o potrzebne funkcjonalności, których użytkownicy potrzebują.

 

ROBERT ZATYCKI

Brzmi to wszystko bardzo fajnie, ale kto decyduje o tym, co będzie robione albo jakie funkcje są kolorowe dla danego produktu? Skąd przychodzą decyzje albo rekomendacje?

 

ALEKSANDER DYTKO

Po pierwsze ze strony wykonawcy, jeśli mówimy o takim modelu, w którym jest firma zlecająca, znająca się na swoim biznesie oczywiście. I jest firma technologiczna, która pomaga im pewne rzeczy wypracować, które pomogą im w osiągnięci celów. No i po tej stronie klienta, który zarządza swoim biznesem, ale też chce zbudować produkt, są oczywiście interesariusze. Ta firma ma swoich użytkowników już, czy swoich klientów, którzy obecnie korzystają z pewnych usług i czegoś im brakuje. Więc po pierwsze, zbierając zdanie interesariuszy – powinna być jedna taka osoba, która kontaktuje się z firmą wykonującą, która zarządza zestawem zadań, które są przekazywane do wytworzenia, czyli do zespołu deweloperskiego. I tutaj pojawia się taka rola Product Ownera. Product Owner to jest najczęściej jedna osoba po stronie klienta, która zbiera wszystkie zdania ze strony organizacji. Zbiera te interesy i decyduje o priorytetach. Czyli co wchodzi na kolejną iterację, jako nowe zadania i jakie są priorytety dla tych zadań, czyli w jakiej kolejności mamy je wykonać.

 

ROBERT ZATYCKI

Po drugiej stronie jest zespół deweloperski, który najczęściej jest mocno zmotywowany i chciałby wykonać swą pracę jak najlepiej, żeby być z tego dumnym i żeby się móc tym chwalić. No i pewnie często chciałby korzystać z nowych technologii, z nowych rozwiązań, bo nie każdy lubi się babrać w rozwiązaniach starych. I teraz, czy nie ma tutaj konfliktów czy jakiegoś przeciągania liny ze strony na stronę?

 

ALEKSANDER DYTKO

W tym podejściu, o którym powiedziałeś jest zespół deweloperski. Pewnie tam są różne role,  odpowiadające za to, co widzi klient końcowy, czyli frontendowcy, deweloperzy, którzy odpowiadają za to, co się dzieje pod spodem czyli backend deweloperzy plus architekci, którzy projektują całą architekturę tego systemu. I wszystkie te osoby, tak jak powiedziałeś, chcą bardzo często nauczyć się czegoś nowego, ale też z drugiej strony są zmotywowani, żeby dostarczyć wartość do klienta, bo wiedzą jaki jest cel budowy tego systemu czy tej aplikacji.

 

ROBERT ZATYCKI

A z twojego doświadczenia, czy klienci są gotowi na taki kredyt zaufania dla zespołu, że to zespół będzie decydował co i jak będzie zrobione?

 

W tym podejściu można zastosować dwie ścieżki albo idziemy bezpiecznie, czyli korzystamy z technologii, które są już przetestowane, są już od kilku czy kilkunastu lat na rynku i wiemy, że jest duża społeczność stojąca  za tą technologią, rozwijająca ją, działająca aktywnie, żeby odpowiadać na pytania. No i tutaj idziemy w takim podejściu, kiedy wiemy, co ma być zrobione. Używamy odpowiednich technologii do tego. Jednak w ramach działania tego zespołu deweloperskiego mogą pojawić się problemy czy trudności, żeby użyć technologii którą już znamy, ponieważ bardzo często napotykamy na taką rzecz, która nie jest do zrobienia przy wykorzystaniu technologii, które już mamy czytamy w projekcie.

 

ROBERT ZATYCKI

I wtedy musimy sięgnąć po coś nowego?

 

ALEKSANDER DYTKO

I wtedy sięgamy właśnie po coś nowego. Patrząc na to, jak u nas zespoły deweloperskie pracują, bardzo często korzystają z tego podejścia, o którym wcześniej powiedziałem, czyli proof of concept,  tak żeby bardzo szybko zwalidować, czy ta technologia nadaje się do realizacji tych zadań. Bo załóżmy, że budujemy system, który łączy się z systemami zewnętrznymi i potrzebujemy mieć takie miejsce centralne, które zarządza tymi różnymi systemami tak, żeby pewien proces był zrealizowany od początku do końca i te dane były przekazywane pomiędzy tymi systemami, a także żeby dane były walidowane po wprowadzeniu ich. Możemy sobie wyobrazić, że napiszemy to wszystko od początku budując ten nowy system tak, żeby spełnić ten cel. Jednak możemy zrobić krótki research na rynku, zobaczyć jakie są rozwiązania w tym obszarze i wybrać coś, co jest dedykowane akurat do tego.

 

ROBERT ZATYCKI

Czyli oszczędzamy tu czas i nie nadwyrężamy kompetencji zespołu, a przy okazji unikamy sytuacji, w której zespół utknie wraz z jakimś problemem, którego nie da się szybko rozwiązać. Dlatego chyba korzystniej jest pozwolić zespołowi wybrać jakąś technologię, żeby cel zrealizować.

 

ALEKSANDER DYTKO

Po wybraniu takiej technologii czy narzędzia, która pomoże nam zrealizowaniu tego celu możemy w kilka dni czy nawet w kilka godzin zwalidować, czy da się to zrobić w tej technologii lub sprawdzić, jak ta technologia jest rozwijana? Czy jakaś społeczność za tym stoi, która może pomagać przy rozwiązywaniu problemów? Więc zamiast budować własne rozwiązanie można użyć czegoś, co jest już gotowe, tak żeby zrobić to szybciej i taniej.

 

ROBERT ZATYCKI

Czyli mamy tutaj właściwie takie zagnieżdżone podejście MVP, bo z jednej strony podejście do produktu, a z drugiej strony – wewnętrznie – podejście do wyboru narzędzi technologicznych, sprawdzenia czy one działają, tak żeby szybko wiedzieć czy to, co robimy będzie miało w ogóle sens.

 

ALEKSANDER DYTKO

Więc wracając do tego, od czego tak naprawdę zaczęliśmy dzisiejszą rozmowę, chodzi w tym podejściu o to, żeby bardzo szybko walidować, czy nasze hipotezy są prawidłowe. Po pierwsze to, o czym teraz powiedziałeś, czyli ta warstwa taka najwyższa – czyli jaki ma być cel tego produktu, do jakich użytkowników ma trafiać, schodząc coraz niżej, aż do wyboru poszczególnych technologii do poszczególnych funkcjonalności. I tutaj też możemy posłużyć się tym szybkim walidowaniem naszej koncepcji, żeby sprawdzić czy dana technologia jest dobra do tej potrzeby, którą mamy. I albo zarzucamy to, albo idziemy dalej i już wdrażamy to produkcyjne, tak żeby nie okazało się na przykład po roku developmentu w danej technologii, że ona ma bariery i nie możemy pewnych rzeczy zrobić, które moglibyśmy przetestować już na samym początku.

 

ROBERT ZATYCKI

To podejście takiego sprawdzania raz za zarazem, czy to działa, to jest takie podejście charakterystyczne dla startupów, prawda? Gdzie te fundusze nie są za duże i trzeba szybko mieć jakieś efekty, żeby wiedzieć czy to czy to w ogóle ma sens?

 

ALEKSANDER DYTKO

Tak, ale też żeby to nie było w takim pojęciu gdzie tylko małe firmy czy startupy mają benefity z takiej metodyki pracy, to również w dużych organizacjach obserwuję, że coraz więcej takich firm, po których byśmy się tego nie spodziewali. Wdrażają podejście zwinne, gdzie w miarę w krótkich iteracjach wypuszczają produkt na rynek. Oczywiście w pewnych segmentach tego pełnego rynku, to jest utrudnione bo np. są regulacje prawne, bo np. są narzucone pewne rzeczy, które muszą być w każdym produkcie, więc te iteracje z natury będą dłuższe, czy to MVP będzie dłużej budowane. Ale zauważam, że te duże firmy również korzystają z tego, także na początku wypuszczają pewien zestaw funkcjonalności, który spełnia pewne potrzeby, a później, jeśli użytkownicy z tego korzystają, to inwestują więcej pieniędzy i zasobów, żeby to rozbudować, tak żeby to było coraz bardziej atrakcyjne.

 

ROBERT ZATYCKI

A kiedy możemy powiedzieć, że produkt przestał być już MVP?

 

ALEKSANDER DYTKO

Uważam, że dodanie takich, troszkę nazwijmy to bajerów do naszego produktu, już powoduje, że to nie jest MVP.  To znaczy MVP to jest taka minimalna wersja produktu, spełniająca dany cel biznesowy i kiedy dodajemy poboczne funkcjonalności, to już wtedy przestaje być MVP, tylko to już się staje rozbudowanym produktem czy aplikacją. Więc po takiej pierwszej wersji, która jest wdrożona zwykle po kilku miesiącach,którą nazywamy MVP, potem rozwijamy ją dodając kolejne funkcjonalności, dodając kolejne możliwości w tym produkcie, tak żeby stało się to pełnowartościowym produktem.

 

ROBERT ZATYCKI

Rozmawiamy sobie o samych fajnych rzeczach w tym podejściu, że jest to szybkie, że przy okazji nie tak drogie jak wytwarzanie pełnowartościowego produktu, że pozwala nam uniknąć szeregu błędów. Ale czy są jakieś minusy tego podejścia? Bo słyszałem taką opinię, że przy podejściu MVP, kiedy zdradzamy nasz pomysł, narażeni jesteśmy na to, że ktoś nam ten pomysł po prostu ukradnie. Spotkałeś się z takimi sytuacjami?

 

ALEKSANDER DYTKO

To częsta obiekcja żeby szybko zdradzać się z naszym pomysłem na produkt na samym rynku, tak żeby konkurencja nam tego nie ukradła. Ale zobaczmy to z innej strony.

 

ROBERT ZATYCKI

Czy jest to prawda czy jest to mit? Czy jest to taki jakiś lęk pierwotny, który bardziej ogranicza nam działanie? Czy jest tu więcej zysków, czy może narażeni jesteśmy na straty?

 

ALEKSANDER DYTKO

Opowiem ci o tym, co ja mam w głowie odnośnie tego podejścia, a potem sam osądzisz,  czy to ma więcej plusów czy minusów.

 

ROBERT ZATYCKI

Słuchacze osądzą…

 

ALEKSANDER DYTKO

Załóżmy, że mamy pewien pomysł którego jeszcze nie ma na rynku i przygotowujemy się do budowy tego systemu. Przez jakiś czas zbieramy najpierw fundusze, zbieramy odpowiednie osoby i odpowiedni zespół, który będzie go potem wytwarzał. Pracujemy nad naszą koncepcją, żeby to ubrać w funkcjonalności żeby stworzyć proto persony, czyli jacy użytkownicy będą z tego korzystać. No i załóżmy, że po pół roku powstaje pierwsza wersja produktu, czyli MVP, który jest wdrożony na rynek i testowany na realnych użytkownikach. W tym momencie, tak jak zauważyłeś, może pojawić się takie ryzyko, że ktoś nam ukradnie ten pomysł. Ale zobaczmy to od drugiej strony. Czyli my mamy przynajmniej sześć miesięcy więcej, ponieważ zaczęliśmy sześć miesięcy wcześniej i już mamy pierwsze wnioski z rynku. Spotkałem się też z takim podejściem, że firmy które są pierwsze w danej kategorii, tak naprawdę kształtują tą kategorię i każda kolejna firma, która będzie w tym segmencie, ma troszkę mniejszy udział udział w rynku.

 

ROBERT ZATYCKI

I przynajmniej na początku gorsze wyniki, bo wiadomo, że pierwsi klienci reagują lepiej i intensywniej na nowości, na nowe produkty nawet, jeśli te nie są jeszcze do końca dopracowane. Za to w późniejszym czasie takie zainteresowanie spada. I nawet kiedy konkurencja wzoruje się na czyimś pomyśle, to może mieć już znacznie trudniej.

 

ALEKSANDER DYTKO

Jest takie prawo, o którym kiedyś czytałem – prawo gównianych kliknięć, przepraszam za wyrażenie, ale naprawdę istnieje, które określa to, że następna firma w danej kategorii będzie miała gorsze rezultaty niż ta pierwsza.

 

ROBERT ZATYCKI

No tak, bo czas działa mocno na niekorzyść. Marnowanie czasu zazwyczaj się nie opłaca.

 

ALEKSANDER DYTKO

Myślę, że tak zostawię i sami osądźcie, czy to jest duże ryzyko, czy można z tym żyć wdrażając swój produkt.

 

ROBERT ZATYCKI

We wprowadzaniu produktów na rynek cyfrowy musimy być jak piloci myśliwców. Trzeba strzelać tam, gdzie samolot wroga będzie za chwilę, a nie gdzie jest w tej chwili. Bo jeśli będziemy strzelać w to miejsce, gdzie on jest w tej chwili, nigdy go nie trafimy.

 

ROBERT ZATYCKI

Nie mamy prostych odpowiedzi na każde pytanie, ani też nie mamy gotowej recepty na sukces, czy to technologiczny czy biznesowy. Za to możecie poznać tu różne punkty widzenia, które być może zainspirują was do pogłębienia wiedzy, a może nawet do działania.

 

ROBERT ZATYCKI

Dziękuję za wysłuchanie dzisiejszego odcinka i już zapraszam na kolejne. Do usłyszenia!

 

Dziękujemy!

Twój email został wysłany.

Nasz serwis internetowy używa plików cookies do prawidłowego działania strony. Korzystanie z serwisu bez zmiany ustawień dla plików cookies oznacza, że będą one zapisywane w pamięci urządzenia. Ustawienia te można zmieniać w przeglądarce internetowej. Więcej informacji udostępniamy w Polityce plików cookies.