Rola analityka
Podczas jednego z meetupów w którym uczestniczyłem ostatnio, jeden z prelegentów podczas swojej prezentacji zastanawiał się nad różnicami pomiędzy analitykiem biznesowym, a projektantem UX. Wynikiem jego rozważań było stwierdzenie, że analityk biznesowy, to ktoś kto pośredniczy pomiędzy „biznesem” a zespołem deweloperskim, a projektant UX to ktoś kto pracuje na styku użytkownik – zespół deweloperski. Sugestia, jakoby analitykom biznesowym nie bardzo zależało na zadowoleniu użytkownika, trochę mnie dotknęła. Po chwili jednak doszedłem do wniosku, że taka opinia nie wzięła się znikąd. Zacząłem się zastanawiać czy faktycznie jest tak, że ogromna część naszej pracy skupiona jest na modelowaniu wymagań, a trochę gorzej wygląda to gdy przychodzi sprawdzić wyniki naszych prac.
Dość często zdarza się (niestety), że analityk nie uczestniczy w fazie testowania i rozruchu systemu, bądź jego rola ogranicza się do weryfikacji czy określona wartość została dostarczona. Organizujemy i przeprowadzamy testy akceptacyjne, weryfikujemy, czy kryteria akceptacji zostały spełnione, czasem nawet dokonujemy pomiarów. Czy jednak nie powinniśmy pójść krok dalej i zweryfikować potencjalne usprawnienia? Niejeden z Was odpowie: „ale przecież to mają na celu testy akceptacyjne”, nieliczni powiedzą: „ale przecież prowadzimy badania użytkowników i weryfikujemy użyteczność systemu”. Ja przekornie zapytam: „Może da się zrobić coś wcześniej i bez angażowania sporych zasobów”? Co gdy nie mamy możliwości przeprowadzenia badań (np. brak zrozumienia klienta dla potrzeby przeprowadzenia takich badań, bądź ograniczona dostępność do potencjalnej grupy badawczej)?
Moim zdaniem jest rozwiązanie. Przebadaj system samemu! Brzmi trywialnie, prawda? Często jednak w natłoku codziennych obowiązków potykamy się o „oczywistą oczywistość” i tylko zatrzymanie się i spojrzenie wstecz pozwala nam ją dostrzec. Jak mówi jeden z moich ulubionych bohaterów „Nothing is ever easy”.
Lotniskowy paraliż
Klika lat temu miałem przyjemność uczestniczyć w projekcie mającym na celu stworzenie systemu obsługi taksówek na jednym z lotnisk. Pierwsza wersja systemu powstawała przez klika miesięcy. Włożyliśmy ogrom pracy w przeanalizowanie potrzeb i zamodelowanie systemu w taki sposób, aby osiągnąć zakładaną zmianę głównego wskaźnika (czas oczekiwania taksówki na podjęcie pasażera). Ponieważ wdrożenie systemu powodowało bardzo duże zmiany procesowe (w tym zmiany fizycznych lokalizacji do których musi udać się taksówka), nie byliśmy w stanie przetestować systemu na „żywym” organizmie. Zbudowaliśmy więc „symulator ruchu na lotnisku” (bazujący na rzeczywistych danych, które zmierzyliśmy), dzięki któremu byliśmy w stanie obserwować jak zachowuje się system i wyregulować go tak, aby zmiana wskaźnika była na akceptowalnym poziomie. Byliśmy pewni, ze zrobiliśmy wszystko, aby system zadziałał prawidłowo. W piątek wieczorem przed planowanym uruchomieniem produkcyjnym (poniedziałek rano) przyjechaliśmy na lotnisko. Zadowoleni z pracy, którą wykonaliśmy, wpadliśmy na „genialny” pomysł: „Wsiądźmy w samochód i poudawajmy taksówkę”.
Tak naprawdę w naszych głowach brzmiało to bardziej jak: „Przejedźmy się i podziwiajmy jaki super system stworzyliśmy”. Tak też zrobiliśmy. Jakież było nasze zdziwienie, gdy po dwóch przejazdach okazało się, że owszem, system działa zgodnie z założeniami, ale jeśli nic nie zmienimy to w poniedziałek rano możemy doprowadzić do paraliżu komunikacyjnego lotniska. Było spowodowane przez drobne rzeczy, których wcześniej nie uwzględniliśmy, takie jak np. czas wyświetlania komunikatu dla taksówki czy konieczność oczekiwania taksówki na skrzyżowaniu z sygnalizacją świetlną. Rzeczy, które można było wykryć tylko wcielając się w rolę użytkownika w jego naturalnym środowisku. Całe szczęście mieliśmy jeszcze 2 dni, katastrofy udało się uniknąć i wdrożenie zakończyło się sukcesem (oczywiście nie obyło się bez problemów, ale nie były one krytyczne). System był przetestowany „z każdej strony” – niestety nie w realnych warunkach w których będzie działał.
Budowlaniec z IT
Innym razem pracowałem nad projektem mającym na celu wsparcie prowadzenia projektów budowlanych (rejestracja czasu, możliwość dokumentowania prac itp.). System tworzony w modelu SaaS, co powodowało mnogość wariacji procesów, które są obsługiwane i różne (czasem sprzeczne) wymagania. Jednym z modułów systemu była aplikacja mobilna dla pracowników. Kiedy mieliśmy gotową pierwszą wersję (sporo przed wdrożeniem produkcyjnym) pojawiła się możliwość abym popracował tydzień na budowie. Wziąłem więc krótki urlop od analizy i zatrudniłem się jako budowlaniec.
Pierwszego dnia namówiłem moich współpracowników, aby pomogli mi sprawdzić jak działa i do czego nadaje się aplikacja, którą stworzyliśmy. Jak możecie się domyślić, to było najlepszy test, jaki kiedykolwiek udało mi się przeprowadzić. Użyteczność aplikacji była wcześniej weryfikowana, ale zobaczyć ją działającą w naturalnym środowisku było przejściem o dwa lub trzy poziomy świadomości wyżej. Pozyskaliśmy mnóstwo wartościowych informacji, począwszy od ograniczeń środowiskowych (np. okazało się, że pracownicy nie zawsze mają telefon przy sobie), przez ograniczenia infrastrukturalne (pracownicy tylko od czasu do czasu włączali transfer danych w telefonach, żeby nie wyczerpać limitu – takie czasy 🙂 oraz nie zawsze był odpowiedni zasięg), ograniczenia powodowane przez zaawansowanie technologiczne użytkowników (część funkcjonalności w aplikacji nie została nawet odkryta, ponieważ zastosowaliśmy rozwiązania, które były zbyt zaawansowane w stosunku do poziomu świadomości technologicznej użytkowników), do problemów ze stabilnością rozwiązania i propozycji kliku potencjalnych funkcjonalności.
Wyjdź ze strefy komfortu
Mogła się w Was zrodzić pewna
wątpliwość: „No dobra, ale chwilę wcześniej pisałeś o testowaniu bez
angażowaniu użytkowników, a uraczyłeś nas historyjką o tym jak testowałeś z
potencjalnymi użytkownikami”. To prawda. Co więcej, zrobiłem to celowo. Nie
oszukujmy się – najlepsze rezultaty dadzą testy z użytkownikami i to do nich
powinniśmy dążyć. Często to my jesteśmy główną barierą, która blokuje
przeprowadzenie takiego testu. My którzy mówimy: „nie, mój klient nigdy się na
to nie zgodzi”, „nie, ta aplikacja nie jest jeszcze gotowa na tyle, aby sprawdzać
ją na potencjalnych użytkownikach”, „nie, użytkownicy mojej aplikacji są po
drugiej stronie świata”, „nie, osoby na których mógłbym to przetestować są zbyt
zajęte”… i takich przykładów można by napisać jeszcze kilkanaście. Tak
naprawdę wystarczy trochę zaangażowania i wysiłku, a czasem szczypty
kreatywności i odwagi, a okazuje się, że jednak można. Przykład powyżej jest
tego niezłą ilustracją. System, który tworzyliśmy dedykowany był na rynki
skandynawskie. Zorganizowanie takiego samego testu w Norwegii byłoby dużo
trudniejsze (odległość, koszty, bariera kulturowa, bariera językowa).
Podjęliśmy więc próbę lokalnie. W takiej
sytuacji trzeba jednak pamiętać, aby odpowiednio interpretować uzyskane
informacje (w końcu uwarunkowania skandynawskie i polskie są inne). Pamiętajmy,
że:
- test taki nie sprawdza, czy dostarczamy wartość
(to jesteśmy w stanie zweryfikować tylko mając właściwą dobraną grupę
badawczą), lecz jak tę wartość dostarczamy,
- jeśli rzetelnie przeprowadziliśmy analizę na
wcześniejszych etapach projektu, mamy wiedzę, która pozwoli nam na
interpretację wyników.
Przykładowo, wystarczyła szybka
weryfikacja rynku skandynawskiego aby jedną z pozyskanych podczas mojego testu
informacji „wyłączanie transferu danych przez użytkowników” wyeliminować jako nieistotną
z punktu widzenia rynku docelowego.
Jeśli nie chcecie zatrudniać
się na budowie, lub nie jesteście w stanie opuścić swego ciała, tak aby jako
niewidzialny byt obserwować potencjalnych użytkowników naszej aplikacji (jak
bardzo chciałbym, aby to było możliwe :), poszukajcie innego sposobu. Może
macie ciocię – księgową, która robi dokładnie to do czego dedykowany jest Wasz
system i wpisuje się w profil użytkownika docelowego? Zapytajcie – może zgodzi
się używać przez jakiś czas aplikacji nawet jeśli utrudni to jej życie i będzie
musiała wprowadzać dane do dwóch systemów równocześnie. Może wystarczy zapytać
znajomych?
Najważniejsze rzeczy o których
należy pamiętać:
- wybrana osoba (grupa osób) powinna być jak
najbardziej zbliżona profilem do użytkownika docelowego systemu,
- osoba powinna używać system, w schemacie
przewidzianym dla tego systemu (przebadanie z osobą jednorazowego utworzenia
faktury w systemie, który używany będzie do wystawiania kilkudziesięciu faktur
dziennie przez testowaną osobę, może dać nam zupełnie inne wnioski niż
rzeczywiste używanie tego systemu przez kilka dni).
Czy da się przeprowadzić taki
test w przypadku każdego systemu – oczywiście, że nie. Pytanie tylko na ile
faktycznie się nie da, a na ile my sami jesteśmy przeszkodą. Czasem trzeba
powalczyć o dobro na tym świecie 🙂
Odkryj w sobie aktora
Co jednak w sytuacji, kiedy nie
będziecie w stanie przeprowadzić testów z użytkownikami (czasem potencjalnymi),
lub po prostu będziecie chcieli pogłębić swoją wiedzę o odczuwaniu systemu?
Zostańcie użytkownikami sami. Spróbujcie znaleźć sferę swojego życia, w której
można go zastosować i zacznijcie go używać. Notujcie wszystkie rzeczy, które
Wam się nie podobają, które poddalibyście optymalizacji, wszystko co utrudnia
Wam prace i Was irytuje – począwszy od przycisku w niewłaściwym miejscu, przez
brak potrzebnych danych na niektórych widokach, do szybkości odpowiedzi
systemu. Brzmi znajomo? Możecie teraz pomyśleć „Chwila, ale przecież zawsze tak
robimy…”. Moje pytanie brzmi – czy na pewno używacie tego systemu jako
użytkownik, czy może tylko sprawdzacie, czy działa zgodnie z projektem?
Po pewnym czasie od wdrożenia
ww. systemu do zarządzania projektami budowlanymi (system cały czas jest
rozwijany) zacząłem się zastanawiać co tak naprawdę czuje się jego użytkownik.
O drugim eksperymencie z budową nie było raczej mowy (szkoda :), ale
wiedziałem, że w pewnych kontekstach praca na projektami budowlanymi, nie różni
się tak bardzo od pracy nad projektami informatycznymi – też są zadania do wykonania,
też trzeba zarejestrować czas pracy. Utworzyłem więc konto produkcyjne i
zacząłem na co dzień używać aplikacji. Co więcej – zachęciłem część z
developerów do zrobienia tego samego. Po tygodniu użytkowania zauważyłem
rzeczy, których nie widziałem przechodząc te same ścieżki kilkaset razy
wcześniej podczas testów. Poczynając od drobnych usprawnień, które zwiększyłyby
użyteczność systemu, po pewne zjawiska, które były po prostu irytujące.
Problem z testami
akceptacyjnymi polega na tym, że sprawdzamy czy funkcjonalność systemu działa
poprawnie (zgodnie z projektem) dla różnych scenariuszy i mamy bardzo
ograniczone szanse na wykrycie potencjalnych problemów wynikających z
rzeczywistego użycia systemu (które często jest wielokrotnym powtarzaniem tych
samych scenariuszy).
Gdzie zatem tkwi haczyk? W tym,
że my (choćbyśmy udawali najlepiej jak potrafimy) nie jesteśmy docelowymi
użytkownikami systemu. Uwagi, które wynotowaliśmy są wynikiem subiektywnej
oceny na którą mają wpływ nasze środowisko,
doświadczenia, kontekst użytkowania i osobiste upodobania oraz potrzeby. Zanim
więc wrzucimy je do backlogu, musimy przeanalizować, czy będą miały taką samą
wagę dla użytkownika końcowego i wyeliminować te, które będą dla Niego
nieistotne lub wręcz nieprawidłowe. Dobra wiadomość jest taka, że posiadamy
odpowiednią wiedzę, aby to zrobić. W końcu przeprowadziliśmy wcześniej analizę
systemu 🙂 Dla przykładu: jedna z uwag z moich testów brzmiała: „na raporcie
czasu z danego dnia chciałbym widzieć sumę godzin zarejestrowaną dla zadania, a
nie czas rozpoczęcia i zakończenia pracy w tym zadaniu”. Z wywiadów
przeprowadzonych z firmami budowlanymi, wiem jednak, że dość często ich klienci
wymagają dostarczenia dokładnego rejestru godzin (który jest później przez nich
weryfikowany). Pracownik musi więc mieć możliwość łatwego sprawdzenia
poprawności czasu rozpoczęcia i zakończenia prac. Moja uwaga w dużej mierze
wynikała ze sposobu, w który ja raportuję czas (ilość czasu poświęconego na
zadanie). Można jednak rozważyć wyświetlenie sumy godzin jako dodatkowej
informacji (choć należałoby zweryfikować, czy wniesie to jakąś wartość dla firm
budowlanych).
Zmieniaj systemy na lepsze
Pozostaje tylko pytanie: „Czy
warto?”. W końcu prędzej czy później prawdopodobnie użytkownicy zaczną używać
tego systemu i może sami zgłoszą te problemy. Tylko czy wtedy nie będzie już za
późno? Czy nie uderzy to
w nasz wizerunek? Czy będzie można jeszcze wprowadzić zmiany, czy może projekt
będzie już zamknięty? Ja żyję w przekonaniu, że Analityk Biznesowy bierze na
siebie odpowiedzialność dostarczenia jak najlepszego rozwiązania.
Największą
nagrodą jest zadowolony klient. Warto więc spróbować usprawnić to co
dostarczyliśmy, po to aby na koniec usłyszeć: „Ten system jest dokładnie tym,
czego potrzebowaliśmy”. potrzebowaliśmy”.
autor: Przemysław Machlowski
