Я Мария Темчина – директор по проектам Инфостарта. В качестве хобби я руковожу проектами в лагере добровольных лесных пожарных на Ладожском озере, так что отлично могу подсказать, как надо и как не надо «тушить пожары» на проектах. О том, как правильно организовать проекты и чего делать не стоит, я знаю не понаслышке.
Зачем нужна дорожная карта?
Мне очень нравится метафора про дорожную карту: реализовывать проект без дорожной карты – то же самое, что собирать мебель без инструкции. Можно сказать, что и мебель можно собрать без инструкции, и продукт развивать без дорожной карты – все возможно, но очень сложно, иногда болезненно, а иногда непредсказуемо.
Начну статью с определения, зачем вообще нужна дорожная карта. Если вы считаете, что это инструмент планирования – разочарую вас. Она, прежде всего, инструмент коммуникации.
-
Способ донести нужную информацию до нужных сторон. Для команды разработки нужна одна дорожная карта, для менеджмента – другая, для маркетологов – третья. Для будущих клиентов, которым вы показываете, какой у вас замечательный продукт, нужна совершенно иная дорожная карта, чем для команды разработки, с которой вы начинаете работу. В этой информации не должно быть ничего лишнего, только то, что действительно важно. Очень важно понять, какая информация нужна для разных задач.
-
Способ провести дискуссию и создать общее виденье будущего. Это способ определиться и договориться, что именно мы делаем и куда движется наш продукт, убедиться, что у всех одна картинка.
-
Способ вытащить из-под ковра конфликты и найти способы их разрешения. Выявлять конфликты и решать их необходимо сразу, на берегу. Обратите внимание, что это не способ погасить конфликты. Напротив, если конфликт назревает, лучше его выявить и обсудить. Если по итогам обсуждения не возникает споров или разногласий – это тревожный знак. Такой ситуацией можно дать понять, что участники не очень внимательно смотрят на предложение, потому что именно в процессе обсуждения выясняются варианты дальнейшей работы.
Как не надо делать дорожные карты?
Есть подход: «Давайте что-нибудь красиво нарисуем, и всем сразу станет понятно». Такой подход редко обеспечивает успех. Посмотрите на следующий рисунок. Мне очень нравится эта карикатура: люди знают, что будет на первом и втором этапах проекта, а чтобы перейти к третьему – нужно какое-то чудо.
Сложности при подготовке дорожных карт
-
Отсутствие четкой цели – для кого-то инструмент избыточен, а для кого-то – недостаточен. Инструмент неудобен.
-
Попытка сделать диаграмму Ганта вместо высокоуровневой карты. В самой диаграмме Ганта ничего плохого нет, она полезна в определенных случаях. Но зачастую встречается ситуация, когда руководитель проекта говорит: «Я могу показать тебе дорожную карту, но она уже устарела». Или обнаруживается, что большинство таких карт – устаревшие, обновлять их сложно или невозможно. В условиях высокой неопределенности и сложных проектов планирование ведется методом «набегающей волны»: подробно планируем ближайшее будущее и даем приблизительную картину по более отдаленным задачам, основываясь на принципе 3П: пол, палец, потолок. В этом проявляется лишь попытка кого-то обмануть и в лучшем случае – себя.
-
Карта, в сроки которой участники не верят. Когда мы разрабатываем план, зачастую понимаем: он нереален. Однако для успокоения кто-то его все равно рисует. Иногда давят сверху, и изменить ситуацию сложно. Такой подход – тупиковый, потому что мы не вытаскиваем проблемы из-под ковра, а забиваем их глубже под ковер, усугубляя последствия.
-
Устаревающая информация. Отсутствие своевременного обновления. Неактуальная дорожная карта – тоже плохой вариант. Важно регулярно обновлять информацию.
Разработка дорожных карт
Существуют разные типы и подходы к созданию дорожных карт. Разберем несколько примеров, какие дорожные карты создают разные команды.
Кейс №1. Дорожная карта на основе фич
Несколько команд, много бизнес-заказчиков (включая топ-менеджмент), сложный продукт.
Контекст, думаю, знаком многим: у нас сложное взаимодействие нескольких команд – бизнес-заказчиков. Их интересы конфликтуют. Соответственно, продукт достаточно сложный. У команд и у заказчиков возникают проблемы, так как у них нет общей картинки.
Возникает путаница:
-
Какой функционал уже готов?
-
Какой планируется к разработке?
-
Какой отменен?
-
В какой момент планируется готовность будущего функционала?
Появляются конфликты между бизнесом и разработчиками по срокам:
-
Бизнес считает, что разработчики «копаются». Ему нужно, чтобы все готово было уже через неделю. В их картине мира разработчики ничего не делают, раз нужные фичи до сих пор не готовы.
-
Разработчики считают, что все и сразу сделать невозможно, что они делают много и уже подготовили большое количество функционала, который работает, но их работу не замечают.
Решение:
Весь функционал вывели на единой дорожной карте. Очень важно, что на дорожной карте из каждого пункта каждой фичи можно перейти в подробное текстовое описание. Это позволяет понять, какой функционал уже утвержден, как он выглядит – все детали, которые понадобятся. Дорожная карта стала содержать как существующий функционал, так и планируемый. И ситуация сразу стала наглядной.
На дорожной карте отображены:
-
Реализованный функционал,
-
Планируемые фичи со ссылками на описание,
-
Приоритеты и плановые даты релизов.
Это значительно упрощает понимание того, как устроен продукт, и разработчикам стало легче объяснить бизнесу, почему та или иная функция появится не сразу.
Кейс №2. Дорожная карта на базе релизов
Как убедить проектный комитет дать денег на развитие продукта?
Проблема:
Теперь расскажу про проект, в котором пытались развивать продукт, не прорабатывая архитектуру. Здесь другой контекст: есть собственное коммерческое программное обеспечение, которое развивается. Оно востребовано на рынке, ниша понятная и актуальная. Но, к сожалению, отсутствует общая архитектура. Заказчики требуют добавить определенные функции, и их добавляют. Потом добавляют еще что-то, и так далее. В результате получается не очень работоспособная система, с которой хочется что-то делать.
Задача:
Нужно представить на комитете проект будущего комплексного развития продукта. Руководитель решает запустить проект по комплексному развитию продукта и нужно подготовить презентацию для проектного комитета, чтобы убедить выделить на него деньги. Потому что очевидно, что на развитие потребуется больше денег, чем просто на добавление фич.
Сложности:
-
Трудно вместить всю информацию в короткую презентацию;
-
Есть высшее руководство, которому нужно показать красивую
(но убедительную) картинку;
-
Есть финансисты, принимающие решения, которым нужны детали;
-
Разная степень детализации на разных уровнях планирования (ближайший год, следующий год, через несколько лет).
Важно доносить правильную информацию до разных участников: руководству нужна общая картинка, оно не хочет деталей, а финансистам для принятия решений картинка нужна максимально убедительной. Поэтому было решено подготовить две дорожные карты.
Дорожная карта без подробностей с простой и понятной картиной релизов. Она выглядит привлекательно и убедительно для широкой аудитории, лишена лишней информации. Целевая аудитория этой карты: руководство и маркетинг – те, кто не хочет вникать в тонкости релиза. Только даты, цели, плановые затраты и предполагаемые клиенты. Никакой лишней информации.
Подробная дорожная карта, где по каждому релизу подробно расписано, что именно будет выполнено:
-
Развитие функционала (включая новые функции и сервисы),
-
Внедрение технологий,
-
Указаны результаты:
-
по ближайшим релизам с подробными деталями,
-
по далеким релизам – идеи, общее направление (блокчейн, автопилоты, цифровые двойники и т.п.) Мы понимаем, куда двигаемся, хотя размеры детализации разнятся с ближайшими релизами. Это важно, потому что мы не можем так же подробно планировать далекие релизы, как ближайшие.
-
Кейс №3. Дорожная карта на основе этапов проекта
Как сделать, чтобы работа не проваливалась в трещины?
Этот кейс уже не дорожная карта продукта, а дорожная карта проекта. Мне очень нравится в Project Management выражение «so that the work doesn't fall through the cracks» («работать нужно так, чтобы работа не провалилась в трещины»), которое отражает основную цель этой дорожной карты.
Мы структурировали ее по этапам проекта. И сразу стало понятно, как строить взаимодействие команд заказчика и команд исполнителя. Потому что есть много каких-то пограничных тем. Какая инфраструктура в какой момент будет нужна? Какие интеграции в какой момент должны быть готовы? Как проходят тестирования, какие требования к безопасности? Все вот эти моменты мы прописываем, уточняем, и просто по итогу создания дорожной карты выявляем.
Благодаря этому у нас получилось:
-
Сделать наглядным диалог Исполнителя с Заказчиком. Стало понятнее, что будет происходить, у всех стала общая картинка по сравнению с ситуацией, когда просто есть список задач, план-список.
-
Подсветить командам взаимосвязи между разными блоками работы.
-
Увидеть и добавить виды работ, которые были раньше забыты (как «само собой разумеющиеся»). Если бы их не прописали, не зафиксировали, не добавили в план, было бы совершенно неизвестно, были бы эти «само собой разумеющиеся работы» выполнены.
Кейс №4. Дорожная карта на основе стратегии
Как связать цели и действия?
Мы сначала понимаем цель, метрики (как идти к этим целям), потом задачи, которые необходимы для достижения, и только потом уже рисуем дорожную карту.
Перед вами пример, о котором написано в начале статьи – проект «Лагеря добровольных лесных пожарных», в котором:
-
Определены цели и метрики;
-
Расписаны действия для достижения целей и метрик в конкретном расписании;
-
Дорожная карта привязана к целям и метрикам.
Кейс №5. Дорожная карта 666
Общая перспектива
Дорожная карта 666 предлагает нам ответить на три вопроса:
-
Как мы видим продукт через 6 недель? Краткосрочное планирование.
-
Как мы видим продукт через 6 месяцев? Среднесрочное планирование.
-
Как мы видим продукт через 6 лет? Долгосрочное планирование.
К сожалению, нужно быть готовым к тому, что нарисованный продукт через 6 лет не будет реализован в том виде, как мы видим его сейчас. Буквально за год-два картина мира может измениться полностью, и наши ожидания оказываются устаревшими. Но ответ на этот вопрос очень важно знать для того, чтобы понимать, куда мы двигаемся. Конечно, вектор движения может измениться, но сегодня нам надо понимать, ради чего мы все это делаем.
Способы создания дорожных карт
Дорожные карты можно создавать по-разному:
-
В Task Manager с автоматическим отображением.
-
В графическом редакторе.
-
На листе бумаги.
Я сторонник ручного рисования дорожной карты, хотя при ручном рисовании зачастую выходит слишком много деталей, и она получается довольно сложной для понимания.
В чем преимущество «рисования на доске» / в графическом редакторе?
-
Не все трек-менеджеры позволяют самостоятельно делать дорожные карты.
-
Скорее всего, в «автоматической» карте будет слишком много деталей и уйдет наглядность.
-
Вам придется какие-то задачи/эпики добавлять только ради картинки (а потом удалять/переделывать), так как при самостоятельном планировании вы вынуждены делать лишнюю работу по добавлению придуманных задач, о которых у вас еще нет полной информации.
-
«Нарисованную» карту можно выстроить по любой логике.
-
Сама разработка дорожной карты может проходить в форме мозгового штурма. Процесс обсуждения дорожной карты в команде – это способ получить инсайты.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.
