Szkolenia dla programistów - BNS IT
Szkolenia AgileKonferencje Publikacje Klienci Zespół
 
  Książki    Artykuły     
 
Michał Bartyzel
Klient, który wie czego chce

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:

  1. 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.
  2. 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.
  3. 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 koncentruję się wokół następujących faktów:

  1. 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.
  2. 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:

  1. 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
  2. Rysowanie z klientem ekrany systemu i zaznaczam przepływ 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.
  3. 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.
  4. 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 okazuję się, że poprawa komfortu pracy o 5% nie jest warta wysiłku programistów


 
 
Touching the Void
Radość tworzenia
oprogramowania
Pawel.Wrzesz.cz
BNS IT
Plac Przymierza 6/26
03-944 Warszawa