Dzień dobry! Może kawkę?

Rozpoczynamy oficjalnie wspólne warsztaty. Na początek zawsze zapoznajemy się nawzajem przedstawiając członków zespołu, robimy kawkę i przedstawiamy mniej więcej jak będzie wyglądać najbliższy, wspólnie spędzony czas.

Warsztaty produktowe to również bardzo indywidualna sprawa więc zaznaczę tylko, że w tym artykule omówimy jak wygląda przykładowy, pojedynczy dzień warsztatowy. Należy pamiętać, że warsztaty potrafią trwać od jednego do kilku dni oraz bliżej nie sprecyzowaną ilość godzin jednego dnia. Staramy się jednak nie przekraczać pięciu godzin na dzień aby nie przeciążyć naszych komputerów w głowie oraz żeby myśli spływające podczas spotkania były w pełni sprawne i logiczne. Warsztaty prowadzi product designer. Prowadzone są według ustalonej wcześniej agendy ale tutaj również podczas warsztatów często wychodzą sprawy nie przewidziane ze strony zespołu klienta. Dla przykładu właściciel firmy opisał nam wstępnie pewne procesy w pewien sposób, natomiast po wysłuchaniu zespołu klienta wychodzi, że od kuchni diametralnie się to różni i wtedy improwizujemy. Spokojnie - to także część planu warsztatów. Dobrze, w takim razie poniżej w kilku punktach przedstawiamy przykładowy dzień warsztatowy a żeby było bardziej obrazowo, posłużymy się konkretnym przykładem.

Zakładamy, że klient chce stworzyć system CRM, który pomoże zespołowi w pewnych procesach zachodzących wewnątrz firmy, które do tej pory były rozsypane po kilku programach takich jak np. Excel. Następnie aby przekazać część informacji z działy pierwszego, Plik Excela jest drukowany lub wysyłany emailem do kolejnego i tak w kółko.

Więc startujemy!

• Rozpoczynamy od strony klienta z prośbą o przedstawienie wszystkim, krótko swojej firmy oraz wizji stworzenia produktu rozumianej przez klienta. Wiem, że była to część scoping session natomiast dobrze aby cały zespół usłyszał to osobiście w celu uniknięcia nieporozumień.

• Kolejnym krokiem jest sesja pytań oraz odpowiedzi. Jako, że prowadziliśmy wcześniej analizę po sesji scopingowej, zazwyczaj pojawiają się dodatkowe pytania, które warto na początku zadać. Oczywiście dotyczy to obu stron.

• Rzut oka na architekturę systemu z lotu ptaka. Czyli generalnie jest to poglądowe spojrzenie na wstępnie przygotowany rzut modułów, z którym mógłby składać się docelowy system informatyczny. Jest to w tym przypadku podział na elementy związane z administracją, bazę danych, z którym następnie będzie korzystać zespół, "pierwszy" dział firmy zajmujący się określonym zakresem informacji, dział "drugi" przejmujący dane od pierwszego oraz kolejne jeśli występują. Omawiamy te główne bloki oraz zastanawiamy się wspólnie czy potrzebujemy innego podziału lub może kolejnych bloków.

• Procesy fizyczne: Tutaj staramy się przejść z każdym działem główne procesy, które aktualnie są wykonywane w firmie aby zrozumieć jak funkcjonują oraz by móc zaproponować rozwiązania ułatwiające wykonywanie codziennych czynności jak i bezpieczne przechowywanie danych w odpowiednim miejscu. Procesy te tworzy product designer w schemacie blokowym w programie Figma Jam a opis tekstowy tworzony jest osobno, w tym wypadku głównym skrybą jest nasz project manager.

• Kolejnym blokiem prac, który poruszamy na warsztatach to opisanie modułów systemu bardziej szczegółowo. W zależności od ilości informacji, może to być na tych samych lub kolejnych warsztatach. Opisujemy wspólnie poszczególne widoki/zakładki/moduły, wyznaczając ich funkcjonalność oraz wstępną zawartość informacji. Dla przykładu jeśli jest to widok szczegółów kontrahenta, to omawiamy jakie informacje chcemy zbierać na jego temat, czy będą potrzebne np. dodatkowe notatki, powiadomienia lub lista osób kontaktowych. Tym przykładem idziemy po kolei po poszczególnych modułach aż opiszemy sobie cały produkt.

• Brainstorming: W trakcie warsztatów cały zespół może sobie zapisywać luźne sugestie, pomysły i przemyślenia aby przedstawić je na koniec spotkania. Ma to na celu nie zaburzanie przebiegu warsztatów gdyż wyobrażając sobie 7 osób na sali, którzy mają różne pomysły nie związane z omawianym w danym momencie modułem. Tworzy to spory chaos i utrudnia poprawne przeprowadzenie procesów. Omawiając pomysły na końcu ustalamy również ich priorytet oraz czas potencjalnego ich wdrożenia np. MVP, Etap 2 czy daleka przyszłość.

• Warsztaty kończymy podsumowaniem tego co udało się nam uzyskać danego dnia i przedstawiamy wstępny plan na kolejne prace. W zależności od tego czy widzimy konieczność spotkania się jeszcze raz lub może mamy zaplanowany ciąg spotkań, informujemy o tym zebranych i prosimy o przygotowanie się odpowiednio na kolejne współnedziałania.

Po każdych warsztatach nasze zespół analizuje zebrane informacje, układa je w struktury oraz aktualizuje cały plik warsztatowy aby był gotów na kolejną sesję. Zazwyczaj mamy też spotkanie wewnętrzne omawiające dotychczas zebrane materiały aby zadać dodatkowe pytania klientowi lub zaznaczyć, że dla przykładu: pewne pomysły wiążą się z większym nakładem prac deweloperskich i należy przemyśleć czy aby na pewno będzie to część MVP czy może przesuniemy coś na kolejny etap. W tym miejscu powstaje też zalążek architektury informacji oraz ścieżek użytkownika, które są tworzone na bazie zebranych danych o procesach fizycznych wewnątrz firmy.

Warsztaty kończymy spotkaniem podsumowującym i zdefiniowaniem wizji o czym już w kolejnym artykule.

Dzięki za Twój czas, wpadnij do nas ponownie.