ЕПЦП_Роли_и_процесс_порядок_работ_2026

1.

Управленческая структура проекта ЕПЦП
Суды (Функциональные Заказчики)
Рабочая группа
«Фронт-офис»
Качаев Д. – общее управление Продуктом, п. 1, п. 5
Арх. комитет – п. 2, п. 4
Проектный комитет – п. 3, п. 6
Продукт «Цифровое Правосудие» (Генеральный Заказчик)
Планирование и контроль проектной деятельности, методологическая и административная поддержка, портфельное управление, управление отдельными кросс-функциональными проектами и программами
1. «Аккаунтинг»
(«единое окно» работы с ФЗ)
2. Проектирование
целевого ландшафта
3. Управление объемом работ
(портфелями проектов)
4. Внедрение и контроль
методологии работы по
разработке
Архитектурный комитет
«Бэк-офис» (Проектно - производственное подразделение)
5. Центр компетенций
(стык технологий и судебного
делопроизводства)
6. Обеспечение
контрактной и договорной
работы
Проектный комитет
Барышев М. – ответственный за создание Платформы ЕПЦП, п.2, п.3
«Электронная Москва» (Генеральный подрядчик)
Левов И. – п. 1, п. 2
Крылов Д. – п. 2, п. 3
АНО ЦТ
Проектно-производственное подразделение, отвечающее за организацию и исполнение работ по атомарным проектам. При отсутствии готовой подрядной команды – организация привлечения ресурсов подрядных
организаций. Обеспечивает развитие и эксплуатация текущих решений, создание новых продуктов
1. Управление проектами и экономика (распределение
задач и управление работами, расчет и защита расходов)
2. Управление ресурсными корзинами
(РП, аналитики, разработчики, др.)
Субподрядчики
3. Обеспечение архитектурно-технического единства
(формирование и контроль за исполнением архитектурных и
технических требований)

2.

Роли в ЕПЦП
Ответственный за создание Плафтормы ЕПЦП
Цель – создание единого центра координации работ в условиях сжатых сроков
1. Стратегическое управление платформой
Формирование видения и дорожной карты развития платформы с целью реализации бизнес-требований ФЗ;
Определение приоритетов эволюции архитектуры и технологий;
2. Управление жизненным циклом работ по Платформе
Формирование решений о создании, модернизации или выводе из эксплуатации компонентов;
Координация обновлений, миграции и интеграции с другими системами;
3. Согласование потребностей пользователей с возможностями платформы
Взаимодействие с функциональным заказчиком;
Обеспечение баланса между скоростью доставки функций и техническим качеством в соответствии с
требованиями ТЗ;
4. Координация кросс-функциональных команд (решение спорных ситуаций). Модерация1 работы
архитектурного и проектного комитета
5. Управление техническими рисками и реализацией компонентов (сервисов) Платформы в соответствии с
заявленными сроками
1 Модерация - процесс управления групповым обсуждением и/или проверки результатов/работы участников на соответствие установленным правилам, целям и регламентам. Владелец Продукта утверждает (или отклоняет) те или иные решения.
Формулирование (подготовку) решений, согласование этих решений, вынесение их на утверждение Владельца Продукта - ответсвенный за ЕПЦП

3.

Роли в ЕПЦП
Архитектор
• обеспечивает техническую реализуемость бизнес-требований и обозначает тех. ограничения;
• отвечает за техническое лидирование работ по сервисам Платформы;
• через анализ бизнес-требований и ожиданий функционального заказчика формирует тех. стратегию,
проектирует и отвечает за страт. построение программного решения, выбор тех. стека и
инструментов достижения бизнес-целей;
• обеспечивает единство технических решений.
Руководитель проекта (РП)
• отвечает за планирование и запуск проекта (формирование паспорта проекта, целей и критериев
успеха);
• формирует план-график работ, бюджет и ресурсное обеспечение;
• координирует работу участников проекта (управление командой и коммуникациями);
• контролирует исполнение, выявляет отклонения от плана и принимает корректирующие меры;
• управляет рисками и проблемами в проекте;
• контролирует соответствие результатов заявленным требованиям. Организует приемку работ;
• отвечает за эффективное использование выделенного бюджета и ресурсов. Согласовывает доп.
расходы при необходимости;

4.

Роли в ЕПЦП
Бизнес аналитик
• Сбор, формализация и документирование бизнес-требований Функционального заказчика;
• Формирование бизнес-требований на основании анализа существующих процессов;
• Проактивное формирование требований в связи с изменениями в законодательстве
Системный аналитик (СА)
• формирует функциональные и нефункциональные требования на основании бизнес потребностей.
• обеспечивает покрытие проблемных ситуаций Пользователя системными требованиями для
дальнейшей реализации
• отвечает за создание и проверку технической (отчетной) документации в соответствии с ГК/ТЗ
Методолог (МТ)
• обеспечивает согласованность бизнес требований с действующим законодательством, по
необходимости – формирует проекты изменений законодательства
• Осуществляет мониторинг изменений законодательства для их своевременного отражения в рамках
Платформы

5.

АК и ПК
Архитектурный комитет (сокращенно - АК):
АК – место обсуждения и утверждения тех. решений между командами Продукта;
формирует архитектурное видение платформы как единой системы;
ведет дорожную карту создания ЕПЦП на 12 месяцев вперед;
управляет требованиями, отвечает за выбор и согласование решений при создании/ развитии ЕПЦП;
Формирует единые технические требования для внешних команд.
Проектный комитет
ПК – обязательный шаг для инициации работ по любому Сервису;
ПК – место для мониторинга и принятия решений по проекту;
ПК управляет портфелем сервисов (Релизом) как единым активом: цели, ресурсы, сроки, риски;
Утверждает квартальные релизные планы (в т.ч. на основании потребностей Заказчика), команду реализации
и изменения;
Обеспечивает исполнение требований ГК в полном объеме в установленные сроки (в т.ч. осуществляет
мониторинг и управление рисками в части деятельности всех команд Платформы, влияющих на исполнение ГК)
координирует взаимодействие участников проектной деятельности, связанную с принятием необходимых
решений на соответствующем уровне управления;
контролирует исполнения принятых решений, а также принятие мер при их неисполнении

6. Общий процесс

6

7. Зона ответственности АО «Электронная Москва»

1. Идея о реализации сервиса/группы сервисов
упаковывается РП в формат Паспорта и выносится
на Проектный комитет
2. Проектный комитет с участием Владельца
продукта согласовывает концепт проекта
3. Бизнес анализ формирует бизнес-требования в
формате пользовательских историй
4. На основании бизнес-требований дизайнерами
формируется прототип (при необходимости)
5. Архитекторы на основании БТ формируют
архитектурные требования, ограничения и
спецификацию
5.1 На основании бизнес-требований и
архитектурного решения системным анализом и
архитекторами формируются ФТ/НФТ
6. РП формирует паспорт проекта, техническое
задание, расчет НМЦК и выносит на ПК
7. ПК утверждает комплект документов для
передачи исполнителю
7

8. Зона ответственности Подрядчика

8. На основании ТЗ Подрядчик проводит целевое
макетирование (при необходимости) и
проектирование
9. По итогам проектирования Подрядчик
осуществляет разработку Сервиса/группы
Сервисов
10. Разработанная функциональность тестируется
силами Подрядчика
11. Подрядчик формирует комплект отчетной
документации по Сервису/группе Сервисов и
сообщает о готовности к проведению
приемочных испытаний
Итогом работ по Сервису/группе Сервисов
являются приемочные испытания с участием
представителей Подрядчика и приемочной
комиссии АО «Электронная Москва»
Контроль работы Подрядчика осуществляется ПАУ с привлечением специалистов иных структурных
подразделений (при необходимости) в формате регулярных статусов/демонстраций
8

9. Порядок работ

№
Задача
Исполните
ль
Содержание шага
Артефакт
1
Формирование паспорта
сервиса
РП
2
Формирование бизнестребований
БА
РП по результатам заседания ПК формирует паспорт проекта, отражающий его. В паспорт входит:
– план работ (который формирует РП и архитектор). План работ представляет собой перечень задач (по чек-листу) в Jira со сроками в рамках релиза и ответственными
– и другие артефакты (см. шаблон паспорта проекта)
БА формируют бизнес-требования к Сервису в формате пользовательских историй в соответствии с шаблоном:
Все БТ к сервисам ЕПЦП заносятся в ЦМ ЕПЦП.
3
Формирование
проволочного макета
Д
Дизайнер с участием БА формируют проволочный макет, отражающий карту экранов сервиса (wireframe). Проволочный макет не должен быть идентичен разрабатываемой странице, он должен
отражать набор и положение компонентов в схематичном формате. Для формирования проволочного макета может быть использован любой редактор: Figma, draw.io, PlantUML, MS Visio и др.
4
Разработка архитектурного
решения (формирование
видения сервиса)
5
Согласование
архитектурного решения
АК
Архитектурное решение по разрабатываемому сервису выносится на обсуждение и утверждение Архитектурным комитетом
6
Формирование системных
требований
СА
На основании утвержденной АК спецификации к сервису и БТ СА формируют функциональные и нефункциональные требования к сервису.
Функциональные требования должны быть оформлены в формате, позволяющем их оценить по методике 3-р (т.е. xlsx файл с указанием сложности функции обработки информации)
7
ТЗ на создание сервиса
ТП
На основании системных требований, спецификации, проволочного макета и БТ техническими писателями формируется ТЗ на реализацию сервиса.
Комплект документов включает в себя расчет НМЦК, позволяющий оценить стоимость реализации сервиса в соответствии с методикой 3-р
8
Согласование с ФЗ/РГ
ОЕ
ТЗ, согласуется с Функциональным заказчиком и/или Рабочей группой
Дальнейшие работы могут быть продолжены по решению ПК с доведением протокола ПК до Директора Департамента
Протокол РГ
9
Утверждение работ по
сервису
ПК
Проектный комитет определяет и утверждает команду реализации, сроки, границы и бюджет сервиса.
Также заполняется карточка сервиса для создания репозитория и стендов, по итогам заполнения уведомляется РП, ответственный за сервис со стороны ДИТ (ЭМ).
Протокол ПК
10
Постановка на разработку
СА
11
Описание подхода к
реализации
РГР
Руководитель группы разработки (РГР) ознакамливается с набором документации (спецификация, ADR и пр.), по итогам через РП ДИТ (ЭМ) может быть запрошена встреча с авторами данной
документации для обсуждения открытых вопросов
На основании документации РГР в рамках данной задачи создаются отдельные задачи на разработку функциональности, по каждой задаче формируются критерии приемки, которые должны
быть согласованы архитектором ДИТ (ЭМ), ответственным за сервис
12
Обеспечение
инфраструктуры для
сервиса
ИНЖ
В рамках данной задачи выполняются работы по предоставлению доступов, настройке пайплайнов, созданию стендов, БД и т.д.
Задачи на DevOps назначаются только через РП ДИТ (ЭМ), ответственного за сервис
13
Разработка сервиса
Р
В рамках данной задачи выполняются задачи на разработку функциональности
14
Тестирование
Т
В рамках данной задачи команда разработки проводит формирование тестовых сценариев, а также функциональное/регресионное тестирование по разработанной функциональности
Отчет о
тестировании
15
Документирование
СА
В рамках данной задачи команда разработки формирует набор документации, определенный ТЗ
Отчетная
документация
16
Приемка
ПрК
В рамках данной задачи команда разработки демонстрирует разработанную функциональность Приемочной комиссии ДИТ (ЭМ) в соответствии с согласованной программой и методикой
испытаний
Протокол
приемочных
испытаний
АРХ
*все БТ, формируемые внешними командами, в обязательном порядке должны быть согласованы БА со стороны ДИТ (ЭМ).
**при разработке ядровых компонентов БТ могут быть сформированы архитектором
* данный шаг не обязателен для сервисов, не имеющих графического представления или носящих ограниченный характер доступа (например только для технолога системы)
** проволочные макеты, формируемые внешними командами в обязательном порядке должны быть согласованы дизайнером и БА со стороны ДИТ (ЭМ)
Архитектор, ответственный за сервис, определяет перечень БТ, которые могут быть технически реализованы исходя из текущего состояния развития ЕПЦП. Те БТ, которые могут быть
реализованы в ближайшее время описываются ответственным архитектором в рамках спецификации в соответствии с шаблоном:
Архитектурные решения, принятые в рамках подготовки спецификации оформляются в формат ADR в соответствии с шаблоном:
Также в рамках шага Архитектор должен проанализировать необходимость в создании нового справочника (в т.ч. его описание), UI-элемента, интеграции и т.д.
Паспорт сервиса
Пользовательские
истории
Проволочный макет
Спецификация, ADR
*для формирования спецификации может быть привлечен СА
В рамках данной задачи СА (в случае разработки внутренней командой) или команда разработки подрядчика формируют постановку на разработку в соответствии с шаблоном:
*в отдельных случаях при разработке подрядчиком постановка на разработку может быть написана специалистами ДИТ (ЭМ), данный вопрос уточняется при формировании и согласовании плана работ
Протокол АК
ФТ, НФТ
ТЗ (в т.ч. Расчет
НМЦК)
Постановка на
разработку
Перечень тасков в
Jira
Выполненная задача
в Jira