01. Poznajemy pracę od środka.
Pierwsza rozmowa dotyczy sytuacji, którą chcesz zmienić. Co opóźnia realizację? Gdzie wracają poprawki? Jakiej informacji brakuje osobie podejmującej decyzję? Potem przechodzimy przez konkretną sprawę z ludźmi, którzy ją obsługują. Perspektywa kierownika i pracownika operacyjnego pomaga zobaczyć ten sam proces z różnych stron.
W dużej organizacji jedno zamówienie lub dokument może przejść przez kilka działów. Szukamy miejsc, w których zmienia się odpowiedzialność, pojawia oczekiwanie albo ginie kontekst. Właśnie tam często znajduje się największa szansa na uproszczenie pracy.
- Cel projektu i obecny sposób jego realizacji.
- Osoby korzystające z rozwiązania oraz podejmujące decyzje.
- Najczęstsza ścieżka i sytuacje, które sprawiają trudność.
02. Porządkujemy reguły, dane i pierwszy zakres.
Prosimy o reprezentatywne próbki: przykładowy formularz, dokument lub zestawienie z usuniętymi danymi osobowymi i zbędnymi informacjami poufnymi. Zamiast oceniać wyłącznie poprawny przypadek, sprawdzamy braki, powtórzenia i korekty. Ustalamy, kto może zmieniać dane i kiedy potrzebna jest akceptacja.
Wybieramy niewielki, ale kompletny fragment procesu. Powinien mieć początek, przebieg i użyteczny wynik. Taki zakres pozwala sprawdzić rozwiązanie w pracy. Spisujemy również zależności i elementy, które świadomie pozostają na później.
- Co uruchamia sprawę i po czym rozpoznajemy jej zakończenie?
- Kto odpowiada za poszczególne informacje?
- Jak obsługujemy wyjątek lub wycofanie decyzji?
Najważniejsze na początek
Zaczynamy od konkretnej pracy i rozmawiamy z osobami, które ją wykonują.
Pierwszy zakres obejmuje kompletny obieg oraz najważniejsze wyjątki.
Prototyp, kryteria testów i odbiór odnoszą się do tych samych zadań użytkownika.
03. Sprawdzamy pomysł na prototypie.
Układamy najważniejsze ekrany i przechodzimy przez zadania przyszłego użytkownika. Czy rozumie status? Czy znajduje dokument? Czy wie, dlaczego nie może wykonać operacji? To moment na sprawdzenie języka, kolejności działań i informacji potrzebnych przy podejmowaniu decyzji.
Prototyp służy rozmowie o sposobie pracy. Nie udaje gotowego systemu: rzeczywiste integracje, kontrola dostępu i zapis danych wymagają wykonania oraz testów. Ustalone wnioski przekładamy na zakres, który można zbudować i odebrać.
04. Budujemy rozwiązanie razem z jego połączeniami.
Łączymy interfejs z regułami, danymi i potrzebnymi systemami. Dostępność API, dokumentacji oraz środowisk sprawdzamy przed założeniem pełnej wymiany informacji. Ustalamy, które narzędzie jest źródłem danej i jak połączenie zachowa się przy przerwie lub powtórzeniu zdarzenia.
Projekt rozwijamy w uzgodnionych częściach, które można pokazać i sprawdzić. Nowe pomysły zapisujemy oraz oceniamy względem celu. Dzięki temu istotna zmiana może świadomie wpłynąć na zakres, zamiast po cichu zmieniać oczekiwania wobec terminu i kosztu.
05. Testujemy również to, co może pójść inaczej.
Weryfikujemy scenariusze ustalone podczas analizy: poprawny przebieg, brakujące dane, błędne uprawnienia i nietypowe decyzje. Przy integracjach sprawdzamy ponowienia i niedostępność źródła. Przy migracji porównujemy dane, aby potwierdzić, że zachowały swoje znaczenie.
Użytkownicy otrzymują możliwość sprawdzenia istotnych zadań w odpowiednim dla nich kontekście. Aplikacja na telefonie wymaga innego spojrzenia niż panel używany przy biurku. Kryteria odbioru odnosimy do konkretnych wyników i uzgodnionego zakresu.
- Czy użytkownik może zakończyć właściwą sprawę?
- Czy widzi i zmienia tylko dozwolone informacje?
- Czy błąd jest zrozumiały i ma określoną ścieżkę obsługi?
06. Uruchamiamy w sposób dopasowany do firmy.
Jeżeli proces na to pozwala, zaczynamy od pilota z wybraną grupą lub częścią danych. Można wówczas porównać pracę z dotychczasowym obiegiem i skorygować szczegóły przed rozszerzeniem dostępu. W innym przypadku planujemy uzgodniony moment przełączenia oraz postępowanie w razie problemu.
Przed odbiorem ustalamy odpowiedzialności, sposób przekazania informacji użytkownikom i obsługę zgłoszeń. Prawa do kodu, dostępy, dokumentacja oraz zasady przekazania projektu wynikają z umowy i ustalonego zakresu. Omawiamy je wcześniej, aby firma wiedziała, co otrzyma i jak będzie mogła rozwijać rozwiązanie.
07. Sprawdzamy efekt i planujemy kolejne kroki.
Wracamy do problemu, od którego zaczęliśmy. Sprawdzamy czas wykonania zadania, oczekiwanie, liczbę poprawek lub inne wcześniej wybrane kryterium. Nie każda korzyść musi być wykresem: ważnym efektem może być możliwość ustalenia statusu bez szukania osoby posiadającej wiedzę.
Utrzymanie, kopie zapasowe, monitoring, aktualizacje i reakcję na zgłoszenia określamy w uzgodnionym zakresie współpracy. Nowe moduły wynikają z obserwacji użytkowników i priorytetów firmy. Dzięki temu rozwój odpowiada na rzeczywiste potrzeby, a podstawowy proces pozostaje pod kontrolą.
Od czego zaczniemy rozmowę?
- Prawa, dostępy i odpowiedzialność za utrzymanie ustalamy przed przekazaniem rozwiązania.
- Efekt oceniamy względem problemu i punktu wyjścia, a nie liczby dodanych funkcji.
