Дорожную карту разработки утверждают в пять шагов: готовят версию документа, согласовывают данные с бизнесом, ИТ, финансами и ИБ, устраняют противоречия, выносят на коллегиальный орган и фиксируют решение с номером версии и датой пересмотра.
Дорожная карта разработки — это документ, который связывает инициативы по созданию корпоративных сервисов с ожидаемыми результатами, бюджетом, командой, контрольными этапами и зависимостями. Под корпоративным сервисом понимается цифровой сервис для сотрудников или клиентов организации. До начала работ руководство должно принять решение не только о перечне инициатив, но и о допустимых ограничениях: что делать, в какой последовательности, за какие средства и при каких условиях пересматривать план.
Что утверждается в дорожной карте разработки корпоративных сервисов
Дорожная карта разработки корпоративных сервисов фиксирует состав и последовательность инициатив, которые организация готова реализовать в заданном периоде планирования. Она не заменяет ни портфель инициатив, ни план отдельного проекта.
До утверждения дорожной карты необходимо зафиксировать:
- бизнес-цель каждой инициативы;
- ожидаемый результат и критерий его приемки;
- владельца сервиса и владельца дорожной карты;
- бюджет и состав команды по этапам;
- зависимости от систем, данных, инфраструктуры и поставщиков;
- контрольные точки, где требуется новое управленческое решение;
- риски и меры реагирования.
Утверждение дорожной карты — это управленческое согласование направления и ресурсов. Утверждение отдельного проекта — решение о запуске конкретной инициативы с детальным планом работ.
Какие данные собрать до подготовки дорожной карты
Для подготовки дорожной карты разработки нужны подтвержденные данные о целях бизнеса, текущем состоянии корпоративных сервисов, ограничениях и зависимостях.
Минимальный набор входных данных:
От качества исходных данных зависит точность оценки сроков и бюджета. От доступности владельца сервиса зависит скорость принятия решений по требованиям.
Допущения выносят в отдельный раздел. Например, готовность API смежной системы, когда бизнес выделит сотрудников для тестирования и организация получит инфраструктурные мощности. Если допущение не подтверждено, оно становится проектным риском.
Как сформировать состав инициатив и приоритетов
Состав инициатив формируют от бизнес-целей. Инициатива — это обособленный замысел с определенной целью, результатом, границами и владельцем сервиса. Задача — отдельная работа внутри инициативы.
Для каждой инициативы в дорожной карте разработки указывают цель, измеримый ожидаемый результат, состав работ, зависимости, ресурсы и критерии готовности контрольных этапов.
Приоритет инициативы целесообразно оценивать по четырем критериям:
- вклад в бизнес-цель;
- обязательность по регуляторным или внутренним требованиям;
- объем ресурсов;
- критичность зависимостей.
Ранжирования по экономическому эффекту недостаточно. Расчет верен только тогда, когда подтверждены доступность команды, готовность данных и состояние интеграций.
Контрольная точка — это точка принятия решения: продолжить работы, изменить границы инициативы, перенести этап или остановить финансирование. Срок и контрольная точка — не одно и то же. Срок фиксирует дату, а контрольная точка фиксирует решение.
Где возникает типичная ошибка
Типичная ошибка — ставить в план на один период инициативы, которые опираются на одну команду или одну интеграцию. Формально сроки не конфликтуют, но исполнитель у них общий. Пока он занят первой инициативой, вторая ждет, и любая задержка переносится дальше по цепочке.
Интеграции часто ставят последним этапом и описывают одной строкой. К моменту, когда до нее доходит очередь, выясняется, что смежная система не готова отдавать данные, а ее доработка требует отдельного бюджета и согласования. Сервис готов, а запустить его нельзя. Поэтому состав интеграций оценивают до расстановки приоритетов: от их сложности зависит и очередность инициатив, и реалистичность сроков.
Как подтвердить ресурсы и модель реализации
Ресурсы в дорожной карте разработки подтверждают по инициативам и контрольным этапам. Ресурсы — это бюджет и команда, доступные для реализации утвержденных инициатив. Общая сумма без разбивки по работам не позволяет оценить финансовый план, дефицит компетенций и последствия переноса этапов.
Бюджет определяют после диагностики, он зависит от состава работ, числа интеграций, требований ИБ и доступности команды. Важно разделять оценку разработки и оценку запуска.
Внутренняя команда и внешний подрядчик работают по-разному. Внутренняя команда сохраняет экспертизу в организации, но ее доступность ограничена текущими обязательствами. Внешний подрядчик может выделить команду с нужными навыками на согласованный срок, если таких специалистов или свободной загрузки нет внутри организации, однако требует прозрачного управления результатом, правами на код и передачей знаний.
При выборе внешнего подрядчика для разработки корпоративных сервисов под ключ оценивают опыт сопоставимых интеграций, состав выделяемой команды, практики ИБ, порядок тестирования, условия передачи исходного кода и документации, способность работать по контрольным этапам. От качества технического задания зависит точность коммерческого предложения. От условий приемки зависит управляемость бюджета.
Отдельно стоит проверить, кто именно будет вести проект, так как состав команды до контракта и на исполнении часто различается.
Роли и ответственность участников утверждения
Роли распределяют до заседания коллегиального органа: кто отвечает за содержание документа, кто за результат каждой инициативы, кто подтверждает бюджет, архитектуру и требования ИБ. Владелец дорожной карты, владелец сервиса и участник согласования выполняют разные функции.
Рабочая группа снимает противоречия по данным, срокам и составу работ. Коллегиальный орган принимает решения о приоритетах, бюджете и изменении ограничений. У каждого решения должен быть владелец, срок исполнения и ссылка на версию документа.
Как оценить риски до утверждения дорожной карты
Риск в дорожной карте разработки — это возможное событие, которое может изменить сроки, бюджет или ожидаемый результат. Риск отличается от проблемы тем, что проблема уже возникла и требует устранения. Зависимость описывает внешнее условие. Ограничение задает допустимую границу по ресурсам, срокам или технологиям.
Реестр рисков должен содержать описание риска, вероятность, влияние, владельца риска, меру реагирования и дату следующей проверки. Для каждого риска назначают владельца, который контролирует срок следующей проверки, выполняет меры реагирования и выносит риск на эскалацию при изменении его влияния.
Риски при разработке корпоративного веб-сервиса снижают четырьмя мерами: разделяют работы на контрольные этапы, проверяют интеграции и требования ИБ до основной разработки, закрепляют условия передачи результатов от внешнего подрядчика и регулярно обновляют реестр рисков.
Критическим ограничением нередко оказывается не код, а доступ к тестовым данным: именно от него зависит дата запуска.
Как организовать утверждение дорожной карты
Утверждение дорожной карты разработки проходит в несколько этапов: подготовка версии, рабочая проверка, коллегиальное рассмотрение, фиксация решения и публикация утвержденной версии. Решение не стоит принимать на встрече, где участники впервые видят бюджет или зависимости.
Мини-алгоритм для владельца дорожной карты:
- Проверить, что у каждой инициативы есть владелец сервиса.
- Сверить бюджет с финансовым циклом организации.
- Подтвердить ресурсную модель по каждому этапу.
- Вынести зависимости и допущения отдельным списком.
- Назначить владельцев рисков.
- Подготовить реестр замечаний до заседания.
- Зафиксировать итоговое решение с номером версии и датой пересмотра.
Если решения по интеграциям не приняты заранее, заседание их не заменит. На вопрос о готовности смежных систем ответить будет нечем, и документ вернется на доработку.
Комплект документов для утверждения дорожной карты
Комплект документов должен позволить руководству проверить основания, последствия и условия исполнения дорожной карты разработки без поиска данных по разным файлам. Единая версия — обязательное условие.
Для рассмотрения руководством также готовят краткую записку с перечнем решений, которые требуется принять: утвердить состав инициатив, подтвердить бюджет, принять ресурсные ограничения, согласовать критические зависимости и установить порядок пересмотра.
Какие методологии и инструменты использовать
Методологию управления выбирают по предсказуемости требований, числу зависимостей, доступности владельцев сервисов и требованиям к отчетности. Для инициатив с фиксированным результатом и большим числом согласований подходит этапное управление; для сервисов с изменяющимися требованиями — итерационный подход с контрольными точками дорожной карты.
Нужные артефакты управления:
- список работ по инициативе;
- план контрольных этапов;
- реестр зависимостей;
- реестр рисков;
- реестр решений и замечаний;
- отчет о статусе по срокам, бюджету и результатам.
Для ведения задач применяют системы управления задачами: YouGile, Kaiten, Yandex Tracker, Weeek. Список не полный: выбор зависит от того, что уже используется в компании и какие требования заданы внутренними регламентами. Инструмент не заменяет дисциплину управления. От единого источника актуальной версии зависит, по каким данным принимаются решения.
Особенности утверждения в российских крупных компаниях
В крупной российской организации дорожную карту разработки утверждают с учетом внутренних регламентов, бюджетного цикла и полномочий коллегиальных органов. Устного подтверждения владельцев функций недостаточно. Если внутренний регламент организации требует письменного согласования, необходимо фиксировать решение, версию документа и отклонения от процедуры.
Проверке подлежат четыре условия:
- дорожная карта включена в действующий бюджетный цикл;
- бизнес-функции, ИТ и цифровой блок согласовали приоритеты;
- финансовая функция подтвердила источники расходов;
- коллегиальный орган определил, какие решения относятся к его полномочиям.
Если сроки инициативы не совпадают с бюджетным циклом, это необходимо отразить как ограничение или допущение. Если внутренний регламент требует дополнительного согласования, отклонение фиксируют в реестре решений с владельцем и сроком.
Как пересматривать утвержденную дорожную карту
Пересмотр дорожной карты — это обновление дорожной карты после изменения целей, ресурсов, сроков, зависимостей или рисков. Плановый пересмотр проводят с периодичностью, закрепленной в решении об утверждении. Внеплановый пересмотр нужен при существенном изменении бюджета, критической зависимости, состава инициативы или требований ИБ и комплаенса.
Порядок пересмотра включает четыре фактора:
- инициатор описывает изменение;
- владелец дорожной карты оценивает последствия;
- владельцы сервисов и функций подтверждают корректировки;
- коллегиальный орган принимает решение при изменении приоритетов или ресурсов.
Затем публикуют новую версию и закрывают связанные замечания.
Перенос сроков внутри инициативы владелец дорожной карты фиксирует в реестре решений. Изменение утвержденного бюджета, приоритета или ожидаемого результата выносят на коллегиальный орган.
Частые вопросы
Нужно ли утверждать детальный план работ по каждой инициативе?
Нет. Дорожная карта разработки утверждает цели, приоритеты, ресурсы, этапы и ограничения. Детальный план работ утверждают отдельно, если этого требует внутренний регламент.
Кто отвечает за актуальность дорожной карты разработки?
За актуальность отвечает владелец дорожной карты. Владельцы сервисов подтверждают изменения целей, результатов и приоритетов своих инициатив.
Когда нужен внешний подрядчик?
Внешний подрядчик может быть уместен, если внутренней команде не хватает доступной загрузки или нужных компетенций и организация готова определить порядок приемки, передачи кода и знаний.
Какой риск обязательно выносить на утверждение?
На утверждение выносят риск, который может изменить бюджет, сроки, ожидаемый результат или возможность запуска корпоративного сервиса.
Можно ли менять дорожную карту после утверждения?
Можно. Пересмотр дорожной карты проводят по установленным триггерам, с оценкой последствий и фиксацией новой версии управленческого решения.