Как согласовать дорожную карту корпоративных сервисов

Дорожная карта нужна для распределения бюджета, людей и определения очередности работ. По ней принимают ограничения и договариваются, когда план нужно пересмотреть.

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

На согласование под одним названием могут принести разные материалы. В итоге вместо очередности инициатив участники разбирают перечень задач одного проекта — и обсуждение уходит не туда.

Давайте разделять документы:

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

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

До календаря нужны исходные сведения.

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

Допущением считают условие, которое еще не подтвердили, но уже учли в плане.

Например:

Если назначенная дата прошла, а подтверждения нет, допущение превращается в проектный риск. Тогда у коллегиального органа перед глазами есть само условие, ответственный и дата следующей проверки.

Инициатива описывает отдельное изменение: кому оно требуется, какой результат нужен, что входит в границы и кто примет ценность результата. Задача заметно уже — это конкретная работа внутри инициативы.

«Настроить интеграцию» — задача. Создание сервиса для определенной аудитории с измеримым результатом и владельцем — инициатива.

Без этого различия трудно сравнивать предложения по пользе, считать затраты и распределять ответственность.

Для каждой инициативы я бы делал отдельную карточку.

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

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

Срок отвечает на вопрос «когда». Контрольная точка отвечает на другой вопрос: «какое решение нужно принять здесь и сейчас».

В такой точке руководители могут:

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

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

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

С интеграциями ситуация особенно неприятная. Если в дорожной карте для них оставили одну строку в конце, невозможно оценить последствия для запуска. А от готовности обмена данными нередко зависит дата запуска.

Перед утверждением полезно проверить пять вопросов:

Исходный код может быть готов, но без доступа к тестовым данным сервис не запустят. В такой ситуации дата запуска не подтверждена.

Ресурсы — это деньги и команда, доступные для утвержденных инициатив. Одна сумма на весь горизонт не дает проверить финансовый план, нехватку компетенций и последствия переноса отдельных этапов.

Бюджет оценивают после диагностики. При расчете учитывают:

Расчет разработки лучше не смешивать с расчетом запуска.

Ресурсы стоит разбирать и по инициативе целиком, и по контрольным этапам. Тогда видно, в какой момент потребуются специалисты конкретного профиля, финансирование или доступ к среде.

Выбор модели зависит от компетенций внутри организации и от распределения ответственности за архитектурные решения.

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

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

При выборе исполнителя для разработки корпоративных сервисов под ключ я бы смотрел на практические условия, а не на общие обещания:

От проработки технического задания зависит точность коммерческого предложения. Согласованные условия приемки позволяют контролировать бюджет.

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

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

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

По каждому решению стоит записывать:

Иначе через несколько недель сложно восстановить, что именно согласовали, на каких условиях и кто должен сделать следующий шаг.

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

Удобно использовать такие определения:

Для дорожной карты подойдет такой формат:

В реестре рисков нужны описание, вероятность, влияние, владелец риска, мера реагирования и дата следующей проверки.

Назначить владельца недостаточно. Этот человек следит за датой проверки, организует согласованные меры и передает вопрос на эскалацию, если меняется влияние риска.

Для корпоративного веб-сервиса в дорожной карте стоит предусмотреть:

На утверждение выносят риск, если он может изменить бюджет, сроки, ожидаемый результат или саму возможность запуска корпоративного сервиса.

Коллегиальный орган не должен впервые увидеть бюджет, зависимости или требования ИБ уже на заседании. До него бизнес, ИТ, финансы, ИБ и комплаенс разбирают рабочие вопросы и вносят замечания.

Процесс состоит из 5 этапов.

Перед заседанием владельцу дорожной карты стоит пройти список из 7 пунктов:

Вопрос по интеграции нельзя закрыть формальной визой накануне заседания. Если владелец смежной системы не подтвердил готовность, материалы вернут на доработку.

Руководству нужны единая версия дорожной карты, карточки инициатив, реестр рисков и реестр решений и замечаний. Этот пакет позволяет быстро проверить основания для выбора, последствия решений и условия исполнения дорожной карты.

Обязательное условие — единая версия документов.

К основному пакету стоит приложить короткую записку с перечнем решений для руководителей:

Тогда на заседании обсуждают управленческие решения, а не погружаются в подробности разработки.

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

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

Независимо от методологии понадобятся:

Для ведения задач можно использовать YouGile, Kaiten, Yandex Tracker, Weeek. Перечень не исчерпывающий: выбор зависит от решений, уже применяемых в организации, и требований внутренних регламентов.

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

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

Если регламент предусматривает письменное согласование, устного подтверждения владельцев функций недостаточно. Нужно сохранить решение, версию документа и сведения об отклонениях от процедуры.

Отдельно проверяют четыре условия:

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

Пересмотр требуется после изменения целей, ресурсов, сроков, зависимостей или рисков.

Плановую проверку проводят с периодичностью, указанной в решении об утверждении. Внеплановый пересмотр нужен при существенном изменении бюджета, критической зависимости, состава инициативы либо требований ИБ и комплаенса.

Порядок пересмотра выглядит так:

Затем публикуют новую версию и закрывают связанные замечания.

Не каждый перенос срока нужно выносить на коллегиальный орган. Но изменение утвержденного бюджета, приоритета или ожидаемого результата следует оформить управленческим решением по внутреннему регламенту организации.

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

За актуальность отвечает владелец дорожной карты. Владельцы сервисов подтверждают изменения целей, результатов и приоритетов своих инициатив.

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

Риск, способный изменить бюджет, сроки, ожидаемый результат или возможность запуска корпоративного сервиса.

Да. Для этого используют установленные триггеры, оценивают последствия и выпускают новую версию управленческого решения.

Утверждение дорожной карты — это решение о целях, очередности, ресурсах, рисках, зависимостях и ответственности, а не согласование презентации с датами.

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