Jak wyglądają warsztaty produktowe i biznesowe? Case Study Intilio.

W artykule opiszę projekt, który rozpoczęliśmy w styczniu 2020 roku. Myślę, że rzeczywisty opis zdarzeń lepiej zobrazuje Ci pierwszą fazę tworzenia produktu.

Definicję oraz opis warsztatów biznesowych i produktowych znajdziesz w naszym artykule „Warsztaty biznesowe – czym są i dlaczego warto brać w nich udział”. Tutaj chciałbym skupić się na wartościach jakie wnoszą warsztaty, a także omówić rzeczywisty proces ich realizacji.

Nowe rozwiązanie dla branży budowalnej

W grudniu 2019 skontaktował się z nami Maciej – właściciel rodzinnej firmy budowlanej USTR GmbH. Od wielu lat z sukcesem prowadzi firmę w Niemczech.

Maciej zaczął myśleć nad stworzeniem autorskiego systemu do zarządzania procesami w firmach budowlanych. Po kliku miesiącach miał już naprawdę konkretny obraz produktu, do którego dąży.

Zaprosiliśmy Macieja wraz z jego zespołem na spotkanie. Szczerze mówiąc byłem niemal pewny, że skoro nasz potencjalny partner posiada już obraz produktu, to bardzo ciężko będzie mu wytłumaczyć, dlaczego powinniśmy zacząć od warsztatów i jak wymodelować produkt. Maciej oczywiście rozmawiał też z innymi wykonawcami, ale tylko my zaczęliśmy rozmowę właśnie od warsztatów. Doznałem szoku. Jemu na tym właśnie zależało. Zdawał sobie sprawę, że zespół programistów nie jest budowlańcami. Nie znają dokładnie problemów, które pojawiają się podczas codziennej pracy na budowie.

Byłem zaskoczony, ale z drugiej strony cieszyłem się, że od pierwszego kontaktu myślimy podobnie i zaczyna budować się relacja. Maciej otrzymał oferty od innych wykonawców na stworzenie produktu. Od nas otrzymał ofertę na przeprowadzenie warsztatów – nie możemy wycenić czegoś, co jest opisane, ale nie przeanalizowane przez cały zespół. Maciej wybrał nas – i w ten sposób rozpoczęliśmy przygotowania do warsztatów.

Przygotowanie do warsztatów

Zaplanowaliśmy 5-dniowe warsztaty. Czas spędzony podczas warsztatów zawsze staramy się wykorzystać jak najefektywniej. Z tego względu wymagamy, aby zarówno nasz zespół, jak i zespół partnera był dobrze do nich przygotowany.

Podpisaliśmy umowę. Ustaliliśmy zespół. Przekazaliśmy do partnera listę zadań, które musi wykonać do czasu warsztatów. Jakie zadania otrzymał Maciej?

• Stworzyć opisową listę każdego członka zespołu – musimy wiedzieć jak najwięcej o każdej osobie, która bierze udział w warsztatach
  
• Przygotować się z tego, jak obecnie wygląda branża budowlana, ile różnych gałęzi jest w niej powiązanych i jakie posiadają zależności. Wybranie gałęzi, na której chcemy się najbardziej skoncentrować.
  
• Zastanowienie się, jakie dokładnie problemy występują w wybranej gałęzi. Jakich ludzi dotyczą?
  
• Zebranie informacji o potencjalnej konkurencji. Nie mam tutaj na myśli konkurencji tworzonego rozwiązania, ale konkurencji w branży. Konkurencję trzeba rozumieć jako wszystko to, co odciąga potencjalnego klienta od naszego rozwiązania. Przykład: konkurencją dla rozbudowanego narzędzia dla księgowych nie zawsze jest inne, podobne narzędzie, ale kartka i ołówek lub Excel.
  
• Zapoznanie się, czym jest Lean UX Canvas i Business Model Canvas
  
• Wybranie jednej osoby decyzyjnej, która będzie podejmowała kluczowe decyzje podczas warsztatów

Zacznijmy od Team Canvas

Spotkanie rozpoczęło się o 9:00 w naszej siedzibie w Rzeszowie. Wejście całego zespołu partnera. Wszyscy z uśmiechem na twarzy. Kawka, herbatka i krótka dyskusja. Każdy z zespołu po krótce się przedstawił i powiedział w jakiej dziedzinie jest ekspertem. Rozpoczynamy warsztaty!

Podczas warsztatów zarówno nasz zespół i zespół partnera musi stać się jednością. Żeby tak się stało, używamy narzędzia jakim jest Team Canvas. Pomaga ono odpowiedzieć na pytania takie jak:

• Kim jesteś i jaka jest Twoja rola?
• Jakie są Twoje cele projektowe / produktowe?
• Jakie są Twoje cele personalne?
• Jaką wartość możesz wnieść do zespołu?
• Jakie masz potrzeby i oczekiwania?
• Jakie zasady według Ciebie powinny obowiązywać w zespole?
• Co jest Twoją silną stroną?
• Jakie są Twoje słabości?
• Co jest dla Ciebie najważniejsze do osiągnięcia w trakcie trwania warsztatów? Do czego dążysz?

Każdy indywidualnie odpowiada na te pytania na karteczkach samoprzylepnych, które umieszcza na odpowiednim szablonie.

Następnie jako zespół omawiamy to, co pojawiło się na szablonie. Dzięki temu jesteśmy w stanie poznać się nawzajem i określić, czy na pewno mamy wspólny cel. Czy na pewno to jest zespół, który po następnych 5 dniach przybije sobie „piątkę” i powie:

„Tak! Udało się! Wiemy jak ma wyglądać nasz produkt MVP!”

Mapa obecnego biznesu

Rozwiązanie, które chce stworzyć Maciej wywodzi się z procesów, które zaimplementował w obecnym swoim biznesie (firmie budowlanej). Nasz zespół nie jest ekspertem w budowlance, dlatego musimy stworzyć razem mapę obecnego biznesu. Pozwoli to nie tylko zrozumieć nam wszystkie gałęzie branży budowlanej, ale również poukłada zależności między nimi w zespole naszego partnera. Tego typu mapa pozwala dokładnie określić:

• 5 najważniejszych procesów w firmie
• Aktorów (ludzi), którzy biorą udział w procesie
• Narzędzia informatyczne wspomagające obecne procesy
• Zewnętrznych dostawców ściśle powiązanych z procesami
• Kluczowe zasoby

Zbudowaliśmy mapę biznesu i co dalej? Maciej otrzymał czarny marker i proste zadanie – wraz ze swoim zespołem zdecydujcie, która gałąź Twojego biznesu będzie rozwijana za pomocą Twojej aplikacji. Zadanie niby proste, a jednak Maciej odpowiedział, że aplikacja ma dotykać każdej gałęzi.

I co w takiej sytuacji? Produkt MVP nie może od razu rozwiązywać wszystkich problemów. Na naszym blogu jest artykuł Jak stworzyć dobre MVP – taki produkt, to minimum funkcjonalności, które rozwiązują najważniejszy problem. Maciej od razu zrozumiał o co chodzi i zaznaczył markerem gałąź, która będzie dalej eksplorowana przez cały zespół 🙂

Jak ma wyglądać proces usługowy?

Kolejnym krokiem było stworzenie pełnego procesu usługowego dla wybranej gałęzi biznesu. Co to oznacza? Musieliśmy przeanalizować jak wygląda działalność wybranej gałęzi, wcielając się w różnych aktorów odpowiedzialnych za zadania z procesu.

Stanęliśmy w roli klienta firmy budowlanej, opiekuna klienta, pracownika budowlanego, a także wzięliśmy pod uwagę działania obecnych systemów informatycznych. Na tej podstawie zbudowaliśmy historię, w której określiliśmy, jakie konkretnie czynności są wykonywane przez każdego z aktorów. Braliśmy pod uwagę nie tylko firmę Macieja, ale także inne firmy z branży. Ważnym dla nas było znalezienie w tym procesie pułapek, które powodują, że branża w danym miejscu kuleje.

Czy zastanawiałeś się kiedyś jak ważnym elementem procesu sprzedażowego w branży budowlanej jest przekazanie kluczy do remontowanego mieszkania? Niby proste, ale popatrz jakie problemy mogą się pojawić:

• Klient przekazuje przez pomyłkę nieprawidłowy komplet kluczy
• Klient przekazuje jedyny komplet kluczy, jaki posiada i co chwilę prosi o możliwość wejścia
• Firma budowlana gubi przekazane klucze
• W trakcie trwania prac, ktoś dorabia klucze do nieruchomości i okrada ją

Niby problemy i sytuacje, o których każdy myśli, ale czy nie można tych sytuacji w prosty sposób rozwiązać? Żeby dojść do rozwiązania trzeba najpierw zauważyć problemy – stworzenie procesu usługowego na to pozwala.

Czas opracować rozwiązania dla wskazanych problemów

Skoro znaleźliśmy problemy i pułapki w procesie usługowym to przyszedł czas na rozwiązania tych sytuacji. Pomysłodawca posiadał rozwiązania dla większości z tych problemów – w końcu sam się z tymi problemami spotkał i to spowodowało pojawienie się pomysłu na aplikację.

Nic bardziej mylnego. Na tym etapie ujednoliciliśmy naszą wiedzę. My jako programiści i specjaliści od budowania aplikacji webowych, poznaliśmy branżę budowlaną. Dowiedzieliśmy z jakich obszarów jest zbudowana. Wraz z partnerem przeszliśmy jeden wybrany proces, który jest kluczowy dla stworzenia narzędzia w wersji MVP. Partner pokazał nam, na czym jemu zależy. Tutaj pojawiają się kluczowe pytania:

• Czy na tym samym zależy potencjalnym użytkownikom tego rozwiązania?
• Czy na pewno problem, który według niego dotyczy całej branży budowlanej, jest na tyle duży, że firmy zdecydują się na wdrażanie nowego systemu informatycznego?
• Skąd wiemy, czy nasze rozwiązanie problemu trafi w gusta użytkowników? Każdy problem można rozwiązać na kilka rożnych sposobów – czy wybrany przez nas sposób będzie odpowiedni dla Naszej grupy docelowej?

Lista funkcjonalności, jako odpowiedź na realne potrzeby

Dziwne prawda? Mieliśmy podczas warsztatów odpowiadać na kolejne pytania, a tutaj pojawia się ich coraz więcej. I to jest właśnie eksploracja – zadajmy jak najwięcej pytań, dyskutujmy i starajmy się podejmować jak najbardziej przemyślane decyzje!

Z pomocą przychodzi Lean UX Canvas – narzędzie, które pozwoli nam poukładać najważniejsze wartości naszego produktu. Podczas prac określamy:

• Problemy z podziałem na kategorie, które pojawiają się w procesie usługowym
• Jakie zmiany w zachowaniu klientów wskażą, że rozwiązaliśmy problem w sposób, który stanowi wartość dla tych klientów?
• Klientów i użytkowników rozwiązania, których będą dotyczyć te problemy
• Jakie cele chcą osiągnąć klienci i użytkownicy rozwiązania?

Dzięki wypracowaniu informacji na tym szablonie, będziemy w stanie stworzyć listę funkcjonalności, które realnie odpowiedzą na potrzeby rynku. Dodatkowo, będziemy wiedzieć do kogo kierujemy rozwiązanie i w jaki sposób komunikować wartości produktu.

Po przejściu powyższych pytań, powinniśmy zacząć pracę nad budowaniem listy modułów, które mają znaleźć się w MVP. Podczas tych warsztatów tak nie było. Maciej był bardzo dobrze przygotowany. Posiadał szczegółowe i przemyślane opisy modułów, o których rozmawialiśmy. Z tego względu zamiast od razu przechodzić do wyboru zakresu produktu, moderator warsztatów – Mateusz, postanowił, że przekaże pałeczkę Maciejowi.

Decyzja Mateusza była słuszna, chodź kontrowersyjna. Oddał cały dzień tylko po to, żeby Maciej „przeczytał nam swoje opisy”. Według mnie decyzja była w stu procentach trafiona –nie przeczytał nam tylko swoich opisów. On opowiedział nam o modułach wplatając w to dużo doświadczeń sytuacyjnych z jego firmy. Zespół jeszcze bardziej zidentyfikował się z branżą budowlaną.

Wysłuchaliśmy wszystkiego i teraz dopiero przeszliśmy do wyboru funkcjonalności do MVP. Wspólnie wypracowaliśmy zakres produktu. Pojawiły się też „rodzynki”, czyli pomysły, które mogą być doskonałe na pierwszy etap rozwoju produktu po etapie MVP. Wszystko w formie karteczek samoprzylepnych umieściliśmy na kolejnym naszym szablonie.

Jest zakres produktu – poproszę wycenę

Wybraliśmy zakres produktu. Zrozumieliśmy, jakie problemy mamy rozwiązać i gdzie pojawiają się pułapki. Znamy punkt widzenia naszego partnera, ale wiemy też na czym może zależeć grupie docelowej produktu. Czy to już wszystko, aby dokonać estymacji (wyceny) produktu? Nie.

Samo określenie problemu i rozwiązania nie definiuje sposobu wdrożenia danego rozwiązania. Na tym etapie wiedzieliśmy już jakie funkcje mamy zbudować, ale nie znamy jeszcze kontekstu biznesowego – a to potrafi bardzo mocno namieszać.

Przeszliśmy do określenia modelu biznesowego danego produktu. Na środku stołu pojawił się Business Model Canvas. Szablon, według którego zbudujemy sobie obraz pod względem biznesowym, a także dowiemy się na co możemy sobie pozwolić.

Wszystkie zagadnienia z Business Model Canvas dotyczą już punktu biznesowego. Niejednokrotnie całość warsztatów zaczynamy od tego elementu. Dzieje się to zazwyczaj wtedy, kiedy pracujemy nad pomysłem, który nie bazuje na domenowej branży pomysłodawcy, a jest rozwiązaniem rynkowym. Tutaj musieliśmy zacząć od analizy branży i produktu, aby zrozumieć decyzje biznesowe partnera.

Pobierz Business Model Canvas do samodzielnego uzupełnienia szablonu

Pobierz

Event Storming

Przechodzimy do ostatniego etapu warsztatów. Teraz będziemy budować poprawny proces, który powinien być połączeniem wypracowanego procesu usługowego, ulepszonego o powstałe rozwiązania problemów. Dodatkowo, dokładamy do całości aktorów aplikacji, działania systemów zewnętrznych oraz samej aplikacji, którą będziemy tworzyć w przyszłości.

Do tego zadania wykorzystujemy narzędzie Event Storming. Możesz przeczytać w naszym wcześniejszym artykule o tym czym jest Event Storming. Rozpoczęliśmy od wypisania wszystkich możliwych akcji, jakie mogą wydarzyć się w aplikacji i poza nią, ale w obrębie gałęzi, którą eksplorujemy. Powstało ok. 400 akcji, które trzeba poukładać i zbudować z nich proces. I od tego zaczęliśmy.

Czy dodawanie kontaktu to akcja, która jest realizowana zawsze tak samo? Każdy z nas ma inny obraz poszczególnych elementów. Podczas Event Stormingu sprowadzamy każdą akcję do jednego wspólnego obrazu, co pozwala w przyszłości uniknąć pomyłek na poziomie zrozumienia intencji.

Układanie procesu trwało 2 całe dni. Na koniec przeczytaliśmy cały proces, jednocześnie nagrywając narrację. Dlaczego? Podczas nagrywania tworzy się w zespole chęć dopieszczenia każdego elementu. W czytanej na głos „opowieści” o wiele łatwiej jest znaleźć brakujące elementy lub błędy, niż wtedy gdy proces jest czytany indywidualnie „w głowie”.

Koniec warsztatów – co dalej?

Piątek, godzina 17:00. Kończymy warsztaty. Wypracowaliśmy ogrom materiałów, które zostaną przeniesione do wersji elektronicznej. Zespół zgrał się i doskonale wie, do czego dąży. Cel osiągnięty – wiemy jak ma wyglądać MVP!

Pożegnaliśmy się z Maćkiem i jego zespołem. Teraz została praca dla nas. Musimy przecież podać koszt zbudowania takiego rozwiązania. W tym celu zastosowaliśmy Poker Planning. Jest to technika, która pozwala na szybką estymację projektów informatycznych.

Dokonaliśmy estymacji i przekazaliśmy ją partnerowi. Okazało się, że ilość funkcjonalności spowodowała przekroczenie budżetu i czasu trwania projektu, który zakładał Maciej.

MVP vs. budżet

Założeniem MVP jest stworzenie rozwiązania do danego problemu, możliwie szybko i jak najniższym kosztem. Stąd pojawiła się u Nas czerwona lampka przy wycenie. Nie znaliśmy jeszcze budżetu klienta, ale już wiedziałem, że nie możemy iść w tą stronę.

Spotkaliśmy się na telekonferencji i jeszcze raz przeanalizowaliśmy, czy na pewno wszystkich rozwiązań potrzebujemy. W ten sposób zredukowaliśmy estymowany czas pracy (a jednocześnie budżet) z 7 do 3 miesięcy. Teraz jest to faktycznie czas na zbudowanie MVP 🙂

No to startujemy!

Maciej zdecydował się na współpracę z nami. Bardzo mocno spodobało mu się nasze podejście:

„My nie chcemy wystawić jak najwyższej faktury. Chcemy, aby Twój produkt osiągnął sukces.”

Dobra, to siadamy i zaczynamy programowanie. O nie, nie z nami te numery 🙂 Teraz pytanie – skąd wiemy, czy powinniśmy umieścić zielony przycisk na widoku u góry po prawej stronie, a niebieski na dole po lewej stronie? Nie wiemy tego. Jesteśmy doświadczeni, ale nie znamy preferencji użytkowników każdej grupy docelowej. Uwierzcie mi, że jest ich bardzo dużo. Naszym kolejnym krokiem jest ułożenie tego, co wypracowaliśmy w prostą Mind Mapę, zbudowanie User Flow, które będzie odkształceniem poruszania się użytkownika po aplikacji, a następnie zbudowanie klikalnych prototypów, których użyjemy do testów na użytkownikach.

Tak, dobrze przeczytałeś. Nie zaczynamy programowania. Zaczynamy od testów na użytkownikach z naszej grupy docelowej. Muszą nam powiedzieć co jest dla nich wygodniejsze i w jaki sposób umieścić poszczególne elementy. Dopiero po serii testów, będziemy w stanie zaprojektować odpowiednio system i zacząć programowanie. Ale o tym będzie w kolejnych artykułach 🙂

Co sądzisz o warsztatach? Czy Twoim zdaniem Maciej faktycznie ich potrzebował? A może uważasz, że zabrakło jakiegoś elementu? Chętnie posłucham Twojej opinii – zapraszam do dyskusji w komentarzach!