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