Руководитель продуктового маркетинга Divan.ru Андрей Логинов рассказывает, как использовать roadmap в работе.
26 января 2022
Roadmap: зачем дорожная карта руководителю и как ее построить
Roadmap: зачем дорожная карта руководителю и как ее построить
Дорожная карта проекта, или roadmap, помогает руководителю контролировать выполнение проекта. Любой проект можно наложить на карту: запуск сайта, пиар-кампании, перевод отдела на новый режим работы или процесс онбординга. Так легче не сбиться с маршрута.
Андрей Логинов, руководитель продуктового маркетинга Divan.ru, рассказывает, как использовать дорожную карту в работе и почему основная задача roadmap — помогать с адаптивным планированием, а не строго следовать плану, который составлен в начале проекта. Всё — на реальном примере проекта по редизайну интернет-магазина, который был рассчитан более чем на полгода. Первое, что сделала команда на старте, — составила дорожную карту.
Зачем roadmap руководителю
Roadmap проекта помогает:
- определить общий состав работ — что именно нужно сделать;
- оценить трудоемкость — сколько времени и усилий займет та или иная задача;
- спланировать порядок работы в соответствии с задачами бизнеса — когда ждать релиза частей и всего проекта целиком;
- защитить идею перед коллегами, другими руководителями, командой — показать пошагово, как будет выполняться план;
- контролировать работу над проектом — идет ли все по плану или происходят отклонения.
Roadmap нужен для того, чтобы контролировать прогресс работы на каждом этапе до релиза проекта. У руководителя есть цель, дата запуска, шаги, которые к этой цели приведут. Если следить за этапами, можно вовремя заметить, когда что-то идет не по плану, и немного скорректировать маршрут.
Roadmap — это карта, план работ.
Идти без карты — значит делать все подряд. Думаю, так никто не работает — в том или ином виде план существует у всех. Вопрос в том, насколько он декомпозируется и детализируется для оценки сроков или строится пальцем в небо.
Как составить roadmap проекта за пять шагов
1. Определить задачи
По сути roadmap состоит из списка задач, наложенных на таймлайн и распределенных по исполнителям. А значит, для его составления руководителю нужно хорошо знать, сколько времени и кто именно будет работать над задачами. Чем понятнее, что и как работает, тем подробнее будет дорожная карта.
Сложно построить карту без понимания процесса работы над задачей. Если вы не понимаете, какой ресурс и каких специалистов нужно привлечь для решения задачи, в какую сторону смотреть, что учесть, — не получится составить нормальный roadmap. И придется срочно искать людей, которые могут сделать какие-то непредусмотренные работы.
Если в целом вы понимаете, какой список задач придется решить, проблем не будет.
В нашем примере у Divan.ru была четкая цель — редизайн сайта. У проекта был утвержденный срок и понятные задачи: разработка новой айдентики и дизайна, работа с веб-командой.
2. Декомпозировать задачи на этапы
Первым делом менеджеры проекта делят работу на ключевые направления.
Roadmap — декомпозиция проекта или задачи на основные направления работ и этапы.
Этапы бывают зависимые и независимые. Независимые могут исполняться параллельно разными подразделениями. Зависимые влияют на сдачу проекта: если сдвигается предыдущий этап, сдвинется весь срок.
В случае Divan.ru было два основных направления работ: дизайн и разработка. Они зависят друг от друга: без нарисованного макета не получится начать верстать сайт. Когда первые макеты сданы, зависимые процессы дизайна и разработки становятся независимыми — процессы можно выполнять параллельно. Фронтенд-разработчики работают с принятыми макетами, а дизайнеры рисуют остальные. Постепенно дизайнеры завершают свои работы и переходят в режим операционной поддержки веб-разработчиков: остаются на подхвате, если будут изменения в продукте или где-то на макете не хватит деталей.
3. Описать этапы проекта
Когда основные этапы понятны, их нужно описать. Причем описать стоит каждую деталь. На примере редизайна сайта: попапы, выпадающие пункты меню, юридические документы в подвале, страницы ошибок — все, с чем придется работать. Список, который получится, — это набросок дорожной карты, его нужно приоритизировать и положить на таймлайн.
Когда мы описывали дорожную карту проекта, то представляли весь спектр задач, с которым придется работать. Все, что осталось с ними сделать, — расставить приоритеты и запланировать работу по этапам.
4. Оценить трудоемкость и приоритизировать задачи
На этом этапе начинается командная работа.
Если руководитель сам назначает временны́е рамки, появляется вероятность, что исполнители в них не уложатся. Например, руководитель думает: «Тут всего один попап надо прописать, делов-то на 10 минут», а редактор знает, что над коротким форматом ему придется работать дольше, чем над длинным. Со стороны кажется, что отрисовать кнопку или написать заголовок — ерунда, но без исполнителя оценить, сколько это на самом деле займет времени, невозможно.
Для более корректной оценки времени реализации всего проекта нужно каждую задачу обсудить с исполнителем. Это основа планирования и тот этап, где мы договариваемся с командами о сроках. После этого можно планировать финальный срок сдачи всего проекта.
Divan.ru оценивали трудоемкость задач в таблице: отдельно для дизайнеров и разработчиков. А потом к финальному результату добавляли еще 30% времени на доработки. Потому что во многих проектах дизайн и верстка не принимаются сразу — в лучшем случае нужно три цикла доработок, в худшем — до десяти. Это влияет на срок работы над задачей.
Фрагмент карты Divan.ru на этапе оценки трудоемкости задач
Кроме этого, всегда есть вероятность внештатных ситуаций — разработчик заболеет, а дизайнер будет вынужден оставаться допоздна и к середине проекта выгорит. В таком случае срок запуска будет постоянно сдвигаться, а состояние команды будет подавленным и проекту это никак не поможет. Таких ситуаций можно избежать, если заложить время на происшествия, которые никто не может контролировать.
5. Составить roadmap
Для составления дорожной карты подходят Miro, Notion, диаграммы Ганта, а можно выстроить весь процесс в Google Документах и Google Таблицах. Так сделали в Divan.ru: весь операционный процесс проекта строится в трех таблицах.
Плюсы Google Таблиц — быстро и не нужен специальный софт. Минусы — не самая удобная визуализация, нет автоматизированного контроля связей между зависимыми этапами работ. Хотя в нашем случае хватает 30–60 минут в неделю для того, чтобы спланировать спринт и пересобрать весь предстоящий период до сдачи проекта, если происходят какие-либо отклонения от плана.
6. Работать с roadmap
В начале проекта команды Divan.ru взаимодействовали с roadmap по очереди, а в какой-то момент работы начали вести параллельно. По мере того как дизайнеры завершали свои этапы, к работе приступали разработчики. Если упрощать, то как только появляется первый согласованный макет, фронтенд-разработчики уже могут начинать работы. Бэкенд-задачи могут решаться параллельно с дизайном, потому что совсем от них не зависят.
Команда дизайнеров работала по шагам: от проекта дизайна до его приемки. Статус отмечали в таблице, это позволило отслеживать общий прогресс и скорость выполнения задачи.
Чтобы контролировать прогресс по проекту, на базе карты сделали модель расчета процента выполнения плана. Еженедельно обновляли статусы по задачам, прогресс автоматически рассчитывался в Google Документе.
Например, прогресс задач по дизайну отслеживался в реальном времени — исполнитель «закрывает» задачу и общий прогресс обновляется:
Фрагмент roadmap с автоматически рассчитанным прогрессом
Второе направление — веб-разработка. Команда разработки работает спринтами и поэтому задачи тоже разбиты на спринты: одна неделя — один набор задач. Набор, в свою очередь, разбит на две категории: страницы, которые стоят в плане работ на текущий спринт, и страницы, которые пришли с доработок. Если что-то не успевают сдать в срок, пересматривают все остальные спринты — и сроки в roadmap сдвигаются. Дорожная карта разработчиков:
Задачи разбиты на два списка: новые на неделю и предыдущие на доработку. Таблица включает задачи на все спринты до дедлайна
Как корректировать маршрут, если команда отклоняется от плана
Roadmap — помощник руководителя. Кажется, что если внедрить его в работу команды и использовать при запуске проекта, то все само сложится, исполнители будут четко идти по этапам и задачи будут всегда сдаваться в срок.
Но это в идеальном мире. В реальности проект чаще всего отклоняется от плана: тут неверно заложили время, тут задача оказалась слишком сложной и нужно привлекать внешних специалистов, здесь дизайнер решил поменять всю арт-концепцию. Это нормально, и не значит, что затея с дорожной картой провалилась. Просто маршрут нужно пересмотреть.
Задача руководителя — вовремя скорректировать действия команды, чтобы не потерять слишком много времени на доработках. И здесь на помощь приходит еженедельная синхронизация.
Мы каждую неделю сверяем план с фактом.
Иногда отстаем, например, из-за того, что неправильно определили трудоемкость, выпал участник команды, на задачу ушло больше времени, чем планировалось. В таких случаях в первую очередь инициируем обсуждение решений, которые позволят не выбиться из графика: привлекаем команду со стороны или исключаем необязательные доработки, например. Если это не помогает, начинаем пересобирать план на весь оставшийся период. Так мы понимаем, на какой именно срок сдвигаемся. Опоздания будут всегда, но здорово узнавать о них за несколько месяцев, а не за неделю. Для этого и нужен roadmap.
Формат синхронизации руководителя и исполнителей может быть любым — раз в неделю, в две недели, в месяц. Зависит от проекта и от того, как удобно команде. Divan.ru проводит одну встречу в неделю с командой разработки, на которой обсуждается все — выполненные задачи, задачи, которые были запланированы в roadmap и не сделаны, и перераспределяются приоритеты.
Например, если для выполнения задачи привлекли внешнюю команду разработки и погружали ее в контекст дольше, чем планировалось, срок сдачи проекта сдвигается. При еженедельной синхронизации об этом становится известно заранее. А значит, можно:
- перенести часть задач на будущее или и вовсе сложить их в бэклог;
- заранее обсудить изменение срока со стейкхолдерами — со всеми, кто так или иначе вовлечен в проект и на кого изменение сроков повлияет напрямую;
- скорректировать список задач на предстоящие недели.
План в roadmap — не статичная картинка, а живая история. И если недельный план не выполняется, мы пересобираем весь оставшийся период вплоть до того, что часть текущих работ переходит на будущее. Этот этап общекомандный, потому что команда лучше оценит срок выполнения задачи, чем руководитель. Но кроме этого, когда переносится задача, полезно обсудить, почему это произошло. Разобраться, с чем столкнулись и как избежать этого в будущем.
