Adnotacja
Książka jest opowiedzianym algorytmem przeprowadzania procesu rozwoju od pomysłu do wdrożenia przy użyciu technik zwinnych. Proces jest podzielony na etapy i na każdym etapie wskazane są metody stosowane w danym etapie procesu. Autor zwraca uwagę, że większość metod nie jest oryginalna, nie podając się za oryginalną. Jednak dobry styl pisania i pewna rzetelność procesu sprawiają, że książka jest bardzo użyteczna.
Kluczową techniką mapowania historii użytkownika jest uporządkowanie pomysłów i wyników w miarę poruszania się użytkownika przez proces.
Jednocześnie proces ten można opisać na różne sposoby. Możesz budować kroki w miarę osiągania kluczowej wartości lub możesz po prostu wyobrazić sobie dzień pracy użytkowników podczas korzystania z systemu. Autor skupia się na tym, że procesy należy opisać, opowiedzieć w formie user history na mapie procesów, stąd nazwa user history map.
Kto tego potrzebuje
Dla analityków IT i kierowników projektów. Musisz to przeczytać. Książkę czyta się łatwo i przyjemnie, jest średniej wielkości.
wycofanie
W najprostszej formie wygląda to tak.
Gość przychodzi do kawiarni, wybiera dania, składa zamówienie, otrzymuje jedzenie, je i płaci.
Na każdym etapie możemy napisać wymagania dotyczące tego, czego chcemy od systemu.
System powinien pokazywać listę dań, każde danie ma skład, wagę i cenę oraz mieć możliwość dodania do koszyka. Dlaczego jesteśmy pewni tych wymagań? Nie jest to opisane w „standardowym” opisie wymagań, co stwarza ryzyko.
Wykonawcy, którzy nie rozumieją, dlaczego jest to konieczne, zwykle postępują źle. Wykonawcy, którzy nie są zaangażowani w proces tworzenia pomysłu, nie są zaangażowani w wynik. Agile mówi, skupmy się przede wszystkim nie na systemie, ale na ludziach, na konsumentach, ich zadaniach i celach.
Tworzymy persony, przekazujemy im szczegóły dotyczące empatii i zaczynamy opowiadać historie od strony persony.
Pracownik biura Zakhar poszedł na lunch i chce zjeść szybką przekąskę. Czego potrzebuje? Pomysł jest taki, że prawdopodobnie ma ochotę na lunch biznesowy. Inny pomysł jest taki, że chce, żeby system zapamiętał jego preferencje, bo jest na diecie. Inny pomysł. Chce, żeby natychmiast przyniesiono mu kawę, bo jest przyzwyczajony do picia kawy przed lunchem.
Jest jeszcze biznes (charakter organizacyjny to cecha reprezentująca interesy organizacji). Firmy chcą zwiększyć średni czek, zwiększyć częstotliwość zakupów i zwiększyć zyski. Pomysł jest taki - proponujmy niezwykłe dania jakiejś kuchni. Kolejny pomysł - wprowadźmy śniadanie.
Pomysły można i należy konkretyzować, przekształcać i prezentować w formie historii użytkownika. Jako pracownik Zakhar Business Center chcę, żeby system mnie rozpoznał, abym mógł otrzymać menu zgodne z moimi preferencjami. Jako kelner chcę, żeby system powiadamiał mnie, kiedy mam podejść do stołu, aby klient był zadowolony z szybkiej obsługi. I tak dalej.
Dziesiątki historii. Dalej jest ustalanie priorytetów i zaległości? Jeff wskazuje na pojawiające się problemy: grzęźnienie w drobnych szczegółach i utrata zrozumienia konceptualnego, a także nadanie priorytetu funkcjonalności tworzy nierówny obraz z powodu niezgodności z celami.
Ścieżka autora: Priorytetem jest dla nas nie funkcjonalność, ale wynik = to, co ostatecznie otrzymuje użytkownik.
Oczywisty nieoczywisty punkt: sesja ustalania priorytetów nie jest prowadzona przez cały zespół, bo jest nieskuteczna, ale przez trzy osoby. Pierwszy odpowiada za biznes, drugi za doświadczenie użytkownika, a trzeci za wdrożenie.
Wybierzmy minimum do rozwiązania problemu jednego użytkownika (minimalne wykonalne rozwiązanie).
Wyszczególniamy najważniejsze pomysły, korzystając z historii użytkowników, szkiców projektowych, ograniczeń i reguł biznesowych na mapie historii użytkownika, opowiadając i omawiając z zespołem, czego potrzebują ludzie i interesariusze na każdym etapie procesu. Pozostałe pomysły pozostawiamy bez zbadania w zaległościach możliwości.
Proces jest zapisany na kartkach od lewej do prawej, a pomysły na kartkach poniżej etapów procesu. Koniecznie należy omówić drogę przez całą historię wspólnie z członkami zespołu, aby zapewnić wzajemne zrozumienie.
Opracowanie w ten sposób tworzy integralność zgodną z procesami.
Otrzymane pomysły należy przetestować. Osoba niebędąca członkiem zespołu zakłada czapkę danej osoby i przeżywa jej dzień w swojej głowie, rozwiązując jego problem. Możliwe, że nie widzi rozwoju wydarzeń, tworząc karty na nowo, a zespół odkrywa dla siebie alternatywy.
Następnie następuje wyszczególnienie w celu oceny. Do tego wystarczą trzy osoby. Odpowiedzialny za doświadczenia użytkowników, programista, tester z ulubionym pytaniem: „A co jeśli…”.
Na każdym etapie dyskusja przebiega według mapy procesu historii użytkownika, co pozwala na uwzględnienie zadania użytkownika i stworzenie spójnego zrozumienia.
Czy dokumentacja jest konieczna zdaniem autora? Tak, potrzebuję tego. Ale jako notatki, które pozwalają zapamiętać, na co się zgodziłeś. Ponowne zaangażowanie osoby z zewnątrz wymaga dyskusji.
Autor nie zagłębia się w temat wystarczalności dokumentacji, skupiając się na potrzebie dyskusji. (Tak, potrzebna jest dokumentacja, niezależnie od tego, jak twierdzą ludzie, którzy nie mają głębokiego zrozumienia zwinności). Również opracowanie tylko części możliwości może skutkować koniecznością całkowitej przeróbki całego systemu. Autor zwraca uwagę na ryzyko nadmiernego rozwinięcia w przypadku, gdy pomysł jest błędny.
Aby wyeliminować ryzyko, konieczne jest szybkie otrzymanie informacji zwrotnej na temat powstającego produktu, aby zminimalizować szkody powstałe w wyniku stworzenia „złego” produktu. Zrobiliśmy szkic pomysłu - zwalidowaliśmy go z użytkownikiem, naszkicowaliśmy prototypy interfejsów - zwalidowaliśmy z użytkownikiem itp. (Oddzielnie jest trochę informacji na temat walidacji prototypów programów). Celem tworzenia oprogramowania, zwłaszcza na początkowym etapie, jest nauka poprzez otrzymywanie szybkiej informacji zwrotnej, dlatego też pierwszym tworzonym produktem są szkice, które są w stanie udowodnić lub obalić postawioną hipotezę. (Autor opiera się na pracy Erica Riesa „Startup wykorzystujący metodologię Lean”).
Mapa historii pomaga usprawnić komunikację, gdy wdrożenie odbywa się w wielu zespołach. Co powinno znaleźć się na mapie? Czego potrzebujesz, aby kontynuować rozmowę. Nie tylko historia użytkownika (kto, co, dlaczego), ale pomysły, fakty, szkice interfejsów itp.
Dzieląc karty na mapie historii na kilka poziomych linii, możesz podzielić pracę na wydania - zaznacz absolutne minimum, warstwę zwiększającą funkcjonalność i kokardki.
Opowiadamy historie na mapie procesu.
Pracownik przyszedł na lunch.
Czego on chce? Prędkości serwisowe. Aby jego lunch już na niego czekał na stole lub chociaż na tacy. Ups - pominięty krok: pracownik chciał zjeść. Zalogował się i wybrał opcję lunchu biznesowego. Zobaczył zawartość kalorii i wartości odżywczych, które pomogły mu w diecie i zapobieganiu przybieraniu na wadze. Zobaczył zdjęcia potrawy, aby zdecydować, czy zje w tym miejscu, czy nie.
Następnie, czy pójdzie na lunch i kolację? A może lunch zostanie dostarczony do jego biura? Kolejnym etapem procesu jest wybór miejsca do jedzenia. Chce wiedzieć, kiedy zostanie mu dostarczona i ile będzie kosztować, aby móc wybrać, gdzie spędzić czas i energię – zejście na dół czy pójście do pracy. Chce zobaczyć, jak bardzo jest tłoczno w kawiarni, żeby nie przepychać się w kolejkach.
Następnie do kawiarni przyszedł pracownik. Chce zobaczyć swoją tacę, żeby móc ją zabrać i iść prosto na kolację. Kawiarnia chce przyjmować pieniądze, aby zarabiać na obsłudze. Pracownik chce tracić minimum czasu na rozliczenia z kawiarnią, aby nie marnować bezużytecznie cennego czasu. Jak to zrobić? Zapłać z góry lub odwrotnie po wykonaniu usługi zdalnie. Lub zapłać na miejscu w kiosku. Co jest w tym najważniejsze? Ile osób jest skłonnych zapłacić za lunch kartą bankową? Ile osób zaufałoby tej stołówce w przechowywaniu numeru karty w celu powtarzania płatności? Bez badań terenowych nie jest to jasne, potrzebne są badania.
Na każdym etapie procesu musisz w jakiś sposób zapewnić funkcjonalność, w tym celu musisz wziąć za podstawę jakąś osobę i wybrać to, co jest dla niej ważniejsze (te same trzy selektory). Prześledziłem historię do końca = znalazłem realne rozwiązanie.
Następnie przychodzi czas na detale. Klient chce zobaczyć jak duży jest ruch w kawiarni, żeby nie przepychać się w kolejkach. Czego on właściwie chce?
Zobacz prognozę, ile osób będzie za 15 minut, kiedy tam dotrze
Zobacz średni czas obsługi w kawiarni i jego dynamikę z półgodzinnym wyprzedzeniem
Zobacz sytuację i dynamikę obłożenia stolików
A co jeśli system prognostyczny da niejasny wynik lub przestanie działać?
Obejrzyj na wideo kolejki w kawiarni, a także obłożenie stolików. Hmm, dlaczego nie zrobić tego najpierw?!
Autorka wskazuje małe ćwiczenie do przećwiczenia: spróbuj wyobrazić sobie, co robisz rano po przebudzeniu. Jedna karta = jedna akcja. Powiększ karty (zamiast mielenia kawy wypij orzeźwiający napój), aby usunąć poszczególne szczegóły, skupiając się nie na sposobie realizacji, ale na celu.
Dla kogo jest ta książka: dla analityków IT i kierowników projektów. Musisz to przeczytać.
aplikacje
Dyskusja i podejmowanie decyzji są skuteczne w grupach liczących od 3 do 5 osób.
Na pierwszej karcie napisz, co należy rozwinąć, na drugiej - popraw to, co zrobiłeś w pierwszej, na trzeciej - popraw to, co zostało zrobione w pierwszej i drugiej.
Przygotowuj historie jak ciasta - nie pisząc przepis, ale dowiadując się, dla kogo, na jaką okazję i dla ilu osób jest to ciasto. Jeśli rozbić sprzedaż, to nie byłaby to produkcja ciast, kremów itp., ale produkcja małych gotowych ciastek.
Tworzenie oprogramowania przypomina tworzenie filmu, kiedy trzeba dokładnie opracować i dopracować scenariusz, uporządkować scenę, aktorów itp. przed rozpoczęciem zdjęć.
Zawsze będzie brakowało środków.
20% wysiłków daje wymierne rezultaty, 60% daje niezrozumiałe rezultaty, 20% wysiłków jest szkodliwych - dlatego ważne jest, aby skupić się na nauce i nie rozpaczać w przypadku negatywnego wyniku.
Komunikuj się bezpośrednio z użytkownikiem, poczuj się na jego miejscu. Skoncentruj się na niektórych problemach.
Opisywanie i rozwijanie historii do oceny to najnudniejsza część scruma, dyskusje powinny odbywać się w trybie akwariowym (3-4 osoby dyskutują na tablicy, jeśli ktoś chce wziąć udział, to kogoś zastępuje).
Źródło: www.habr.com