Руководство по сбору требований в формате User Story Mapping: Дисциплина метода, 2/3

Инструменты проектирования

Во второй статье серии мы сосредоточимся на порядке создания карты. В предыдущей подробно рассмотрен центральный элемент карты User Story Mapping — пользовательская история.

Понадобится пример. Давайте представим, что собираемся улучшить работу аэропорта, а именно, повысить качество такого сервиса как туалет. Я намеренно опущу вводные по целям. Выбранный пример хорош тем, что прост, вне области информационных технологий и будет понятен большинству.

Пространственная структура карты

Карта User Story Map состоит из четырёх слоёв: действующих лиц, активностей, историй и детализированных задач.

• Действующее лицо — карточка с его обозначением вешается над началом линейки историй с ним. Для историй с несколькими действующими лицами вешают столько лиц, сколько участвует в ней.
• Активности — наименования действий, группирующие истории. Помогают ориентироваться на карте, очерчивают крупными мазками, что планируется спроектировать и разработать.
• Пользовательские истории — ряд из карточек с историями в порядке логики повествования о создаваемой системе.
• Детализированные задачи, крепящиеся к историям сверху вниз — каждая из карточек соответствует какой-то конкретной особенности реализации истории. Положение по вертикали имеет значения только относительно линий релизов.
• Линии релизов — разделительные линии, отделяющие границы релизов. Между ними располагают детализированные задачи, чтобы спланировать релизы.

Этап 1. Запись историй

Порядок действий

• Выбрать подготовленного ведущего — от качества модерации зависит качество итоговой карты.
• Инструктировать всех присутствующих о сути методе и его принципах. Вот минимум: пояснить для чего и как строится карта, как записывать истории, почему важно формулировать ценность. Без этой части вы рискуете потерять время зря.
• Выбрать действующее лицо — персону или функциональную роль — для которой записываются истории. Записать его на новую карточку и поместить на карте:

• Записать истории в порядке, в котором вы считаете логичным повествовать о создаваемой системе. Разместить карточки с историями (зелёные на картинке ниже) под карточкой действующего лица слева направо по ходу разворачивания повествования. Оставить место для этажа с активностями (красные карточки) между этажами с действующими лицами и историями. Нестрашно, если две истории в разных ситуациях случаются в жизни в разном порядке. Метод не поддерживает ветвления линии повествования. Если ветвление важно, ввести его за счёт отдельной группы истории (активности) или новой функциональной роли.

• Сгруппировать истории, вешая над ними карточки активностей (красные в примере ниже). Легче это делать после того как несколько историй уже записано. Наблюдал неоднократно как участникам трудно выдумать названия активностей заранее, хотя формулировки историй идут легко. Поэтому я обычно пропускаю слой активностей, вешая на него пустую карточку. Затем вписываю название активности как только для этого достаточно информации.

Слои активностей и историй вместе называют хребтом USM. Создание хребта карты — добротная часть работы, её можно выделить в отдельную сессию

• Разместить над историями с несколькими действующими лицами их карточки, чтобы обозначить для кого они справедливы:

Для примера взят фрагмент карты системы для проведения спортивных соревнований

• Прикрепить под каждой историей карточки с задачами (жёлтые на картинке ниже), детализирующими то, как именно будет реализована история. Здесь может появиться по несколько вариантов реализации одной истории. Это не будет означать, что все их требуется реализовать в одном релизе. Эти варианты реализации будут распределены по релизам на этапе планирования, о нём будет ниже.

Оранжевым выделена история и относящиеся к ней задачи

• Повторить процедуру для всех действующих лиц.
• Проверить карту с участием всех важных заинтересованных лиц. Для этого зачитывать громко истории и просить высказаться присутствующих, если в формулировках есть неточности. Очистить истории от ложных ценностей, выявить истинные, выкинуть или переписать истории, если необходимо. В число заинтересованных лиц входят и выборочные представители действующих лиц на карте.

Принципы и рекомендации

• Всё, что не записано в карту — отсутствует. Не стоит полагаться на память участников проекта, о незаписанном непременно забудут. Считайте карту артефактом совместного видения продукта. Задача ведущего следить за соблюдением этого принципа.
• Создание карты историй — групповой процесс. Если вы будете вносить изменения без участия команды, без проверки всех заинтересованных лиц, об изменениях никто не узнает, и вы будете лишены важной предварительной обратной связи о том, на что не обратили внимание, а значит с большей вероятностью ошибётесь на этапе проектирования или теста в реальности.
• Истории и раскрытие полезного действия важнее формата записи.
• Ценность/польза важнее конкретных средств, за счёт которых она достигается.
• Важно избегать терминов и частных решений в историях, в особенности, наименований интерфейсных концепций. Кнопки, панели, поиск — претенденты на выброс. Плохо: «нажимает кнопку», «получает СМС», лучше: «подаёт команду», «получает уведомление». Излишняя детализация и термины попадают в историях вследствие того, что нам проще мыслить готовыми решениями, хотя методологически это неверно. Ведущий встречи обязан обращать внимание на такую особенность мышление и просить исправить формулировки при всех участниках.
• Реальный мир — единственный критерий истинности. Разрабатывая продукт, мы находимся в квадранте ‘Complex’ фреймворка Cynefin, где нет ни лучших, ни хороших готовых практик. Здесь не может быть экспертов, знающих «как нужно делать». Мы выдвигаем гипотезу и ставим эксперимент в условиях реального мира, и по результату этого эксперимента получаем новое знание. Чаще всего отрицательное — что что-то не работает. В результате понимаем, что требуется сменить подход. Важно это помнить, когда вы записываете истории. Истории — это не фантазии о том, как на ваш взгляд должна работать система, а результат совместного с заинтересованными лицами исследования реальности. То есть, каждая историй — это гипотеза, которую ещё предстоит проверить жизнью. Чем меньше предположений вы сделаете априори, тем меньше шанс ошибиться.

Типичные ошибки

• Записывать истории не по горизонтали, а по вертикали — в детальные задачи. Истории должны идти на своём слое друг за другом в хронологическом порядке. Записывать истории как подыстории нет смысла, потому что теряется одно из измерений — главная находка метода. В этом случае некуда будет крепить детализирующие задачи для историй размещённых по вертикали, а не по горизонтали, как того требует метод. Если вам нужна группировка историй, используйте слой активностей.
• Не пригласить команду разработки на сессию USM. В этом случае вас ждут проблемы с передачей созданных артефактов. Команда «не возьмёт» требования, или вы потратите много времени на её погружение в суть происходящего.
• Записывать в историю только действия без ценности. Проявление фичеризма или кнопочного мышления. Как я уже писал, ведёт к серьёзным ошибкам, связанным с излишним постулированием.
• Остановиться на первом «чтобы», не достигнув глубины понимания настоящей ценности.
• Записывать истории в терминах детальных решений, а не сценариев и задач пользователя. Для сервиса, в котором делятся фотографиями, чересчур детальной историей была бы такая: «Кликает на „Загрузить“, вводит описание фотографии, чтобы поделиться». Таким деталям не место на слое историй, вместо неё лучше уйти от деталей реализации к сути. Как вариант, я бы ограничился двумя историями про отображение и изменение статуса: «Какие фотографии публичны?», «Эти опубликованы! Вот ссылка». Конкретные решения записываются в детализирующие задачи под историями.
• Использовать ложные или притянутые ценности. Записывать в качестве ценности ценность бизнеса или лиц, создающих систему, а не действующего лица.

Этап 2. Планирование релизов

Порядок действий

1. Определить важные ближайшие вехи продукта и добавить для них линии релизов на карте.
2. Разместить все детализированные задачи по релизам согласно приоритетам. Детализированные задачи, помещенные сразу под линией первого релиза, относятся к первому релизу. Задачи, размещённые под линией второго — ко второму, и так далее.
3. На каждом этаже релиза должны остаться карточки с задачами минимально необходимыми для реализации истории в завершенном виде в этом релизе. Эту полноту важно проверять.
4. Добавить к карточкам с задачами критерии готовности или указать всё, что необходимо, в самих карточках.
5. Проверить карту с заинтересованными лицами на адекватность их ожиданиям. Обеспечит ли выбранный способ реализации минимальную работоспособность истории? Не отодвинуты ли важные этапы на дальние релизы?

Принципы и рекомендации

• USM — это карта to be,то есть как мы собираемся делать систему. Я встречал попытки использовать метод для описания текущей функциональности существующего продукта для его переноса. Это приемлемо, но, на мой взгляд, излишне трудоёмко и окупится лишь в случае, когда вам важно скрупулёзно скопировать систему и ничего не забыть при переносе.
• Нет смысла планировать дальше первого и второго релиза. Потому что то, что вы узнаете во время работы над первым релизом настолько изменит ваше представление о создаваемом сервисе, что сделанная заранее работа по планированию наперёд потеряет актуальность. Чаще всего первой линией является линия минимального ценного продукта, а остальное откладывают за его черту. Я чаще всего планирую ближайший релиз, а все идеи не заслуживающие реализации здесь и сейчас, отправляю за общую ватерлинию будущих релизов.

Доморощенная попытка отслеживать прогресс по историям с помощью отметок разных цветов. Красными галками помечены выполненные истории первого релиза, голубыми — второго. Голубым контуром обведён скоуп второго релиза.

Этап 3. Ведение проекта по карте

Несомненно трекинг проекта по карте — занятие для дисциплинированных команд. На моей практике редкие проекты доживали до второго-третьего релиза с первозданной картой. Обычно поддерживать карту ленятся. Истории на грядущий релиз либо собирают в кучку из бэклога, либо строят новую мини карту. Если вы решились вести проект как положено, вот некоторые руководства.

Порядок действий

1. Прийти в исходную ситуацию: есть карта историй, задачи в которой разнесены по релизам, то есть состав работ предстоящего релиза заключён между линейками с названием/номером предстоящего релиза и следующим за ним.
2. Отметить на карте истории, запланированные на следующую итерацию. Здесь нет общих практик, помечайте как вам удобно. Мы обводим карточки маркером, либо помечаем их в интерактивном инструменте тэгами или флажками.
3. Подробить и детализировать командой задачи под историями, выбранными к разработке на этой итерации.
4. Занести детализированные задачи в трекер, если вы пользуетесь им, и вести в нём.
5. Перед планированием новой итерации обозначить на карте выполненные истории и задачи, чтобы отличать их от оставшихся.
6. Повторять процедуру с шага 2 до завершения релиза.

Принципы и рекомендации

• Удалять или править устаревшее важнее, чем добавлять новое. Как только вы начинаете использовать карту как командный бэклог, вам не избежать ухаживания за ней. Карта историй начинает устаревать сразу же как вы закончили её составлять. Один из самых частых претензий к методу — карта устарела, новую делать трудно. Выход только один — холить карту понемногу, но регулярно.

Рекомендации для ведущего

Как вы могли заметить, метод требует дисциплины и умственного напряжения. Без хорошего ведущего сессия сбора требований рискует затянуться, либо выжать из участников все соки. Ниже несколько рекомендаций для ведущих сессий в формате ответов на вопросы моих коллеги.

С чего начинать

У нас карта историй, и любая большая история с чего-то да начинается. Вопрос «С чего всё начинается?» — отличная отправная точка.

Какие вопросы задавать

Теоретически вы можете обойтись формальным набором вопросов, типа «А что происходит дальше?», который рекурсивно будет вести вас вдоль хребта карты. Однако вряд ли вы так достигнете глубины, и уж точно поверхностными вопросами не добиться расположения и должного участия других участников сессии.

Работа над картой USM — это продолжение беседы, начавшейся в момент выяснения целей проекта и знакомства с процессами как они есть, если уже существует некоторая система. В ходе этих первых встреч вы формируете базис для понимания, откуда сможете черпать вопросы. Если таких встреч не было, придётся сымпровизировать и провести их подобие в начале сессии USM. Задача-минимум здесь — понять очертания бизнес-ландшафта: цели бизнеса, гипотезы их достижения.

Когда вам будут рассказывать истории, ваша основная работа разложить задачи и мотивацию действующих лиц. Для этого важно вытащить и записать истинную ценность рассказываемых историй. Участники, не со зла, будут изображать не проблему, а варианты решения — так уж мы, люди, устроены. Чтобы разобраться в том, что под всем этим лежит, придётся заглубляться. Скорее всего, вашими рабочими лошадками будут «Пять почему», «Зачем?», «Чтобы что?». Ну и конечно, терпение и юмор.

Что делать если «идёт с трудом»

Начинающих ведущих беспокоят паузы с неловким молчанием, либо наоборот чересчур активные стейкхолдеры, за которыми трудно поспеть. К тому же в области ближайшего развития люди всегда испытывают синдром самозванца, и неоправданно много волнуются.

Я рекомендую ведущему снять с себя ложное убеждение о важность «держать лицо», и делать видимой каждую проблему, которую вы встречаете. Задумались — скажите над чем вы задумались или, лучше, пригласите к этому всю команду. Так не возникнет ожидающей паузы, и вы не потеряете динамику. Не знаете куда двигаться дальше — так и скажите: «Коллеги, похоже мы в тупике и вот почему…».

Другая проблема — перегруз по информации. Участники вываливают на вас бесконечный поток сценариев, вы не успеваете. Что ж, опять тот же принцип. Сделайте проблему видимой и предложите варианты решения. «Коллеги, извините, здесь я вас прерву. Вы рассказываете важные сведения, мы не можем себе позволить пропустить их. Но, кажется, мы их упускаем, потому что прямо сейчас никто не записывает их в карту в нужном формате. А я напомню, всё, что не записано — потеряно. Предлагаю сбавить темп и вернуться к записи. Хорошо? <Получаем согласие или работаем с возражением>. Отлично! Давайте начнём с истории про <…>, как бы вы её записали?»

Как понять успешно ли я веду?

Если вы всё верно организовали, то дело обстоит так. Льётся интересная беседа, на доске появляется карточки историй, вокруг них возникает дискуссия, карточки переписываются, все участники вовлечены. К концу сессии пройден некоторый участок карты в требуемом вам формате. К концу нескольких сессий получена карта, обладающая известной на текущий момент полнотой.

Как определить готова ли карта

Как понять, что полнота достигнута и можно остановиться? Это трудный вопрос. Пуленепробиваемых рекомендации здесь нет, есть несколько уловок.

Полноты трудно достичь, наблюдая за тем, что уже найдено. Когда вы спросите участников, «всё ли здесь учтено» и получите ответ «да», важно понимать, что это значит «мы посмотрели на эти истории и не вспомнили ничего нового». Ключами для поиска отсутствующих историй могут быть память участников и системная логика, проверяющая целостность и работоспособность описываемой системы. Некоторые истории удаётся обнаружить только когда кто-то начал работать над реализацией и посмотрел на историю с другого угла, либо когда недостающие истории были встречены позже в жизни. От этого никак не уберечься. Важно быть готовыми принимать изменения и новые требования в любой момент работы над продуктом.

И всё же, как понять, что сейчас можно остановиться. Как ведущий, я обращаюсь к участникам и спрашиваю «что мы ещё не учли»? В поиске пропущенных историй помогает общий пересмотр карты, когда громко озвучиваются активности и истории из хребта USM. В это время и по ходу записи я сам слежу за системной сборкой — чтобы всё было непротиворечиво, а записанные ценности обеспечивали работоспособность историй. Когда все участники выражают ощущение достижения полноты, сессия завершается.

Типичные ошибки организации сессии USM

• Не инструктировать всех в начале по правилам метода.
• Вести сессию без перерывов и дольше полутора часов. По опыту, за полтора часа напряженного мыследействия все устают, поэтому лучше не устраивать марафоны, а разбить сессии на несколько дней. Саму сессию лучше тоже разбить хотя бы одним перерывом и проветрить помещение перед началом сессии и в перерыве.
• Бояться ошибиться или сделать что-то не то. Помните, что все пришедшие не знают чем она завершится. В конце концов, вы создаёте продукты, это область высокой неопределённости. Ваша задача — помочь участникам как можно больше ошибаться, потому что тогда все получат почву для дискуссии и идей.
• Подолгу не фиксировать рассказываемые истории в формате метода. Обмен мнениями без фиксации формулировок, устраивающих всех, впустую тратит время всех присутствующих.
• Пригласить лишних для обсуждаемого участка карты стейкхолдеров. Нет ничего хуже зря потерянного времени. Эти люди позже нехотя придут на встречи про их куски процесса.
• Записать всё, что было сказано участниками и уйти писать истории. В идеале рассказы и попытка записи историй сменяют друг друга на одной встрече. Опрашивать и записывать истории раздельно — дорого. Придётся вернуться ко всем интервьюированным и вместе с ними вновь провалидировать запись.

Другие статьи серии

• Часть 1. Суть метода. Пользовательская история её форматы
• Часть 3. Чистка требований и критика метода
• Переход от историй к реализации

Буду рад вашим замечаниям, критике и любым другим вариантам разговора на тему картирования историй и сбора требований. Комментируйте или пишите — andrew@ashapiro.ru