Заполните форму,
и мы с вами свяжемся
и мы с вами свяжемся
Кейс
Agile-аудит для крупной
финтех-компании
Как мы провели аудит Agile-, Scrum-процессов в одной из крупнейших финтех-компаний Таджикистана и что обнаружили за фасадом “правильных” ритуалов
Команда аудита:
Менеджер по эффективному управлению проектами (PDM ), аналитик
Продолжительность:
3 недели
Клиент
Финтех-компания Таджикистана, мобильный кошелёк
Методы
Интервью, наблюдение, анализ
ритуалов, артефактов, метрик
ритуалов, артефактов, метрик
Тип аудита:
Agile & Scrum аудит
О клиенте
Alif Tech — технологическое ядро Alif Bank, одной из крупнейших финтех-экосистем Таджикистана. Компания разрабатывает и поддерживает ключевые продукты: мобильный банк Alif Mobi, платёжную платформу Alif Wallet и банковскую систему CBS.
На момент аудита в разработке было задействовано несколько кросс-функциональных команд, разбитых по технологическим направлениям. Компания активно росла и ощущала, что текущие процессы не справляются с этим ростом.
На момент аудита в разработке было задействовано несколько кросс-функциональных команд, разбитых по технологическим направлениям. Компания активно росла и ощущала, что текущие процессы не справляются с этим ростом.
Задача
В процессе роста продуктов и команд существующая модель разработки заказчика перестала обеспечивать необходимый time to value:
Перед командой Sibedge стояли задачи:
- сроки сдвигались,
- часть задач не завершалась в рамках спринтов,
- усложнилось планирование релизов и управление приоритетами.
Перед командой Sibedge стояли задачи:
- понять, как на самом деле работают ритуалы, роли и артефакты;
- проверить, насколько процессы соответствуют Agile и Scrum;
- найти системные ограничения, которые мешают росту;
- получить понятную целевую модель и шаги перехода;
- определить быстрые улучшения, которые можно внедрить сразу.
Решение
Артём Бородин, Agile-эксперт Sibedge, провёл 3 недели в плотной работе с командами заказчика: неделя подготовки и две недели непосредственно в офисе Alif Tech в Душанбе. Очное присутствие было принципиальным. Живые наблюдения дают то, что никогда не передаётся через сообщения и созвоны.
01
Интервью с ключевыми участниками
Более 15 глубинных интервью: Team Leads, PM, Product Owner, разработчики, QA, продуктовый директор, руководитель IT-департамента. Каждый уровень иерархии — свой угол зрения на одни и те же процессы.
02
Наблюдение за ритуалами
Мы погрузились в оффлайн стендапы, ретроспективы, планирования, демо. Без предупреждения и подготовки со стороны команд. Это позволило сделать важные наблюдения.
Стендапы превратились в утренние отчёты менеджеру: команда отчитывалась о статусах вместо того, чтобы синхронизироваться и снимать блокеры.
Ретроспективы велись в Excel, без трекинга решений, без ответственных, без проверки выполнения. Договорённости испарялись между встречами.
Демо как практики не существовало вовсе: стейкхолдеры не видели продукт до релиза, обратная связь приходила слишком поздно и слишком дорого обходилась.
Стендапы превратились в утренние отчёты менеджеру: команда отчитывалась о статусах вместо того, чтобы синхронизироваться и снимать блокеры.
Ретроспективы велись в Excel, без трекинга решений, без ответственных, без проверки выполнения. Договорённости испарялись между встречами.
Демо как практики не существовало вовсе: стейкхолдеры не видели продукт до релиза, обратная связь приходила слишком поздно и слишком дорого обходилась.
03
Аудит артефактов и задач
Анализ реальных задач в системах управления выявил отсутствие User Story, Acceptance Criteria, Definition of Ready и Done. Каждая команда вела бэклог по-своему, единой точки правды не существовало. Разработчики начинали задачи, не понимая критериев готовности. QA получали задачи без описания ожидаемого поведения. Это не организационная небрежность, а системная потеря скорости на каждом цикле.
04
Формирование heatmap проблемных зон
Карта обновлялась по ходу аудита. Это позволило увидеть системные паттерны ещё до окончания полевой работы и сфокусировать глубину анализа там, где это было важнее всего.
05
Разработка целевой архитектуры
По результатам диагностики стало ясно: «починить Scrum» недостаточно. Масштаб компании требовал перехода на SAFe с перестройкой команд с компонентной модели на потоки ценности. Был выбран первый кандидат для Agile Release Train.
Результат
По итогам аудита клиент получил исчерпывающую базу для трансформации. Конкретный план с приоритетами и обоснованием каждого шага:
- 200-страничный отчёт с полной диагностикой: карта проблем, категоризация по критичности (Blocker / Critical / Major), аудит задач и ритуалов с конкретными примерами;
- Дорожная карта трансформации к SAFe: целевая структура команд, новые роли, процессы и метрики. С обоснованием, почему именно эта методология, и почему альтернативы не подходят;
- 23 быстрых изменения. Конкретные действия, которые можно запустить без длительной реструктуризации: от формата задач и ретроспектив до метрик;
- Сдвиг мышления от «Scrum как набор процессов» к «Agile как способ думать». Именно это изменение определяет устойчивость любой трансформации.
Ожидаемый эффект для бизнеса
- Более понятные сроки и результаты за счёт общего ритма планирования;
- Ускорение Time to Market благодаря end-to-end фича-командам;
- Масштабируемая модель роста без хаотичного расширения команд;
- Рост вовлечённости и ответственности команд за результат
Вывод
Alif Tech – показательный пример того, как компания может делать всё «правильно» внешне и при этом терять скорость изнутри. Ритуалы были. Роли были. Инструменты были. Не хватало системы, в которой всё это работает вместе, и культуры, в которой изменение воспринимается не как угроза, а как нормальный рабочий режим.
Трансформация – это не точка назначения, а процесс постоянного улучшения. Именно к этому мы сдвигали мышление команд Alif Tech, и с этим пониманием они входят в следующий этап роста.
Трансформация – это не точка назначения, а процесс постоянного улучшения. Именно к этому мы сдвигали мышление команд Alif Tech, и с этим пониманием они входят в следующий этап роста.
Хотите с нами сотрудничать?
Заполните форму, и мы с вами свяжемся