Streszczenie
Książka ta jest opisanym algorytmem przeprowadzania procesu rozwoju od pomysłu do wdrożenia z wykorzystaniem technik agile. Proces jest rozłożony na kroki, a na każdym etapie wskazane są metody dla danego kroku. Autor zaznacza, że większość metod nie jest oryginalna i nie aspiruje do oryginalności. Jednak dobry styl pisania i pewna spójność procesu czynią tę książkę bardzo użyteczną.
Kluczową techniką mapy użytkowników jest strukturyzacja pomysłów i wymagań w toku procesu użytkowania.
Przy tym można różnie przedstawiać przebieg procesu. Można uporządkować kroki w miarę osiągania kluczowej wartości, a można po prostu przedstawić dzień roboczy użytkowników, tak jak przebiega z użyciem systemu. Autor koncentruje się na tym, że procesy należy przedstawiać, opowiadając historię użytkownika na mapie procesu, co stało się podstawą nazwy mapa użytkownika.
Komu to potrzebne
Dla analityków IT i kierowników projektów. Zdecydowanie do przeczytania. Czyta się łatwo i przyjemnie, książka ma średnią objętość.
Revokacja
W najprostszym ujęciu, jak to działa.
Odwiedzający przychodzi do kawiarni, wybiera dania, składa zamówienie, otrzymuje jedzenie, je, płaci.
Można zapisać wymagania, co chcemy od systemu na każdym etapie.
System powinien pokazywać listę dań, przy każdym daniu skład, wagę i cenę, oraz mieć możliwość dodania do koszyka. Dlaczego jesteśmy pewni tych wymagań? W "standardowym" opisie wymagań to nie jest uwzględnione i rodzi to ryzyko.
Wykonawcy, którzy nie rozumieją, dlaczego to jest potrzebne, zazwyczaj robią coś, co nie jest potrzebne. Wykonawcy, którzy nie są zaangażowani w proces tworzenia pomysłów, nie są także zaangażowani w wynik. Agile mówi, więc skupmy się przede wszystkim nie na systemie, ale na ludziach, na konsumentach, ich zadaniach i celach.
Tworzymy persony, aby zwiększyć empatię, nadajemy im szczegóły i z perspektywy person zaczynamy przedstawiać historie.
Pracownik biurowy Zachar poszedł na obiad i chce szybko coś zjeść. Czego potrzebuje? Pomysł — pewnie chce lunch biznesowy. Jeszcze pomysł, chce, aby system pamiętał jego preferencje, ponieważ jest na diecie. Jeszcze pomysł — chciałby, aby od razu przynieśli mu kawę, ponieważ ma zwyczaj picia kawy przed obiadem.
Istnieje również biznes (orgsonaż – postać reprezentująca interesy jakiejś organizacji). Biznes chce zwiększyć średnią wartość zamówienia, częstotliwość zakupów oraz zysk. Pomysłem jest, aby oferować niezwykłe dania z jakiejś kuchni. Innym pomysłem jest wprowadzenie śniadań.
Pomysły można i należy konkretizować, przekształcać i przedstawiać w formie opowieści użytkowników. Jako pracownik centrum biznesowego Zakhar, chcę, aby system mnie rozpoznał, aby dostarczał mi menu uwzględniające moje preferencje. Jako kelner chcę, aby system powiadamiał mnie, kiedy podejść do stolika, aby klient był zadowolony z szybkiej obsługi. I tak dalej.
Dziesiątki opowieści. Następnie priorytetyzacja i backlog? Jeff wskazuje na pojawiające się problemy: zaplątanie w drobnych detalach i utrata konceptualnego zrozumienia oraz priorytetyzacja funkcjonalności tworzy rozdartą wizję z powodu niespójności z celami.
Droga autora: Priorytetyzujemy nie funkcjonalność, ale efekt = to, co użytkownik ostatecznie otrzymuje.
Oczywisty, nieoczywisty punkt: sesja priorytetyzacji nie odbywa się z całą drużyną, bo jest to nieefektywne, a z trzema osobami. Pierwsza odpowiada za biznes, druga za doświadczenie użytkownika, a trzecia za realizację.
Wyróżniamy minimum dla rozwiązania jednego zadania użytkownika (minimalne żywotne rozwiązanie).
Szczegółowo opiszmy pomysły pierwszego priorytetu za pomocą opowieści użytkowników, szkiców projektowych, ograniczeń oraz zasad biznesowych na mapie historii użytkowników poprzez opowiadanie i dyskusję z zespołem, co jest potrzebne postaciom i interesariuszom na każdym etapie procesu. Pozostałe pomysły pozostawiamy niezbadanymi w backlogu możliwości.
Proces zapisywany jest w formie kart od lewej do prawej, a pomysły na kartach są umieszczane pod krokami procesu. Ważne jest, aby ścieżkę przejścia całej historii omawiać wspólnie z członkami zespołu, aby osiągnąć wzajemne zrozumienie.
Opracowywanie w ten sposób tworzy integralność zgodności z procesami.
Otrzymane pomysły należy sprawdzić. Nieczłonek zespołu zakłada nakrycie głowy postaci i spędza dzień w myślach postaci, rozwiązując jego zadanie. Może się zdarzyć, że nie widzi on wcześniejszych prac, tworząc karty od nowa, a zespół odkrywa alternatywy.
Następnie następuje szczegółowe opracowanie do oceny. Wystarczą do tego trzy osoby: odpowiedzialny za doświadczenia użytkownika, programista i tester z ulubionym pytaniem: "A gdyby...".
Na każdym etapie dyskusja toczy się wokół mapy procesów historii użytkownika, co pozwala mieć na względzie zadanie użytkownika i tworzyć spójne zrozumienie.
Czy według autora potrzebna jest dokumentacja? Tak, jest potrzebna. Ale jako notatki, które pomagają przypomnieć sobie, o czym się umówiono. Zaangażowanie osoby z zewnątrz znów wymaga dyskusji.
Autor nie zgłębia tematu wystarczalności dokumentacji, koncentrując się głównie na potrzebie dyskusji. (Tak, dokumentacja jest potrzebna, niezależnie od tego, co twierdzą ludzie, którzy nie mają głębszego zrozumienia agile). Przepracowanie tylko części możliwości może również prowadzić do konieczności całkowitego przekształcenia całego systemu. Autor wskazuje na ryzyko nadmiaru pracy w przypadku, gdy nie trafiono w pomysł.
Aby zminimalizować ryzyko, konieczne jest szybkie uzyskanie opinii na temat tworzonego produktu, aby zminimalizować straty związane z tworzeniem "nieodpowiedniego" produktu. Sporządzono zarys pomysłu — zwalidowano go u użytkownika, zarys prototypów interfejsu — zwalidowano u użytkownika itd. (Osobno wskazano, jak walidować prototypy programów). Cele tworzenia oprogramowania, szczególnie na wczesnym etapie, to nauka poprzez szybkie uzyskiwanie informacji zwrotnej, odpowiednio pierwszy stworzony produkt to zarysy, które mogą potwierdzić lub obalić hipotezę. (Autor opiera się na pracy Erica Rieesa "Startup w metodologii Lean").
Mapa historii pomaga w nawiązywaniu komunikacji, jeśli realizacja zapewniana jest przez kilka zespołów. Co powinno być na mapie? To, co potrzebne jest do wspierania rozmowy. Nie tylko user story (kto, co, dlaczego), ale również pomysły, fakty, wstępne wersje interfejsów itp.
Dzieląc kartki na mapie historii na kilka poziomych linii, można podzielić prace na wydania — wyróżnić minimalny zakres, warstwę rozszerzania funkcjonalności i dodatki.
Omówmy historie na mapie procesu.
Pracownik przyszedł na obiad.
Czego on pragnie? Szybkości obsługi. Chce, aby jego obiad czekał na stole lub przynajmniej na tacy. Oops — pominięty krok: pracownik zapragnął coś zjeść. Zalogował się do systemu i wybrał opcję lunchu biznesowego. Zobaczył kaloryczność i zgodność wartości odżywczych, aby przestrzegać diety i nie przytyć. Zobaczył zdjęcia dania, aby podjąć decyzję, czy zje w tym miejscu, czy nie.
Następnie zamierza wziąć lunch i zjeść? A może lunch zostanie mu dostarczony do biura? Wtedy krokiem procesu jest wybór miejsca jedzenia. Chce zobaczyć termin dostawy i ile to będzie kosztować, aby zdecydować, gdzie poświęcić czas i siły — na zejście na dół czy do pracy. Chce zobaczyć obciążenie kawiarni, aby uniknąć stania w kolejkach.
Następnie pracownik wszedł do kawiarni. Chce zobaczyć swoją tacę, aby ją wziąć i od razu przejść do jedzenia. Kawiarnia chce przyjąć pieniądze, aby zarobić na obsłudze. Pracownik chce stracić jak najmniej czasu na płatności w kawiarni, aby nie marnować cennych chwil bez korzyści. Jak to zrobić? Zapłacić z góry, czy może po obsłudze zdalnie. Albo płacić w momencie przy pomocy kiosku. Co z tego jest najważniejsze? Ile osób jest gotowych płacić kartą bankową za obiad? Ile osób zaufa przechowywaniu numeru karty na ponowne płatności w tej stołówce? Bez badania w terenie nie wiadomo, potrzebne są testy.
Na każdym kroku procesu należy w jakiś sposób zapewnić funkcjonalność, do tego trzeba wziąć jako podstawę jakąś personę i wybrać, co jest dla niego ważniejsze (ta konkretna trójka wyborców). Przeszliśmy historię do końca = stworzyliśmy wykonalne rozwiązanie.
Następnie następuje szczegółowe opracowanie. Klient chce zobaczyć obciążenie kawiarni, aby uniknąć stania w kolejkach. Czego konkretnie chce?
Sprawdzać prognozę, ile osób będzie za 15 minut, kiedy tam podejdzie.
Sprawdzać średni czas obsługi w kawiarni i jego dynamikę na pół godziny do przodu.
Obserwować sytuację i dynamikę zajętości stolików.
A co jeśli system prognozowania daje niejasny wynik lub przestanie działać?
Obserwować kolejki w kawiarni przez wideo, a także zajętość stolików. Hmm, a czemu nie zrobić tego w pierwszej kolejności?!
Autor wskazuje na niewielkie ćwiczenie do praktyki: spróbuj wyobrazić sobie, co robisz rano po przebudzeniu. Jedna karta = jedno działanie. Zwiększ karty (zamiast mielić kawę — wypić pobudzający napój), aby usunąć szczegóły, skupiając się nie na sposobie realizacji, a na celu.
Dla kogo jest ta książka — dla analityków IT i kierowników projektów. Obowiązkowa lektura.
Aplikacje
Dyskusje i podejmowanie decyzji są efektywne w grupach od 3 do 5 osób.
Napisz na pierwszej karcie to, co trzeba opracować, na drugiej — popraw to, co zrobiono w pierwszej, a na trzeciej — popraw to, co zrobiono w pierwszej i drugiej.
Przygotowuj historie jak torty — nie pisząc przepisu na wykonanie, a dowiadując się, dla kogo, z jakiego powodu, na ile osób jest tort. Jeśli rozbijać realizację, to nie na wykonanie biszkoptów, kremu itd., a na wykonanie małych gotowych torcików.
Tworzenie oprogramowania przypomina kręcenie filmu, gdzie trzeba starannie opracować i dopracować scenariusz, zorganizować scenę, aktorów itd. przed rozpoczęciem zdjęć.
Zawsze będzie brakować zasobów.
20% wysiłku przynosi zauważalny rezultat, 60% daje coś niejasnego, 20% wysiłku szkodzi — oto dlaczego ważne jest skupienie na nauce i nie załamywanie się w przypadku negatywnego wyniku.
Komunikuj się bezpośrednio z użytkownikiem, poczuj się w jego skórze. Skup się na niektórych problemach.
Szczegółowa analiza i rozwój historii do oceny to najbardziej czasochłonna część scrum, zróbcie dyskusje stojące w trybie akwarium (przy tablicy dyskutuje 3-4 osoby, jeśli ktoś chce uczestniczyć, zastępuje kogoś).
Źródło: habr.com
