lukaszkogut.pl

Odcinek 9 serii: AgileBA w praktyce wdrożenia WMS

W historyjkach użytkownika piszemy: „Jako magazynier chcę…”

I tu zaczyna się problem. Bo „magazynier” nie istnieje.

Istnieje Ewa, która jest na magazynie od trzech tygodni, przyszła z agencji pracy tymczasowej i boi się, że naciśnie nie ten przycisk i zablokuje rampę.

Istnieje Piotr, który pracuje na kompletacji od dwunastu lat, jest najszybszy na zmianie i ma własne skróty, bo „tak się da szybciej”.

Ten sam system. Ta sama historyjka. Zupełnie inne potrzeby.

(Ewa i Piotr są postaciami ilustracyjnymi, stworzonymi na potrzeby tej serii. Opisują typowe sytuacje, a nie konkretne osoby ani konkretną firmę.)

Czym jest Persona w AgileBA

W odcinku 6 pisaliśmy historyjki w formacie „Jako <rola> chcę <funkcja> aby <rezultat>„. Rola jest tam pierwszym słowem, ale też najczęściej najmniej przemyślanym.

AgileBA proponuje narzędzie, które tę lukę wypełnia: Persona. To „aktor” w naszym rozwiązaniu. Tworzenie Persony polega na identyfikowaniu każdego potencjalnego użytkownika rozwiązania i traktowaniu go jak prawdziwą osobę albo kategorię osób, z uwzględnieniem jej:

• upodobań,
• niechęci,
• obaw,
• potrzeb.

Persony powinny wydawać się prawdziwe. Metodyka zaleca, żeby obejmowały fotografię, a nawet krótką biografię. To nie ozdoba: im bardziej Persona przypomina kogoś, kogo można spotkać na hali, tym łatwiej zespołowi o niej rozmawiać, kłócić się o nią i podejmować decyzje „z jej perspektywy”.

Ewa i Piotr: dwie różne osoby, jedna historyjka

Weźmy historyjkę z odcinka 6:

Jako magazynier chcę, żeby system wskazał mi lokalizację, w której mam odłożyć paletę, aby nie tracić czasu na szukanie wolnego miejsca i nie blokować korytarza.

Teraz zobaczmy ją oczami dwóch Person.

	Ewa (przyjęcie)	Piotr (kompletacja)
Doświadczenie	3 tygodnie, agencja pracy tymczasowej	12 lat na magazynie
Czego potrzebuje od systemu	Jasnego komunikatu, jednego kroku naraz, informacji, co robić, gdy coś pójdzie nie tak	Minimum kliknięć i systemu, któremu może zaufać
Czego się obawia	Pomyłki, która zablokuje rampę albo wpędzi ją w kłopoty	Że system go spowolni i obniży jego wyniki
Co go/ją irytuje	Komunikaty w żargonie, których nie rozumie	Ekran, który każe potwierdzać oczywistości
Co zrobi, gdy system przeszkadza	Poprosi o pomoc albo przerwie pracę	Znajdzie obejście

(Opisy ilustracyjne, oparte na typowych sytuacjach na magazynie.)

Ta ostatnia linijka to ta sama pułapka, o której była mowa w odcinku 4 o interesariuszach: magazynierzy, którzy skanują po fakcie, hurtem albo wcale, bo system ich spowalnia. Persona Piotra pozwala przewidzieć to zanim system trafi na halę, a nie odkryć po kilku tygodniach, że dane nie są wiarygodne.

Jeden ekran, który zadowoli oboje, bywa trudny do zaprojektowania. Ale dopóki nie wiemy, że to dwie różne osoby, nie mamy nawet szansy się nad tym zastanowić. „Magazynier” to uśredniony użytkownik, który nie istnieje i dla którego nikt nie zaprojektuje niczego sensownego.

Gdzie Persony przydają się w praktyce

1. W historyjkach. „Jako Ewa chcę, żeby komunikat o braku miejsca w strefie mówił mi, dokąd mam iść dalej, aby nie musieć szukać kierownika.” Konkretniejsze, łatwiejsze do oszacowania, łatwiejsze do przetestowania.

2. W mapowaniu podróży klienta. To technika, o której wspominałem w odcinku 8. Schemat jej użycia według AgileBA jest prosty: wybieramy Personę, określamy jej cel, wyznaczamy punkty styku łączące Personę z usługą, a potem analizujemy jej doświadczenia w kolejnych punktach. Mapa pokazuje luki, problemy i szanse. Dla Ewy mapa „pierwszy tydzień pracy z terminalem” będzie wyglądała zupełnie inaczej niż dla Piotra.

3. Na demonstracjach i testach. Pytanie „czy działa?” zastępujemy pytaniem „czy Ewa poradzi sobie z tym bez pomocy?” i „czy Piotr nie uzna, że to go spowalnia?”. To bardzo praktyczny test akceptacji z perspektywy użytkownika.

4. W priorytetyzacji. Przy MoSCoW (odcinek 7) łatwiej rozstrzygać spory, kiedy można zapytać: komu ta funkcja realnie pomoże? Jeśli odpowiedź brzmi „nikomu z naszych Person”, to prawdopodobnie jest to „Could” albo „Nie tym razem”.

Jak tworzyć Persony: kilka praktycznych zasad

Poniższe zasady to moja praktyczna rada, a nie cytat z podręcznika AgileBA. Metodyka definiuje, czym jest Persona i do czego służy, a szczegóły tworzenia zostawia praktykom.

Tworzymy je na podstawie obserwacji i rozmów, a nie przy biurku. To bezpośrednie nawiązanie do odcinka 5. Pół dnia spędzone na hali z Ewą (albo kimś takim jak Ewa) da więcej niż dwugodzinny warsztat w sali konferencyjnej. Persona wymyślona w pokoju bez okien to po prostu życzenie.

Mniej znaczy lepiej. Trzy do pięciu dobrze opisanych Person zwykle wystarcza. Dziesięć Person to już katalog, którego nikt nie pamięta.

Unikamy stereotypów. Persona to nie karykatura („doświadczony magazynier, który nienawidzi komputerów”). To człowiek z konkretnymi potrzebami i konkretnymi powodami, dla których pracuje tak, a nie inaczej. Piotr nie jest „oporny na zmiany”, tylko ma uzasadnione obawy o swoje wyniki.

Nie wystarczy jedna Persona „dla wszystkich”. Jeśli opis pasuje do każdego, nie pasuje do nikogo.

Persona to nie wyłącznie rola. Dwie osoby na tym samym stanowisku mogą mieć zupełnie różne potrzeby (Ewa i Piotr obaj „pracują na magazynie”). Rola odpowiada na pytanie „co robi?”, Persona na pytanie „kim jest i czego potrzebuje?”.

Wracamy do nich. Persona, która powstała na warsztacie i trafiła do szuflady, jest bezużyteczna. Powinna wisieć na ścianie, pojawiać się w historyjkach, być przywoływana na demonstracjach.

Weryfikujemy. Gdy okaże się, że realni użytkownicy zachowują się inaczej, niż zakładaliśmy, poprawiamy Personę. Tak jak Uzasadnienie Biznesowe i priorytety, to dokument „żywy”.

Szablon Persony do wypełnienia

Poniżej prosty szablon, który można wydrukować i wypełnić na warsztacie z ludźmi z hali. Ostatnie pole jest najważniejsze: pokazuje, czy Persona opiera się na faktach, czy na domysłach.

Pole	Opis	Twoja Persona
Imię i rola	Imię (może być zmienione) i stanowisko / obszar pracy
Zdjęcie lub szkic	Cokolwiek, co nadaje twarz
Krótka biografia	2-3 zdania: skąd, jak długo na magazynie, jak trafiła/trafił do tej pracy
Doświadczenie z systemami	Skanery, terminale, WMS, ERP: jak radzi sobie z technologią?
Typowy dzień pracy	Kiedy zaczyna, jakie zadania, jakie przestoje, gdzie traci czas
Cele	Co chce osiągnąć? (np. nie popełnić błędu, osiągnąć normę)
Potrzeby	Czego potrzebuje, żeby dobrze wykonać pracę?
Upodobania	Co działa dla niej/niego dobrze?
Niechęci	Co ją/jego irytuje?
Obawy	Czego się boi w związku z nowym systemem?
Warunki pracy	Hałas, rękawice, oświetlenie, pośpiech, praca na stojąco
Co zrobi, gdy system przeszkadza?	Poprosi o pomoc? Znajdzie obejście? Przestanie używać?
Charakterystyczny cytat	Jedno zdanie, które oddaje jej/jego podejście
Skąd to wiemy?	Obserwacja, rozmowa, dane, a może tylko domysł?

Przykład wypełnienia (ilustracyjny):

Pole	Ewa
Imię i rola	Ewa, operator przyjęć
Krótka biografia	Trzy tygodnie na magazynie, wcześniej praca w handlu. Przyszła z agencji pracy tymczasowej.
Doświadczenie z systemami	Obsługiwała kasę fiskalną, nigdy nie pracowała na terminalu mobilnym
Cele	Przejść okres próbny, nie popełnić błędu przy przyjęciu
Obawy	Że zablokuje rampę, że pomyli lokalizację, że ktoś na nią krzyknie
Niechęci	Komunikaty typu „błąd 4017”
Co zrobi, gdy system przeszkadza?	Poszuka kogoś doświadczonego, a gdy nikogo nie ma, przerwie pracę
Charakterystyczny cytat	„Wolę zapytać dwa razy niż zrobić źle raz.”
Skąd to wiemy?	(do uzupełnienia: obserwacja zmiany porannej, rozmowa z brygadzistą)

Pytania kontrolne

1. Czy w naszych historyjkach występuje „magazynier”, czy konkretne Persony?
2. Czy Persony powstały na podstawie obserwacji i rozmów z hali, czy przy biurku?
3. Ile ich mamy? Czy ktoś potrafi wymienić je z pamięci?
4. Czy mamy w gronie Person kogoś, kto najbardziej obawia się zmiany, i kogoś, kto jest w pracy najszybszy?
5. Czy na demonstracjach faktycznie pytamy, jak system sprawdzi się z perspektywy konkretnej Persony?

---

To dziewiąty odcinek serii łączącej metodykę AgileBA z praktyką wdrożeń WMS. Kolejny odcinek: Timeboxing we wdrożeniu WMS, czyli dlaczego „zrobimy wszystko na raz” to prosta droga do katastrofy i jak etapować uruchomienie.

A jak było u Was? Czy w projekcie WMS ktoś zastanawiał się, jak z systemu skorzysta najmniej doświadczony pracownik zmiany? A jak najbardziej doświadczony?