rss

Rozmowy językiem klienta

Rozmowy z klientami bywają żmudne, trudne i prawie zawsze kończą się frustracją ze stwierdzeniem, że użytkownik nie wie czego chce. Stąd ważne jest aby rozmawiać z klientami ich językiem. Tylko jaki jest ten ich język?

Michał Paluchowski, 25 listopada 2009

„Stosujemy w naszej praktyce szeroko język UML, w szczególności diagramy przypadków użycia oraz diagramy czynności. Dzięki temu możemy rozmawiać z klientem jego językiem.” Siedziałem w niewielkim pokoju na rozmowie kwalifikacyjnej na stanowisko kierownika zespołu programistów. Przed oczami stanął mi sam diagram czynności:

Diagram aktywności UML

Wyobraziłem sobie rozmowę z potencjalnym klientem takim właśnie językiem i coś zazgrzytało. Przecież to nie tak użytkownicy komunikują się z komputerami. Nie poprzez bloki, strzałki i konstrukcje warunkowe ani nawet nie przez aktorów i scenariusze. Komunikują się tak:

Programista natomiast jest osobą, która tenże język interfejsu, znany i przyjazny użytkownikom, ma przetłumaczyć na język komputera, oparty o operacje arytmetyczne, stosy, rejestry i inne konstrukcje.

Diagramy UML są znakomitym narzędziem komunikacji pomiędzy programistami. Opisują wspólny dla nich język (kod źródłowy, algorytmy, moduły) w sposób graficzny, dzięki czemu szybko można przekazać innym złożone struktury i zależności. Znacznie szybciej niż pokazując czysty kod programu. Dzięki temu programiści nie tylko nawzajem się rozumieją, ale również z wyższej perspektywy widzą systemy, które tworzą.

Natomiast dla Pana Dyrektora Kowalskiego, który zamawia dedykowany program dla swojej firmy, nie jest on zbiorem modułów, algorytmów i interakcji, ale narzędziem do rozwiązywania problemów biznesowych. Narzędziem, które powinno pomóc, a nie stać na drodze, kluczowa jest więc intuicyjność użycia.

Historia komunikacji użytkownika z komputerem

Dominujące w ostatnich latach interfejsy użytkownika opierają się ściśle na metaforach znanych ze świata rzeczywistego. Mamy pulpit, jako odwzorowanie powierzchni biurka, na której się pracuje. Śmietnik, do którego wyrzucamy niepotrzebne papiery, lub pliki. Drukarka, której przesyłamy dokumenty, aby otrzymać ich papierowe wersje. Możnaby jedynie zastanawiać się, czemu u licha ktoś miałby trzymać śmietnik na biurku?

Odpowiedź na to pytane podaje Tim Mott, współtwórca tychże pierwszych metafor w latach ’70 w laboratoriach Xerox PARC:

„Nie myśleliśmy o tym jako o pulpicie biurka, raczej o pomieszczeniu biurowym, w którym pracownicy przemieszczają dokumenty.”

Pierwsze pulpity były więc faktycznie pokojami, w których rozstawione były śmietnik, drukarka (wówczas nieco większy kawałek sprzętu nić obecnie) czy szafki z dokumentami.

Historia interfejsów użytkownika sięga jednak nieco dalej w przeszłość, do początku lat ’60 i pana Douglasa Engelbarta, który jednocześnie jest wynalazcą pierwszej myszy komputerowej:

Pierwsza mysz komputerowa

Engelbart z zespołem pracowali nad systemem NLS, który miał być pierwszym komputerowym graficznym interfejsem użytkownika. Jak wymyślić coś takiego nie mając żadnych wcześniejszych podobnych doświadczeń? Prototypując! Co wydaje się być modne dopiero w erze Agile w ostatnich latach, zostało wynalezione już w latach ’60. Sadzano potencjalnych użytkowników – pracowników biurowych, sekretarki, dyrektorów – przed ekranami lub kartkami ze schematami interfejsów i modelami narzędzi do ich manipulacji, prosząc o wyobrażenie sobie interakcji w takim środowisku i opisywanie co i jak po kolei chcieliby zrobić.

Matka wszystkich demonstracji

Doug Engelbart pokazał nowy system światu w San Francisco w roku 1968 w trakcie czegoś, co ochrzczono mianem Matki Wszystkich Demonstracji. Pełna sala operatorów komputerów typu mainframe, z którymi „komunikowali” się za pomocą kart perforowanych i przetwarzania wsadowego, obserwowała jak Douglas „klika” sobie po ekranie za pomocą kilku dziwnych przyrządów. To się nazywa doświadczyć momentu, kiedy tworzy się historia!

To jak się w końcu komunikować?

Wracając do teraźniejszości – Agile uznaje, że najlepiej komunikuje się z użytkownikiem przez działające oprogramowanie. Pracujemy w krótkich iteracjach, przygotowujemy w pełni działające funkcje, demonstrujemy i zbieramy cięgi za to, co nie działa tak jak trzeba. To faktycznie jest najlepsza z punktu widzenia jakości komunikacji metoda.

Niekoniecznie jest to jednak najlepsza metoda z biznesowego punktu widzenia, ponieważ w przygotowanie każdej iteracji wchodzi sporo pracy i jeśli nie trafimy odpowiednio blisko z naszym wyobrażeniem wymagań klienta, to ta cała praca pójdzie zaraz na marne. Do tego wspomniany już rekruter z początku artykułu stwierdził, że „są systemy, w których pierwszy raz można coś pokazać po miesiącach pracy.” Słusznie. Dla tak skomplikowanych systemów wymyślono więc narzędzia do prototypowania. W kilku ruchach można skonstruować łudząco podobny do prawdziwego interfejs użytkownika, który można zademonstrować w ciągu godzin lub najwyżej dni od rozpoczęcia prac.

Nie trzeba nawet iść aż tak daleko. Istnieją techniki papierowego prototypowania, gdzie szybki szkic kilku okien przygotowuje się na kartkach papieru i przy ich pomocy rozmawia z użytkownikami. Instruuje się ich aby wyobrazili sobie wykonywanie działań na niektórych elementach, a zmiany widoków ilustrujemy podmieniając kartki.

Przy takim podejściu nagle okazuje się, że użytkownik woli jednak mieć możliwość dodać nowy rząd w tabeli przez wciśnięcie Insert, a nie klikanie plusa. Może nie chcieć wcale potwierdzać usuwania każdego z kolei rekordu z bazy danych. A na pewno może nie mieć ochoty na cztero-, pięcio-, czy sześciostopniowy proces robienia zakupów w sklepie internetowym.

To jest komunikacja prawdziwym językiem użytkownika, tym samym, którym on później będzie „rozmawiał” z gotowym programem.