Najczęściej kiedy dochodzi do pierwszego kontaktu pomiędzy nami a klientem zadajemy klientowi sporo szczegółowych pytań dotyczących pomysłu na aplikację, oprogramowanie, MVP. Chcemy w ten sposób dowiedzieć się, czy pomysł, który klient chce zrealizować faktycznie został w jakiś sensowny sposób zwalidowany. Klienci często idealizują swój projekt, wychodząc z założenia, że to co wymyślili jest na tyle unikatowe, przełomowe, że nie może się nie udać. Problemem jest sam fakt, że najczęściej nie były przeprowadzane żadne analizy, warsztaty, nawet zwykłe rozmowy o produkcie z potencjalnymi klientami. Często klienci mówią “Po co nam warsztaty, doskonale wiemy co chcemy zrobić, jak ma działać aplikacja itp.” Niestety jest to błąd, nie powinno się zakładać, że tego co my chcemy chce reszta świata. Warsztaty Product Discovery mają właśnie odpowiedzieć na najbardziej kluczowe pytania, znaleźć rozwiązania i stworzyć produkt, który finalnie będzie dopasowany do potrzeb klientów, aby odniósł sukces na rynku.
Warsztat Discovery jest nieocenionym etapem każdego projektu MVP. Musisz z niego skorzystać jeśli chcesz, aby Twój produkt digitalowy odniósł sukces rynkowy.
Jest to proces, który w sposób uporządkowany przechodzimy przez fazę odkrycia, czyli jakie cechy powinien mieć produkt, jakie są potrzeby klientów, jak powinien wyglądać i zachowywać się cyfrowy produkt, jakie ma mieć cele. Precyzujemy je poprzez właśnie warsztaty, brainstorming, dyskusje oraz analizę pomysły na aplikacje.
Proces w Warsztatach Product Discovery w zasadzie skupia się na danych wejściowych czyli poznajemy potrzeby użytkowników oraz dostarczamy pomysły na ich zaspokojenie, po to aby finalnie opracować usługę, produkt, które w 100% będą odpowiadać potrzebom użytkowników.
Istotą jest zbieranie na każdym etapie dowodów, chcemy mieć pewność, że problem, który staramy się przekształcić na usługi lub produkty, faktycznie rozwiązuje potrzeby klientów i jest on fundamentalny dla użytkowników aplikacji oraz dla biznesu.
Proszę pamiętać, że najlepsze pomysły nie mogą być izolowane od użytkowników, musimy je zwalidować przy ich udziale. Chronienie pomysłu przed walidacją jest najgorszym z możliwych pomysłów, ponieważ nie mamy możliwości sprawdzenia jak faktycznie użytkownik reaguje na naszą usługę lub produkt. Jeśli więc chcesz faktycznie sprawdzić czy Twój pomysł jest przełomowy, to Warsztaty Product Discovery są jedynym sposobem aby zweryfikować pomysł na MVP.
Warsztaty Discovery robimy po to, aby zweryfikować pomysł na produkt cyfrowy przed wytworzeniem go. Taniej i łatwiej jest zrobić to na papierze przed wypuszczeniem go na rynek, niż zweryfikować pomysł po zakończonym procesie developmentu, czyli sprawdzaniu pomysłu na aplikację na realnym rynku. Warsztaty Discovery można również stosować już w późniejszych etapach wytwarzania aplikacji.
Jednym z głównych atutów Warsztatów Product Discovery jest schemat, który prowadzi nas za rękę i pozwala niezależnie od etapu na wyciągnięcie z projektu kluczowych informacji. Jest to forma, która zapobiega generowaniu zbyt płytkich, nie zwalidowanych pomysłów, które potem okazują się kosztownymi błędami. Zwykle klient chce jak najszybciej przejść do etapu opracowywania aplikacji z pominięciem etapów początkowych, które są kluczowe dla odniesienia sukcesu Twojej aplikacji.
Zbyt szybkie przechodzenie do developmentu z pominięciem Warsztatów Discovery, doprowadza do sytuacji, w której najczęściej zrealizowany pomysł jest nikomu niepotrzebny, nikt z niego nie chce z niego korzystać.
Odpowiedzieć brzmi jak zwykle to zależy. Jeśli posiadasz dokumentację projektową, przemyślaną ścieżkę opracowywania produktu, to być może nie ma sensu inwestowania w dodatkowe Warsztaty Projektowe. Niestety nie możemy odpowiedzieć na to pytanie za klienta. Jeśli uważa, że takie warsztaty powinny być jednym z etapów prac projektowych, to im wcześniej przejdziemy przez nie tym więcej wyciągniemy informacji na temat produktu lub usługi. Opierając się na naszych dotychczasowych doświadczeniach, większość klientów nie uwzględnia wszystkich elementów w projekcie, nawet tych najbardziej ważnych. Z reguły skupia się na własnej wizji swojego produktu, w dodatku idealizując go, uważając, że zna swój produkt najlepiej i nic go nie zaskoczy. W rzeczywistości jednak pominięcie tego etapu jest ogromnym błędem. Równie dobrze można byłoby również zrezygnować z wizualizacji i tworzyć widoki aplikacji MVP w locie przez programistę na podstawie dostarczanych na bieżąco przez klienta wymaganiach. Podejście takie jest ekstremalne i raczej skończy się katastrofą.
Zastanówmy się nad kilkoma kwestiami:
Zasada ta dotyczy również wytwarzania produktów i usług cyfrowych takich jak aplikacje, usługi SaaS itp. Jeśli lubisz szybko działać i ponosić ryzyko ta zasada nie jest dla Ciebie. Ona pozwala ograniczać straty i podnosić jakość produktów. Generalnie szybkie i nieprzemyślane działania generują w przyszłości problemy, koszty. Najczęściej działając szybko nie zwracamy uwagi na te elementy, które są najbardziej potrzebne. Jeśli je zauważamy, pomijamy stwierdzając, że może uda się to naprawić później. Niestety im dalej idziemy z projektem tym trudniej to naprawić. Jeśli więc uważasz, że pośpiech w tworzeniu oprogramowania jest ważna, to de facto skazujesz się na ogromne problemy i koszty w przyszłości.
Zasada 1-10-100 została zaczerpnięta z teorii jakości. Zasada ta mówi nam, że im szybciej zauważymy błąd, tym wcześniej poprawimy go, a w konsekwencji koszty naprawy będą najmniejsze.
Zasad x1
Najtańsze jest korygowanie błędów na najwcześniejszym etapie. Zatem jeśli przeprowadzimy Warsztaty Discovery możemy znacznie wcześniej wyłapać błędy. Należy zatem testować koncepcje, walidować pomysł, sprawdzać wymagania, analizować projekt, potwierdzać założenia zanim przekażesz projekt do wdrożenia. Na tym etapie korekcja 1 wykrytego błędu w zasadzie jest nieodczuwalna finansowo.
Zasada x10
Wykrycie błędu na tym etapie a następnie korekcja błędu kosztuje już 10 krotnie więcej niż na etapie projektowym. Z reguły wykrycie błędu jest już na etapie programowania aplikacji.
Poprawienie błędu wymaga współpracy całego zespołu testerskiego, programistów oraz biznesu. Zaangażowanie tylu osób w naprawę błędu powoduje straty finansowe i opóźnienia w harmonogramie prac.
Zasada x100
Wykrycie błędu już na etapie oddania na produkcję, czyli uruchomienie aplikacji na serwerze klienta jest najgorszym scenariuszem. Koszt naprawy tego błędu wynosi 100 krotność kwoty, którą wydalibyśmy na naprawę błędu na etapie projektowym. Jest to koszt finansowy, alternatywny np. utraconych korzyści, utratę reputacji. Naprawa błędu wiąże się z wycofaniem produktu, usługi z rynku, analizą aplikacji, założeń biznesowych oraz zatrudnieniem ponownie specjalistów IT, którzy naprawią jeśli jest to możliwe wykryte błędy.
Zasada ta ma również odniesienie do poprawności założeń. Zatem warsztaty discovery pozwalają również na analizę założeń pod kątem adekwatności. Analizujemy cele projektu, wymagania, UX/UI, bezpieczeństwo aplikacji.
Najlepszym sposobem na uniknięcie niespodzianek w projekcie oraz szybkie rozpoczęcie tworzenia aplikacji internetowych lub tworzenia aplikacji mobilnych jest rozpoczęcie procesu projektowego o nazwie Warsztaty Discovery w tworzeniu MVP. Jest to pewnego rodzaju framework oparty o pracę z klientem, który ma zapewnić znalezienie najlepszego rozwiązania oraz ścieżki wytworzenia aplikacji. Naszym celem jest poprowadzenie klienta, aby uświadomił sobie jak faktycznie powinna wyglądać oraz działać jego aplikacja.
Nasze Warsztaty Discovery podzieliliśmy na kilka logicznych etapów, które prowadzą nas do odkrycia czym jest produkt. Dzięki kolejnym etapom w Warsztatach Discovery gromadzimy wiedzę na temat aplikacji oraz generujemy szkice przyszłego produktu.
Efektywne Warsztaty Discovery w projektowaniu MVP wymagają udziału grupy osób reprezentujące różne punkty widzenia. Planując nasze warsztaty, bierzemy pod uwagę nie tylko nasz wewnętrzny zespół, który ma pomóc klientowi rozwijać produkt, ale również osoby od strony klienta czyli tych, którzy znają zarówno specyfikę biznesową projektu jak również grupę docelową.
Z reguły w skład zespołu uczestniczącego w Warsztatach Discovery są:
Facylitator
Projektant UX
Projektant interfejsu użytkownika
Programiści inaczej deweloperzy
Project Manager
Product Owner
Interesariusze (biznes)
Interesariusze (grupa docelowa)
Odpowiednio dobrani uczestnicy warsztatów są kluczowi dla skuteczności całego procesu.
Nawet jeśli może się wydawać, że Warsztaty Discover mogą jedynie generować koszt, i nie było planu w budżecie na tego typu działania to są one całkowicie tego warte. Ograniczają ryzyka, szczególnie finansowe, przynoszą wiele ważnych podpowiedzi, które przyczyniają się do sukcesu produktu, ale przede wszystkim chronią przed ewentualną porażką. Przeprowadzenie Warsztatów Discover na początku tworzenia aplikacji MVP zminimalizuje ryzyko zbudowania niewłaściwej aplikacji, pomoże wszystkim zaangażowanym zrozumieć, kim są użytkownicy i jak produkt wpłynie na użytkownika. Zdefiniuje jasne, realistyczne cele dla aplikacji MVP.