Persona w analizie biznesowej: jak zbudować ją na danych

Na ścianie sali projektowej wisi plakat: "Marta, 34 lata, mieszka w Krakowie, lubi jogę i podcasty". Zespół mija go codziennie od trzech miesięcy i nikt ani razu nie użył Marty do podjęcia decyzji. Bo Marta nie mówi nic o tym, czego Marta potrzebuje od systemu, który budujecie.

Tak wygląda większość person w polskich projektach IT. Ładna grafika, zero wpływu na wymagania. A persona to jedno z niewielu narzędzi, które potrafi realnie zmienić sposób, w jaki zespół rozmawia o użytkownikach - pod warunkiem, że zbudujesz ją na danych, a nie na wyobrażeniach z burzy mózgów.

Poniżej cały proces: skąd brać dane, co persona ma zawierać, jak zacząć bez budżetu i jak podpiąć ją pod user stories. Na końcu szablon i wypełniony przykład dla systemu HR.

Persona z sufitu vs persona z badań - dlaczego większość person ląduje w szufladzie

Persona z sufitu powstaje tak: zespół siada na warsztacie, ktoś rzuca "no to nasz użytkownik to pewnie kobieta, 30-40 lat, pracuje w biurze", ktoś dorysowuje hobby, ktoś wybiera zdjęcie ze stocka. Godzina pracy, efekt wygląda profesjonalnie.

Problem: taka persona jest lustrem zespołu, nie użytkownika. Utrwala założenia zamiast je testować. Jeśli zespół myśli, że użytkownicy "nie lubią zmian", persona z warsztatu też będzie "nie lubić zmian" - i nikt nigdy nie sprawdzi, czy to prawda.

Persona z badań powstaje odwrotnie. Najpierw dane: rozmowy z użytkownikami, zgłoszenia do wsparcia, analityka. Potem wzorce - grupy ludzi o podobnych celach i problemach. Dopiero na końcu twarz i imię.

Różnicę widać w momencie sporu. Gdy ktoś kwestionuje personę z sufitu, dyskusja brzmi "a ja myślę, że użytkownicy wolą inaczej" - opinia kontra opinia. Gdy ktoś kwestionuje personę z badań, odpowiadasz: "w ośmiu z dwunastu wywiadów pojawił się dokładnie ten problem". Koniec dyskusji, wracamy do roboty.

W BABOK persony to część techniki "Stakeholder List, Map, or Personas". Dobra podpowiedź, do czego naprawdę służą: do zrozumienia interesariuszy na tyle konkretnie, żeby dało się podejmować decyzje o wymaganiach.

Skąd brać dane: cztery źródła, które masz bliżej niż myślisz

Nie potrzebujesz agencji badawczej. Większość danych już jest w organizacji, tylko nikt ich nie skleił.

Wywiady z użytkownikami

Podstawa. Wystarczy 5-8 rozmów po 30-45 minut na jedną grupę użytkowników, żeby zobaczyć powtarzające się wzorce. Pytaj o konkrety, nie o opinie: "opowiedz mi, jak wyglądał Twój ostatni onboarding nowego pracownika, krok po kroku" zamiast "czy proces onboardingu jest wygodny?". Ludzie fatalnie przewidują własne zachowania, ale świetnie opowiadają o tym, co zrobili wczoraj.

Zgłoszenia do wsparcia i helpdesku

Kopalnia frustracji, za darmo. Wyeksportuj tickety z kilku miesięcy, pogrupuj tematycznie i policz. Jeśli jedna trzecia zgłoszeń dotyczy resetowania hasła do jednego modułu, masz frustrację numer jeden do karty - realny, mierzony ból, nie domysł.

Analityka produktu

Jeśli system już działa, dane o zachowaniach pokazują to, czego ludzie nie powiedzą w wywiadzie. Które funkcje są używane codziennie, a których nikt nie otworzył od wdrożenia. W którym kroku formularza użytkownicy się poddają. Persona księgowej, która robi zamknięcie miesiąca między 1. a 5. dniem, to zupełnie inny kontekst obciążenia niż równy ruch przez cały miesiąc.

Obserwacja użytkowników przy pracy

Najbardziej niedoceniane źródło. Usiądź obok użytkownika na godzinę i patrz, jak naprawdę pracuje. Zobaczysz rzeczy, o których nikt Ci nie powie, bo dla użytkownika są niewidzialne: Excel prowadzony "obok systemu", żółte karteczki z kodami obejść, ręczne kopiowanie danych między dwoma oknami. Każde takie obejście to gotowy wsad do sekcji "frustracje" - i często gotowe wymaganie.

Zasada łączenia źródeł: wywiady mówią "dlaczego", analityka i tickety mówią "co i jak często". Persona zbudowana tylko na jednym źródle jest ślepa na jedno oko.

Anatomia użytecznej persony: cele, frustracje, kontekst pracy

Wiek, miasto i hobby nie pomagają podjąć żadnej decyzji projektowej. To dekoracja przeniesiona żywcem z marketingu. Użyteczna persona w analizie biznesowej odpowiada na inne pytania:

• Rola i odpowiedzialność - za co ta osoba odpowiada i z czego jest rozliczana. Nie stanowisko z papieru, tylko realny zakres.
• Cele - co ta osoba chce osiągnąć, używając systemu. Nie "chce wygodnego narzędzia" (to chce każdy), tylko np. "chce zamknąć rozliczenie urlopów bez ręcznego sprawdzania sald w trzech miejscach".
• Frustracje - co dziś ją blokuje albo zwyczajnie wkurza. Najlepiej z liczbą lub cytatem z badań.
• Kontekst pracy - kiedy i w jakich warunkach korzysta z systemu. Codziennie po 6 godzin czy raz w miesiącu przez 15 minut? Przy biurku w spokoju czy na hali, z tabletem i kolejką ludzi nad głową? Użytkownik "raz w miesiącu" potrzebuje prowadzenia za rękę, użytkownik "cały dzień" - skrótów klawiszowych.
• Poziom biegłości - z narzędziami w ogóle i z Waszą domeną. To decyduje o tym, ile system może od użytkownika wymagać.
• Cytat - jedno prawdziwe zdanie z wywiadów, które oddaje sedno. Prawdziwe, nie wymyślone. Cytat robi więcej dla empatii zespołu niż cała reszta karty.

Test jakości jest prosty: czy karta rozstrzyga realny spór projektowy? "Dodajemy import z Excela?" - jeśli persona ma frustrację "ręczne przepisywanie danych z arkusza rekrutacyjnego", odpowiedź wynika z karty. Jeśli mówi tylko, że Marta lubi jogę - jest bezużyteczna.

Proto-persona: wersja startowa, gdy nie masz budżetu na badania

Czasem nie ma czasu ani zgody na wywiady, a projekt startuje lada moment. Wtedy uczciwym rozwiązaniem jest proto-persona: karta zbudowana na wiedzy zespołu i interesariuszy, z jawnie przyklejoną etykietą "hipoteza, nie fakt".

Różnica między proto-personą a personą z sufitu nie leży w treści, tylko w statusie. Proto-persona to zestaw założeń do zwalidowania, z planem walidacji. Persona z sufitu udaje wiedzę.

Jak pracować z proto-personą:

1. Zbuduj ją z ludźmi najbliżej użytkownika - wsparcie, sprzedaż, key userzy. Oni mają najwięcej kontaktu z rzeczywistością.
2. Oznacz każdy element pewnością. Fakt (mamy dane), przypuszczenie (słyszeliśmy od kogoś), zgadywanka (wydaje nam się). Zobaczysz czarno na białym, ile karta ma dziur.
3. Ustal plan walidacji. Najtańsza wersja: przy każdej okazji kontaktu z użytkownikiem (demo, UAT, szkolenie, ticket) sprawdzaj jedno założenie z karty. Trzy pytania doklejone do spotkania, które i tak się odbywa, kosztują zero.
4. Aktualizuj i datuj. Proto-persona bez daty ostatniej weryfikacji po pół roku znów jest personą z sufitu, tylko starszą.

Nawiasem mówiąc - budowanie obrazu użytkownika z rozproszonych strzępów wiedzy to kompetencja, którą ludzie wchodzący do analizy biznesowej z innych zawodów często już mają. Jeśli jesteś na tym etapie, zobacz ścieżki przebranżowienia do roli analityka.

Jak używać person przy wymaganiach i priorytetyzacji

Persona, która nie pracuje przy wymaganiach, to plakat. Trzy konkretne zastosowania:

User story z personą zamiast "as a user"

Klasyczny grzech backlogu: sto historyjek od "jako użytkownik chcę...". "Użytkownik" nie istnieje - istnieje rekruterka przetwarzająca 40 aplikacji dziennie i dyrektor, który raz na kwartał chce jeden raport.

Porównaj:

Jako użytkownik chcę filtrować listę kandydatów, żeby szybciej znaleźć właściwych.

Jako Ola (rekruterka, 40 aplikacji dziennie) chcę zapisać zestaw filtrów jako widok domyślny, żeby nie ustawiać tych samych sześciu filtrów przy każdym otwarciu listy.

Druga wersja sama podpowiada kryteria akceptacji i od razu widać, dla kogo to robimy. Podmiana "as a user" na konkretną personę to najtańsze podniesienie jakości backlogu, jakie znam.

Priorytetyzacja

Gdy dwie funkcje walczą o miejsce w sprincie, pytanie "która ważniejsza?" zamienia się w "dla której persony i jak często?". Funkcja dotykająca głównej persony codziennie zwykle wygrywa z funkcją dla persony pobocznej raz na kwartał. To nie automat (czasem rzadka operacja jest krytyczna prawnie), ale rozmowa robi się merytoryczna zamiast politycznej.

Ocena zakresu i luk

Rozłóż backlog na persony i policz. Jeśli 80% historyjek obsługuje administratora, a główna persona operacyjna ma trzy, coś poszło nie tak przy zbieraniu wymagań. Lepiej zobaczyć to przed wdrożeniem niż po.

Persona a segment marketingowy - to nie to samo narzędzie

Te dwa pojęcia mylą się notorycznie, bo oba nazywają się czasem "persona". Różnica:

W B2B rozjazd jest dramatyczny: kupującym jest dyrektor HR, a użytkownikiem specjalistka, która w systemie spędzi 6 godzin dziennie. Persona marketingowa opisze dyrektora. Zaprojektujesz na jej podstawie system i zbudujesz narzędzie pod kogoś, kto otworzy je dwa razy w roku.

Jeśli w organizacji istnieją persony marketingowe, nie wyrzucaj ich - ale nie projektuj na ich podstawie wymagań. Inne narzędzie, inna decyzja.

Szablon persony + przykład wypełniony dla systemu HR

Szablon do skopiowania. Jedna strona, ani linijki więcej - persona na trzy strony nie będzie czytana.

PERSONA: [imię + rola]                    Status: [zbadana / proto]
Źródła: [np. 6 wywiadów, tickety z 3 mies., obserwacja 2h]   Data weryfikacji: [RRRR-MM]

ROLA I ODPOWIEDZIALNOŚĆ
Za co odpowiada, z czego jest rozliczana.

CELE (max 3)
1. ...
2. ...
3. ...

FRUSTRACJE (max 3, z dowodem)
1. ... [źródło: ...]
2. ... [źródło: ...]
3. ... [źródło: ...]

KONTEKST PRACY
Częstotliwość i długość pracy w systemie, miejsce, urządzenie,
presja czasu, szczyty obciążenia.

BIEGŁOŚĆ
Narzędzia ogólnie / nasza domena.

CYTAT
"..." (prawdziwy, z badań)

CZEGO NIE ROBI
Operacje poza zakresem tej persony (chroni przed rozdymaniem).

I przykład wypełniony - system HR do obsługi urlopów i onboardingu:

PERSONA: Ola - specjalistka HR              Status: zbadana
Źródła: 5 wywiadów, 214 ticketów helpdesku, obserwacja 2h   Data weryfikacji: bieżący kwartał

ROLA I ODPOWIEDZIALNOŚĆ
Obsługuje wnioski urlopowe i onboarding dla ~300 pracowników.
Rozliczana z terminowości onboardingu i poprawności sald urlopowych.

CELE
1. Zamknąć komplet formalności onboardingowych przed pierwszym dniem pracy nowej osoby.
2. Odpowiadać na pytania o saldo urlopu bez ręcznego liczenia w Excelu.
3. Nie być wąskim gardłem: przenieść proste sprawy na samoobsługę pracowników.

FRUSTRACJE
1. Dane nowego pracownika wpisuje ręcznie w trzech systemach; każda literówka
   wraca jako ticket. [obserwacja + wywiady 4/5]
2. Salda urlopowe w systemie rozjeżdżają się z rzeczywistością po umowach
   na część etatu - prowadzi równoległy arkusz. [wywiady 5/5]
3. Największa grupa ticketów do HR to pytania "ile mam urlopu?". [tickety]

KONTEKST PRACY
System otwarty cały dzień, praca przy biurku na laptopie. Szczyty:
maj-czerwiec (wnioski urlopowe) i pierwsze dni miesiąca (starty nowych osób).
Częste przerywanie pracy - telefony i wiadomości od pracowników.

BIEGŁOŚĆ
Sprawna w narzędziach biurowych, bardzo dobra znajomość prawa pracy.
Nie zna i nie chce znać "technicznych" ustawień systemu.

CYTAT
"Ja nie potrzebuję kolejnego systemu. Ja potrzebuję przestać przepisywać
te same dane trzy razy."

CZEGO NIE ROBI
Nie nalicza wynagrodzeń, nie konfiguruje uprawnień, nie tworzy raportów
zarządczych (to persona: HR Business Partner).

Zwróć uwagę, ile decyzji projektowych wynika wprost z tej karty: jedno źródło danych pracownika (frustracja 1), poprawna obsługa etatów cząstkowych w saldach (frustracja 2), samoobsługowy podgląd salda (frustracja 3 + cel 3). To jest różnica między plakatem a narzędziem pracy analityka.

Persony to też element warsztatu sprawdzanego na certyfikacjach BA - jeśli porządkujesz swoje techniki pod kątem egzaminu, porównaj wymagania w porównywarce certyfikacji.

Od czego zacząć: plan na pierwszy tydzień

Nie potrzebujesz zgody zarządu ani budżetu. Wybierz jeden system, nad którym pracujesz, i:

1. Wyciągnij tickety wsparcia z 3 miesięcy wstecz i pogrupuj je tematycznie (godzina pracy).
2. Umów dwie rozmowy z użytkownikami - o tym, co robili wczoraj, nie o tym, czego chcą.
3. Wypełnij szablon powyżej, oznacz status "proto" tam, gdzie brakuje danych.
4. Przy najbliższym spornym wymaganiu połóż kartę na stole i sprawdź, czy rozstrzyga spór.

Jeśli rozstrzyga - masz działającą personę. Jeśli nie - wiesz dokładnie, jakich danych Ci brakuje.

A jeśli chcesz przećwiczyć budowanie person i innych technik BA na realistycznych scenariuszach, z feedbackiem zamiast samotnego czytania teorii - załóż konto na platformie Analify i ucz się przez praktykę.