Формирование MVP продукта. StoryMapping

Наверняка вы хоть раз заказывали себе или кому-нибудь из близких на День рождения торт. Но всегда ли он получался именно таким, как вы хотели? Бывает, что ожидания не совпадают с результатом.

Реальный случай: мама заказывает торт для дочери Алисы. Просит надпись фиолетовым цветом: «Всего хорошего, Алиса», а вокруг надписи – звезды. Кондитер говорит: «Без проблем, завтра забирайте». Вроде ничего сложного.

 

 

Но в итоге на торте появляются не звезды, а надписи «звезды». И торт, хоть и красивый, но совсем не тот. Вроде мелочь, но для ребенка – разочарование.

Если вы считаете, что это – выдумка и преувеличение, есть целый сайт с фотографиями таких тортов. Всякие разные случаи. Например, там есть фото торта, при заказе которого в заметках написали «аллергия на орехи» – в результате прямо на торте появилась надпись: «аллергия на орехи».

Думаю, и у вас при постановке задач иногда тоже случаются подобные недопонимания.

 

 

В итоге – что мы имеем? Если рассматривать торт как продукт или проект, у менеджера – продакта или РП – возникает масса вопросов: «Что же пошло не так? Почему результат не соответствует ожиданиям? Возможно, мы неправильно сняли требования? Или использовали не тот подход при их формулировке?»

 

Заказчик, конечно, будет крайне недоволен: «Я же столько раз все объяснил – что, зачем и куда!», и выплеснет на нас все свои негативные эмоции.

 

 

А разработчик (в данном случае – кондитер), скорее всего, даже не поймет, что в чем-то не прав. Ему дали ТЗ, он его закодил – у него все отлично. Он счастлив. Ему осталось только поставить финальный штрих – как этому турецкому повару, посыпающему мясо солью.

 

 

Формально все сделано по ТЗ. Но по факту – продукт получился совсем не тот, который был нужен. Его можно вылить в канализацию – в таком виде он никому не нужен.

 

 

Ладно торт – максимум несколько тысяч рублей. Бывают случаи куда серьезнее.

Например, в истории освоения космоса был проект, где ошибка стоила 125 миллионов долларов. Это был 1999 год, NASA запускала космическую станцию на Марс. И потеряла эту космическую станцию.

Как думаете, из-за чего? Дело в том, что раньше в команде NASA для единиц измерения использовалась англо-американская система счисления (мили), а потом ее решили поменять на международную метрическую систему. Но разработчику об этом ничего не сказали – он как кодил в милях, так и накодил. В результате потеряли целую станцию – 125 миллионов долларов буквально «сгорели». А с учетом инфляции – она, наверное, сейчас уже миллиарды долларов стоить будет.

 

 

А что насчет ИТ? Наверняка вы видели мем о том, как заказчик просит проектную команду сделать качели на дереве, и как эту задачу понял РП, описал аналитик, и реализовал программист. У каждого на выходе получился совершенно разный результат.

 

 

Почему вообще так происходит? Одна из причин – «испорченный телефон». Помните такую детскую игру? Один человек шепчет фразу другому, тот – следующему и так по цепочке. А потом сравниваются варианты первого и последнего участника – и чаще всего, то, что слышит последний, не имеет ничего общего с исходным сообщением.

Даже по телевизору в свое время была передача с похожим принципом – называлась «Пойми меня». Причем интересно, что в качестве главного приза тогда были коробочные версии 1С в комплекте с компьютером – на тот момент величайшая ценность.

 

 

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

Так и в проектах – иногда заказчик сразу диктует решение, не разобравшись в сути проблемы. Это мешает правильно определить задачу и выбрать адекватное решение.

 

User Story Mapping – ищем общий язык с заказчиком, определяем бэклог и формируем MVP

 

После обсуждения проблематики предлагаю перейти к практике – она будет построена вокруг трех английских терминов:

• Workshop – формат нашего мероприятия. В отличие от мастер-класса, где участники просто повторяют действия за ведущим, воркшоп предполагает самостоятельную работу. Фасилитатор направляет процесс и говорит, что делать, а участники действуют и принимают решения сами. Получается более творческая работа.

• User Story Mapping (Карта пользовательских историй) – основной инструмент, с которым мы будем работать. Он помогает наглядно выстроить путь развития продукта: от общей цели к конкретным действиям и задачам, которые нужно реализовать.

• MVP (Minimun Viable Product, минимально жизнеспособный продукт) – то, к чему мы придем в результате. Это базовая версия продукта, где реализованы только самые важные и приоритетные функции – такие, которых достаточно, чтобы показать продукт заказчику и начать его использовать.

Задача каждого участника воркшопа – рассказать свою собственную пользовательскую историю, перечислить те действия, которые вы делаете с момента пробуждения до выхода из дома. На каждое действие – один стикер. В итоге у каждого должно получиться примерно 20 стикеров с действиями – из них мы сформируем список пользовательских задач, которые станут фундаментом для User Story Mapping.

 

 

После того как каждый подготовил свой набор действий, участники объединяются в команды по 5-7 человек (максимум 10) и начинают клеить свои стикеры на лист, проверяя, чтобы действия не повторялись – на листе должны остаться только уникальные пользовательские задачи. Если стикер с таким действием уже есть, свой нужно убрать, если еще нет – наклеить отдельно.

 

 

Следующее задание – объединяем отдельные действия в более обобщенные категории. Например, если среди действий были «Почистить зубы» и «Умыться», их можно объединить в общую категорию «Водные процедуры». В результате сверху будут располагаться названия категорий, такие как:

• Водные процедуры.

• Питание.

• Дети.

• Питомцы.

• Одежда.

• Сборы.

• Рабочие вопросы, и т.д.

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

 

 

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

 

 

Следующая задача – совместно подсчитать, сколько времени занимает весь процесс наших пользовательских историй от пробуждения до выхода из дома. Можно подсчитать просто среднеарифметическое на команду – например, в среднем, примерно 1.5 часа.

 

 

А теперь представьте, что вы треть этого времени проспали – получившееся время делим на три и эту треть убираем, оставляя для каждой категории только самые приоритетные действия.

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

 

 

Усложняем задачу – убираем еще одну треть времени. Представьте, что вы проспали еще сильнее, и на подготовку у вас осталось лишь треть привычного времени (например, всего 30 минут вместо полутора часов).

При этом появляется новая вводная: сегодня у вас крайне важная, уникальная встреча, которую невозможно перенести или повторить – например, защита проекта перед губернатором. Поэтому нужно успеть сделать все необходимое, чтобы выглядеть перед губернатором достойно.

Получается, что:

• Сверху у вас перечислены категории задач и самые важные действия, которые обязательно нужно успеть сделать.

• Снизу – те действия, которые вы исключили на прошлом этапе как несущественные.

• А в середину будут перемещаться те задачи, от которых вы отказываетесь сейчас.

Если ради губернатора вам нужно достать какие-то задачи из убранных вниз – переклеивайте их наверх.

В результате получится три уровня приоритетов:

• Верх – те действия, которые нужно обязательно успеть за ограниченное время.

• Середина – те действия, от которых вы сейчас отказываетесь

• Низ – самое неважное.

Для удобства поделите лист на три зоны – отчертите две горизонтальных линии, чтобы четко обозначить верх, середину и низ.

 

 

У нас получилось три уровня – по сути, три релиза:

1. Верхняя часть – MVP. Самые приоритетные задачи, которые должны быть реализованы в продукте, чтобы он уже мог существовать и был максимально крутым – то, что вы берете в реализацию на первый спринт.

2. Средняя часть – следующий релиз. То, что тоже важно, но может подождать.

3. Нижняя часть – в последнюю очередь.

Пример с утренним ритуалом мы рассмотрели, потому что он всем близок и понятен. Если бы мы взяли пример из ИТ, вы бы сейчас спорили о каждой задаче по 15 минут. А тут – легко определить, что важнее: чистить зубы или проверять Instagram.

В случае, если захотите попробовать этот инструмент совместно с клиентом – собрать эти истории, а потом сохранить их как основу для будущих обсуждений, можно:

• Сфотографировать получившуюся доску.

• Обмотать ее скотчем.

• Или перенести все в электронный формат – например, в Miro, Trello и прочие инструменты.

 

Применение User Story Mapping для реальных проектов

 

 

Теперь давайте рассмотрим, как методика User Story Mapping применяется на практике. Мы использовали этот подход в нескольких реальных проектах:

• При создании с нуля конфигурации и Android-приложения для клиента – генерировали идеи и обсуждали, какие задачи стоит включить в первый, второй и третий релизы.

• В работе над нашим внутренним проектом – базой знаний – чтобы определить, каких функций ей не хватает.

• Проводили подобный практикум с нашим клиентом – определяли, какую конкретную «шину» выбрать для проекта и какие задачи взять в работу в первую очередь.

В последнем случае мы допустили глобальную ошибку – пожалуйста, не повторяйте ее. Вместо того чтобы описывать пользовательские истории (что нужно сделать, чтобы достичь результат), мы начали описывать функциональность Шины. Не нужно так делать, функциональность – это просто описание возможностей, а не конкретные действия, которые важны для пользователя. Такое описание не несет в себе конкретного примера, и в результате вам не из чего будет выбрать.

 

 

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

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

• Сформулировать цель – например, цель «Управление заказами» используют как клиент, так и менеджер по продажам. В данном случае, цели – это наши глобальные категории.

• Уточнить действия, необходимые для достижения цели. Например, для цели «Управление заказами» действиями будут «Ввести заказ» и «Обработать заказ». Это чуть более конкретный уровень детализации целей – в нашем упражнении мы этот уровень не стали добавлять, чтобы не перегружать карту.

• Сгенерировать пользовательские задачи – они здесь указаны как функции. На этом уровне мы перечисляем, какие конкретные действия нужно выполнить, чтобы реализовать то или иное действие, которое свою очередь направлено на достижение цели. Эти задачи и отражают то, как пользователи взаимодействуют с системой на практике.

 

 

Все эти задачи формируют бэклог – полный список функций для нашего продукта или проекта. И далее мы эти задачи приоритизируем – распределяем их по релизам: первый, второй, третий и т.д.

Важно понимать: не всегда задачи из первого спринта автоматически переходят во второй. Часто после его завершения возникает необходимость переоценки – стоит снова провести подобную сессию, чтобы скорректировать и уточнить дальнейшие шаги. Для ИТ-сферы это уже вполне привычно.

 

 

В рамках этого воркшопа я сознательно не стал вас сильно контролировать и рассказывать, как нужно действовать – специально дал вам возможность побурлить, чтобы вы максимально эффективно прошли через эту практику и прочувствовали ошибки, которые могут возникнуть при организации такого мероприятия. И впоследствии при его проведении уже таких ошибок не делали.

На слайде приведен дополнительный список аспектов, которые помогут сделать ваш User Story Mapping еще более эффективным. Надо всегда обращать внимание:

• Какие на данный момент есть решения.

• Какие глобальные цели мы реализуем.

• Какую выгоду получат ключевые заинтересованные лица – наши стейкхолдеры и так далее.

Используйте приведенный здесь перечень как подсказку.

 

 

Учитывайте, что не все пользователи будут довольны изменениями продукта или проекта. Самое главное, чтобы вы и большинство членов вашей команды были нацелены на то, чтобы сделать ваш продукт или проект круче.

 

Советы: как сделать свой User Story Mapping еще лучше

 

 

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

Да, есть «Черная книга Scrum», где утверждается, что это невозможно, потому что от скейтборда к машине вообще ни одной детали не подойдет, и все это – просто пустая трата времени и ресурсов. Но у нас в ИТ немного не так. И не только в ИТ.

 

 

Представьте, что вы должны нарисовать «Джоконду», но ни вы, ни заказчик до конца не знаете, как она должна выглядеть.

Если вы начнете рисовать «по частям» – сначала глаз, потом ухо, потом руку – и попытаетесь таким образом угадать итог, то, скорее всего, сразу ничего не получится. То же самое – и с конечными очертаниями продукта.

А если рисовать по эскизу – показываете заказчику, он говорит: «Здесь надо руку ниже опустить». Вы корректируете. Потом обсуждаете фон, выражение лица, цвета. В результате шаг за шагом через промежуточные версии, получается более жизнеспособный продукт – а заказчик лучше улавливает его смысл и может давать более точные комментарии.

 

 

В мероприятия по User Story Mapping нужно обязательно вовлекать все стороны – не только руководителей проекта и продакт-менеджеров с обеих сторон, но и представителей бизнеса. Именно они могут озвучить свои потребности, ожидания и приоритеты.

Также желательно привлекать разработчиков – их участие на этапе формирования пользовательских историй помогает максимально эффективно решить наши продуктовые задачи.

Например, бизнес может предложить задачу, которая кажется важной, но разработчик сразу скажет: «Это полгода работы». Тогда как другая задача, не менее полезная, может быть реализована за несколько минут. Программист сразу скажет – имеет ли смысл брать эту задачу или нет. Тем самым мы выберем максимально эффективные задачи при минимальных затратах.

 

 

Следующий важный момент – говорите и записывайте. Обратите внимание, что на первом этапе вы уже существовали как команда, но пока друг с другом практически не общались.

В ходе User Story Mapping крайне важно, чтобы каждый высказался, а все идеи без исключения были зафиксированы. Вы сначала должны записать все идеи, а только потом их приоритизировать и решать – что оставить, а что убрать.

 

 

Не стоит с самого начала нырять в глубину и выписывать очень детализированные задачи. Вместо этого на первом этапе постарайтесь рассмотреть всю историю целиком – например, определите все верхнеуровневые шаги, которые нужны для управления заказами. Сделайте широкий обзор – наметьте «берег», к которому вы плывете.

 

 

После того, мы вы собрали все задачи для бэклога, надо остановиться и подумать. Вот мы выбрали MVP – верхнюю часть карты. Теперь важно задать себе вопрос: если мы реализуем эти 15 задач, которые попали в первый спринт, получим ли мы работающий продукт? Не упустили ли мы что-то важное? Не забыли ли мы какую-то критически важную задачу, без которой «наше Рождество» не состоится?

Если замечаете пробелы – дописывайте. Задачи, которые обязательно должны быть включены в ближайший релиз, должны быть учтены.

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

 

 

Теперь о том принципе, который мы сегодня нарушили. Вы наверняка участвовали в совещаниях Zoom, где присутствуют 20-30 человек и все одновременно что-то говорят. Обычно эффективность у таких мероприятий крайне низкая, потому что есть эмпирическое правило: человек способен одновременно взаимодействовать эффективно максимум с 5-7 другими участниками. У кого-то этот диапазон чуть шире, но редко превышает 8.

Поэтому, если вам нужно проработать пользовательскую историю с участием 15 человек, не стоит собирать всех одновременно. Разделите участников на группы по 5-7 человек и проводите сессии по очереди, чтобы повысить фокус и продуктивность группы.

Или используйте метод «аквариума»: оставьте основную группу, а остальных временно выведите из обсуждения – пусть отдохнут, пообщаются на отвлеченные темы. Сегодня мы это правило нарушили – участников в командах было больше, чем нужно – но теперь вы знаете, как действовать в будущем.

 

 

Украшайте User Story Mapping визуальными элементами: таблицами, схемами, диаграммами, изображениями. Это нужно, потому что при проведении сессии по User Story Mapping вам может потребоваться не одно совещание – возможно, два, а то и больше. Но приходя на следующую встречу, вы с большой вероятностью забудете примерно треть обсужденного ранее. Это нормально – информация забывается.

Чтобы этого избежать и сохранить целостность картины, используйте визуальные элементы. Они помогают восстановить контекст, особенно если прошло время. Одна картинка или диаграмма может быстро «включить» память и напомнить, о чем шла речь, какие задачи обсуждали и почему они важны.

 

 

Пример. Как вы думаете, что изображено на этой фотографии? Задняя часть лошади, какие-то люди. На первый взгляд – ничего особенного. Но для меня и моей команды это целый мир. Это Алтай, это дядя Саша, который там существует без связи. Это ночные конные походы, воспоминания о том, что лошадь боится молнии. Мой друг там упал с лошади, когда та испугалась грозы – молния ударила, животное встало на дыбы и его сбросило. Это опыт, когда понимаешь: в дождь лучше подниматься в седле, а спускаться уже пешком, используя страховку, потому что конь может проскользить на несколько метров по грязному склону.

Я могу рассказать десятки историй, связанных с одной фотографией. Точно так же и ваша визуализация на User Story Mapping – если вы дополните ее не только текстом, но и образами, схемами, неформальными пометками, она обретет для команды гораздо больший смысл.

 

 

Что ещё важно учитывать при составлении пользовательских историй и задач?

Когда мы на сессии прописываем одно короткое действие – кажется, что всё ясно. Но когда вы превращаете это в полноценную ИТ-задачу, может возникнуть неоднозначность в трактовке. Чтобы избежать путаницы, особенно для задач, которые идут не в MVP, а откладываются в бэклог для следующих релизов, желательно оформлять их подробно – как карточки в библиотеке. Тогда, когда придёт время, вы сможете «вынуть» такую карточку, сразу понять, о чём речь, и быстро принять решение: брать её в работу или нет.

Что можно включить в такую карточку задачи:

• Автор задачи (кто создал).

• Дата и время создания.

• Статус утверждения (если у вас есть процесс согласования).

• Основание (если нужно – например, внутренний приказ или регламент).

• Название задачи.

• Описание (чёткое и развёрнутое).

• Ссылки (например, на документы, ТЗ или другие материалы с деталями).

• Комментарии или пояснения, если задача сложная или содержит нюансы.

Подход к оформлению может быть индивидуальным, но важно, чтобы при возвращении к задаче спустя время всё было понятно без лишних расспросов.

 

 

И наконец, самое важное. Самые крутые проекты и продукты получаются, когда есть:

• Люди, которые понимают, что они хотят (заказчики).

• Люди, которые могут это реализовать (программисты, аналитики, продакты).

• Люди, которые могут помочь договориться этим двум сторонам совместно сделать крутой результат (скрам-мастера и фасилитаторы).

 

 

Подробнее про User Story Mapping можно прочитать в книге Джеффа Паттона «Пользовательские истории. Искусство гибкой разработки ПО». Автор пишет очень интересно – приводит множество примеров и историй, некоторые из которых я сегодня попытался до вас донести.

Надеюсь, этот опыт поможет вам в дальнейшем в работе над вашими продуктами и проектами.

 

Вопросы и ответы

 

Что делать, если заказчик сам не знает, чего хочет?

Именно для таких случаев и организуется мероприятие User Story Mapping. Оно помогает «достать» из головы заказчика его представление о продукте, даже если он сам его пока не может сформулировать. Часто проблема не в том, что заказчик ничего не хочет, а в том, что его ожидания не проговорены и могут сильно отличаться от того, что планируют разработчики.

В процессе User Story Mapping мы не просто технически описываем, что и как будем делать, но и стараемся донести это понятным, «человеческим» языком. Потому что если заказчик смотрит на задачу и говорит: «Я не понимаю, что вы тут написали. Я такое не буду брать. Давайте еще разговаривать» – это сигнал: нужно продолжать диалог и уточнение.

Нужно ли в заказной разработке объединять команду заказчика и исполнителя, чтобы совместно строить карту пользовательских историй?

Да, именно в этом и заключается суть подхода User Story Mapping. Совместное составление карты пользовательских историй помогает обеим сторонам выработать общее понимание продукта.

А какое соотношение людей со стороны заказчика и со стороны исполнителя должно быть в команде User Story Mapping при таком привлечении? Особенно, если учесть, что рекомендовано ограничить численность команды в 10 человек, а мы должны привлечь все заинтересованные стороны?

Не нужно собирать сразу всех – лучше поделить команду на подгруппы, распределить людей по тематикам или направлениям. Например, сегодня – обсуждение только «Управления заказами», и приглашаются только те представители бизнеса, кто отвечает за этот блок.

• На встрече должны быть представители со стороны заказчика, которые высказывают свое мнение и подтверждают либо согласуют видение реализатора.

• И реализатор, который говорит: «Вот эти задачи на данном этапе сделать легко и просто». Его участие поможет реализовать продукт качественно и уложиться при этом в срок

При этом важно, чтобы встречу вел фасилитатор – человек, которые не навязывает решения, а помогает организовать конструктивный диалог.

Если среди заказчиков есть не очень вовлеченные участники, подключите тех, кому они доверяют – так называемых «амбассадоров» – кто сможет их «раскрыть»: пошутить, поддержать, перевести техническое на понятный язык.

Как бороться с проектами апгрейда, когда заказчик хочет «как в старой версии» – сделать MVP, который будет меньше, чем предыдущий продукт?

Это отдельная история. Часто заказчик говорит: «Сделайте, как у нас было в 7.7». В такой ситуации можно действовать через экономику и логику развития:

• Покажите, сколько стоит добавить нужную функциональность в старый продукт

• Сравните это с затратами на создание нового MVP

• Продемонстрируйте, что дальнейшие доработки в новом продукте будут дешевле, быстрее и гибче.

Так можно постепенно убедить заказчика в необходимости перемен.

У вас на слайде было написано «Не нырять вначале глубоко» – т.е. сначала мы весь кейс смотрим, а потом уже уточняем его. Но что делать, если в MVP забыли важную часть? А забыли – потому, что не копнули глубже.

Это нормально. Одно из преимуществ гибкой разработки – возможность быстро реагировать на недочеты. Если что-то не попало в первый релиз – добавите в следующий. Главное – не допускать критичных для бизнеса ошибок и не выходить за рамки сроков и бюджета.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.