Agile без обязаловки и фанатизма — как мы в МКБ перевернули канонический подход и прокачали цифровые сервисы

Я пятнадцать лет работаю в финансовом секторе. До этого у меня были проекты в нефтянке, с государственными заказчиками, в сфере образования, в промышленной автоматизации. Это сформировало определенную гибкость, теперь погружение в новую предметную область происходит быстро.

Сейчас мы работаем над цифровизацией в МКБ. Это не просто проект — это огромный вызов.

— В бэк-офисе мы избавляемся от бумаги, увеличиваем возможности электронного взаимодействия: от подбора кадров до логистики. Например, с помощью сложной математики можно определить, сколько наличности надо закладывать в банкоматы. Или оптимизировать маршруты инкассаторов.

— Мы внедряем речевую аналитику в контакт-центр для контроля качества взаимодействия с нашими клиентами и для большей эффективности в удаленных продажах. Первоначально это технология speech-to-text. Весь массив разговоров превращается в текст, и начинается большая аналитика. Мы ищем сотрудников контакт-центра, которые наиболее эффективны, ищем корреляции между тем, как они говорят, и их результатом. Это одновременно технологическая и творческая работа — выяснить по тексту, почему одни сотрудники успешнее других, и научить правильным подходам всех.

— Еще одна история — подключение чатов и создание многоканальной платформы. Здесь мы в начале пути. Когда в чатах накопится большой объем текста, его тоже надо будет проанализировать, создать чат-бота, и часть вопросов клиентов решать с его помощью.

— Но наш самый успешный кейс — это обновление мобильного приложения. За год мы поднялись на восемь пунктов в Mobile Banking Rank, у нас увеличился трафик в полтора раза и примерно на столько же — количество активных клиентов. Причем мы не делали дорогой рекламной кампании, а добивались эффекта созданием полезной функциональности, переделкой интерфейса и повышением удобства.

Раньше у нас были не команды, а то, что я бы назвал феодальными княжествами. Например, отдельная команда программистов, они не общались ни с аналитиками, ни с бизнесом, или общались только через начальника, очень формально.

Одна из команд разработки находится в тверском офисе. Очень классные позитивные ребята. Но до определенного момента остальная команда ни разу их в глаза не видела. Хотя Тверь — это не Владивосток. Можно за пару часов доехать на электричке и сломать все коммуникационные барьеры.

Понятно, почему этого не делалось — мешала иерархия. Когда люди знакомы и периодически общаются лично, уровень доверия и взаимопонимания всегда намного выше. Поэтому мы сломали старые установки и бюрократические препоны и собрали команду в одном пространстве.

Год назад у нас была просто большая тусовка человек из сорока. Теперь же есть четкое продуктовое деление: люди, которые занимаются депозитными продуктами, кредитными, которые отвечают за разработку бэк-офисных систем. Сотрудники поделились на команды сами и поняли, что так эффективнее. Теперь процессом разработки дирижируют владельцы продуктов, а не начальники департаментов.

Но сломать иерархию и перемешать всех в один пул — недостаточно. Нужны определенные организационные мероприятия и инструменты.

Иногда я сталкивался с сопротивлением, внедряя Agile в корпорации. Сталкивался и с тем, что люди из-за этого уходили. Когда происходят большие изменения, нарастает напряжение, начинаются изменения в кадровом составе. Хотя на деле процессы могут не меняться радикально, просто люди начинают думать по-другому.

Agile — это только система ценностей, то, что написано в манифесте, ни больше ни меньше. Там нет никаких ритуалов, лишь набор аксиом. Они ничего не говорят о методологии разработки и ведении проектов. Можно разделять ценности Agile и работать в Waterfall.

Ритуалы, обряды и описания процесса находятся в методологиях. Поэтому очень часто люди путают Scrum c Agile. У меня есть знакомые, которые говорят: «Аджайл равен cкраму, cкрам должен насаждаться сверху, на всех сразу. Просто делим людей на скрам-команды по семь человек, и вперед. А если у вас нет стендапа каждый день, значит, у вас не cкрам, не аджайл, и работать вы не умеете».

Я не фанат жесткой привязки к обрядам и ритуалам и позволяю командам выбирать практики самим, особенно хорошо это работает на начальном этапе внедрения. Только через год-полтора надо смотреть, кто показал большую эффективность, и устраивать внутренний обмен опытом, тиражировать успешные решения.

После этого можно перевести всех на одну методику, адаптированную под особенности компании. В такой метод внедрения я верю — когда не дядя-начальник заставляет всех «завтра же перейти на скрам», а команды сами доходят до лучших решений, делятся практиками и инструментами.

Работать по специальности (а я заканчивал факультет компьютерных наук и информационных технологий в Саратовском государственном университете) я начал еще во время учебы. В 2004 у нас была команда из трех человек, и мы получили заказ от министерства труда и социального развития. Важные люди пообещали, что первого мая будет торжественный запуск продукта, сотрудникам раздадут компьютеры, принтеры, и тут же начнется работа. Дата была утверждена на министерском уровне, сдвинуть ее было уже нельзя.

Сейчас интеграторы берут за подобное десятки миллионов рублей, закладывают пару лет и набирают огромную команду. Мы разработали систему втроем за пять месяцев. Отказались от идеи какого бы то ни было ТЗ и уже через две недели принесли заказчику прототип. Он печатал нам скриншоты, делал на них правки от руки. Мы встречались два раза в неделю и приносили очередную версию. Фактически работали спринтами.

В итоге готовая система работала автономно, не падала, не просила колл-центра, не требовала первой, второй и третьей линий поддержки. Данные собирались по райцентрам и регионам, агрегировались на федеральный уровень — все это сопровождалось работой одного человека, даже не IT-специалиста.

Мы дошли до этого подхода сами, ничего специально не изучая. Конечно, начитались книжек про экстремальное программирование — тогда эта тема только набирала обороты. Все остальное пришло интуитивно. Квалифицированные и мотивированные люди сами выбирают правильные методы чутьем.

Уже потом мы с коллегой проанализировали подход и поняли…

Выше я рассказал про свободу в нашей команде. Но, конечно, есть несколько обязательных правил и установок, которые я требовал соблюдать:

— Все должны жить в общем таск-трекере. Один мой коллега утверждал, что невозможно заставить всех жить в едином трекере, что каждая команда рано или поздно уходит в свой. Но у нас получается.

— Необходимость трекинга времени. Мы управляем стоимостью — считаем, дорого ли нам стоят новые фичи, считаем time to market. Без общих правил делать такие вещи не получится.

— Обязательная для всех и примерно одинаковая структура работ, общий подход к декомпозиции. Например, большие задачи надо оценивать без декомпозиции и постановки. Эти оценки нужны даже с высокой погрешностью, чтобы соотносить потребности заказчика и количество людей в IТ. Нельзя оказываться в ситуации, где у бизнеса есть план на сто проектов, а мы можем разработать только десять.

Команде не всегда нравятся ограничения, которые я спускаю и от которых не готов отказаться. Периодически я получаю критику. Больше всего ребята хотят убрать «тайм-шитинг» или отказаться от жесткой структуры работ. Хотят вести только спринты, и не заводить таски на всю структуру.

Может, это несколько цинично с моей стороны, но я сказал, что готов отменить большинство ограничений для тех, кто покажет без них лучший результат с точки зрения качества продукта. И «процессные костыли» — предохранители, которые не дают качеству упасть, когда команда гонится за новыми достижениями.

Команда понимает, что они идут первыми, идут по тонкому льду. Когда ты делаешь что-то новое, очень важно ощущение безопасности, чтобы соседние команды не показывали пальцем: «Сейчас у вас ничего не получится, и вас всех расстреляют».

Мы перешли на удаленку гладко, даже обогнали многих коллег по банковской сфере. В конце марта все, кто мог работать удаленно, уже работали из дома. Мы вовремя осознали, что организация удаленного доступа — это критичный объект инфраструктуры, его надо защищать и выделять на это дополнительные мощности.

Сейчас все топ-менеджеры радуются — оказывается, ничего не сломалось. Для меня, как для IT-руководителя, радости мало. Ведь это означает, что мы уже владели инструментарием, который повышает нашу эффективность, делает нас более гибкими, позволят нанимать людей за пределами привычных нам городов — и не пользовались им.

Да, все оказались изолированы, хотя раньше многие сидели в опенспейсе без кабинетов. Когда вы все были собраны в хорошем общем офисе, а потом разошлись по углам — определенно что-то теряется. Но есть и плюсы. Мы тратили по три часа на дорогу. А сейчас можем уделять больше времени и работе, и себе.

Я не говорю, что всем навсегда теперь надо уйти на удаленку. Но использовать этот инструмент в дальнейшем нужно обязательно. Просто надо подходить к нему без фанатизма. Сохранить опенспейсы и возможность собираться, но уже без обязаловки, как раньше.

Людям, которые не верят в Agile или говорят, что это не подходит крупным организациям, важно помнить — это просто набор ценностей, который работает, если сохранять разумность и уметь договариваться с бизнесом.

Когда мы внедряем Agile, то стремимся к двум вещам:

Первая — это внутренняя эффективность. Есть очень много процессов, которые мы автоматизировали и будем автоматизировать. Но не для красоты, не просто, чтобы всем было удобно нажимать на кнопки. Технологии — этот способ оптимизировать процессы и быть менее затратными. Потому что когда мы смотрим на автоматизацию поддерживающих функций, мы всегда думаем об экономике.

Вторая цель — сделать IT-подразделение полноценным партнером для бизнеса, который приносит идеи, помогает зарабатывать. Для владельцев продукта вклад в технологии ради результата — основное. Мы это понимаем и хотим дальше жить в этой парадигме, когда IT-блок не просто отрабатывает спущенные сверху заказы, а выступает партнером и приносит идеи зарабатывания денег.