środa, 13 lutego 2008

Czy „ergonomista” jest potrzebny w zespole projektowym? (Do we need user experience role inside the project team?)

W trakcie trzeciego z prowadzonych przez mnie kursów „Efektywne zarządzanie innowacyjnym projektem informatycznym z wykorzystaniem metodyki Microsoft Solutions Framework v4.2 for Agile System Development i Team Foundation Server 2008” (pierwszy, drugi), w Warszawie – poniedziałek i we wtorek 11-12 lutego wywiązała się dyskusja na temat roli określanej przeze mnie jako „ergonomista” (ang. user experience). Dla mnie to bardzo ważna rola, bo końcowy użytkownik i płatnik (ktoś, kiedyś musi zapłacić za software, który budujemy) ocenia nas poprzez jakość („Czy tą aplikację da się używać?”) jak i prostotę używania (Na ile korzystanie z aplikacji jest intuicyjne?). „Ergonomista” to rola, która pojawiła się w tzw. starej Microsoft Solutions Framework (do wersji 3.2) i jest obecna w metodyce Microsoft Solutions Framework for CMMI Process Improvement v4.x. W metodyce Microsoft Solutions Framework v4.x for Agile System Development rola ta (w sensie operacyjnym) nie występuje, choć jeden z analityków biznesowych musi lobbować na rzecz ergonomii rozwiązania.
Czym zajmuje się "ergonomista"?
Najważniejszy zakres odpowiedzialności dotyczy:
- interfejsu aplikacji (na ile łatwo, intuicyjnie można z rozwiązania korzystać?)
- przygotowania instrukcji użytkownika i pomocy (ang. help) – wsparcia w sytuacjach trudnych.
Dyskusja (w trakcie kursu dotyczyła) odpowiedzi na pytanie, kiedy pisać podręcznik użytkownika? W trakcie implementacji, czy stabilizacji? Ja (intuicyjnie wypracowałem podobne metody działania jak Microsoft) uważam, że w trackie implementacji, uczestnicy kursu uważali (mam nadzieję, że już nie), że w tracie stabilizacji - kiedy pełna funkcjonalność została zaimplementowana.
Dlaczego musimy zacząć pisać podręcznik użytkownika w trackie fazy implementacji?
1. Rolą "ergonomisty" jest również zarządzanie używalnością aplikacji – musi być aktywny w tracie implementacji i podejmować decyzje na bieżąco. Opisując pracę budowane rozwiązania weryfikuje swoje koncepcje. Deweloperzy poprawiają błędy na bieżąco. To działa! To nie jest zarządzanie zmianą.
2. Przygotowując podręcznik w trakcie stabilizacji i natrafiając na ewidentne pomyłki w zakresie ergonomii użytkowania, błędy zgłaszane przez ergonomistę mają najniższy priorytet (pol. musztarda po obiedzie). Rzadko, kiedy dochodzi do ich poprawy.
3. Pisanie podręcznika i pomocy (zwykle ten sam plik przetwarzany do innej formy wynikowej) to sztuka, często zajmuje więcej czasu niż pisanie kodu.
4. Kiepski podręcznik (i help) to ogromne obciążenie dla call center zajmującego się wsparciem użytkownika końcowego (ang. help-desk) – niezależnie od tego, czy dotyczy to klienta biznesowego, czy prywatnego. Było to (i jest) problemem dla wielu polskich firm IT. Tych sprzedających setki, czy tysiące licencji rocznie.
5. Dobry „ergonomista” nie tylko przygotuje dobrze zrozumiały podręcznik, ale przede wszystkim tak zaprojektuje aplikację, że korzystanie z podręcznika, helpu, help-desk będzie minimalne.
Czy piszę o wyimagowanym problemie? Próbowaliście kiedyś zmontować meble IKEA na podstawie instrukcji? Zamontować, korzystając z instrukcji bagażnik dachowy na samochodzie KIA? Uruchomić radio po odłączeniu akumulatora na podstawie instrukcji dostarczonej przez firmę OPEL? To przykłady z mojego prywatnego help-desk za ostatnie 3 dni. Instrukcje, które wręczyli mi znajomi były „tak dobre” jak wielu aplikacji komputerowych. Nie, miały pewną przewagę. Wiele aplikacji ma jedynie coś, co „markuje” podręcznik użytkownika.
Raz na tydzień dostaje email w stylu „help desk Microsoft mnie ignoruje, czy mogę prosić o …”. Nie reaguję! Nigdy nie reaguję. Mam zasadę, że nie otwieram Puszki Pandory.

1 komentarz:

delorian pisze...

Może posunąć się jeszcze dalej w abstrakcję i przyznać za pierwszy cel ergonomisty ustalenie, czy dany problem biznesowy sensownie z punktu widzenia użytkownika końcowego rozwiązywać w ten sposób czy inny? W sensie ogólnego faktu konieczności "doświadczania" przez człowieka interakcji z systemem. Czy rzeczywiście potrzebne nam jest takie oprogramowanie? Czy w ogóle potrzebujemy komputera, żeby to zrobić? Właściwie dlaczego mamy to robić, coś nie może wykonać tego za nas? Te i inne pytania powinna, moim zdaniem, zadawać osoba zajmująca się ergonomią w projekcie.

Technologia narzuca jeszcze nam pewne, coraz mniejsze, ograniczenia, ale myślę, że rola "ergonomisty" będzie jeszcze większa w przyszłości. Taki ktoś zajmie się wymyśleniem i nadzorowaniem budowy "interfejsu" (czymkolwiek by ten interfejs nie był) dla naszego systemu. I postara się tak bardzo, żeby nie musieć w ogóle przygotowywać manuala.

Dobry design jest niewidzialny dla użytkownika, chociaż ta utopia jest niezauważalna dla świata rzeczywistego ;-)