Как мы внедрили единый производственный процесс для трех компаний Финтех-группы (MOEX)

Всем привет! Меня зовут Олеся, я руковожу отделом процессов и технологических стандартов ИТ на Московской Бирже.

Сегодня хочу поделиться опытом, который мы накопили при построении единой производственной системы SDLC (Software Development Life Cycle), включающей три компании Группы MOEX.

Это была не просто бюрократическая задача по написанию инструкций, а сложный инженерный и организационный вызов для нас!

Материал будет полезен CIO, руководителям ИТ-подразделений и архитекторам, которые сталкиваются с проблемой разрозненности в подходах к разработке внутри одной экосистемы.

Что полезного вас ждет в этой статье?

1. как не ограничить командам свободу в выборе инструментов, сохранив при этом прозрачность для бизнеса;

2. как адаптировать SDLC под разные типы проектов без создания хаоса из множества разных правил;

3. какие конкретные метрики влияют на предсказуемость релизов и позволяют управлять качеством;

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

SDLC: Единый жизненный цикл производственного процесса

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

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

Зачем нам была нужна единая производственная система?

Изначально проблема заключалась в том, что каждый департамент и компания внутри Группы развивали свои внутренние подходы к разработке самостоятельно. Каждая компания – это отдельный бизнес-юнит со своей спецификой, но общими для всех системными платформами и едиными целями Группы.

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

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

2.     Низкая предсказуемость сроков и бюджета. Из-за различия методики оценки трудозатрат и этапов производства реальные сроки реализации проектов часто отличались от заявленных. Бизнес-подразделения не могли строить свои продуктовые стратегии, опираясь на ненадежные данные от ИТ. Это приводило к прямому упущенному заработку и снижению доверия к ИТ-подразделению.

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

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

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

От хаоса к фреймворкам

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

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

Для поддержания этой идеи мы внедрили концепцию Фреймворков. Мы закрепили 5 базовых типов Фреймворков. Важно понимать: Фреймворк в нашей системе – это не просто методология (Scrum или Waterfall), а методологическая модель планирования и управления ресурсами, определяющая подход к реализации задачи.

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

Мы классифицировали фреймворки следующим образом:

Главным артефактом этого подхода стала Матрица RACI, которая четко развела ответственность между ролями для каждого типа фреймворка. Таким образом, мы получили ролевую матрицу ответственности на каждом этапе SDLC процесса в зависимости от выбранного типа фреймворка.

Ниже приведен пример части матрицы RACI на Подготовительном этапе – переходу к производственному процессу SDLC.

 R- исполнитель, А – ответственный, С- консультирует, I- уведомляет

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

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

Механика управления

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

1.     Артефакты как основа. Закрепили правило: переход между этапами SDLC невозможен без формирования и согласования конкретных артефактов. В системе трекинга задач настроены контрольные точки: статус задачи не может быть изменен на следующий, пока не будет прикреплен требуемый документ. Это гарантирует, что каждая следующая команда получает четкие входные данные.

2.     Триггерные точки контроля. Мы внедрили обязательные проверки на ключевых этапах, которые работают как фильтры качества:

·       Gate «Архитектура»: Любое изменение целевого ИТ-ландшафта или интеграции с внешними системами требует согласования Архитектором решения (SA) или Корпоративным архитектором (EA). Это предотвращает появление технологического долга и разрозненных решений. Отслеживание прохождения этой точки контроля осуществляется при помощи проверки соответствующего артефакта, прикрепленного к задаче в системе трекинга задач, ответственной за это ролью.

·       Gate «Информационная безопасность»: Перед переходом к тестированию или внедрению, если задача затрагивает информацию ограниченного доступа, проводится экспертиза ИБ. Наличие задачи в пространстве ИБ системы трекинга задач обязательно для таких случаев, что обеспечивает соблюдение требований регулятора и снижение рисков уязвимостей.

·       Gate «Согласование с Заказчиком»: Задачи не допускаются к реализации без подтверждения оценки и стоимости со стороны Заказчика. Это дисциплинирует команды и предотвращает работу над задачами, не имеющими обоснования или утвержденного бюджета.

3.     Метрики для принятия решений. Мы перешли от субъективных оценок к управлению на основе данных. Ключевые показатели, которые мы используем для контроля эффективности и качества:

·       Lead Time (Время выполнения задачи): Время от инициации до релиза. Показывает скорость доставки ценности (Time to Market). Рост метрики сигнализирует об узких местах на этапах оценки или реализации.

·       Deployment Frequency (Частота релизов): Количество релизов в единицу времени. Индикатор зрелости CI/CD и автоматизации процесса внедрения. Высокая частота говорит о хорошем состоянии этапа развертывания.

·       Change Success Rate (Успешность изменений): Процент релизов, не вызвавших инцидентов в прод-среде. Оценивает качество кода и тестирования. Падение метрики требует усиления контроля на этапах разработки и информационной безопасности (SAST/DAST).

·       Defect Containment (Локализация дефектов): Доля ошибок, обнаруженных внутри команды до релиза (в отличие от инцидентов в продакшене). Показывает эффективность внутреннего тестирования и приемочных проверок (UAT). Низкий процент означает проброс багов до эксплуатации.

·       Throughput (Пропускная способность): Объем задач, решаемых за период. Сравнивается с планом мощностей (Capacity). Расхождение служит сигналом для пересмотра состава команды или приоритезации бэклога.

В будущем этот инструмент поможет контролировать прохождение всех этапов процесса, а также предоставлять объективную картину эффективности.

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

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

Использование конкретных метрик (Lead Time для оценки скорости, Change Success Rate для контроля качества релизов и Throughput для планирования мощностей) позволит перейти от субъективных оценок к объективному управлению. Это даст вам точные инструменты для предсказуемости релизов, раннего выявления узких мест в процессе и снижения рисков.

Главная сложность – поиск компромисса в управлении

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

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

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

·        Единый каркас: Этапы производственного цикла (анализ, разработка, тестирование, внедрение) остались неизменными для всех. Это дало возможность видеть общую картину производства на уровне Группы.

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

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

Результаты внедрения

Через год активного внедрения и корректировок производственной системы мы получили следующие результаты:

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

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

• Снижение рисков. Интеграция ИБ на ранних этапах позволила сократить время прохождения проектов через экспертизу безопасности и избежать критических уязвимостей в продакшене.

• Единый язык. Роли стали общими для трех компаний, что облегчило обмен специалистами и лучшими практиками внутри Группы.

Измеримая динамика показателей (2025 – 2026)

Внедрение системы дало количественный эффект, который мы зафиксировали по ключевым метрикам процесса:

Lead Time: Зафиксировано снижение времени цикла со 126 до 102 дней (-18%). Данный результат демонстрирует высокую эффективность внедренного SDLC и автоматизации контроля, что позволяет быстрее доводить продукт до пользователя.

Метрики Defect Containment показали стабилизацию и рост эффективности процессов SDLC и DevSecOps. Показатель 87% подтверждает, что системы уже эффективно блокируют критические дефекты. Дальнейшая работа направлена на стабилизацию этого показателя за счет автоматизации проверок и углубления Code Review.

Cycle Time: Рост с 91 до 94 дней (+4%) в данном контексте не является негативным индикатором. Это свидетельствует о внедрении качественных барьеров и регламентов. Мы сознательно направляем этот рост в сторону повышения ценности и устойчивости продукта, а не в пользу скорости любой ценой.

Самое важное изменение коснулось мышления: от подхода «сдать код» мы перешли к подходу «сдать ценность, проверенную качеством и безопасностью». Теперь мы управляем не просто задачами, а потоком ценностей с учетом всех рисков.

Анализ внедрения показывает, что соблюдение следующих практик позволяет существенно повысить эффективность производственного процесса:

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

·       Наличие дифференциации по типам команд (Фреймворков) и использование матрицы RACI позволяет адаптировать процесс под специфику каждой команды. Четкое разграничение ответственности и функционала помогает избежать неэффективных решений и создает единую среду управления.

·       Внедрение системы конкретных метрик позволяет перейти от субъективных оценок к управлению на основе данных. Это обеспечивает объективную картину скорости доставки ценности, качества кода и эффективности использования ресурсов, выявляя реальные узкие места в производственном цикле.

Что дальше?

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

• Автоматизируем проверку наличия обязательных артефактов в системе трекинга задач.

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

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

• Разрабатываем систему мониторинга для контроля прохождения всех этапов процесса и расчета эффективности.

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

Спасибо, что дочитали! Буду рада обсудить ваш опыт внедрения SDLC в комментариях.