Roadmapping — карта развития продукта?

“Responding to change over following a plan” — важный постулат философии гибкой разработки. Но он не подразумевает отсутствия планов.

Планы или реакция на изменения? предсказуемость или адаптивность? долгосрочная стратегия или тактические цели? — такие примеры выбора между двумя существенными вещами, составляющими одно целое, называют в науке “ложной дихотомией”, а в буддизме “дуалиазмом”. Нам важны обе составляющие. И одна не работает без другой.

Планы важны, как и важно их обновлять при поступлении новой информации. Это здравый смысл. Мы так делаем в жизни: планируем отпуска долгосрочно, зная, что возможно нам придётся немного адаптировать планы, если не задастся погода; планируем ремонт в квартире, зная, что скорее всего, на всё не хватит денег и терпения и чем-то придётся жертвовать; планируем карьеру и отвечаем на вопрос “кем я вижу себя через пять лет”, зная, что всё на самом деле будет совершенно не так, как мы себе это сейчас рисуем.

Тем не менее — это очень полезное упражнение: оторваться от рабочего стола и посмотреть в даль. Только в product roadmapping’е мы это делает ни в одиночестве, а в кругу коллег и руководителей.

Roadmapping как процесс

Само слово “roadmap” или как любит говорить наш сладкий президент “дорожная карта” — это не совсем верная метафора.

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

Поэтому здесь и далее мы будем использовать слово “roadmapping”, чтобы подчеркнуть, что это не артефакт (roadmap, дорожная карта), но некий процесс (~ing) прояснения целей, вех, метрик и других важных деталей развития продукта.

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

Roadmapping для построения общей большей картины

Как бы вы гибко не налаживали процессы в организации, как бы вы не старались добиться кросс-функциональности команд в Scrum, сколько бы времени представители интересов клиентов, владелец продукта, аналитики и команда разработки не работали тесно вместе — информация всегда будет несколько фрагментирована, а общая картина или “bigger picture” известна лишь по частям и не всем.

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

1. попросите каждого участника воркшопа взять листок бумаги ручку или карандаш и нарисовать диван

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

3. когда диваны готовы, попросите за диваном нарисовать висящую на стене картину в раме

4. ушлые участники воркшопа начнуть догадываться о подвохе и просить деталей картины, размеры, положение; добавьте деталей: картина прямоугольная, форм-фактор ландшафт, висит слева

5. попросите добавить волосы — тут все зайдут в тупик!

6. но стоит показать всем фото из музея Дали (см ниже) и уверяю вас, всё станет на свои места!

7. теперь попросите нарисовать на стене вторую картину и участники будут готовы это сделать без прояснения деталей

8. попросите добавить камин-нос, и это тоже не вызовет особых трудностей!

Лицо Мэй Уэст, использованное в качестве сюрреалистической комнаты, музей Сальвадора Дали. Вид сбоку.

Та же комната. Вид через удаляющий оптический аппарат.

В чём же соль?

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

Для этого нам в продуктовой разработки время от времени и нужны сессии построения “большей картины”. Они же product roadmapping.

Roadmapping — это как проработка беклога продукта?

Проработка беклога продукта (в народе “груминг беклога”) — это полезное упражнение совместной проработки деталей. Опытные Скрам-команды научились проводить его регулярно. И это неплохой шанс заглянуть за завесу текущего спринта, посмотреть немного наперёд, разобраться в деталях предстоящей работы.

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

Горизонт груминга обычно ограничен несколькими спринтами вперёд — от пары недель до полутора месяцев, в лучшем случае, и их стараются проводить “без отрыва от производства” — часто как собрания на час-два в неделю. Так что как показывает наш опыт, таких встреч недостаточно, чтобы видеть общую большую картину. Вопросы накапливаются, видение расплывается, фрагментация знаний усиливается.

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

Груминг как часть роудмаппинга, вторая половина второго дня.

Участники сессий roadmapping-а

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

Мы называем такую группу “расширенным кругом продукта”, и в неё входят (в зависимости от продукта и компании) представили таких орг функций как:

• marketing
• sales
• customer care
• product support
• development teams
• product management
• project management(если эта функция выделена в организации)
• top-management и executives

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

В случае компании IPLand и их продукта effie> такая команда составила около 20 человек, и мы работали вместе два дня.

Я сказал, что мы зовём представителей различных функций организации — кого-то из маркетинга, кого-то из продаж. Да всё верно. Но есть исключение: в независимости от размера команды разработки или количества таких команд при масштабной разработке, мы настоятельно советуем приглашать всех инженеров без исключения. Их явка обязательна, и им с очень большой вероятностью очень понравятся такие встречи.

Работа в группах по составлению портретов пользователей для анализа их текущих “болей”.

Roadmapping — это то же, что и PI-planning в SAFe?

Не совсем. Вернее, совсем нет.

Не смотря на то, что в случае масштабной разработки (сотни участников, десятки команд) мы тоже советуем приглашать всех членов всех команд на сессию roadmapping-а, не стоит путать это мероприятия с тем, что методология SAFe называет “Program Increment Planning” или “PI-Planning”.

В чём же отличие?

Планирования инкремента продукта в SAFe (на сколько я это понимаю) ставит перед собой целью составление детального плана разработки на следующие спринты и commitment от команд менеджменту. На нашем опыте такой процесс хоть и несомненно имеет положительные стороны (всё та же bigger picture, обсуждение целей и прояснение тактики), его обратной стороной является составление внутренних “контрактных обязательств” между командами и менеджментом о детальных планах спринтов.

На мой взгляд это снижает гибкость системы и приводит к известным негативным эффектам водопадной разработки — этот процесс фиксирует как время так и объём работы, а это опасно. Так как для того, для того, чтобы выполнить план, разработчикам ничего не остаётся, как раскрыть свой “секретный ящичек хитрых инструментов” и начать срезать углы техпроцесса — чистоту кода, написание тестов, и т.д. От этого страдает качество и мотивация, а как следствие — все, в том числе менеджмент, заказчики и конечные пользователи. Так что PI Planning в чистом виде — это не совсем то, чего мы хотим. Вернее, совсем не то!

Roadmapping — про коллективное прояснение целей и стратегии развития продукта. На выходе — ясность долгосрочной перспективы, на которую потом спринт за спринтом, день за днём, фичей за фичей команды и владелец продукта и команда (или команды в случае масшабного Скрама) будут нанизывать эффективные тактические решения. Никаких обещаний здесь никто никому не даёт. Что мы вообще можем друг другу обещать о будущем? Разве что то, что оно точно будет не таким, как мы его себе сегодня рисуем! Поэтому мы рисуем крупными мазками.

Составление карты — Product Owner и команда, день второй.

Roadmapping — что именно мы обсуждаем?

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

1. понимание текущего состоянии продукта (конечно, кроме случая самого начала разработки, когда продукта ещё нет)
2. стратегия и цели бизнеса
3. знания о рынке и нуждах пользователях
4. технические ограничения и риски

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

ормат сессии роудмаппинга сводится по сути сводится к тому, чтобы свести воедино эти четыре вектора. Как? Очень просто: дать возможность людям, которые владеют информацией о каком-то из них презентовать то, что известно. (Ниже приведено примерное расписание проведения воркшопа.)

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

Разработчики демонстрируют всем участникам роудмаппинга часть текущего продукта (версию для Android tablet).

Примерное расписание двух дней проведения сессии Product Roadmapping

Участники

• весь круг продукта

Цели воркшопа

1. собрать воедино четыре вектора развития продукта: текущее состояние продукта, пользователи, бизнес, инжиниринг
2. составить высокоуровненую стратегическую карту развития продукта с учётом трёх векторов на уровне эпиков
3. начать разнесение эпиков на временные горизонты (лето, осень, зима)

Расписание

Оба дня: 10:00–19:00

День первый — сбор информации

В этот день мы собираем всех, кто так или иначе вовлечён в разработку, развитие и поддержку продукта. Это может быть 20 человек и больше. Программа дня построена таким образом, чтобы дать каждой группе представить своё текущее понимание продукта и его дальнейшего развития.

Демонстрация продукта и его развития за последние месяцы

10:00–12:00

Цель: познакомить всех с текущим состояние продукта, “погордиться” достижениями, начать вместе думать о продукте и его дальнейшем развитии

Текущая картина с точки зрения бизнеса

12:00–13:30

Цель: описать текущее видение продукта с точки зрения бизнеса и рынка сбыта

Расширенный перерыв на обед

13:30–15:00

Обзор инсайтов от рынка, пользователей, их специфики и нужд

15:00–17:00

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

Агрегация данных, открытые вопросы, буфер времени

17:00–19:00

Время для обдумывания и проработки полученной информации.

Быстрая визуальная сортировка-ранжирование болей пользователей.

День второй — построение карты развития продукта

В этот день в IPLand мы работали в основном с командой разработки и её Владельцем Продукта на основании полученной в первый день разносторонней информации.

Составление карты развития продукта

10:00–12:00

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

Первичный груминг идей ближайших спринтов

13:00–16:00

Мини-тренинг по составлению качественных элементов беклога и много практики на свеже-составленном роудмапе.

Lessons learned

17:00–19:00

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

Agile product roadmap

Выгоды от product roadmapping:

More Alignment: все участники процесса разработки продукта — стейкхолдеры, представители бизнеса, менеджмент и инженеры — получают общую картину. Это создаёт согласованность на уровне стратегии, долго- и среднесрочных целей и гарантирует, что все будут идти в одну сторону.

Less Management and Process: наличие согласованности на уровне стратегии и планов снижает необходимость менеджмента (и в частности документации). Когда цели согласованы и понятны всем, нужно намного меньше описанных деталей, чтобы гарантировать общее понимание.

More Self-Organization: понятные цели (и их одобрение всеми участниками процесса) позволяют командам разработки и их участникам принимать ежедневные решения и свободней экспериментировать без ожидания “согласований” сверху.

Better Products: и это, конечно же, наша цель! Но она достижима лишь косвенно… Мы верим в то, что регулярные (наша рекомендация: раз в квартал) сессии совместного обновления и построния роудмапа продукта позволяют делать лучшие продукты.