Warsztat discovery przed budową aplikacji: jakie decyzje powinny z niego wyniknąć

Po co spotykać się przed projektem

Warsztat discovery to uporządkowana rozmowa o problemie, który aplikacja ma rozwiązać. Jego dobrym wynikiem nie jest lista ekranów ani prezentacja pełna kolorowych karteczek. Jest nim zestaw decyzji: komu i w jakiej sytuacji trzeba pomóc, co sprawdzimy przed budową oraz jak rozpoznamy, że pierwsza wersja działa w praktyce. Czasem rezultatem będzie również decyzja, że nowa aplikacja nie jest jeszcze potrzebna.

Przykład: zespół obsługuje zlecenia w kilku miejscach i chce mieć jeden widok sprawy. Kierownik widzi przede wszystkim brak raportu, osoba przyjmująca zlecenia wskazuje na niepełne dane, a pracownik w terenie potrzebuje informacji bez stałego połączenia. Każda z tych obserwacji może być prawdziwa. Warsztat pomaga sprawdzić, jak łączą się w jeden proces i od czego zależy usunięcie opóźnień. To przykład sytuacji, nie opis realizacji Archifutura.

Nie trzeba zaczynać z kompletną specyfikacją. Przygotuj raczej opis jednej sprawy, która dobrze pokazuje problem, i zaproś osoby znające jej przebieg. Jeśli projekt jest jeszcze na etapie pierwszego zamówienia, pomocny będzie też tekst o tym, jak przygotować rozmowę o aplikacji. Sam warsztat idzie o krok dalej: zamienia przypuszczenia z tej rozmowy w pytania i ustalenia, które da się sprawdzić.

Kogo zaprosić i o co poprosić przed spotkaniem

Wybierz osoby według wiedzy potrzebnej do decyzji, a nie miejsca na schemacie organizacyjnym. Przydadzą się osoba odpowiedzialna za wynik procesu, osoba wykonująca codzienną pracę oraz przedstawiciel zespołu, który później utrzyma lub zintegruje rozwiązanie. Jeżeli potrzebne są decyzje o dostępie do informacji, zaproś również osobę, która zna zasady bezpieczeństwa. Przy małym projekcie kilka ról może pełnić jedna osoba.

Uczestnicy nie muszą spędzać całego dnia w jednym pokoju. Część pytań wymaga obecności osoby decyzyjnej, inne najlepiej omówić z kimś, kto przyjmuje sprawy albo poprawia błędy. Ustal wcześniej, kto podejmuje decyzję w razie rozbieżnych potrzeb. Bez tego spotkanie może bardzo sprawnie wyprodukować trzy sprzeczne listy priorytetów.

Poproś o przykładowy przebieg zadania, nazwy używanych narzędzi, wzór dokumentu pozbawiony wrażliwych danych i znane ograniczenia. Nie przesyłaj haseł ani kluczy dostępowych w materiałach warsztatowych. Jeśli nie da się pokazać prawdziwego przypadku bez ryzyka ujawnienia danych, przygotuj fikcyjny zapis z zachowaniem struktury. Ważne, żeby uczestnicy mogli pokazać kolejność czynności i potrzebne informacje.

Przed rozpoczęciem nazwij cel pytaniem, na przykład: „Co musi wiedzieć osoba obsługująca zlecenie, żeby przekazać je dalej bez ponownego telefonu?”. To pytanie prowadzi do konkretnych obserwacji. Hasło „zróbmy nowoczesny system” pozostawia zbyt wiele miejsca na domysły, w tym na bardzo nowoczesne domysły.

Przygotuj również reguły pracy. Osoba prowadząca pilnuje pytania i czasu, lecz nie powinna rozstrzygać za zespół, jak wygląda rzeczywistość. Osoba zapisująca ustalenia notuje rozbieżności i daty, a właściciel procesu potwierdza, które decyzje należą do niego. W większej organizacji może być potrzebna także konsultacja z osobą spoza spotkania. Zaznacz ją w notatkach zamiast przedstawiać decyzję jako ostateczną.

Odtwórz prawdziwy przebieg sprawy

Poproś jedną osobę o opowiedzenie ostatniego typowego zadania od początku do końca. Kto je rozpoczął? Skąd przyszły informacje? Co działo się po drodze, kto podjął decyzję i kiedy sprawę uznano za zamkniętą? Przy każdym kroku zapisz narzędzie, dane wejściowe, osobę odpowiedzialną oraz wynik. Zamiast pytać wyłącznie, jak proces powinien wyglądać, dopytaj, co dzieje się rzeczywiście.

Przydatne są konkretne przykłady: uzupełnienie brakującego adresu, korekta błędnej pozycji, przekazanie sprawy podczas nieobecności pracownika. Jeśli dwie osoby opisują różne wersje, nie wybieraj automatycznie tej bardziej eleganckiej. Być może obie dotyczą innych oddziałów albo różnych typów klientów. Rozbieżność jest wskazówką do sprawdzenia, a nie przeszkodą, którą trzeba usunąć z notatek.

Obok przebiegu zaznacz momenty oczekiwania i powrotu do wcześniejszego kroku. Nie zakładaj, że samo usunięcie jednego formularza rozwiąże problem, jeżeli zatwierdzenie i tak wymaga dodatkowej decyzji. W projekcie obejmującym różne lokalizacje warto przeczytać o tym, jak uzgodnić wspólne zasady między oddziałami, pozostawiając miejsce na rzeczywiste różnice.

Jeśli w opowieści pojawia się krok „potem to się samo aktualizuje”, poproś o pokazanie, co faktycznie uruchamia zmianę. Zmianę może uruchamiać pracownik, poranny import albo ręczna aktualizacja po wiadomości od współpracownika. Takie doprecyzowanie pomaga zobaczyć zależności, których nie widać w samej nazwie systemu. Można je zapisać bez rozstrzygania jeszcze, jak ma działać przyszła integracja.

Wyjątki, dostęp i dane

Mapa zwykłego przebiegu jest punktem wyjścia. Następnie wybierz sytuacje, które mogą zmienić decyzję o projekcie: brak wymaganej informacji, błędne dane z innego systemu, przerwę w dostępie, cofnięcie zgody lub potrzebę poprawienia sprawy po jej zamknięciu. Nie trzeba omawiać wszystkich możliwych awarii świata. Wystarczy wskazać te, które uczestnicy już znają albo które mogą mieć istotne skutki.

Do każdego wyjątku dopisz, kto go zauważy, co może zrobić i jakie informacje zobaczy następna osoba. Jeśli zgłoszenie utknie, potrzebna jest odpowiedzialność za dalszy krok, a nie tylko czerwony komunikat. Więcej o takich decyzjach przeczytasz w artykule o monitorowaniu automatyzacji i obsłudze błędów.

Zrób osobną listę danych: skąd pochodzą, kto może je poprawiać i komu są potrzebne. Gdy numer klienta występuje w kilku systemach, trzeba ustalić sposób identyfikacji tej samej osoby oraz postępowanie przy rozbieżności. O tym, jak wyznaczać źródło danych w integracji systemów, piszemy szerzej w osobnym tekście.

Nie zamieniaj warsztatu w prośbę o pełny dostęp do systemów. Na tym etapie ważniejsze jest ustalenie, jakie dostępy będą potrzebne do dalszego rozpoznania i kto może je przyznać. Jeżeli dane obejmują informacje o zdrowiu, finansach albo dokumentach pracowników, odpowiednie osoby powinny osobno ocenić bezpieczny sposób pracy z tym materiałem.

Prototyp ma odpowiedzieć na pytanie

Kiedy zespół zrozumie przebieg zadania, może narysować prosty ekran lub kolejność widoków. Prototyp nie musi mieć docelowej grafiki ani działać z prawdziwymi danymi. Jego zadaniem jest sprawdzenie konkretnego pytania: czy osoba przyjmująca zgłoszenie potrafi znaleźć brakujące informacje i przekazać sprawę dalej? Jeśli odpowiedź brzmi „nie wiemy”, warto poprosić przyszłego użytkownika o wykonanie zadania i obserwować, gdzie się zatrzymuje.

Nie pokazuj gotowego rozwiązania wyłącznie osobom, które je wymyśliły. Poproś uczestnika testu, aby własnymi słowami opisał, co widzi i czego spodziewa się po kolejnym działaniu. Różnica między intencją projektanta a oczekiwaniem użytkownika bywa cenniejsza niż długa dyskusja o kolorze przycisku. Szczegóły przygotowania takiej próby opisujemy w tekście o testowaniu prototypu z pracownikami.

Jeśli warsztat nie pozwala na test z użytkownikami, zapisz to jako otwarte zadanie. Ustalenie grupy odbiorców i zebranie ich doświadczeń może wymagać osobnej pracy. Brytyjski GOV.UK Service Manual podkreśla w materiałach o fazie discovery poznanie potrzeb, obecnych sposobów pracy i trudności użytkowników. To podejście można dopasować do firmy, bez kopiowania całego procesu administracji publicznej.

Zanim rozpoczniesz test, uzgodnij, jakie zadanie zlecisz i czego nie będziesz podpowiadać. Prośba o znalezienie historii zlecenia mówi więcej niż pytanie, czy ekran jest intuicyjny. Po próbie oddziel obserwację od interpretacji: „uczestnik otworzył trzy zakładki przed znalezieniem statusu” jest obserwacją, a „potrzebuje większego przycisku” dopiero propozycją wyjaśnienia. Warto zanotować obie, ale nie mieszać ich w jednym wniosku.

Zapisz decyzje, a nie tylko notatki

Dobry zapis po spotkaniu oddziela fakt od hipotezy. „Zespół korzysta z dwóch rejestrów” można potwierdzić przez obserwację. „Jeden ekran usunie opóźnienia” jest przypuszczeniem, które dopiero trzeba sprawdzić. Przy każdym otwartym pytaniu wpisz osobę odpowiedzialną, sposób sprawdzenia oraz moment, do którego odpowiedź jest potrzebna.

Efektem może być krótka mapa procesu, lista potrzeb użytkowników, kilka najważniejszych wyjątków, przegląd zależności i propozycja kolejnego kroku. Dokument powinien też pokazać decyzje odłożone na później oraz warunki, które mogą zmienić zakres. Nieznane zasady dostępu do zewnętrznego systemu są ryzykiem do sprawdzenia, a nie szczegółem, który sam rozwiąże się podczas programowania.

Pierwszą wersję warto ograniczyć do zadania, które można wykonać od początku do końca i ocenić z użytkownikami. W artykule o pierwszej wersji aplikacji pokazujemy, jak wybierać taki zakres bez mylenia prostoty z niedokończonym procesem. Ustal również, kto zaakceptuje wynik i co konkretnie zostanie sprawdzone przed odbiorem.

Przy ocenie rezultatu warsztatu użyj trzech pytań: czy wiadomo, co zespół rozumie przez problem; czy ktoś może wskazać dowód albo sposób sprawdzenia założeń; czy istnieje decyzja o kolejnym kroku? Jeżeli odpowiedź na którekolwiek jest niejasna, dopisz brakujące ustalenie zamiast dopisywać kolejny slajd.

Do decyzji o zakresie dodaj kryterium użytecznego wyniku. Dla procesu obsługi może nim być możliwość przyjęcia kompletnej sprawy, przypisania osoby odpowiedzialnej i sprawdzenia statusu przez uprawnioną osobę. To przykładowe kryterium, które trzeba dopasować do pracy firmy. Jeśli wynik ma być mierzalny, ustal również sposób pomiaru i punkt odniesienia, zanim pojawi się obietnica poprawy. Bez tych danych procent zapisany na slajdzie pozostaje ozdobą.

Co zrobić po spotkaniu

Rozesłanie notatek nie kończy pracy. Właściciel projektu powinien sprawdzić, czy osoby odpowiedzialne przyjęły swoje zadania, a następnie wrócić do decyzji, które zależą od wyników badań lub dostępu do danych. Jeśli nowe informacje zmienią założenia, warto jawnie zaktualizować zakres, zamiast po cichu przesuwać wymagania między zespołami.

Gdy znasz już problem, ale nie masz pewności, jak przygotować rozmowę z wykonawcą, opisz obecną pracę, osoby korzystające z procesu i jedną trudną sytuację. Możesz skorzystać ze strony oprogramowania na zamówienie, a następnie skontaktować się z Archifutura. W wiadomości wystarczy krótki brief: cel, używane narzędzia, ograniczenia i pytania, które wymagają wspólnego rozpoznania.

Warsztat ma sens wtedy, gdy ułatwia następne działanie. Dla jednego zespołu będzie nim próba prototypu, dla innego rozmowa z dostawcą systemu albo decyzja o uporządkowaniu danych. Nie trzeba udawać pewności tam, gdzie potrzebna jest jeszcze odpowiedź. Trzeba natomiast wiedzieć, kto jej poszuka i co od niej zależy.

Nie każda niewiadoma musi zniknąć przed rozpoczęciem prac, ale istotne niewiadome powinny mieć właściciela. Ustal też, kiedy zespół ponownie spotka się przy decyzjach zależnych od wyników: po rozmowie z pracownikami, przeglądzie dokumentacji integracji albo sprawdzeniu próbnych danych. Dzięki temu kolejny etap zaczyna się od aktualnych ustaleń, a nie od odtwarzania z pamięci, kto co miał sprawdzić. Gdy po warsztacie przyjdzie czas na wybór wykonawcy, przyda się porównanie ofert opisujących różny zakres aplikacji.