Напомена
Књига је нарирани алгоритам за спровођење процеса развоја од идеје до имплементације користећи агилне технике. Процес је приказан у корацима и на сваком кораку су назначене методе за корак процеса. Аутор истиче да већина метода није оригинална, не претендујући на оригиналност. Али добар стил писања и одређени интегритет процеса чине књигу веома корисном.
Кључна техника мапирања корисничких прича је структурирање идеја и перформанси док се корисник креће кроз процес.
Истовремено, процес се може описати на различите начине. Можете да градите кораке док постигнете кључну вредност, или можете једноставно да узмете и замислите радни дан корисника како пролази кроз систем. Аутор се фокусира на чињеницу да процесе треба оцртати, изговорити у облику корисничке приче на мапи процеса, што нам је дало назив мапа прича корисника.
Коме треба
За ИТ аналитичаре и менаџере пројеката. Обавезно прочитати. Лака и пријатна за читање, књига је средње величине.
Феедбацк
У свом најједноставнијем облику, овако функционише.
Посетилац долази у кафић, бира јела, наручује, прима храну, једе и плаћа.
Можемо написати захтеве за оно што желимо од система у свакој фази.
Систем треба да прикаже листу јела, свако јело има састав, тежину и цену и може да се дода у корпу. Зашто смо сигурни у ове захтеве? Ово није описано у „стандардном“ опису захтева и то ствара ризике.
Извођачи који не разумеју зашто је то неопходно обично раде погрешно. Извођачи који нису укључени у процес стварања идеје нису укључени у резултат. Агиле каже, хајде да се фокусирамо пре свега не на систем, већ на људе, на потрошаче, њихове задатке и циљеве.
Креирамо личности, дајемо им детаље за емпатију и почињемо да причамо приче са стране личности.
Запослени у канцеларији Закхар отишао је на ручак и жели на брзину да нешто угризе. Шта му треба? Идеја је да вероватно жели пословни ручак. Друга идеја је да жели да систем запамти његове преференције, јер је на дијети. Друга идеја. Жели да му одмах донесу кафу јер је навикао да пије кафу пре ручка.
А ту је и бизнис (организациони карактер је карактер који заступа интересе организације). Предузећа желе да повећају просечан чек, повећају учесталост куповине и повећају профит. Идеја је - понудимо необична јела неке кухиње. Још једна идеја - хајде да уведемо доручак.
Идеје се могу и треба конкретизовати, трансформисати и представити у облику корисничке приче. Као запослени у пословном центру Закхар, желим да ме систем препозна како бих могао да добијем јеловник на основу мојих жеља. Као конобар, желим да ме систем обавести када да приђем столу како би клијент био задовољан брзом услугом. И тако даље.
Десетине прича. Следе приоритети и заостаци? Џеф указује на проблеме који се јављају: заглављивање у малим детаљима и губљење концептуалног разумевања, плус давање приоритета функционалности ствара изоштрену слику због недоследности са циљевима.
Пут аутора: Не дајемо приоритет функционалности, већ резултату = ономе што корисник на крају добије.
Очигледна неочигледна ствар: сесију одређивања приоритета не спроводи цео тим, јер је неефикасна, већ троје људи. Први је одговоран за пословање, други за корисничко искуство и трећи за имплементацију.
Одаберимо минимум за решавање једног корисничког проблема (минимално одрживо решење).
Идеје првог приоритета описујемо користећи корисничке приче, скице дизајна, ограничења и пословна правила на мапи корисничких прича говорећи и разговарајући са тимом шта је људима и заинтересованим странама потребно у сваком кораку процеса. Преостале идеје остављамо неиспитаним у заостатку могућности.
Процес је написан на картицама с лева на десно, са идејама на картицама испод корака процеса. Императив је да се о путу кроз целу причу разговара заједно са члановима тима како би се обезбедило међусобно разумевање.
Разрада на овај начин ствара интегритет у складу са процесима.
Примљене идеје треба тестирати. Нечлан тима ставља шешир особи и живи дан те особе у њеној глави, решавајући њен проблем. Могуће је да он не види развој, поново ствара карте, а тим открива алтернативе за себе.
Затим постоје детаљи за евалуацију. За ово су довољна три човека. Одговоран за корисничко искуство, програмер, тестер са омиљеним питањем: „Шта ако...”.
У свакој фази, дискусија прати мапу процеса историје корисника, која омогућава да корисников задатак има на уму како би се створило кохерентно разумевање.
Да ли је документација неопходна по мишљењу аутора? Да, треба ми. Али као белешке које вам омогућавају да запамтите шта сте се договорили. Поново укључивање аутсајдера захтева дискусију.
Аутор се не упушта у тему довољности документације, фокусирајући се на потребу дискусије. (Да, документација је потребна, ма како то тврдили људи који немају дубоко разумевање агилности). Такође, разрада само дела могућности може довести до потребе за комплетном прерадом целог система. Аутор указује на ризик од претеране разраде у случају када је идеја погрешна.
Да би се елиминисали ризици, потребно је брзо добити повратну информацију о производу који се креира како би се минимизирала штета од стварања „погрешног“ производа. Направили смо скицу идеје - потврдили је са корисником, скицирали прототипове интерфејса - потврдили је са корисником итд. (Одвојено, постоји мало информација о томе како се валидирају прототипови програма). Циљеви креирања софтвера, посебно у почетној фази, су учење кроз добијање брзе повратне информације, сходно томе, први креирани производ су скице које могу доказати или оповргнути хипотезу. (Аутор се ослања на рад Ерица Риеса „Стартуп користећи Леан методологију“).
Мапа приче помаже у побољшању комуникације када се имплементација спроводи у више тимова. Шта би требало да буде на мапи? Шта вам је потребно да бисте наставили разговор. Не само корисничка прича (ко, шта, зашто), већ идеје, чињенице, скице интерфејса, итд...
Поделом карата на мапи историје у неколико хоризонталних линија, можете поделити рад на издања - истакните голи минимум, слој све веће функционалности и лукове.
Причамо приче на мапи процеса.
Дошао је службеник на ручак.
Шта хоће? Сервисне брзине. Тако да га ручак већ чека на столу или бар на послужавнику. Упс - промашен корак: запослени је хтео да једе. Пријавио се и изабрао опцију пословног ручка. Видео је садржај калорија и нутритивних садржаја који му помажу да дијета и не добија на тежини. Видео је слике јела да би одлучио да ли ће јести на том месту или не.
Следеће, хоће ли отићи по ручак и вечеру? Или ће можда ручак бити достављен у његову канцеларију? Затим корак процеса је одабир места за јело. Жели да види када ће му бити испоручено и колико ће коштати, како би могао да бира где ће трошити време и енергију – сићи доле или на посао. Жели да види колико је кафић заузет да се не би гурао у редовима.
Тада је службеник дошао у кафић. Жели да види свој послужавник да га узме и оде право на вечеру. Кафић жели да прихвати новац да заради на услузи. Запослени жели да изгуби минимум времена на обрачунима са кафићем, како не би бескорисно губио драгоцено време. Како се то ради? Плаћајте унапред или обрнуто након услуге на даљину. Или платите на лицу места користећи киоск. Шта је у овоме најважније? Колико људи је спремно да плати ручак банковном картицом? Колико би људи веровало овој кантини да чува број њихове картице за поновљена плаћања? Без теренског истраживања нејасно је, потребно је тестирање.
У сваком кораку процеса треба некако да обезбедите функционалност за то треба да узмете неку особу као основу и изаберете шта је њему важније (иста три селектора). Пратио причу до краја = направио одрживо решење.
Следеће долази до детаља. Клијент жели да види колико је кафић заузет, како се не би гурао у редовима. Шта он тачно жели?
Погледајте прогнозу колико ће људи бити за 15 минута када стигне
Погледајте просечно време услуге у кафићу и његову динамику пола сата унапред
Погледајте ситуацију и динамику попуњености столова
Шта ако систем предвиђања даје нејасан резултат или престане да ради?
У видеу погледајте редове у кафићу, као и попуњеност столова. Хмм, зашто то не урадите прво?!
Аутор истиче малу вежбу за вежбање: покушајте да замислите шта радите ујутру након буђења. Једна карта = једна акција. Повећајте карте (уместо млевења кафе, попијте окрепљујуће пиће) да бисте уклонили појединачне детаље, фокусирајући се не на начин имплементације, већ на циљ.
Коме је ова књига намењена: ИТ аналитичарима и пројект менаџерима. Обавезно прочитати.
Аппс
Дискусија и доношење одлука су ефикасни у групама од 3 до 5 људи.
На првој картици напиши шта треба да се развије, на другој - исправи оно што си урадио у првој, на трећој - исправи шта је урађено у првој и другој.
Припремајте приче као колаче - не тако што ћете написати рецепт, већ тако што ћете сазнати коме, за коју прилику и за колико људи је торта. Ако рашчланимо продају, онда то не би било у производњи колача, крема и сл., већ у производњи малих готових колача.
Развој софтвера је сличан прављењу филма, када треба пажљиво развити и исполирати сценарио, организовати сцену, глумце итд. пре почетка снимања.
Увек ће недостајати ресурса.
20% напора даје опипљиве резултате, 60% даје несхватљиве резултате, 20% напора је штетно - зато је важно фокусирати се на учење и не очајавати у случају негативног резултата.
Комуницирајте директно са корисником, осетите се у његовој кожи. Фокусирајте се на неке проблеме.
Детаљно и развијање приче за евалуацију је најмучнији део сцрум-а, нека се дискусије одвијају у акваријумском режиму (3-4 особе дискутују за таблом, ако неко жели да учествује, он некога замењује).
Извор: ввв.хабр.цом