Наверняка вы хоть раз заказывали себе или кому-нибудь из близких на День рождения торт. Но всегда ли он получался именно таким, как вы хотели? Бывает, что ожидания не совпадают с результатом.
Реальный случай: мама заказывает торт для дочери Алисы. Просит надпись фиолетовым цветом: «Всего хорошего, Алиса», а вокруг надписи – звезды. Кондитер говорит: «Без проблем, завтра забирайте». Вроде ничего сложного.
Но в итоге на торте появляются не звезды, а надписи «звезды». И торт, хоть и красивый, но совсем не тот. Вроде мелочь, но для ребенка – разочарование.
Если вы считаете, что это – выдумка и преувеличение, есть целый сайт с фотографиями таких тортов. Всякие разные случаи. Например, там есть фото торта, при заказе которого в заметках написали «аллергия на орехи» – в результате прямо на торте появилась надпись: «аллергия на орехи».
Думаю, и у вас при постановке задач иногда тоже случаются подобные недопонимания.
В итоге – что мы имеем? Если рассматривать торт как продукт или проект, у менеджера – продакта или РП – возникает масса вопросов: «Что же пошло не так? Почему результат не соответствует ожиданиям? Возможно, мы неправильно сняли требования? Или использовали не тот подход при их формулировке?»
Заказчик, конечно, будет крайне недоволен: «Я же столько раз все объяснил – что, зачем и куда!», и выплеснет на нас все свои негативные эмоции.
А разработчик (в данном случае – кондитер), скорее всего, даже не поймет, что в чем-то не прав. Ему дали ТЗ, он его закодил – у него все отлично. Он счастлив. Ему осталось только поставить финальный штрих – как этому турецкому повару, посыпающему мясо солью.
Формально все сделано по ТЗ. Но по факту – продукт получился совсем не тот, который был нужен. Его можно вылить в канализацию – в таком виде он никому не нужен.
Ладно торт – максимум несколько тысяч рублей. Бывают случаи куда серьезнее.
Например, в истории освоения космоса был проект, где ошибка стоила 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 минут вместо полутора часов).
При этом появляется новая вводная: сегодня у вас крайне важная, уникальная встреча, которую невозможно перенести или повторить – например, защита проекта перед губернатором. Поэтому нужно успеть сделать все необходимое, чтобы выглядеть перед губернатором достойно.
Получается, что:
-
Сверху у вас перечислены категории задач и самые важные действия, которые обязательно нужно успеть сделать.
-
Снизу – те действия, которые вы исключили на прошлом этапе как несущественные.
-
А в середину будут перемещаться те задачи, от которых вы отказываетесь сейчас.
Если ради губернатора вам нужно достать какие-то задачи из убранных вниз – переклеивайте их наверх.
В результате получится три уровня приоритетов:
-
Верх – те действия, которые нужно обязательно успеть за ограниченное время.
-
Середина – те действия, от которых вы сейчас отказываетесь
-
Низ – самое неважное.
Для удобства поделите лист на три зоны – отчертите две горизонтальных линии, чтобы четко обозначить верх, середину и низ.
У нас получилось три уровня – по сути, три релиза:
-
Верхняя часть – MVP. Самые приоритетные задачи, которые должны быть реализованы в продукте, чтобы он уже мог существовать и был максимально крутым – то, что вы берете в реализацию на первый спринт.
-
Средняя часть – следующий релиз. То, что тоже важно, но может подождать.
-
Нижняя часть – в последнюю очередь.
Пример с утренним ритуалом мы рассмотрели, потому что он всем близок и понятен. Если бы мы взяли пример из ИТ, вы бы сейчас спорили о каждой задаче по 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 забыли важную часть? А забыли – потому, что не копнули глубже.
Это нормально. Одно из преимуществ гибкой разработки – возможность быстро реагировать на недочеты. Если что-то не попало в первый релиз – добавите в следующий. Главное – не допускать критичных для бизнеса ошибок и не выходить за рамки сроков и бюджета.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.