Tuesday, May 27, 2008

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 koncentruje 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 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.

  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 okazuje się, że poprawa komfortu pracy o 5% nie jest warta wysiłku programistów


4 comments:

  1. Ciekawy wywód, fajne spojrzenie na pracę u podstaw z klientem.

    ReplyDelete
  2. Jeśli już analityk myśli obiektowo, to dobrze, wszak wtedy łatwiej wykryć różnego rodzaju ułatwienia myślenia, które stosuje klient, a które nie są poprawnym przełożeniem jego dziedziny na obiektowe struktury.

    I jeszcze ten cytat:
    "czasem okazuje się, że poprawa komfortu pracy o 5% nie jest warta wysiłku programistów "

    Hmm.. ale to nie jest takie proste, że się mówi po prostu 'nie, tego nie zrobimy :)' - tłumaczenie się zawiłością rozwiązania też chyba nie jest takie proste. W jaki sposób to osiągasz?

    Racjonalny Developer

    ReplyDelete
  3. Staram się skłonić klienta do przeanalizowania konsekwencji żądanej funkcjonalności, jej wpływu na inne elementy systemu. Czasem dochodzi on do wniosku, że rzeczywiście nie ma sensu czegoś robić. Jeśli się upiera i wtedy przedstawiam szacowania i kosztorys i proszę o wybranie co jest najważniejsze przy ustalonym budżecie (można zasugerować dodatkowa funkcjonalność spowoduje, że cena wykonania może wzrosnąć albo czas się wydłuży). Czasem jednak umowa już podpisana, klient się upiera (a jest to kluczowy klient), wtedy nie ma rady - robimy:)

    ReplyDelete
  4. Co do praktyk, które opisujesz: do punktu 2 istnieje całkiem zmyślne narzędzie u konkurencji (ćwiczyłem to rok temu ze studentami)
    http://www.microsoft.com/expression/products/sketchflow_overview.aspx

    ReplyDelete