5 стримов, 1 портфель: как Казначейство достигло 91% предсказуемости поставки
Бахтияр Сартаев
Банк ЦентрКредит · Руководитель команды разработки
Иван Дубровин
Управляющий партнер ScrumTrek�Приглашенный преподаватель МШУ Сколково
фото спикера
Москва
17 сентября
2026
Мой AgileDays
“Видеть-то мы видим, а делать что?” �Столкнувшись с дефицитом внутренней экспертизы Agile мы решили не изобретать велосипед и вызвались в пилот со ScrumTrek�
фото / архивный кадр
memory
КОНТЕКСТ
Банк CenterCredit в цифрах
Один из лидеров банковской системы Казахстана: работает с 1988 года и входит в топ-3 по объёму активов
Присутствие по всему Казахстану
01
Источник: официальный сайт Банка ЦентрКредит, данные на 14.09.2026
Головной офис Банка ЦентрКредит · Алматы
Казначейство в Банке
Регулятор
Нормативы и отчетность
Клиенты и бизнес
Платежи и конвертация�Ценные бумаги�Деривативы
Казначейство
Финансовый рынок
Межбанк и биржи�Нацбанк и контрагенты�Валюты, ставки, ценные бумаги
Баланс, ликвидность �Стоимость фондирования �Риск
02
КОНТЕКСТ
Дилинг
Другие�
Middle Office
Бэк-офис
Global Treasury
02
ПОДРАЗДЕЛЕНИЯ КАЗНАЧЕЙСТВА
КОНТЕКСТ
Где мы работаем
Global Treasury
2023
год образования
23
специалиста
Продуктовые, инфраструктурные и регуляторные задачи одновременно
Общие специалисты и большое количество зависимостей
НАШИ ПРОДУКТЫ — КОНТУР СОПРОВОЖДЕНИЯ
Брокер
ское обслуживание Retail
Производные фин. инструменты Corporate
Trading
FX Платформа
Внутренние автоматизации Казначейства
Бэк-офис процессы
Люди работали много, но направление не работало как единая управляемая система.
03
РЕЗУЛЬТАТ
Что получилось за 3 месяца
5
стримов в команде
Свой контекст, backlog, владелец результата, отдельные daily и retro.
>91%
выполнение спринта
Объем взятый в спринт, завершается в рамках этого же спринта.
Q → S
цели связаны со спринтами
Квартальная цель раскладывается в инкременты и цели спринтов.
Дальше — как мы к этому пришли и почему после стабилизации delivery занялись продуктовым портфелем.
04
ПРЕДПОСЫЛКИ
Что хотели починить
06
1
Предсказуемость
Команда должна понимать хотя бы ориентировочный срок и выдержать его.
2
Командная ответственность
За результат отвечает команда, а не отдельный специалист.
3
Ранняя обратная связь
Показывать работающий результат в спринте, а не в конце большого пакета.
4
Быть, а не казаться
Сделать Scrum способом эффективной работы, а не набором формальных церемоний.
Как перестроили delivery
Проблемы по одной — и что с каждой сделали
Part 1
ПРОБЛЕМА 1
23 специалиста, один backlog, один daily, одно ретро
08
Чтобы работа двигалась, мне приходилось самому помнить весь контекст, определять, кто чем займется сегодня, и каждому отдельно объяснять следующий шаг
ПРОБЛЕМА 2
Scrum больше культ, чем эффективный процесс
09
Разный уровень знаний или незнаний Scrum
ПРОБЛЕМА 3
Переключение контекста
10
Мы оптимизировали загрузку отдельных людей, но проигрывали в скорости всей системы.
ПРОБЛЕМА 4
Водопад внутри спринта
Спринт, 10 дней
Аналитика
Дизайн
Разработка
Тестирование
Хвост тестирования — уже в следующем спринте
ЧТО СЛЫШНО НА ДЕЙЛИ
ЧЕМ ЗАКАНЧИВАЕТСЯ
«Тестировщику пока нечего делать»
Все баги находятся в пятницу после обеда
«Сначала доделаем аналитику по всем задачам»
Разработка стартует, когда полспринта позади
«Задача готова, осталось только протестировать»
На демо готово ноль задач — показывать нечего
«Перенесем в следующий спринт, там уже начато»
Незакрытый хвост растёт от спринта к спринту
11
ПРОБЛЕМА 5
Discovery и спайков не было
Все задачи сразу попадали в общий производственный процесс. Не было пространства, чтобы:��
12
Неопределенность обнаруживалась уже после начала разработки — поэтому команда не могла прогнозировать сроки даже ориентировочно.
Микроменеджмент стал способом компенсировать несовершенную систему.
Вывод, с которого начались изменения
РЕШЕНИЯ
Меняли операционную модель, а не церемонии
Устройство команд
Кто с кем работает постоянно и за какой продукт отвечает.
Движение работы
Как задача проходит путь от гипотезы до работающего инкремента.
Правила решений
Кто расставляет приоритеты и что команда решает сама.
15
РЕШЕНИЕ 1
Продуктовые стримы вместо общего пула
Что получил каждый стрим
Что изменилось
Люди перестали быть общим ресурсом направления и начали накапливать глубину в своих продуктах.
16
Зависимости между стримами не исчезли — они стали явными.
РЕШЕНИЕ 2
Встречи с тайм боксами и результатом
(+) Квартальное планирование
1 раз в квартал
(+) PBR стрима
1 раз в спринт · ≤ 2 ч
Планирование спринта
1 раз в спринт · ≤ 2 ч
Ежедневный синк
ежедневно < 15 мин
(+) Демо спринта
конец спринта · ≤ 2 ч
(+) Квартальное демо
конец квартала · ≤ 3 ч
(+) Ретроспектива
после демо · ≤ 1 ч
Квартальное ретро
1 раз в квартал · ≤ 1,5 ч
24
РЕШЕНИЕ 3
Структура управления работой в направлении
Единые приоритеты сверху, ответственность за результат внутри стримов
PO
Product Owner
Единый портфель и бизнес-приоритеты
Продуктовая экспертиза
ПРОДУКТОВЫЕ СТРИМЫ
S1
Stream Owner 1
отвечает за результат
Бэклог Stream 1
свои приоритеты
S2
Stream Owner 2
отвечает за результат
Бэклог Stream 2
свои приоритеты
S3
Stream Owner 3
отвечает за результат
Бэклог Stream 3
свои приоритеты
S4
Stream Owner 4
отвечает за результат
Бэклог Stream 4
свои приоритеты
TL
Stream 5
АБС
Frontend
Auto QA
Devops
Платформа поддерживает четыре продуктовых стрима
17
РЕШЕНИЕ 3
Одна общая доска превратилась в доски продуктовых стримов
БЫЛО
Одна доска на всё направление
23 специалиста и задачи разных продуктов в одном спринте
23 специалиста в одном общем фильтре
Фокус терялся: daily превращался в диспетчерскую, а люди переключались между направлениями
СТАЛО
Отдельный спринт для каждого стрима
Команда видит только свой поток работы и проверяемый результат
Отдельные спринты стримов
Доска одного продуктового стрима
Результат: меньше переключений, понятная ответственность, прозрачный статус цели
21
РЕШЕНИЕ 4
От больших задач к небольшим инкрементам
БЫЛО
Реализовать весь продукт или большой процесс
СТАЛО
Поставить часть функциональности, которую можно продемонстрировать, проверить и использовать
ранняя обратная связь
меньше рисков
понятный прогресс
возможность менять решение
более точные прогнозы
25
РЕШЕНИЕ 4
Квартальная цель разложена на шесть целей спринтов
КВАРТАЛЬНАЯ ЦЕЛЬ ЭПИК
Полная автоматизация процесса корпоративных событий для Back Office
USER STORY - ЦЕЛЬ СПРИНТА
Каждый спринт завершает проверяемую часть общего процесса
Системный анализ интеграций и контракты dbp-admin
выполнено
02
Функционал разработан в Admin Panel
выполнено
Интеграция CBS с DBP завершена
выполнено
Связка Admin · DBP · QORT протестирована
выполнено
E2E-тестирование выплаты корпоративных событий
выполнено
06
21
Приёмочное тестирование и релиз всего функционала
выполнено
РЕШЕНИЕ 4
Цель 5 · завершить E2E-тестирование выплаты корпоративных событий
ПОДЗАДАЧИ
DEV
Документация сервиса на dev и test средах
100%
QA
Функциональное тестирование корпоративных событий
100%
DEV
Подключение endpoints на странице корпоративных событий
100%
AN
Описание параметров для отображения в Admin Panel
100%
DEV
Дополнительные работы по корпоративным событиям
100%
5 из 5
Выплата корпоративных событий прошла полное E2E-тестирование
22
РЕШЕНИЕ 5
Разделили Discovery и Delivery
Discovery
Гипотеза и бизнес-анализ.
Системный анализ и спайки.
Архитектурные и интеграционные риски.
Подготовка небольших инкрементов.
Delivery
Разработка.
Тестирование.
Выпуск.
Получение обратной связи.
23
РАСЧЕТЫ
Предсказуемость поставки: 91,9%
91,9%
Индекс выполнения спринтовых обязательств: фактический результат относительно целей, заявленных до начала спринта.
КАК СЧИТАЕМ
Зелёный — 100% �Жёлтый — 80% �Красный — 40% �Багровый — 0%. �Пауза исключается только после официальной смены приоритета.
Индекс = сумма оценок целей ÷ число целей
Период: 8 спринтов, 111 целей
26
(73×100% + 35×80% + 2×40% + 1×0%) ÷ 111 = 91,9%
Delivery стал предсказуемым. Но появился более важный вопрос: уверены ли мы, что берём в работу именно то, что нужно?
Можно дисциплинированно развивать продукт, в который уже не стоит инвестировать
Портфель и роль владельца продукта
Part 2
Бимодальный портфель продуктов
29
Работа с продуктовым портфелем
Продуктовый портфель – мониторинг финансовых эффектов
Визуализация состояния отдельных продуктов и портфеля в целом
Способы оценки рисков
Виды объектов в портфеле
Уровень портфеля
классический проект
гибкий проект
продукт
Связь проектов и продуктов на уровне портфеля
Ожидаемые эффекты
Уровень риска
исследование
эксплуатация
очередь инициатив
идеи
+
эффекты
риски
-
риски
-
+
эффекты
Зрелые продукты
Пилоты и эксперименты
31
Виды объектов в портфеле
Уровень портфеля
классический проект
гибкий проект
продукт
Связь проектов и продуктов на уровне портфеля
Ожидаемые эффекты
Уровень риска
исследование
эксплуатация
очередь инициатив
идеи
+
эффекты
риски
-
риски
-
+
эффекты
Зрелые продукты
Пилоты и эксперименты
Классический проект по повышению эффектов у зрелого продукта
Гибкий проект по снижению рисков
Классический проект без продукта (общая польза, пока пилот)
Продукт не требует значимого развития (устаивают текущие эффекты)
Проект по выводу из портфеля
Масштабирование из статуса пилота в зрелый продукт (работаем гибко)
ОК!
$!
вендорлок
AI-платформа
Сокращение затрат на поддержку
Стоимость привлечения / операционная прибыль
Общий потенциал эффектов в пилотах
Остаточный уровень инновационного риска
Уровень риска наступления большой Ж
Отдача от зрелых продуктов
32
Что видите? Что хочется поправить?
34
«Нет ничего более бесполезного, чем эффективно делать то, что делать вообще не нужно».
— Питер Друкер
35
КОНТАКТЫ
AgileDays