Всем привет. Меня зовут Сергей Пищуленок, и сейчас я занимаюсь направлением технологического совершенства в банке. Так и сложилось, что я отвечаю за большое направление с простой на словах и непростой на практике задачей: помогать командам доставлять быстрее и качественнее, опираясь на цифры, а не на ощущения.
Эта статья написана по мотивам моего выступления на DevOpsConf 2026. Поговорим о Time-to-Market: как разложить его на части, найти узкое место и подобрать под это узкое место инженерную практику, которая действительно сдвинет метрику. Сразу предупрежу, что универсального рецепта на все случаи здесь не появится. Это и есть главная мысль всего материала.
Время это деньги, и все хотят доставлять быстрее
Time-to-Market содержит в себе слово time, а время это деньги. Каждому хочется доставлять быстрее, чтобы фичи не остывали и изменения раньше доходили до пользователей. Когда мы задаем себе вопрос, что с этим делать, чаще всего всплывает один и тот же ответ: давайте тюнить инженерные практики, давайте тюнить процесс. Звучит правильно. Ветвление, автоматизация тестирования, качество релизов это всё про хорошее.
Дальше возникает ключевой вопрос. Какие практики реально дают ускорение? Практик много, у каждой есть свои аргументы и свои кейсы. При этом эффект бывает небольшим, иногда совсем незаметным, а иногда даже обратным. Внедрили что-то полезное по всем учебникам, а скорость доставки осталась прежней или просела.
Поэтому я предлагаю посмотреть на то, как практики влияют на Time-to-Market, насколько сильно влияют и как подойти к выбору практик под существующий bottleneck вашей системы. Двигаться будем так. Сначала немного контекста про DORA Core Model. Затем разберём структуру Time-to-Market и посмотрим на него как на систему. После этого расскажу, как мы считаем инженерные практики у себя в банке, поищем bottleneck по компонентам, построим карту корреляции и выделим профили практик. В финале разберем небольшой плейбук работы с узкими местами.
Немного контекста: DORA и почему мы берём именно скорость
Если совсем коротко, логика DORA Core Model такая. Сначала смотрим, как устроена система, это блок Capabilities. Потом смотрим, как работает поток, это блок Performance. И только потом смотрим, какой это даёт результат, это блок Outcomes.
Основной упор я сознательно делаю на Performance, а внутри Performance на скорости. DORA про перформанс изменений в широком смысле, и если исследовать сразу всё, легко получить поверхностные выводы. Поэтому мы берём один понятный слой и работаем с ним внимательно.
Разбирать скорость удобно через компонент Time-to-Market. Он не заменяет DORA и не совпадает с ней один в один. DORA Change Lead Time описывает время от коммита до результата в системе, а Time-to-Market в моём понимании шире. Это время от заведения идеи в таск-трекере до момента, когда задача получает реализацию в системе. За счёт такой ширины Time-to-Market становится рабочим фреймворком, который позволяет назвать конкретный тип потерь времени вместо общего ощущения, что мы долго доставляем.
Time-to-Market как система
Чтобы с метрикой можно было работать руками, её нужно разложить. На верхнем уровне Time-to-Market делится на две большие части. Discovery это время с момента, когда задача только появляется в голове у менеджера или у техлида, и до момента, когда решение достаточно формализовано в виде задач. Delivery это время, за которое задача проходит стадию реализации.
Внутри идём глубже. Lead Time это общее время доставки ценности. Оно складывается из Backlog Time, то есть времени, которое задача лежит в бэклоге, и Cycle Time, то есть времени прохождения потока ценности. Cycle Time, в свою очередь, складывается из Process Time, времени активной работы, и Delay Time, времени задержек.
Смысл этой декомпозиции один. После того как мы её сделали, нас перестаёт интересовать абстрактное «медленно». Нас интересует конкретное место потери: bottleneck в process time, в delay time или в backlog time. Эту же систему можно наложить и на Delivery, и на Discovery, разбирая каждый участок отдельно.
В исследовании я осознанно беру только Delivery. Причина простая. Delivery лучше измеряется и теснее связана с инженерными практиками и инженерными процессами. Discovery же ближе к организационным практикам, там можно запускать опросы, но измеряется такое заметно сложнее. К тому же большая часть инженерной аудитории живёт именно в Delivery, так что туда и пойдём.
Как мы считаем Time-to-Market
У каждой команды свой флоу доставки ценности. Кто-то работает на тасках, кто-то на стори, кто-то принципиально таски не использует. Ломать это и устраивать жёлтую революцию я не хотел. Поэтому в основе расчётов лежит конфигурационный файл, в котором команда сама описывает свой поток: доски, статусы, что включать и что исключать. Получается достаточно гибко. Команда кладет этот файл к себе в репозиторий, мы собираем такие файлы и понимаем, что и как считать.
Дальше начинается механика. Источник истины у нас Jira, и она же критичный сервис, ходить в неё напрямую нельзя. Поэтому данные из Jira уезжают в Data Lake, где стоят витрины. Из витрин данные по задачам попадают в нашу базу, а внутри базы живёт специальное представление с предрасчета ми, которое я называю ModView. Запросы у пользователей бывают тяжёлые: несколько досок, много статусов, и без перерасчетов ответ собирался бы очень долго. Предрасчет заметно сокращает время обработки запроса. Когда представление обновлено, пользователь стучится в сервис Time-to-Market Data Bridge и получает свои данные.
Архитектуру можно повторить под себя и в более простом виде. Никто не мешает сделать монолит вместо набора сервисов или ходить в Jira напрямую, если позволяет нагрузка. У нас такой опции не было, поэтому разнесли на сервисы. В интерфейсе всё это выглядит как набор моментальных показателей Time-to-Market по компонентам, графики, переключатель между Delivery и Discovery и фильтр по датам, вплоть до сравнения года с предыдущим годом.
Как мы считаем инженерные практики
С Time-to-Market разобрались. Вторая половина истории это блок Capabilities, то есть сами инженерные практики. Под них у нас есть отдельная платформа, и сразу скажу, что это не реклама: платформу мы не продаем, а показываем, как устроена методология.
Начну с прозаичного вопроса. Как вообще понять, что команда внедрила практику и придерживается её? Я выделяю четыре способа, и каждый имеет право на жизнь в своё время.
На честном слове. Большой руководитель просит маленького внедрить практику, тот приходит и говорит «да, внедрили», на этом всё заканчивается.
На периодическом чек-апе честного слова. То же самое, только слово подтверждается регулярно.
На метриках. Команда выделяет себе показатели, следит за ними, отлавливает резкие скачки и спады, получает наблюдаемость. Это уже неплохой уровень.
На полной автоматизации. Самый интересный способ.
Чтобы управлять инженерными возможностями на масштабе всей организации, нам нужна была именно полная автоматизация. Для этого практику пришлось формализовать. Каждая практика описана, у неё есть риски, рекомендации и влияние, то есть методологический костяк, на который можно опереться. Практика разбивается на критерии, критерий описывает группу действий, нужных для ее соблюдения. Возьмём практику бранчинг: один из ее критериев это срок жизни ветки. У каждого критерия есть одно или несколько действий, по сути метрик, и у каждого действия есть уровни зрелости, по которым мы выставляем оценку.
Здесь важная оговорка про измеримость. Метрики бывают булевыми, числовыми, строковыми, на вхождение, на отсутствие вхождения, на даты. Зоопарк приличный, и далеко не каждый аспект практики поддается однозначной оценке. Малое время ревью само по себе еще ничего не говорит о зрелости команды, как и большое время ревью. А вот совокупность метрик уже даёт картину. Если у команды настроены уведомления об МР и при этом по организации время ревью невелико, можно осторожно предположить, что команда что-то предприняла для зрелости в этой практике. Поэтому метрики практик мы рассматриваем именно в совокупности.
Итоговую зрелость считаем как отношение выполненных сочетаний «действие, уровень зрелости» к общему числу таких сочетаний внутри практики. Получается процент, при этом сами уровни никуда не исчезают, и ими тоже можно оперировать. Если команде какое-то действие неприменимо, она может опираться на уровни. Для построения корреляций я использую именно процентную характеристику зрелости.
Технически платформа устроена как поток обновления данных. Refreshment-сервис выступает оркестратором и шлёт сигнал в интеграционный слой. Интеграционный слой агрегирует метрики практик и идёт в сервисы gateway-слоя, а те уже стучатся во внешние системы: GitLab, Sonar, Jira. Когда данные получены, в дело вступает assessment-сервис, который оценивает и отдельные метрики, и практику целиком. Результат складывается в main-сервисы как артефакт, после чего пользователю остаётся открыть фронтенд и получить предрассчитанные данные. MVP такой платформы реально собрать примерно за четыре месяца, хотя времени на методологию до этого ушло заметно больше. Решение получилось довольно самобытным, готовых аналогов под наши задачи мы не нашли.
Ищем bottleneck
Теперь самое интересное. Можно ли по метрикам Time-to-Market понять, где у системы узкое место.
Сначала честная оговорка про числа. Все абсолютные значения ниже обфусцированы: где-то умножены, где-то поделены, где-то возведены в степень. Опираться на конкретные цифры не стоит, а вот тенденции сохранены один к одному, и смотреть нужно именно на них.
Если просто построить Time-to-Market во времени, видно, что система живет не статично. Есть периоды ухудшения и периоды восстановления. Из такого графика следует один важный вывод про саму природу метрики: Time-to-Market запаздывает, и эффект изменений проявляется через месяц или больше. Был скачок, ну плохо, а что с этим делать, пока непонятно.
Картина проясняется, когда мы раскладываем Time-to-Market на компоненты по месяцам. Становится видно, где сильнее delay time, а где process time. Чтобы убрать визуальный шум от скачков, мы переходим к медианам. И тут начинается содержательный разговор. Lead Time большой, но это общее время работы над задачей, в этом ничего страшного. Радует, что Cycle Time больше Backlog Time, потому что это означает, что бэклог не пылится. А вот соотношение Process Time и Delay Time заставляет задуматься: почему задача проводит в ожидании больше времени, чем в работе. На наших данных в delay time действительно есть что оптимизировать.
Сразу скажу, что у вас всё может выглядеть иначе. У кого-то сильнее окажется process time, у кого-то распухнет бэклог. Всё сильно зависит от контекста.
Карта корреляции и главный инсайт
Перейдем к основному артефакту. Это карта корреляции, она же теплокарта, она же hitmap.
Пара сухих вводных. Основной коэффициент корреляции у нас Спирмена. Time-to-Market меряем в часах. Это значит, что отрицательное значение для нас хорошее: меньше времени и выше зрелость. Данные охватывают двадцать команд за девять месяцев.
Сама теплокарта на первый взгляд пугает, и разобраться в ней сразу сложно. По вертикали практики, по горизонтали компоненты Time-to-Market. Видно, что одни практики ярко проявляются в ожиданиях, другие в задержках. Радует обилие минусов. И именно здесь живет главный инсайт, который стоит унести с собой: лучшей практики, которая ускоряет сразу всё, не существует. Разные практики по-разному влияют на разные компоненты. Серебряной пули нет, работать нужно адресно, с конкретным узким местом.
Посмотрим на отдельные компоненты. Если bottleneck в бэклоге, то есть до старта работ теряется много времени, логично присмотреться к практикам вроде test automation, disaster recovery и подхода infrastructure as code. Здесь важно не делать вывод в духе «внедрю эту практику и бэклог упадёт». Корректная формулировка осторожнее: если проблема именно в бэклоге, эти практики стоит рассмотреть в первую очередь.
Process Time даёт совсем другой класс практик. Здесь сильнее проявляются вещи, влияющие на стоимость самого выполнения: ветвление, интеграция и сборка, код-ревью, качество релиза, поддерживаемость кода. Это хорошо ложится на инженерную логику. Если узкое место в самой работе, то и практики, влияющие на этот компонент, стоит искать поближе к исполнению.
Три профиля практик
По мере анализа практики начали группироваться в профили. У меня их получилось три. Первый профиль это практики, которые чаще коррелируют с process time и cycle time. Второй профиль это практики, тяготеющие к backlog time и delay time. Третий профиль я называю контекстно-тяжёлым, и про него поговорим отдельно, потому что четкого паттерна там не просматривается. Разберу по одной показательной практике на каждый профиль.
Бранчинг: профиль process time
Бранчинг логично влияет на cycle time и process time. Ветвление определяет, как долго живут изменения в отрыве от мастера, насколько сложным будет слияние и какого размера получаются батчи. При удачно устроенном флоу интеграция проходит более гладко. При этом бранчинг сильно контекстен: сложные системы по своей природе обладают более сложными схемами ветвления, это говорит о высокой зрелости, но и поворотливость у таких систем ниже, чем у систем поменьше.
Если разбить практику на действия, картина проходит проверку здравым смыслом. Больше всего отрицательных связей именно в cycle time и process time, ровно там, где живёт интеграционное трение. Пройдёмся по действиям.
Срок жизни веток. Долгоживущие ветки означают рост конфликтов, удорожание финальной интеграции и больше доработок. Короткий срок жизни ветки говорит о высокой зрелости в этом показателе.
Количество измененных строк кода. Это про размер батча. Большие изменения сложно читать и поддерживать, поэтому отрицательная корреляция в cycle time выглядит закономерно.
Push rules. Это скорее ограничитель, чем ускоритель: правила уменьшают хаос вокруг мастера.
Флаг delete source branch и слияние с default. Я читаю эти действия как «доводим работу до конца и чисто интегрируемся». Меньше висячих хвостов, меньше параллельных линий изменений, меньше дорогих разборов в финале.
Test automation: профиль backlog и delay time
Test automation работает скорее как способ снизить неопределенность в потоке. Автоматические проверки убирают часть ручных перепроверок и спорных мест, а задержки часто связаны именно с готовностью. Поэтому сигнал в delay time и backlog time выглядит правдоподобно. Здесь карта читается тяжелее, так что сначала возьмём ожидаемые связи, а затем разберем ту, что выглядит спорно.
Наличие тест-планов. Снижает неопределенность и количество возвратов: есть план, по нему тестируемся. Логично отражается в delay time и backlog time.
Наличие слоев для тестов. Структурирует работу с тестами, снижает неопределённость и количество перепрогонов.
Процент успешности запусков. Стабильные прогоны, которые редко ломаются, означают меньше перезапусков и возвратов.
А теперь спорное. Процент покрытия кода тестами не показывает очевидного ускорения, и это объяснимо. Высокое покрытие означает более строгий контроль и больше гейтов, выше критичность, и в совокупности это начинает влиять на время ожидания и на время нахождения задачи в бэклоге. Действие неплохое, но пользоваться им стоит аккуратно. Вывод напрашивается сам: если вы оптимизируете именно скорость прохождения задачи через поток, некоторые очевидные на первый взгляд решения приводят к непопулярным выводам.
Мониторинг: контекстно-тяжёлый профиль
Мониторинг попадает в третий профиль, где паттерн определить не удалось. По бэклогу видно стабильное увеличение времени компонента, а по остальным компонентам сигнал плавает. Практика тяжёлая и контекстная. Она важна для итогового результата системы, но не обязана давать ускорение потока выполнения задач.
В идеальном мире более зрелый алертинг и короткий mean time to recover снижают потери из-за инцидентов и время разборов. На практике встаёт честный вопрос: все ли мы аккуратно регистрируем время аварий в Jira. Скорее не все, хотя кто-то этим занимается. Когда команда вводит больше сигналов, она вводит больше контроля и берёт в работу инфраструктурные задачи, которые не приносят прямой бизнес-ценности. Это естественно отражается ростом в бэклоге, процессе и cycle time, ведь задач становится больше.
Это не повод сворачивать мониторинг. Развивать его нужно, просто аккуратно и с пониманием цели. Если ваша цель чистая пропускная способность системы, мониторинг здесь вряд ли поможет. Я смотрю на него как на часть взросления системы: сначала система становится наблюдаемой и гибкой, и только потом быстрой, и то лишь при удачном стечении обстоятельств. В зрелых критичных системах мониторинг изначально строится с высокой зрелостью, странно ожидать банковский процессинг без алертов. А в незрелых командах и проектах без высокой критичности тот же мониторинг оборачивается тратами времени без заметной пользы.
К контекстно-тяжёлым практикам относятся также application security и disaster recovery, у которых окно наблюдения короче, около семи месяцев, потому что сами практики относительно свежие. Оперировать профилем контекстных практик можно, но осторожно и с ясным пониманием цели. Если нужно резко ускориться, например в режиме MVP или пожара, от части таких практик иногда отказываются временно, понимая все последствия.
Плейбук: как выбрать практику под bottleneck
Соберём всё в короткий алгоритм работы с теплокартой.
Определите поток доставки ценности клиенту.
Соберите метрики, по которым вы будете судить о потоке.
По этим метрикам определите bottleneck своей системы.
Откройте карту практик, посмотрите нужные разрезы и выберите пару практик-кандидатов под конкретное узкое место, будь то cycle time или delay time.
Запустите пилот, внедрите практику и наблюдайте за ней после завершения внедрения.
Про наблюдение скажу отдельно. Я рекомендую подождать не меньше трех месяцев, потому что компоненты Time-to-Market запаздывают, и только после этого анализировать результат. Влияние практики во многом зависит от того, насколько корректно вы подобрали её под свой bottleneck, и результат может отличаться от системы к системе. Вы можете увидеть улучшение, отсутствие изменений или ухудшение. Уже на основе этого наблюдения принимаете решение: продолжать развивать практику, оставить на текущем уровне или откатить.
Честно про корреляцию и каузацию
Здесь стоит сказать прямо. Корреляция это сила связи, а каузация это причинность, и одно не равно другому. Карта корреляции не доказывает причин и не претендует на это. Поэтому все связки выше я предлагаю воспринимать как гипотезы, которые можно развивать и проверять экспериментально, а не как готовые законы.
Чтобы гипотезам можно было доверять чуть больше, мы делаем два шага. Первый это большой массив данных: мы находимся внутри контекста собственной инфраструктуры и работаем на накопленной истории. Второй шаг это регрессия. В дополнение к корреляции мы считаем в абсолютных значениях, насколько меняется метрика Time-to-Market при изменении конкретного действия практики. Например, можно посмотреть, что происходит со скоростью и в каком её аспекте, если код-ревью проходит за определённое время.
Метод работы при этом остаётся честным к самому себе. Это метод кандидатов гипотез: пробуем, измеряем результат, видим улучшение или ухудшение и только потом принимаем или отвергаем практику. Однозначного ответа заранее нет, многие практики контекстны, и на больших системах тот же бранчинг бывает уже сложно развивать дальше.
Куда всё это движется
Сейчас платформа устроена практикоцентрично: практика для нас первична, и из нее выводятся метрики. В новом видении логика переворачивается. У нас есть банч метрик как атомарных кусочков, и уже из этих кусочков собираются практики, в том числе кастомные. Это закрывает понятную потребность пользователей: строить свои практики под свою формулировку и смотреть на отдельные метрики напрямую, ведь в отрыве от практики метрика иногда выглядит искаженно.
Отдельная большая тема это AI-практики. Замерять их мы пока не начали, методология в проработке, несколько практик лежат в черновиках. По общим трендам AI усиливает сильные места и помогает там, где уже хорошо, а при слабой инфраструктуре, культуре и процессах способен сделать всё заметно хуже. Так что прежде чем измерять влияние AI, важно навести порядок в самих процессах.
Ещё пара важных оговорок из практики. Инженерные практики и Time-to-Market мы сознательно не ставим командам в KPI. Любая метрика в роли KPI рано или поздно начинает читериться: задачу заведут позже, дробят один таск на три, закрывают и переоткрывают. Поэтому технологическое совершенство у нас держится на добровольной и энтузиастической основе, а цель по Time-to-Market работает как ориентир, который толкает к инновациям, а не как инструмент наказания. При этом скорость нельзя разгонять ценой стабильности: уровень SLA мы держим в приемлемых рамках и не жертвуем им ради цифр.
Вместо заключения
Главная мысль простая. Не пытайтесь улучшать всё сразу и не ищите одну волшебную практику. Разложите Time-to-Market на компоненты, найдите своё узкое место, подберите под него пару практик-кандидатов и проверьте эффект на собственных данных, дав метрике время проявиться. Цифры не врут, если вы аккуратно настроили свои метрики. Доверяйте им и стройте свои гипотезы на них.