Punkt widzenia zależy od punktu siedzenia

Jest to historia mojego odkrycia. Stwierdziłem mianowicie, że potrafię oszczędzić użytkownikowi 75% czasu potrzebnego do wprowadzania danych (a sobie wielokrotnych i uciążliwych poprawek), dzięki obserwacji użytkownika w trakcie codziennej pracy z aplikacją.

Jest to historia mojego odkrycia. Stwierdziłem mianowicie, że potrafię oszczędzić użytkownikowi 75% czasu potrzebnego do wprowadzania danych (a sobie wielokrotnych i uciążliwych poprawek), dzięki obserwacji użytkownika w trakcie codziennej pracy z aplikacją.

W trakcie przygotowywania aplikacji, pracującej w systemie klient/serwer służącej do dokonywania operacji finansowych, zaprojektowaliśmy (na ekranie monitora) przycisk służący do wykluczania regionów geograficznych podczas alokacji wydatków. Zwykły drobiazg. Wprowadzenie przycisku było poprzedzone szczegółową dyskusją z przyszłym użytkownikiem, a aplikacja starannie przetestowana.

Pech chciał, że użycie tego przycisku w praktyce powodowało przerwę we wprowadzaniu danych i zakłopotanie operatora. Nigdy byśmy się o tym nie przekonali (w czasie testów użytkownik nie miał najmniejszych problemów z poprawnym użyciem przycisku), gdyby nie mój pomysł spędzenia godziny (cichutko jak myszka) za plecami użytkownika, podczas jego normalnej pracy.

Clou historii stanowi fakt, że dokonanie odpowiedniej zmiany w kodzie źródłowym programu zajęło mi dokładnie 15 sekund! Aplikacja bez tej zmiany funkcjonowałaby zapewne przy akompaniamencie cichych przekleństw operatorów, zaś wydajność wprowadzania danych byłaby dużo niższa.

Opowieść ta stanowi wstęp do tego, co nazywam "programowaniem przez spacerowanie". Pożyczyłem to określenie z terminologii zarządzania (management by walking around). Oznacza on przeprowadzanie częstych wizyt u dostawców, pracowników i klientów poprzez personel kierowniczy w celu sprawdzenia, jak produkt wytwarzany przez firmę jest wykorzystywany i oceniany. Celem jest w tym przypadku poprawa jakości.

W zastosowaniu do tworzenia aplikacji, pomysł mój sprowadza się do oderwania programisty od komputera i wizyty u użytkownika, w celu sprawdzenia na miejscu jak wygląda praca z aplikacją. I w tym przypadku chodzi o poprawę jakości. Opisywany przypadek przycisku służącego do wyłączania regionów podkreśla celowość techniki uważnego obserwowania użytkownika w miejscu jego pracy - podczas wdrażania aplikacji.

Jak się to zaczęło?

Odkrycie dokonane przeze mnie nastąpiło w gruncie rzeczy przez przypadek. Pracowałem nad aplikacją, która miała umożliwić alokację wydatków poniesionych na konkretny produkt w odniesieniu do wyselekcjonowanych transakcji. Wynik miał służyć do miesięcznych zestawień zbiorczych. Stary system wymagał znacznej pracy ręcznej. Użytkownik dokonywał wyboru transakcji dla określonego produktu (posługując się plikiem z bazy danych zainstalowanej na głównym komputerze przedsiębiorstwa), następnie alokował wydatki i wyniki umieszczał z powrotem w bazie danych. Taka technika wymagała ręcznego wprowadzania blisko setki transakcji i zajmowała 4-5 godzin.

Nowy system opracowano w ten sposób, aby można było wykorzystać zalety architektury klient/serwer (minimalizując liczbę wprowadzanych danych). Wyświetlał on wszystkie transakcje dla każdego produktu (pobierając je z serwera bazy danych i przekazując do aplikacji PowerBuilder). Następnie użytkownik dokonywał wyboru transakcji przez kliknięcie myszą. Wybrane transakcje były automatycznie włączane do wyliczenia alokacji, zaś wyniki przekazywane do serwera bazy danych.

Po zakończeniu projektowania, przetestowaliśmy starannie program. Działał bez błędów. Gdy kończyliśmy już pracę zadzwonił telefon. To główny księgowy Tom, z niecierpliwością dopytywał się o aplikację (mając w perspektywie comiesięczne sprawozdanie). Oprogramowanie było w zasadzie gotowe, toteż wyraziłem zgodę na przyspieszoną instalację. Kończąc rozmowę Tom poprosił mnie o obecność podczas pierwszego użycia produktu. Koniec miesiąca był już bliski i jakikolwiek kłopot mógłby opóźnić sprawozdanie. Myślałem, że wizyta ta będzie czystą formalnością. Po prostu, jak zwykle zbiorę pochwały za porządnie wykonaną pracę.

Ostrzeżenie

Nazajutrz przyszedłem do działu głównego księgowego i wybrałem krzesło stojące z dala od stacji roboczej, na której pracował Tom. Chciałem pozostać możliwie nie zauważony. Po chwili Tom wprowadził pierwszy kod produktu i potwierdził go klawiszem ENTER. Opis produktu pojawił się na ekranie monitora. Spodziewałem się, że Tom zerknie na niego a następnie przyciśnie przycisk RETRIEVE. Ale ku memu zaskoczeniu nie zrobił tego, czekając na pojawienie się listy transakcji związanych z wyrobem.

"Hej, teraz musisz kliknąć na przycisk RETRIEVE" - podpowiedziałem. Jednocześnie zrozumiałem na czym polegał problem. Tom pracował z kodami produktów od lat. Nie spodziewał się popełnić jakiegokolwiek błędu, a więc nie uważał za celowe sprawdzenia opisu produktu. Klawisz RETRIEVE był niewątpliwie potrzebny w fazie projektowania i testowania aplikacji. Ale przy pracy doświadczonego księgowego, który mógł poświęcić minimalną ilość czasu na wprowadzanie danych, stawał się po prostu niepotrzebny. Tom kliknął myszą na przycisk - program ruszył dalej, zaś ja zapisałem w notatniku odpowiednią uwagę.

Gdy dane wypełniły ekran, Tom zdecydował się posortować je wg regionów geograficznych. Wskazał myszą na odpowiedni przycisk, zawahał się na moment a następnie kliknął przycisk sortowania.

Przy projektowaniu aplikacji, ustaliliśmy wspólnie zasadę, aby sortowanie i filtrowanie były potwierdzane poprzez naciśnięcie odpowiedniego przycisku. Zakładaliśmy, że czynności te - jako wolniejsze od innych, wymagają dodatkowego potwierdzenia ze strony operatora. Teraz zdałem sobie sprawę z bezsensowności założenia. Sortowanie zachodziło przecież w pamięci RAM komputera klienta i nawet przy setkach danych dokonywało się tak szybko, że użytkownik nie odczuwał opóźnienia programu. W tym kontekście dodatkowe potwierdzanie czynności było zwykłą stratą czasu. Zrobiłem wobec tego następną uwagę w notatniku. Jak przypuszczałem, z mojego punktu widzenia rozwiązanie problemu było drobiazgiem. Po prostu należało w kodzie źródłowym usunąć kod jednego przycisku.

Po wpisaniu kilku rekordów, wydawało się, że Tom zapomniał o mojej obecności. Całkowicie skoncentrował się na pracy. Przez obserwowanie ruchu jego oczu oraz wskaźnika myszy mogłem wczuć się w rytm aplikacji. Mogłem też łatwo zauważyć, które sekwencje spowalniają jego pracę. W krótkim czasie lista moich uwag wzrosła do ok. 20. Nagle zdarzyło się coś dziwnego. Zamiast czuć się zniechęconym z powodu znacznej liczby koniecznych poprawek, poczułem podniecenie. Zdałem sobie sprawę, że mogą one znakomicie przyspieszyć wprowadzanie danych przez użytkownika. Gdybyśmy odwrócili sytuację i to właśnie użytkownik informowałby mnie (prawdopodobnie pojedynczo) o mankamentach programu, wprowadzanie poprawek trwałoby pewnie miesiącami.

Przejdźmy teraz do przycisku wspomnianego na wstępie. W większości przypadków Tom alokował wydatki przy użyciu wszystkich transakcji. W pewnej chwili doszedł do produktu, którego koszty były związane jedynie z regionami zachodnim i południowym. Tom wprowadził kod produktu, następnie sumę dolarów i wybrał przyciski symbolizujące odpowiednie regiony. Czas stanął. Tom nachylił twarz bliżej do ekranu i patrzył nań bez ruchu. Nic się nie działo. Po kilku sekundach zapytał "Dlaczego regiony, które odrzuciłem znajdują się ciągle na ekranie?" "Musisz użyć przycisk EXCLUDE", podpowiedziałem mu. Patrzył na ekran nic nie robiąc. Zrozumiałem, że nie może znaleźć przycisku, który znajdował się na końcu belki w prawym rogu ekranu. Gdy pokazałem go, Tom wykonał ruch myszą i praca potoczyła się dalej.

W kilka minut później znowu trzeba było wykluczyć kilka regionów. I znów nastąpiło spowolnienie akcji. Wprawdzie tym razem Tom wykonał odpowiednie czynności bez podpowiedzi, ale strata tempa była wyraźna. Nie mogłem tego zrozumieć. Przycisk znajdował się wszak na swoim miejscu, zaś Tom był jednym z najlepszych operatorów komputerowych w firmie. W takim razie winna musiała być aplikacja - nawet jeśli zachowywała się bezbłędnie podczas testów. Byłem ciekaw czy druga księgowa - Jenny, będzie miała podobne problemy. Gdy tylko Tom skończył pracę, podziękowałem mu i poszedłem do pokoju Jenny. Czekało mnie kilka niespodzianek.

Pierwszą był fakt, że Jenny miała identyczne kłopoty z przyciskiem wykluczającym regiony, chociaż to właśnie ona była jego pomysłodawczynią. Ale teraz, w rytmie wprowadzania danych, obecność tego przycisku wyraźnie jej przeszkadzała. Obserwując najpierw Toma a teraz Jenny w akcji, domyśliłem się na czym polega problem. Podczas testowania aplikacji, obydwoje byli skoncentrowani na współpracy z programem. Jeden przycisk mniej lub więcej nie sprawiał żadnego problemu. Teraz, w realnym świecie wprowadzania rekordów, pod naciskiem terminu ukończenia sprawozdania, telefonów, gości etc. ten sam przycisk okazywał się zbędny. Ideałem byłoby stałe dokonywanie przetwarzania danych on-line. Konieczność użycia jakiegokolwiek przycisku powodowała tak poważne zakłócenie rytmu pracy, że stanowiło to zaskoczenie dla operatora. Dla mnie zaskoczeniem było, że mimo iż jestem doświadczonym programistą, fakt ten umknąłby mojej uwadze - gdyby nie wizyta w pokoju księgowych.

Do usług

Następna niespodzianka była związana z prośbą Jenny dotyczącą zmiany w aplikacji. Jenny była bowiem wyjątkowo nieśmiałą dziewczyną, która nigdy nie proszona nie zabierała głosu. Końcowym etapem aplikacji był raport pokazujący wszystkie dane wprowadzone do systemu. Jenny poprosiła jednak, aby wybrać do wydruku tylko część z zapisanych rekordów. Szybko się na to zgodziłem. Wiedziałem jak prosta będzie poprawka związana z wyświetleniem wszystkich rekordów, a następnie wybraniem za pomocą myszy tych, które miały się znaleźć na wydruku. Jednocześnie zdałem sobie sprawę, że przy całej swojej nieśmiałości Jenny nie poprosiłaby mnie o zmianę, gdyby rozmowa ta nie odbywała się w trakcie nieoficjalnej wizyty, w atmosferze koleżeńskiej współpracy. "Programowanie przez spacerowanie" (a może raczej przez podglądanie) okazało się znakomitą metodą, nie tylko w kontekście wykrycia usterek programu, ale także wyciągnięcia maksymalnych korzyści płynących z architektury klient/serwer.

Gdy Jenny skończyła księgowanie obiecałem, że dokonam koniecznych poprawek przed następnym wprowadzaniem danych. Wróciłem do biura i rozpocząłem pracę. Poprawka związana z fatalnym przyciskiem zajęła mi 15 s. Inne też nie były dużo więcej czasochłonne. Pod koniec dnia byłem gotów z nową wersją aplikacji (PowerBuilder jest jednak znakomitym narzędziem). W kilka dni później z satysfakcją przeczytałem notatkę służbową Toma, w której informował szefa, że wszystkie moje poprawki przyspieszyły wprowadzanie danych o co najmniej 75%. Reakcja Jenny była jeszcze milsza. "To graniczy z cudem", powiedziała.

Ponieważ coraz więcej aplikacji wykonywanych jest w architekturze klient/serwer, zamierzam przedyskutować zalety mojego systemu z całym zespołem programistów. Wam zaś mogę jedynie poradzić, aby uważnie obserwować użycie nowo tworzonych aplikacji w ich rzeczywistym środowisku pracy. Aha, i nie zapomnijcie o notatniku.


TOP 200