Rezumat
Cartea este un algoritm narativ al procesului de dezvoltare de la idee la implementare, utilizând tehnici agile. Procesul este împărțit în pași, iar pentru fiecare pas sunt indicate metodele corespunzătoare. Autorul subliniază că majoritatea metodelor nu sunt originale și nu pretind a fi originale. Totuși, un stil bun de expunere și o oarecare coerență a procesului fac cartea foarte utilă.
Tehnica cheie a hărții poveștilor utilizatorilor este structurarea ideilor și stabilirea cerințelor pe parcursul procesului utilizat de către utilizator.
În acest sens, prezentarea procesului poate fi realizată în moduri diferite. Pașii pot fi organizați în funcție de valorile cheie obținute, sau se poate pur și simplu ilustra o zi de lucru a utilizatorilor, așa cum decurge utilizarea sistemului. Autorul se concentrează pe ideea că procesele trebuie prezentate și discutate sub forma unei povești a utilizatorului pe harta procesului, care este motivul pentru care se numește mapa poveștilor utilizatorilor.
Cui îi este util
Pentru analiști de IT și manageri de proiect. Este obligatorie lectura. Se citește cu ușurință și plăcere, cartea având o dimensiune medie.
Recenzie
În cel mai simplu mod, așa funcționează.
Vizitatorul vine la cafenea, alege mâncărurile, face comanda, primește mâncarea, mănâncă, plătește.
Se pot redacta cerințe, privind ceea ce dorim de la sistem în fiecare etapă.
Sistemul trebuie să afișeze lista de mâncăruri, fiecare mâncare având compoziția, greutatea și prețul și să aibă posibilitatea de a adăuga în coș. De ce suntem siguri de aceste cerințe? În descrierea 'standard' a cerințelor, acest aspect nu este menționat și generează riscuri.
Executanții care nu înțeleg de ce este nevoie de aceste cerințe, de obicei, nu fac ceea ce trebuie. Cei implicați în procesul de creare a ideii sunt, de asemenea, implicați în rezultat. Agile spune că, prin urmare, ar trebui să ne concentrăm în primul rând nu pe sistem, ci pe oameni, pe consumatori, pe sarcinile și obiectivele lor.
Creăm personaje, pentru a dărui detalii în scopul empatiei și, din perspectiva personajelor, începem să expunem povești.
Angajatul de birou Zahari a ieșit la prânz și dorește să mănânce rapid ceva. Ce are nevoie? Ideea - probabil că vrea un prânz de afaceri. O altă idee este că vrea ca sistemul să-i rețină preferințele, deoarece este la dietă. O altă idee. Vrea să primească imediat cafeaua, pentru că este obișnuit să bea cafea înainte de prânz.
Există și afaceri (org-personaj — un personaj care reprezintă interesele unei organizații). Afacerea vrea să crească valoarea medie a comenzii, să crească frecvența achizițiilor, să crească profitul. Ideea este — hai să oferim preparate neobișnuite dintr-o anumită bucătărie. O altă idee este — hai să introducem mic-dejunuri.
Ideile pot și trebuie aduse la specificitate, transformate și prezentate sub formă de user story. Ca angajat al centrului de afaceri Zahăr, vreau ca sistemul să mă recunoască, astfel încât să primesc un meniu personalizat în funcție de preferințele mele. Ca chelner, vreau ca sistemul să mă avertizeze când să mă apropii de masă, astfel încât clientul să fie mulțumit de servire rapidă. Și așa mai departe.
Zeci de povești. Apoi, prioritizarea și backlog-ul? Jeff subliniază problemele apărute: detaliile minore și pierderea înțelegerii conceptului, plus prioritizarea funcționalităților creează o imagine fragmentată din cauza necoordonării față de obiective.
Calea autorului: Prioritizăm nu funcționalitatea, ci rezultatul = ceea ce obține utilizatorul la final.
Un punct evident, dar neobișnuit: sesiunea de prioritizare nu se desfășoară cu întreaga echipă, deoarece este ineficient, ci cu trei persoane. Prima se ocupă de afaceri, a doua de experiența utilizatorului, iar a treia de implementare.
Să definim minimul pentru rezolvarea unei sarcini a utilizatorului (soluția minim viabilă).
Detaliem ideile priorității întâi prin intermediul user story-urilor, schițelor de design, constrângerilor și regulilor de afaceri pe harta poveștilor utilizatorilor, prin povestiri și discuții cu echipa despre ce este necesar pentru personaje și părțile interesate la fiecare pas al procesului. Celelalte idei rămân nerezolvate, în backlog-ul oportunităților.
Procesul este scris sub formă de carduri de la stânga la dreapta, iar ideile de pe carduri sub pașii procesului. Este esențial să discutăm întregul parcurs al poveștii împreună cu membrii echipei pentru a crea o înțelegere comună.
Lucrul în acest mod creează o coerență în raport cu procesele.
Ideile obținute trebuie verificate. Un membru al echipei îmbracă haina personajului și trăiește o zi din perspectiva acestuia, rezolvându-i sarcina. Există posibilitatea ca el să nu observe lucrările anterioare, creând carduri de la zero, în timp ce echipa descoperă alternativele.
Apoi se desfășoară detalierea pentru evaluare. Pentru aceasta, sunt suficienți trei oameni. Responsabilul pentru experiența utilizatorului, dezvoltatorul, testatorul cu întrebarea preferată: „Dar ce ar fi dacă…”.
În fiecare etapă, discuția se desfășoară pe baza hartii proceselor poveștii utilizatorului, ceea ce permite menținerea în minte a sarcinii utilizatorului și crearea unei înțelegeri complete.
Este necesară documentația, în opinia autorului? Da, este necesară. Dar ca notițe, care să ajute la reamintirea a ceea ce s-a convenit. Implicarea unei persoane externe necesită din nou discuții.
Autorul nu se aprofundă în tema suficienței documentației, punând accentul pe necesitatea discuțiilor. (Da, documentația este necesară, oricât de mult ar susține unii că nu este, din neștiință în privința agile). De asemenea, lucrul doar pe o parte a funcționalităților poate conduce la necesitatea refacerii complete a întregului sistem. Autorul subliniază riscul unei supraexploatări în cazul în care nu s-a nimerit ideea.
Pentru a diminua riscurile, este necesar să obții rapid feedback pe produsul creat pentru a minimiza daunele generate de crearea unui produs „inadecvat”. Am realizat o schiță a unei idei — am validat-o cu utilizatorul, schița prototipurilor de interfață — am validat-o cu utilizatorul etc. (Separat este menționat cum se validează prototipurile software-ului). Obiectivele creării software-ului, în special în stadiul inițial, sunt învățarea prin obținerea rapidă a feedback-ului, astfel încât primul produs creat este o schiță capabilă să demonstreze sau să infirme o ipoteză. (Autorul se bazează pe lucrarea lui Eric Ries „Startup-ul conform metodologiei Lean”).
Harta poveștilor ajută la stabilirea comunicării, dacă implementarea este asigurată de mai multe echipe. Ce ar trebui să conțină harta? Ceea ce este necesar pentru a susține conversația. Nu doar user story (cine, ce, de ce), ci și idei, fapte, schițe de interfețe etc.
Împărțind cardurile de pe harta poveștii în mai multe linii orizontale, poți separa lucrările în lansări — evidențiind minimul necesar, stratul de adăugare a funcționalității și fundițele.
Discutăm povestirile de pe harta procesului.
Angajatul a venit la prânz.
Ce vrea el? Viteza serviciilor. Ca prânzul să-l aștepte deja pe masă sau măcar pe un suport. Opa - pas omis: angajatul a dorit să mănânce. S-a conectat în sistem și a ales opțiunea de prânz de afaceri. A văzut caloriile și conformitatea cu valoarea nutritivă, pentru a respecta dieta și a nu se îngrășa. A văzut imagini cu preparatul, pentru a decide dacă va mânca în acel loc sau nu.
Apoi, va merge să își ia prânzul și să mănânce? Sau poate că îi va fi livrat prânzul la birou? Atunci pasul procesului - alegerea locului de masă. Vrea să vadă când va fi livrat și cât va costa, pentru a decide unde să-și investească timpul și energia - să coboare sau să rămână la muncă. Vrea să vadă aglomerarea cafenelei, pentru a nu se împinge în cozi.
Apoi, angajatul a ajuns la cafenea. Vrea să își vadă suportul pentru a-l lua și a merge imediat să mănânce. Cafeneaua vrea să încaseze bani pentru a câștiga din servicii. Angajatul vrea să piardă cât mai puțin timp la plată cu cafeneaua, pentru a nu cheltui timp prețios fără folos. Cum poate face asta? Să plătească în avans sau, dimpotrivă, după serviciu, de la distanță. Sau să plătească în momentul respectiv folosind un chioșc. Ce este cel mai important dintre acestea? Câți oameni sunt dispuși să plătească prânzul cu cardul? Câți oameni ar avea încredere să lase numărul cardului pentru plăți ulterioare la această cantină? Fără cercetare de teren, nu este clar, este nevoie de testare.
La fiecare pas al procesului trebuie asigurat cumva funcționalitatea, pentru aceasta trebuie să luăm ca bază o anumită persoană și să alegem ce este mai important pentru el (acea triplă de factori decizionali). Am parcurs povestea până la capăt = am realizat o soluție viabilă.
Apoi urmează detalierea. Clientul vrea să vadă aglomerarea cafenelei, pentru a nu se împinge în cozi. Ce anume vrea el?
Să vadă prognoza câți oameni vor fi în 15 minute, când va ajunge acolo.
Să observe timpul mediu de servire în cafenea și dinamica acestuia pe următoarea jumătate de oră.
Să urmărească situația și dinamica ocupării meselor.
Dar ce se întâmplă dacă sistemul de prognozare oferă un rezultat neclar sau încetează să funcționeze?
Să urmărească prin video cozile din cafenea, precum și ocuparea meselor. Hm, dar de ce să nu facem asta mai întâi?!
Autorul sugerează un mic exercițiu pentru a exersa practica: încercați să vă imaginați ce faceți dimineața după trezire. O cartela = o acțiune. Agrandați cartelile (în loc de a măcina cafeaua - beți o băutură revigorantă) pentru a elimina detaliile individuale, concentrându-vă nu pe modalitatea de realizare, ci pe scop.
Pentru cine este această carte - pentru analiști IT și manageri de proiect. Este un must-read.
Aplicații
Discuțiile și luarea deciziilor sunt eficiente în grupuri de 3 până la 5 persoane.
Scrieți pe prima cartela ceea ce trebuie dezvoltat, pe a doua - ce trebuie corectat din prima, pe a treia - ce trebuie corectat din prima și a doua.
Pregătiți povești ca dacă ar fi torturi - fără a redacta rețeta de fabricație, ci aflând cui, cu ce ocazie, pentru câte persoane este tortul. Dacă spargeți realizarea, atunci nu pe fabricarea blaturilor, cremei etc., ci pe realizarea unor torturi mici gata făcute.
Dezvoltarea software-ului este asemănătoare cu crearea unui film, când trebuie să dezvolți și să rafinezi cu atenție scenariul, să organizezi scena, actorii etc. înainte de începerea filmărilor.
Resursele vor fi întotdeauna insuficiente.
20% din eforturi oferă un rezultat semnificativ, 60% oferă ceva neclar, 20% din eforturi sunt dăunătoare - de aceea este important să te concentrezi pe învățare și să nu te descurajezi în cazul unui rezultat negativ.
Comunicați direct cu utilizatorul, simțiți-vă în pielea lui. Concentrați-vă pe anumite probleme.
Detalierea și elaborarea poveștii pentru evaluare este cea mai anevoioasă parte a scrum-ului, faceți discuțiile în picioare în modul acvariu (la tablă discută 3-4 persoane, dacă cineva vrea să participe, el îl înlocuiește pe cineva).
Sursa: habr.com
