Dlatego na początku zadajemy dużo pytań. Kto korzysta z rozwiązania? Co dzieje się przed i po danym kroku? Gdzie pojawiają się wyjątki? Jak dziś mierzycie wynik? Co ma zostać bez zmian?
Najpierw chcemy być pewni, że rozwiązujemy właściwy problem. Dopiero potem go kodujemy.
Na początku celowo porządkujemy problem, kontekst i zależności. Dzięki temu rozwiązanie ma być trafniejsze, a nie tylko szybciej wdrożone.
Jeżeli po drodze okaże się, że część procesu warto uprościć zamiast automatyzować, powiemy to wprost. Naszym celem nie jest największy projekt. Naszym celem jest sensowny efekt.
Nie pokazujemy procesu jako checklisty do odhaczenia. Każdy etap zmniejsza inną niewiadomą i przygotowuje kolejną decyzję.
Rozmawiamy o obecnym procesie, użytkownikach, danych, kosztach i tym, co po wdrożeniu ma być wyraźnie lepiej.
Pierwsza wersja ma być wystarczająco mała, żeby szybko trafiła do użytkowników, i jednocześnie wystarczająco solidna, żeby dało się ją dalej rozwijać.
Nie chodzi o wycięcie jakości. Chodzi o wycięcie funkcji, których jeszcze nie potrafimy uzasadnić.
Potrzebujemy osób, które znają proces, potrafią pokazać realne przypadki i są gotowe dawać feedback na działające fragmenty. To wystarczy, żeby wspólnie prowadzić projekt sensownie.
