На рубеже 1910-х годов инженер Генри Лоуренс Гант придумал и начал использовать диаграмму Ганта как способ управления проектами. Основная идея заключается в том, что задачи декомпозированы, имеют начало и конец, и показывают последовательность выполняемых работ. Если вы сталкивались с проектным управлением, то знаете, что это очень полезный инструмент.
Диаграмма Ганта настолько понятна и визуально проста, что её часто используют для визуализации последовательности работ в управлении продуктом. Однако здесь возникают некоторые особенности, которые, на мой взгляд, не помогают, а, скорее мешают продуктовому управлению.
Дело в том, что визуализация по Ганту предполагает, что продуктовые задачи в дорожной карте имеют четкий срок начала и завершения. При этом я часто сталкивался с тем, что в представлении стейкхолдеров задача должна быть выполнена не только в срок, но и с максимальным качеством. Таким образом, используя красивую диаграмму Ганта, мы вводим заинтересованные стороны в заблуждение.
Инструмент, который хорошо помогает управлять проектами, не всегда подходит для управления продуктом. Во-первых, продукт и проект отличаются по своей сути. Во-вторых, при управлении дорожной картой продукта вы работаете с неопределенностью, в то время как проектное управление не предполагает большого количества неизвестных, особенно в объёме задач или сроках.
Согласно отчёту McKinsey о рабочих местах:
сроки реализации проектов сократились на 40% по сравнению с пятью годами ранее;
командам предстоит в 3 раза больше изменений, чем в 2018 году;
82% успешных проектов требуют частой корректировки плана.
Основные причины, указанные в отчёте:
72% руководителей проектов сообщают, что диаграммы Ганта устаревают в течение нескольких недель после создания.
Команды тратят в среднем 4,5 часа в неделю только на обновление графиков проектов.
68% успешных проектов теперь используют методы адаптивного планирования вместо жестких рамок.
На мой взгляд, использование диаграммы Ганта в качестве дорожной карты продукта воспринимается как обещание перед заинтересованными сторонами действовать строго по плану. Я неоднократно сталкивался с критикой при отклонении от запланированных задач в дорожной карте, даже если изменились рыночные условия или тестирование показало перспективность новой функции. Стейкхолдерам психологически легче воспринимать "колбаски" Ганта как правильное направление, даже если внешняя среда резко изменилась.
С другой стороны, мы можем постоянно менять последовательность работ и планов, чтобы даже такой жесткий инструмент, как диаграмма Ганта, стал гибким.
«Будущее не в жестком планировании, а в гибких корректировках». — Питер Друкер
Таким образом, диаграмма Ганта — это хороший инструмент для построения дорожной карты, но нам нужны альтернативы.
Дорожная карта целей
Дорожная карта продукта, ориентированная на достижение целей (GO — Goal Oriented). В ней основное внимание уделяется целям, которые должны быть достигнуты для продукта, а не длинному списку функций. Это очень простой и адаптивный шаблон, который легко перестраивается под ваш продукт и цели. Однако у него есть существенный минус — высокий уровень абстракции. Это компенсируется гибкостью и возможностью квартального планирования, как по OKR, так и со стейкхолдерами, путём понижения уровня абстракции до конкретных ключевых инициатив — крупных функциональностей.
Временной период или версия — позволяет определить промежутки или рамки для вышестоящих пунктов. Если в вашей компании не привыкли к гибкости, с осторожностью ставьте даты или кварталы, лучше используйте понятие версии.
Цель — наиболее важное понятие, отражающее цели, которые стоят перед продуктовой командой или вашей стратегией в целом.
Метрики — это то, как вы отслеживаете достижение целей или прогресс. Метрики должны быть напрямую связаны с целями.
Ключевые функции или результаты — здесь отра��аются ключевые направления или крупные функции, над которыми будет работать ваша команда или несколько команд. При изменении плана вы легко меняете ключевые функции в выбранный период, если они соответствуют целям и могут быть проверены метриками. Старайтесь не писать много функций (лучше порядка четырёх-пяти), оставляйте место для их изменения и предложений от команды.
Несмотря на свою верхнюю уровневость, такая дорожная карта позволяет легко менять ее на уровне функций, не углубляясь в детальное планирование до уровня задач в спринте, сосредотачиваясь на отслеживании целей.
Похоже ли это на OKR? Более чем, но упор делается на совпадение временных рамок и функций через призму целей и метрик для стейкхолдеров.
Дорожная карта пользовательской истории
Такая дорожная карта, на мой опыте, хорошо подходит для запуска новых продуктов. Она подходит для реализации одной или максимум двух пользовательских историй. Она помогает разбить сценарии на релизы или версии поставки, а также отделить важные функции или сценарии от второстепенных и вспомогательных.
Основана она на классических пользовательских историях и глубоком понимании клиентского опыта. По сути, мы описываем сценарии и требования к продукту в виде функций, которые отражают ценность, которую мы хотим создать.
Сгруппировав и описав пользовательские истории в виде цельного сценария, вы обнаружите, что такие истории занимают много места и могут быть весьма громоздкими. Поэтому на втором этапе вы приоритезируете, какие истории будут реализованы на следующем этапе, какие сценарии в какие релизы или спринты планируется реализовать. Таким образом, у вас получается сетка с приоритетами и версиями изменений продукта в разрезе прироста ценности для пользователя.
Для повышения гибкости вы можете пересматривать состав релизов по функциям и сценариям — главное оставаться гибкими.
Из важных нюансов следует то, что каждый стикер в такой дорожной карте может иметь разную важность и разный срок реализации. По этой причине ваша дорожная карта будет меняться несколько раз в месяц, но зато она очень понятна разработчикам и стейкхолдерам. Из минусов — она очень подробная и хорошо подходит для одной команды или команд, работающих над одним продуктом.
При правильном построении дорожная карта пользовательских историй помогает:
Сосредоточиться на ценности для пользователя — вы представляете продукт с точки зрения пользователя.
Расставить приоритеты для правильной работы — создание целостной цепочки визуализации всех работ.
Установить четкие и масштабные требования — наглядно демонстрировать, как крупные элементы работы разбиваются на более мелкие сценарии и функции.
Выявить риски и зависимости — создание историй взаимодействия пользователей с продуктом может дать глобальное представление о продукте, что позволит визуализировать потенциальные препятствия, риски и зависимости.
Обеспечить единое понимание целей и задач всеми членами команды.
Дорожная карта приоритетов
Такая карта — это категоризация задач и инициатив по трём основным приоритетам: Сейчас, Далее, Позже (Now-Next-Later).
Сейчас — это немедленные задачи, требующие решения или внимания. Эти элементы проверены, описаны, и они жизнеспособны, могут быть реализованы и желательны. Это элементы, в которых мы уверены.
Далее — это инициативы для фокуса на краткосрочной перспективе и кандидаты на следующие улучшения. Элементы в этом блоке могут быть отброшены из-за изменения необходимости, сложности реализации или изменения внешней среды.
Позже — это долгосрочные цели, формирующие стратегическое направление. Элементы в этой зоне ещё не определены и могут быть вообще выброшены, так как мы можем узнать что-то новое от наших пользователей, и эти элементы станут не нужны.
Основная цель дорожной карты "Сейчас — Далее — Позже" — оптимизировать процессы планирования и разработки продукта, не теряя из виду стратегию более высокого уровня. Она помогает командам сохранять четкий фокус на том, что необходимо сделать сейчас, а также сохранять основу для предстоящих задач и долгосрочных целей.
Несомненным плюсом является лёгкость изменения такой дорожной карты под изменения рынка и внешних условий. Команда и продакт-менеджер могут легко менять её в зависимости от изменений внешней среды, обновляя приоритеты в задачах. Этот метод способствует ясности, различая немедленные действия, предстоящие планы и будущие цели, тем самым организуя усилия команды продукта.
Из минусов можно указать на непонятность, когда наступит очередь для инициатив, помеченных как "Далее" и "Позже" — срок их реализации непрозрачен.
Дорожная карта "Сейчас — Далее — Позже" учитывает высокую неопределенность, признаёт быструю смену приоритетов и подстраивается к тому, что мы узнаем по мере реализации продукта. Ваши заинтересованные стороны должны быть готовы к этим принципам, прежде чем вы внедрите этот инструмент. Если нет, то это будет трудно продать и ещё труднее с ней работать.
Управление дорожной картой
Независимо от выбора типа дорожной карты, вам придётся её адаптировать и менять. Такие изменения будут происходить ежеквартально, ежемесячно и еженедельно, чтобы поддерживать структуру, не упуская из виду то, что требует изменения и регулирования.
Ежеквартальный уровень:
Ставьте перед собой широкие цели.
Определите основные вехи.
Распределите ресурсы.
Ежемесячные проверки:
Просмотрите показатели прогресса.
Отрегулируйте распределение ресурсов.
Устраните возникающие риски.
Еженедельное регулирование:
Установите конкретные приоритеты задач на короткий срок.
Устраните препятствия на пути.
Отмечайте быстрые победы и достижения команды.
В своей работе я использовал много разных типов карт, даже те, которые не описал в данном материале. Постепенно я пришёл к выводу, что дорожная карта — это инструмент. Как и любой инструмент, она должна применяться исходя из внешних и внутренних условий в компании. Как ни странно, обоснование использования одного типа карт или другого является продолжением культуры и принятых норм в компании, а не конкретной необходимостью. Если у вас компания с культурой "Успеха", то у вас точно будут сроки на дорожной карте и четкие задачи в виде диаграммы Ганта с ответственными за их выполнение — даже если вы выводите новый продукт на рынок.
Выбирайте подходящую вам дорожную карту под ваши задачи, и да пребудет с вами продуктовая сила!
