„Potrzebujemy aplikacji” to dobry początek rozmowy, ale słaba specyfikacja. Nie wiadomo jeszcze, kto ma z niej korzystać, co dziś robi ręcznie i po czym firma pozna, że zakup miał sens. Jeśli od razu przejdziemy do ekranów, możemy bardzo sprawnie zaprojektować niewłaściwe narzędzie. Będzie miało przyciski, powiadomienia i własne logo. Zabraknie mu tylko powodu, żeby ktoś otwierał je rano.
Na pierwszą rozmowę z Archifutura przynieś jedną prawdziwą sprawę z codziennej pracy. Może to być zamówienie, zgłoszenie serwisowe albo przygotowanie oferty. Pokaż, gdzie sprawa się zaczyna, przez czyje ręce przechodzi i kiedy uznajecie ją za zakończoną. Taki przykład daje więcej niż katalog funkcji z aplikacji konkurencji, bo ujawnia zależności, których na cudzych zrzutach ekranu po prostu nie widać.
Opisz zadanie razem z jego niewygodną częścią
Wybierz również przypadek, który poszedł źle. Klient zmienił dane po akceptacji, zabrakło towaru, pracownik był nieobecny. To właśnie na takich sytuacjach wychodzą reguły, które później trzeba zaprogramować. Zwykła ścieżka pokazuje kolejność czynności. Wyjątek pokazuje, kto może podjąć decyzję i kto ponosi jej skutki. Nie potrzebujesz do tego technicznego słownictwa. Wystarczy uczciwie odtworzyć przebieg zdarzeń.
Dobrze też nazwać koszt obecnego sposobu pracy. Nie musi to być od razu kwota w złotych. Możesz przez tydzień zapisywać liczbę ponownych telefonów, czas szukania dokumentu albo sprawy cofnięte do poprawy. Bez takiego punktu odniesienia po wdrożeniu łatwo usłyszeć, że jest nowocześniej. Trudniej odpowiedzieć, czy faktycznie jest sprawniej. Właśnie od takiego rozpoznania zaczyna się projektowanie oprogramowania na zamówienie.
Oddziel potrzebę od proponowanego rozwiązania
Zdanie „potrzebujemy czatu” opisuje funkcję. Zdanie „koordynator nie wie, dlaczego zlecenie stoi” opisuje problem. Być może rozwiąże go komentarz przy sprawie, obowiązkowy powód wstrzymania albo prosty status z właścicielem. Czat też może być potrzebny, lecz nie powinien wygrywać tylko dlatego, że wszyscy znają ten przycisk. Przy rozmowie z wykonawcą zostaw miejsce na prostszy sposób osiągnięcia celu.
To samo dotyczy pierwszej wersji. Wpisanie do niej wszystkiego, co kiedykolwiek może się przydać, utrudnia ocenę kosztu i opóźnia kontakt z użytkownikiem. Lepiej wybrać zamknięty fragment pracy, który da się uruchomić oraz odebrać. O tym, jak wyznaczyć taką granicę, piszemy w tekście o MVP aplikacji. Ograniczony zakres nadal musi obsługiwać potrzebne wyjątki; słowo „pierwsza” nie zwalnia z odpowiedzialności za działanie.
Pokaż pomysł osobom, które będą pracować
Osoba zamawiająca widzi często raport końcowy, a nie moment wprowadzania danych. Dlatego do rozmowy zaproś kogoś, kto wykonuje zadanie regularnie. Pytaj o konkretne dokumenty, skróty i obejścia. Nie oceniaj pracownika za korzystanie z arkusza obok systemu. Ten arkusz może wskazywać brakującą funkcję albo zbyt długą ścieżkę, której nikt wcześniej nie zauważył. To materiał do projektu, nie dowód przeciwko zespołowi.
Zanim powstanie całe zaplecze, warto przejść zadanie na klikalnym prototypie. Poproś użytkownika, żeby sam odnalazł sprawę, wprowadził zmianę i sprawdził wynik. Nie podpowiadaj, gdzie kliknąć. Jeśli projekt działa tylko z komentarzem autora stojącego nad ramieniem, potrzebuje jeszcze pracy. Dzięki temu poprawiacie układ przed kodowaniem, zamiast potem negocjować kolejne wersje gotowego formularza.
Ustal, co zostanie po rozmowie
Już przy ustalaniu zakresu omówcie również sposób odbioru gotowej aplikacji oraz przekazanie kodu i kont. Te decyzje wpływają na ofertę, dostęp do infrastruktury i odpowiedzialność po uruchomieniu. Jeśli zostaną odłożone na koniec, firma może dostać działający produkt, którego nikt po jej stronie nie potrafi obsłużyć ani bezpiecznie rozwijać. Warto wyjaśnić to wtedy, gdy wszystkie warianty są jeszcze dostępne.
Dobrym rezultatem pierwszego etapu jest krótki opis procesu, lista użytkowników, zakres pierwszej wersji i pytania wymagające sprawdzenia. Dopiero na tej podstawie sensownie rozmawia się o czynnikach wpływających na wycenę aplikacji. Jeśli wykonawca musi zweryfikować połączenie z obecnym programem, zaplanujcie mały test. Pewność udawana w ofercie nie staje się tańsza tylko dlatego, że została zapisana pogrubieniem.
Na rozmowę o projekcie możesz przyjść bez makiet i dokumentu na czterdzieści stron. Przygotuj przykład sprawy, osoby, które znają jej przebieg, oraz ograniczenia, których nie możecie obejść. Z takim materiałem da się ustalić pierwszy użyteczny krok. Aplikacja przestaje wtedy być ogólnym pomysłem na cyfryzację, a zaczyna być konkretną odpowiedzią na pracę, którą ktoś ma wykonać.
