Agile в финтех-командах: почему стандартные подходы буксуют
После того как Kaspi задал стандарт скорости для всего рынка, банки и платёжные сервисы начали запускать собственные цифровые продукты, нанимать разработчиков и внедрять Scrum. Через полгода-год многие из них обнаруживают одно и то же: спринты идут, церемонии проводятся, а специфические проблемы финтеха от этого никуда не деваются.
Проблемы
Четыре вещи, которые делают agile в финтехе сложнее
Scrum подходит для финансового сектора, но у финтех-команд есть ограничения, при которых стандартное применение практик требует серьёзной адаптации.
🔒
Compliance и скорость
Каждый релиз проходит через юристов, безопасность и иногда регулятора. «Потенциально готовый инкремент» и «реально готовый к релизу» могут разделять недели согласований.
👥
PO между тремя сторонами
Бизнес хочет фичи быстро, регулятор требует соответствия стандартам, а пользователю важен простой интерфейс. Три потока задач с разной логикой приоритизации конкурируют за один спринт.
📈
Рост с 3 до 10 команд
Каждая команда работает по Scrum, но зависимости между ними множатся, а Sprint Review проводится изолированно, без кросс-командной синхронизации.
⏱
Непредсказуемость оценок
При интеграциях с процессинговыми центрами, госсервисами и внешними API срок выполнения зависит от контрагентов, и story points в таких условиях дают мало информации.
Compliance
Как совмещать регуляторные требования и итеративную разработку
В финтехе каждый релиз проходит через compliance-проверку: изменения в платёжных системах, обработке персональных данных или расчёте тарифов требуют согласования с юристами, службой безопасности и иногда с регулятором. За нарушение этих требований компания платит реальными штрафами, поэтому обойти этап согласования невозможно.
Стандартный Scrum предполагает потенциально готовый к релизу инкремент в конце каждого спринта. В финтехе между «потенциально готовый» и «реально готовый к релизу» могут стоять дни или недели согласований.
→
Compliance в Definition of Done
Задача считается готовой только когда юристы подтвердили соответствие требованиям. Не «после спринта», а как часть спринта.
→
Параллельный процесс
Compliance-специалист работает с командой на этапе планирования, а не принимает готовый результат после. Это требует изменения структуры, но экономит недели.
→
Автоматизация проверок
Статический анализ кода, проверка зависимостей на уязвимости, тесты на утечки данных в CI/CD. Снимает нагрузку с ручного аудита и позволяет релизить чаще.
Product Owner
PO в финтехе: между бизнесом, регулятором и пользователем
Беклог наполняется тремя потоками задач, и если PO не умеет приоритизировать их системно, compliance-задачи откладываются до аврала, а технический долг растёт до точки, когда сервис начинает падать.
💰
Фичи для пользователей
Переводы через QR, рассрочка, выход на рынок Узбекистана. Бизнес торопит, пользователи ждут удобный интерфейс, а каждая задержка стоит конкурентной позиции.
📜
Compliance от регулятора
Стандарты безопасности, антиотмывочное законодательство, защита персональных данных. Обязательные задачи, которые не конкурируют с фичами.
🔧
Технический долг
Накапливается в фоне, пока команда торопится с релизами, и обычно привлекает внимание только тогда, когда начинает влиять на стабильность сервиса.
«Compliance-задачи планируются первыми как обязательные, а фичи и технический долг конкурируют между собой по стоимости задержки. Что берётся в работу следующим, определяют данные.»
Подход к приоритизации в финтех-командах
Масштабирование
Когда три команды превращаются в десять
Проблемы начинаются на стыках: команда платежей зависит от команды идентификации, мобильное приложение ждёт API от бэкенда. Зависимости множатся, и никто не видит полной картины.
S
Из SAFe: квартальная синхронизация
PI Planning решает проблему «каждая команда планирует в вакууме». Определяются приоритеты, зависимости и обязательства на следующий период.
L
Из LeSS: общий беклог
Все команды работают над одним продуктом и вытягивают задачи из одного беклога. Уменьшает количество зависимостей, потому что любая команда может взять любую задачу.
◆
Своё: delivery manager
Координатор на уровне программы, который видит зависимости между командами и помогает разрешать их до того, как они заблокируют чей-то спринт.
На практике большинство финтех-компаний у нас не внедряют ни один фреймворк масштабирования целиком. Берут отдельные практики и собирают модель, которая работает в их конкретном контексте.
Прогнозирование
Flow-метрики вместо story points
Значительная часть работы в финтехе связана с внешними интеграциями, где сроки зависят от контрагентов так же сильно, как от самой команды.
Story points в условиях внешних зависимостей дают мало информации: задача может быть оценена в 8 баллов, но если внешний API не готов, она стоит две недели вне зависимости от оценки.
Прогнозирование на основе flow-метрик работает лучше. Cycle time показывает, сколько задача реально проводит в работе, throughput показывает, сколько задач завершается за спринт, и на основе этих данных строятся вероятностные прогнозы вместо точечных обещаний.
Формулировка «с вероятностью 85% будет готово до 20-го» оказывается полезнее для бизнеса, привыкшего работать с рисками, чем привычное «будет готово к 15-му».
CT
Cycle Time: время задачи в работе
TP
Throughput: задач за спринт
85%
Вероятностный прогноз вместо точной даты
Следующий шаг
Выстройте процессы в финтех-команде системно
Базовый ICP даёт Scrum, Kanban и AI-инструменты. ICP-APO решает задачи Product Owner: приоритизация, стейкхолдеры, метрики. ICP-APM закрывает delivery: flow-метрики, прогнозирование, прозрачность для бизнеса.