Когда банк обновляет мобильное приложение, клиент не думает о спринтах, релизных окнах и регрессе. Он открывает приложение, и перевод денег либо проходит, либо нет. Все, что происходит до этого момента, — работа, которую клиент никогда не увидит, но почувствует сразу, если она сделана плохо.
Еще год назад IT в банке измерялось по принципу: сколько задач закрыто, сколько релизов выпущено, сколько часов списано. Цифры росли, но ответа на главный вопрос — что изменилось для клиента — в них не было. Задача могла доехать до продакшена и не дать никакого эффекта. Или не доехать вовсе и тихо осесть в общей очереди.
В 2026 году мы поменяли сам способ считать. И вместе с ним — то, как устроена поставка ценности для клиента.
Кто отвечает за то, чтобы ценность дошла
Зачастую задачу ведут сразу несколько людей: аналитик отвечает за требования, разработчик — за код, тестировщик — за качество, менеджер проекта — за сроки. Но нет никого, кто отвечал бы за то, чтобы клиент в итоге почувствовал результат изменений.
Эту функцию в Ipoteka bank OTP Group теперь выполняет Delivery Manager.
Разницу можно заметить по работе со статусом задачи:
Менеджер проекта спрашивает: «Проект сдан в срок?»
Delivery Manager спрашивает: «Дошла ли ценность до пользователя — и работает ли она?»
Как появилась роль Delivery Manager
К началу 2010-х британское государство почти полностью отдало разработку внешним подрядчикам: 80 % государственного IT делали всего 18 компаний. Изменение одной строки кода стоило казне £50 000. Общая цена задержек, перерасходов и отмененных проектов — £26 млрд. Парламентский отчет 2011 года назвал это «рецептом для грабежа».
Выбраться из этой ситуации помогла внутренняя команда разработки и человек, чью роль позже назвали Delivery Manager. Команда из 14 человек собрала рабочий прототип государственного портала за 12 недель и £261 тыс. — вместо £128 млн по смете подрядчика. Внутри этой команды впервые появился человек, который держал ритм, снимал препятствия и отвечал за то, чтобы продукт дошел до пользователя.
Вывод, который из этого сделали, звучит так:
The unit of delivery is the team.
Единица поставки — не подрядчик и не проект, а постоянная команда, которая живет с продуктом.
Вендорная модель и инхаус-команда с Delivery
| Вендорная модель | Инхаус-команда с Delivery |
|---|---|
| Экспертиза о продукте живет вне банка. | Небольшая кросс-функциональная команда работает внутри банка. |
| Каждое изменение — отдельная коммерческая процедура. | Собственный контур разработки и свой релизный цикл. |
| Релиз зависит от графика подрядчика. | Delivery Manager ведет ценность от заявки до пользователя. |
| Нельзя быстро проверить гипотезу — нужно ее заказать. | Гипотезу можно проверить в ближайшем спринте. |
В 2012 году роль Delivery Manager стала обязательной для каждой команды цифровой службы. Сегодня Delivery Manager — штатная позиция в Barclays, HSBC, Lloyds, NatWest, ING, Revolut, Monzo, Wise и Starling, в цифровых службах Великобритании, США, Канады, Австралии и Сингапура. В СНГ профессию из роли первым сделал Т-Банк, в Узбекистане — Ipoteka bank OTP Group в 2026 году.
Delivery в командах внутренней разработки
Мы запустили новое мобильное приложение в конце 2025 года. Уже за первые месяцы в приложении зарегистрировались более 400 тысяч клиентов, две трети из них заходят в него каждый месяц. Такой рост невозможно было бы выдержать в условиях, где релиз — разовое событие.
Что изменилось в работе команды
| Показатель | Результат |
|---|---|
| Доля дефектов в проде при регрессе | Снизилась в 7 раз |
| Команда внутри банка | Выросла почти в 10 раз |
| Темп поставки в месяц | Вырос почти в 7 раз |
| Перенос плановых релизных окон с весны | Ни одного |
Приложение входит в топ-3 своей категории в Google Play и App Store — и эту оценку пользователь ставит не релизам, а тому, что между ними ничего не ломается.
Кредитный контур: четыре очереди вместо одной
На кредитном контуре проблема была не столько в скорости, сколько в приоритезации. Из-за общего бэклога на все продукты разные направления кредитования конкурировали за одних и тех же разработчиков. Каждый тянул свои задачи наверх, лид-тайм рос у всех сразу, а ответственного за конкретный продукт внутри разработки не было.
Весной контур разделили на четыре вертикали: у каждой свой бэклог, свой лид, свой владелец продукта и общая платформа под ними.
Что дало разделение общего бэклога на вертикали
| Показатель | Результат |
|---|---|
| Количество инцидентов за период | В 7 раз меньше |
| Частота релизов | В 2–3 раза чаще |
| SLA | 96,9 % → 99,5 % |
| Доля закрытых задач от созданных | 50 % → 75 % |
| Входящий поток задач | Вырос почти в 10 раз |
Объем поставки каждого месяца относительно первого месяца периода. В среднем контур стал доставлять в 3,3 раза больше задач в месяц, при этом лид-тайм сократился в каждом стриме: очередь стала короче, потому что перестала быть общей.
Последняя строка выглядит как рост нагрузки, и это правда. Раньше задач заводили меньше не потому, что их не было, а потому что команда не вытягивала поток и бизнес перестал приносить. Когда контур начал справляться, поток вернулся.
Отдельно — автокредитование. Время от идеи до запуска продукта сократилось с двух-трех недель до трех рабочих дней — в пять раз быстрее. За этим пришли пять новых брендов-партнеров, 45 новых дилеров, а с ними и рост выдач.
Ядро системы: весь банк стучит в одно окно
Ядро банковской системы — это платформа, к которой приходят все девять блоков и более тридцати дирекций. В сравнении с прошлым годом поток обращений за девять месяцев вырос почти на 20 %. Команда при этом осталась прежней.
Раньше заявки падали в общую кучу: приоритеты выставлялись сверху, а у каждой шестой заявки вообще не было владельца при постановке. Теперь у каждой есть Delivery Manager, который доводит ее до прода или честно объясняет, почему ее не сделают в этом квартале. С весны на ядре не было ни одного крупного инцидента, а поток новых дефектов сократился почти вдвое.
О чем мы говорим вслух
В очереди ядра до сих пор лежат сотни открытых заявок. Шесть из десяти помечены высшим приоритетом — и ждут почти столько же, сколько все остальные. Когда срочное все, приоритета нет ни у чего.
Поэтому команда начала называть бизнесу свою пропускную способность в квартал, то есть сколько задач сможет закрыть команда, а на какие не хватит ресурсов. Это неудобная цифра, зато теперь бизнес узнает о том, что его задача не будет сделана сразу, а не через полгода ожидания.
Честный отказ стоит дешевле, чем задача, которая год лежит в статусе «высший приоритет».
Четыре вещи, которые мы поняли
1. Приоритет — это деньги
За каждой заявкой стоит эффект, который можно посчитать. Если заявка год лежит в очереди, эффект сгорает вместе с ней.
2. У каждой заявки должен быть оунер
Не отдел и не комитет, а конкретный человек, который ведет ее до прода и отвечает за результат.
3. Сначала стабильность, потом скорость
Быстро катить сломанное — не достижение. Стабильность начинается с порядка в самом ядре.
4. Говорим бизнесу правду о сроках
«Пока не знаем, ответим в пятницу» честнее красивой даты, в которую никто не верит.
Дальше — единая модель поставки IT-блока
К концу 2026 года все платформы работают по одному стандарту: семь обязательных стадий жизненного цикла от планирования до эксплуатации, одна продуктовая команда на одной платформе и Delivery Manager в каждом стриме.
Сегодня в каждом из шести стримов IT-блока есть свой Delivery Manager. А за каждым релизом стоят команды разработки, тестирования, инфраструктуры и аналитики — без них ни одна задача не доехала бы до прода.
Смелость первого шага
Ipoteka bank OTP Group прошел этот путь от вендорной модели к инхаус-команде Delivery за девять месяцев. Разработка ключевых продуктов переехала от вендора внутрь банка, инженерная команда выросла почти в десять раз, а темп поставки — почти в семь. Банк стал первым в регионе, кто ввел роль Delivery Manager штатно, а не как разовый проектный эксперимент на одну инициативу.
Большой корпоративный бизнес редко ассоциируется со смелыми экспериментами. Но именно эксперимент — завести профессию, которой в регионе еще не было, — дал самый быстрый измеримый результат за год.
Доверие бизнеса к IT устроено так же, как доверие клиента к банку: его нельзя пообещать, а вот заслужить, чтобы на него начали рассчитывать, — вполне.
Девять месяцев — небольшой срок для банка с тридцатилетней историей, но достаточный, чтобы релиз перестал быть событием и стал расписанием. Клиент этого не увидит, но если он откроет приложение и сделает перевод, значит, мы все делаем правильно.