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.