Опыт использования документа Roadmap

(Из ленты Курсы бизнес анализа, тренинги и обучение бизнес аналитике| ArtofBA)

Вступление

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

Почему я считаю, что этот документ так полезен, и стоит о нем рассказать в отдельной статье? Отвечу так: если вы сталкивались с такими проблемами как:

  • сложно найти ответ на вопрос “почему мы так сильно вылезли из бюджета” или “так когда же таки релиз”;
  • идеи, требования на будущее “затерялись” в backlog;
  • нет артефакта/документа, который был одинаково удобен как для деливери команды, так и для бизнеса в плане статуса разработки проекта;

то скорее всего, такой артефакт как Roadmap может оказаться для вас полезным.

Сначала пару слов о себе: мой опыт работы бизнес-аналитиком довольно скромный — 3,5 года. Довелось поработать на проектах разного масштаба: от небольших (до года разработки) до больших enterprise-проектов. Домен проектов был самый разный: ERP, Healthcare, Restaurant Back Office Management, Fintech. Даже с blockchain довелось поработать. Везде понемногу.

Итак, к делу. Для начала опишу, как данный артефакт использовался на моих проектах:

  • Фаза активной разработки, я присоединился на проект спустя более года с его начала. Документ поддерживался и создавался командой бизнес-аналитиков и менеджером продукта, которые были на проекте с самого начала;
  • Далее я решил попробовать использовать этот документ уже на своем проекте, где я был единственным бизнес-аналитиком. Проект разрабатывался с нуля (start-up).

В обоих случаях Roadmap документ приносил свою пользу. Давайте разберемся почему.

*Детали в примерах документов приведенных ниже замазаны по причине NDA

Структура Roadmap документа

Стоит отметить, что документ не похож на классическое представления о roadmap документе. Под “классических представлением” я понимаю что-то типо этого:

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

Разберемся в структуре подробнее:

  1. Feature — имя фичи/страницы/функции/эпика и тд (в зависимости от типа вашей декомпозиции). Я не использовал формат user story здесь, т.к. здесь задача дать максимально емкое название, чтобы адекватно смотрелось в таблице.
  2. Description — краткое описание, о чем этот item. Если это не очевидно из названия, я кратко описывал scope задачи, что предполагается сделать в рамках этого item-a.
  3. Jira reference — ссылка на задачу в Jira, для удобства. Чтобы узнать больше деталей, посмотреть зависимости и т.д.
  4. Type — тип item-a в таблице. Использовались следующие значения:
    1. Epic — эпик (master-story), часть большого функционала, который может быть разбит на несколько user story/задач;
    2. User story — комментарии излишни, думаю всем известно что такое user story. Добавлю лишь что в данном контексте user story не делилась дальше на еще более мелкие задачи, т.е. более глубокие иерархические блоки;
    3. Change Request — этот тип отображал change requests, которые появлялись в ходе разработки. Зачем использовался такой тип я расскажу далее;
    4. Task — этот тип использовался для отображения таких задач как Spike, POC (Proof of Concept) и т.д. Т.е. в рамках задач этого типа мы не разрабатывали что-то новое, а проверяли гипотезы, теории, и тд и тп. Sub-tasks, на которые были декомпозированы задачи разработчиками на Roadmap не отображались.
  5. Status — это статус задачи. Мы выделяли такие статусы задач:
    1. Discovery — т.е. задача находится в работе у аналитика/дизайнера, иными словами находится на этапе обсуждения/проектирования.
    2. Designed — задача получает этот статус после того, как аналитик/дизайнер закончили описывать требования и работу над mockups/designs. В этом статусе задача ждет Refinement Session с командой, где бизнес аналитик или любой другой ответственный член команды представят её команде, расскажут детали и логику.
    3. Refined — после того, как задача была обсуждена на Refinement Session, задача переводится в состояние Refined. Что дает понять, что эта задача готова к оценке на Estimation Session (да, на моих проектах это были две разные сессии).
    4. Ready — задача в этом статусе готова к разработке и соответствует критериям Definition of Ready.
    5. In progress — в этот статус задача переводилась когда попадала в Sprint Backlog.
    6. Done — задача в этом статусе готова, и соответствует критериям Definition of Done.
  6. Estimate — в этой колонке отображается оценка user story/task (в часах, sp, t-shirt — не так важно);
  7. Sprint # — здесь мы отображаем когда (в каком спринте) задача планируется в работу или когда уже была сделана.
  8. Comment — комментарий о задаче. Мы здесь обычно указывали краткое описание задачи (1-2 предложения, если недостаточно деталей в Description), мелкие детали по типу кто будет эту задачу делать/тестировать, какие-либо зависимости и тд.

Группировка

Задачи в Roadmap документе группируются по следующим параметрам:

  • Milestone — это веха проекта, объединяет в себе список эпиков которые должны быть реализованы в рамках этой вехи. Имеет такие атрибуты как Delivery Date, который отображает, когда веха ожидается быть завершенной.;
  • Epic — epic объединяет в себе список user stories/tasks.

Как работать с Roadmap

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

Начало

Немного контекста для начала: перед стартом проекта была проведена небольшая фаза выяснения требований (discovery phase), в ходе которой были прояснены верхнеуровневые требования, и описан just enough объем задач, чтобы сформировать sprint backlog.

На этом этапе, наш Roadmap напоминал просто список milestones, epics и задач для первых спринтов.

Также остальные epics перед стартом проекта были оценены в t-shirt sizing, чтобы дать заказчику примерное понимания сроков и бюджета проекта.

По мере приближения к началу разработки и по мере появления новых деталей, Epic декомпозировался на более мелкие задачи, user stories. Добавлялись spikes, POC задачи, если потребуются. В колонки ‘Sprint #’ проставлялись даты, когда ожидается задачу взять в работу.

Было бы неплохо проставлять delivery date напротив каждого milestone, чтобы понимать примерную дату завершения, но увы, до этого руки не дошли.

Фаза активной разработки

Во время активной фазы разработки этот документ тоже оказался полезен. Документ помогал давать ответы на ряд насущных вопросов. Каких? Читаем дальше.

Планы на будущее

Также начнем с предисловия: capacity и velocity бизнес аналитиков на проекте позволял обгонять ход разработки в плане подготовки задач на 4-5 спринтов вперед. Помимо этого, заинтересованные лица со стороны заказчика оставляли свои фидбеки после демо, идеи для улучшений. И зачастую, все эти вещи имели зависимости с функционалом, который уже готов/разрабатывается. Чем раньше брать эти зависимости во внимание на этапе разработки, тем дешевле/проще будут изменения потом.

Для этого в документе добавлялся отдельный milestone ‘For future’ для идей на будущее, в рамках каждого milestone был epic ‘Feedback/improvements’ где находились фидбеки/идеи для улучшений. Это порой оказывалось очень полезным для разработчиков, так как всегда был виден вектор того, куда мы движемся, с чем предстоит работать и какое влияние это может оказать на текущее состояние системы.

Мы просили разработчиков “поглядывать” в документ время от времени, чтобы быть в курсе наших планов. Открытые вопросы могли выноситься на отдельный meeting, где мы обсуждали непонятные моменты.

Ну когда уже релиз?

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

Разберем это на примере:

  • Проект идет уже месяцев 5-7, мы находимся посредине milestone N, в котором у нас есть 5 epic-ов;
  • Каждый из них оценен в размер M (t-shirt sizing);
  • Задачи в рамках 3 epic-ов уже обсуждены с командой и оценены;
  • Мы занимаемся задачами из эпика 1.

На основе этих данных мы можем понять следующее:

  • На основании оценок задач из первых 3 epic-ов можем понять через сколько спринтов мы сделаем весь объем задач;
  • На основании исторических данных мы можем предположить сколько примерно у нас занимает разработка epic-а с оценкой M.

Таким образом, заказчик имея доступ ко всем этим данным может сам понять сколько остается до завершения того или иного milestone/epic/feature, и на сколько реальны обещанные сроки.

Почему не успеваете?

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

На начальном этапе проекта, epics оценивались в T-shirt sizing, давая заказчику примерную, верхнеуровневую оценку. В ходе разработки добавляются фидбеки, которые имеют высокий приоритет и не могут быть отложены на будущее, улучшения, которые нужно сделать срочно и тд. Бесспорно, все эти вещи сдвигают оценку и таймлайны в большую сторону.

Но, имея все эти запросы зафиксированными в документе с соответствующим статусом (change request), заказчику гораздо проще объяснить почему мы не успеваем или можем не успеть если возьмем item в работу.

Так это backlog, разве нет?

По итогу может возникнуть логичный вопрос: так вы ж просто backlog в табличку перенесли, в чем разница? Да, сходство определенно есть, но можно выделить следующие различия:

  1. Приоритеты не отображены на Roadmap. Как нам всем известно, Backlog — это приоритезированный список product backlog items. Да, очень верхнеуровневый порядок есть, но он не меняется/меняется слабо в ходе разработки.
  2. Roadmap не содержит багов и subtasks.

Имея ввиду различия выше, я назвал бы этот документ миксом backlog и roadmap, но от этого документ не становится менее полезным.

Минусы

Несомненно, документ не решение всех проблем. Есть ряд недостатков, которые тоже следует брать во внимание:

  1. Поддержка документа — работая с этим документом не достаточно просто создать задачу в Jira (или любом другом таск-трекере). Нужно добавить её на Roadmap, заполнить соответствующие атрибуты. Та же ситуация, при каких-то изменениях (поменялся статус задачи, target sprint, estimate, и т.д);
  2. Ложная картина — важно объяснить заинтересованным лицам, что этот документ дает верхнеуровневую картину, и на основании этих данных мы не сможем сделать выводы о velocity команды или её capacity. Для этого, все таки, лучше обратиться к Jira или любому другому task-tracker;
  3. Понимание назначения документа командой — важно донести команде, что главный источник задач — backlog и только он. Roadmap это что-то, что нужно чтобы понять состояние проекта, не более.

Эпилог

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

Отдельно хочу поблагодарить менеджера продукта Тараса и бизнес-аналитика Алексея, которые когда-то и открыли для меня этот документ и научили им пользоваться.

Буду рад услышать ваши мнения и ответить на вопросы.

Всех благ и успехов на нашем нелегком поприще.

Расписание тренингов от Art of Business Analysis
Новости и статьи по бизнес-анализу — https://t.me/artofba

Источник: Опыт использования документа Roadmap