Powszechnie przyjętym dogmatem wśród analityków, projektantów, architektów, deweloperów i innych osób biorących udział w cyklu wytwarzania oprogramowania jest, że Klient nie wie czego chce. Sytuację rodem z głuchego telefonu przedstawia rysunek (http://philhord.com/phord/wp-content/development.jpg), w którym klient opisuje swoje oczekiwania. Następnie trafiają one do poszczególnych osób zajmujących się tworzeniem systemu i w efekcie biedny klient dostaje coś, co drastycznie mija się z jego potrzebami.
Jak to zatem jest z owym klientem? Czy rzeczywiście nie ma on bladego pojęcia czego naprawdę chce? Jak wiadomo: punkt widzenia zależy od punktu siedzenia. Programiści wiedzą, że klient nie ma bladego pojęcia o swoich potrzebach, natomiast klienci są absolutnie przekonani, że deweloperzy dają im coś innego niż zostało to uzgodnione. Jaka jest więc prawda? Hmmm, żyję na świecie wystarczająco długo, by wiedzieć że każdy ma swoją własną prawdę. Jednakże twierdzę, że klient dokładnie wie, czego chce. Z doświadczenia wiem, że:
Klient wie, czego chce – aktualne oczekiwania wobec systemu wyniknęły z problemów, które doskwierają klientowi w pracy, zatem chce on je rozwiązać i ma na to konkretny pomysł. Klient (metaforycznie rzecz ujmując) jest ekspertem z dziedziny problemu, więc tym bardziej wie, czego chce.
Klient nie zawsze wie, czego potrzebuje – wynika to z jego niewielkiej wiedzy o możliwych technologiach. Często klient sugeruje rozwiązanie (na miarę swojej wiedzy), gdy tym czasem powinien zatrzymać się na sformułowaniu problemu i oczekiwanych rezultatów.
Klient często nie uświadamia sobie konsekwencji własnych oczekiwań – jest to bolesne zwłaszcza, gdy prosi się nas o dodatkową funkcjonalność w systemie.
Przyczyna rozmijania się oczekiwań klient z rezultatem prac programistów koncentruje się wokół następujących faktów:
Klient myśli procesowo – ma bardzo konkretne pomysły na sposób pracy z systemem. Potrafi określić warunki początkowe dla danego procesu oraz określić jego rezultat.
Projektant myśli strukturalnie – porusza się w przestrzeni baz danych, tabel, klas, obiektów. Niejednokrotnie już podczas rozmowy z klientem myśli o implementacji. Z tego względu częste zmiany w wymaganiach oraz modyfikacje sposobów pracy z systemem, które klientowi przychodzą niezwykle łatwo, u projektanta powodują frustrację.
Mit o niewiedzy klienta nt. własnych oczekiwań bierze się powyższych różnić w myśleniu i analizowaniu informacji.
W swojej pracy wykorzystuję następujące praktyki pomagające w ustaleniu potrzeb klienta:
Opisywanie cyklu pracy z systemem – tworzę zestaw procesów, które opisują co użytkownik może zrobić w systemie. Jeden proces to jedna konkretna rzecz, np.: wykonanie przelewu, zalogowanie, wygenerowanie raportu
Rysowanie z klientem ekrany systemu i zaznaczanie przepływu sterowania pomiędzy nimi – puryści mówią, że tym powinien zajmować się projektant UI, natomiast do definiowania wymagań służą UML use cases. Cóż , nie spotkałem jeszcze klienta, który miałby ochotę uczyć się nowych symboli (nawet jeśli jest ich kilka), aby definiować swoje wymagania. Klient doświadcza systemu poprzez to co widzi – ekrany.
Pilnowanie, aby klient precyzował jaki efekt chce uzyskać – klient jest od tego, aby wskazać problem i określić oczekiwane rezultaty. Od rozwiązywania zadania jestem ja. Dobrze jeśli klient może udzielić rad odnośnie implementacji, jednak niekontrolowane mieszanie się tych odpowiedzialności nie raz zapędziło mnie w kozi róg.
Skłanianie klienta do przewidywania konsekwencji swoich oczekiwań – duże korzyści przynosi to przy rozbudowanych systemach. Niestety klient patrzy lokalnie na system – skupia się na aktualnym problemie i nie ma wizji całości. Prowadzi to łatania dziur, dodawania funkcyjnie zależnych od siebie usług do systemu i ogólnego bałaganu. Prowokowanie klienta do globalnego spojrzenia na system i przewidywania globalnych konsekwencji swoich oczekiwań ma następujące zalety:
ulepszany system jest traktowany jako całość
unika się dublowania funkcjonalności
czasem okazuje się, że poprawa komfortu pracy o 5% nie jest warta wysiłku programistów
