Как стать автором
Обновить
0
ВТБ Лизинг
ВТБ Лизинг – лизинговая компания

Повесть о двух департаментах, или как в ВТБ Лизинге Agile прививали

Время на прочтение 13 мин
Количество просмотров 6K

Если вы работали в больших компаниях, то знаете, что это за ощущение: у вас вроде бы есть всё для реализации себя как профессионала, все условия для воплощения в жизнь любых идей и задач — однако что-то неосязаемое не даёт планам исполниться, а в голову лезут мысли, что инициатива наказуема и что хата твоя с краю. Когда я полтора года назад пришёл в ВТБ Лизинг, решил, что в моём департаменте всё будет по-другому.

Меня зовут Константин Морозов (morozovvtbl), и я руководитель управления развития информационных систем — то есть отвечаю за всю разработку в ВТБ Лизинге, а также лидирую Agile-трансформацию в компании. В этой статье я расскажу о том, как мы внедрили гибкую разработку в крупную компанию консервативного толка.


Весь последний год мы погружались в культуру Agile. Направление новое и прогрессивное по меркам финансового сектора, где консерватизм традиционно считают залогом надёжности. Потому Agile в связанной с финансами разработке часто воспринимают как игрушку для IT-стартапов.

К тому же ВТБ Лизинг — компания с устоявшимися технологическими и бизнес-процессами. Менять производственную культуру в таких организациях — задача особенно интересная и увлекательная.

Как было, когда я только пришёл

Большинство проектов, почти 80%, реализовывались с опозданием. Большинство заявок на автоматизацию (до 70%) исполнялись с задержкой. Структура компании вертикальная, с делением на департаменты по функциональности. Департамент IT работал на все подразделения и получал противоречивые требования от разных направлений. Продукт шёл через подразделения, преодолевая барьеры, вместо того чтобы готовиться одной командой.

Еженедельные «комитеты по изменениям» проходили с большим накалом. Все участники от IT воспринимали эти встречи как «экзекуцию» — показательную порку кого-нибудь из айтишников или даже всех сразу: человек 30 заказчиков отчитывало наших IT-тимлидов. В результате люди пачками увольнялись, не выдерживая стресса (в частности, именно это случилось с одним из ведущих разрабов). Всем всё важно, всем всё срочно. Годовое планирование представляло собой огромную массу задач от всех департаментов, необходимо было поставить сроки исполнения, а потом ещё и уложиться в них. Но на деле требования были нечёткие, а заказчик далеко не всегда понимал, чего хочет. От семи подразделений накопился список из 650 задач.

К началу 2020 года у нас оставалось 456 задач в плане релизов со сроками. При этом условия были ограниченные. Сколько потребуется времени? Какой нужен бюджет? До 40% заявок, созданных заказчиками в Jira, ими же и отменялись, а все камни летели в сторону IT-департамента как главного виновника всех бед («делают ерунду, не понимая, чего от них хотят»).

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

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

От IT требовали окончательных ответов и точных сроков при отсутствии какой бы то ни было ясности задач. Это вызывало постоянные конфликты: дать план на год вперёд и попасть в него невозможно. Слишком переменчивые условия. Было совершенно очевидно, что «проектная» тактика тут не сработает и нужно искать иной подход. Waterfall во всех направлениях деятельности привёл к появлению кучи регламентов, за которыми люди стали прятаться, и это явно не шло на пользу делу.

В итоге команда управления развитием информационных систем поняла, что нам нужна итеративная разработка с горизонтом планирования в один месяц (более длительные сроки относятся уже к категории ви́дения, а не строгого планирования), разделённый на спринты по две-четыре недели (их точное число каждая команда выбирает сама). А это, соответственно, уже Scrum. Мне очень сильно повезло прийти в компанию в тот момент, когда там появился новый генеральный директор, и он уже начал изменять ее. Хотя до IT еще не дотянулся. Все-таки важно, в какую почву падает посеянное тобой зерно, в каменистой земле шансов у нас было бы немного. И все равно на то, чтобы топы приняли идею Agile, ушло около четырёх месяцев: нужны были доказательства.

Доказательства

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

Я использовал все инструменты, которые мог:

  1. Выступал на всех доступных мне площадках (таун-холлы бизнес-подразделений).

  2. При обсуждении каждой проблемной ситуации  на совещаниях всех уровней подробно объяснял, как мы бы её решили при помощи Agile Scrum (а точнее, сделали бы так, чтобы проблема не возникла).

  3. Узнал, что в нашей «маме» (ВТБ) использовались эджайлоподобные практики, и начал обращать на это внимание других: раз «мама» применяет — значит это работает!

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

Мои усилия не пропали даром: лёд тронулся, и в итоге народ начал говорить про Agile. А когда идею обсуждают, её сложно игнорировать. В целом процесс переубеждения занял 3–4 месяца (с октября 2019 по январь 2020 гг.), а затем я получил благословение на запуск пилота, и оставалось только добыть цифры, доказывающие мою правоту.

С января по май 2020 года я собирал команды для пилота и неустанно пропагандировал им ценности Agile. Сам пилот продлился с мая по декабрь 2020 года.

Пилотный проект

Любой человек сопротивляется новому. И один менеджмент для эффективного запуска переубедить было недостаточно: загореться идеей должны были все. Чтобы достучаться до них, пришлось выступать с убеждающими презентациями на всевозможных мероприятиях. Я напрашивался на собрания подразделений, которые с IT даже не связаны (риски, поддержка бизнеса, продажи), и в свои выступления всегда вставлял пару слов про то, как бы то, о чём я рассказываю, «сработало по Agile». Было крайне важно, чтобы про Agile начали говорить все; чтобы слово «agile» стало ассоциироваться у коллег с выходом из сложной ситуации.

Поскольку у нас не было продуктов, на которых получилось бы доказать работоспособность идеи, в качестве пилотного проекта мы решили «локально оптимизировать» работу двух подразделений: департамента поддержки бизнеса и финансового департамента. Мы определили, что за сервисы/продукты есть в этих департаментах, определили бэклоги и на их основе сформировали StarMap для каждого из направлений. Это и был плацдарм для пилота.

Затем набирали людей в команду. Критериев отбора было всего два:

  1. Должны гореть глаза.

  2. Компетенции должны попадать в StarMap.

Мы сформировали кросс-функциональные команды под функциональные подразделения компании и организовали обучение заказчиков и айтишников гибким методам разработки. Все коммуникации и процессы пришлось выстраивать с нуля.

С самого начала мы пытались соответствовать ценностям Agile в работе и даже просто в общении. Снизили градус накала еженедельных встреч («комитетов по изменениям»), на которые собирались представители департаментов. На этих совещаниях мы действительно старались слушать друг друга. Вскоре решили попробовать Scrum: он хорошо подходит для тестирования гипотез и резкого изменения процессов, а ещё позволяет быстро выдавать результат и получать обратную связь. Последнее мы посчитали особенно важным: уж слишком много неопределённости было в пилотных целях и проектах.

Работали мы удалённо, используя Zoom, Miro и Jira; все команды запускались также в удалённом режиме. Честно говоря, тот ещё опыт: Agile — это ведь про людей и взаимодействие, а у нас эти люди раскиданы по всей стране.

В качестве метрик мы выбрали:

  • CSI (Customer satisfaction index; индекс удовлетворённости клиентов). Простыми словами: понравился ли вам продукт, воспользуетесь ли ещё?

  • Lead Time — среднее время выполнения задач пилотными командами (относительно первоначального показателя).

  • Количество ошибок в разработанном новом функционале продуктов (относительно первоначального показателя).

  • Оценка экономического эффекта в целом.

  • Количество зависших задач в очереди (бэклоге, долгом ящике).

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

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

Раньше бизнес-процессы проходили через несколько систем, и каждое подразделение выпускалось порознь. Юзерам порой приходилось ждать месяцами (кусочек от CRM будет готов сегодня, 1С — через месяц, а Oracle — через два). Фактически, мы не могли поставить ценность, даже если все работали хорошо и быстро в рамках своих отделов.

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

Велика земля наша, но порядка в ней нет: приходите и правьте нами

Ещё до старта пилота, на этапе формирования команд, я стал получать множество возражений в духе «Так не будет работать!». Я поймал себя на том, что постоянно рассказываю людям, как это работает, и безостановочно всех убеждаю. Когда этих людей двое-четверо, в этом нет ничего плохого, но их было за 30! И каждый из них готов был сделать всё, чтобы остаться в зоне комфорта. Стало понятно, что без профессионального тренера, который «укусит эджайлом», уже не обойтись.

Коуч был найден, и всё завертелось. Тренинг и последующее сопровождение команд длились два месяца, после чего команды стали потихоньку брать процессы в свои руки. Мы увидели, что культура Agile начинает приживаться. Более того, среди участников пилота появились убеждённые адепты этого подхода, которые стали проповедниками Agile-ценностей и активными участниками дальнейшей трансформации своих направлений. Пошла-поехала самоорганизация.

У нас был очень скудный бюджет на запуск и тренинг, несколько фасилитаторов на аутсорсе и неисчислимое количество задач от семи департаментов
У нас был очень скудный бюджет на запуск и тренинг, несколько фасилитаторов на аутсорсе и неисчислимое количество задач от семи департаментов

Скоро сказка сказывается, да не скоро дело делается

Убедить менеджмент дать добро на запуск пилота оказалось не самой сложной задачей (хоть и архиважной). А вот заразить всю остальную команду идеалами Agile, даже с помощью профессионального тренера оказалось не так-то просто.

Дело в том, что, как выяснилось, компания ещё не оправилась от неудачных попыток «внедрить Agile», предпринятых много лет назад.

Тогда, в доисторические времена, мой предшественник видимо совершил классическую ошибку - он нёс свет Agile в массы под видом упрощения процессов разработки.

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

Ввиду искажённого восприятия культуры как чего-то механически «внедряемого» люди думали, что речь идёт о наборе ритуалов, которые должны сработать как панацея (в общем, что-то вроде карго-культа). Итог предсказуем: полное отсутствие документации, огромный bus-фактор в IT (ведь каждому проще заниматься тем, что он уже знает и умеет; зачем ему изучать что-то новое и распространять компетенции, правда?) и все вытекающие от этого проблемы:

  • негатив заказчиков;

  • низкое качество функционала;

  • непредсказуемая по объёму поставка;

  • сложность в поддержке.

Прежде чем запускать пилот, нам пришлось потратить около полугода (четвёртый квартал 2019 г. и первый квартал 2020 г.), чтобы «отмыть» Agile от прошлых неудач. К сожалению, некий негатив и неприязнь к нашим нововведениям сохранились у ряда сотрудников до сих пор. Есть и такие, кому Agile просто не зашёл по личным причинам. Например, после смены уклада жизни в компании некоторые лишились своего статуса незаменимых звёзд. И всё же  с такими людьми, если они профессионалы своего дела, мы стараемся не расставаться, а совместно находить интересные области, где они могли бы продолжить расти.

Всплывало всякое:
  • разные KPI у смежных подразделений;

  • постоянные попытки «остальной компании» вернуть создаваемые Agile-команды в старые процессы (приходилось оберегать эти команды от уже сложившейся корпоративной культуры);

  • отсутствие в компании продуктовых и технических метрик (их пришлось создавать по ходу дела) и пр.

Итак, всего в пилотном проекте участвовали три команды на два направления бизнеса. От IT было около двадцати человек, от стейкхолдеров — примерно пять. Две команды из поддержки бизнеса запускались по Scrum. А вот в финансовом департаменте, как оказалось, лучше подошёл Kanban, потому что идея с быстрой поставкой там не сильно востребована. Там у них больше законодательства, внутренние и внешние аудиторы; да и вообще, финансовая область — это не про быструю поставку. Преимуществами Scrum они готовы пожертвовать в пользу визуализированного и предсказуемого результата. Поэтому мы решили не менять процессы резко, а идти к переменам последовательно. Благо Kanban позволяет отрисовать текущие положение и метрики, чтобы эффективно лечить там, где болит и где скапливаются заявки. Команды показывали планомерный рост и со временем самоорганизовались. В комфортный для себя момент они перешли к самостоятельному развитию от спринта к спринту. Теперь каждая команда чуть допиливает фреймворк под себя.

Отбираем продукты у подрядчиков

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

Сделать это было непросто ещё и потому, что в состав команд вошли сотрудники этих подрядчиков. Мы взяли их из-за нехватки ряда внутренних компетенций. Сотрудники подрядчика — это, по сути, работники с несколько иной мотивацией, нежели штатные сотрудники компании (и уж точно люди с другой культурой). Работа с ними просто не могла не давать сбоев. Например, вот что произошло с проектом «CRM корпоративного блока». Подрядчик неверно оценил сложность работы, а также не учёл систематически корректируемых ожиданий стейкхолдеров от системы и фактор изменчивости бизнес-среды. Чтобы исправить ситуацию, мы с нуля собрали команду из четырёх человек, запустили там итеративные процессы и начали прививать Agile-культуру. Сейчас эта команда разрабатывает новый лизинговый калькулятор для корпоративного блока, и мы ожидаем, что уже этой осенью до 80 % всех расчётов будет проходить на их продукте.

Есть мнение, что с подрядчиком реализовать успешную Agile-трансформацию нельзя в принципе, но мы вроде как справились — благодаря тому, что соблюдали баланс между штатными сотрудниками и работниками подрядчика в командах и старались, чтобы внутренние аналитики покрывали все компетенции с точки зрения понимания функционала, а программисты могли приходить извне. Правильная работа с людьми подрядчика и заключение договора T&M позволили создать одну команду, в которой подряд составлял целых 60 % от числа участников.

Перенос разработки внутрь и начало реализации по Scrum дали старт продуктовой разработке в компании; более того, на внутреннюю, домашнюю разработку мы теперь делаем ставку. Каждый год штат разработчиков растёт на 50 %. После ряда успешных кейсов в рамках Agile-пилота был выбран ещё один продукт, работу над которым мы начали строить по гибкой методологии: это конкурент каршеринга, который называется «Автомобиль по подписке». На рынке эта штука недавно, и сейчас её запускают в том числе и наши конкуренты. Было понятно, что столь сложную задачу, где нет времени на раскачку, нельзя запускать по классической модели Waterfall, и мы сделали ставку на Agile. Оперативно собрали команду из уже имеющихся заинтересованных сотрудников и начали работу. На разработку нам дали всего 5 месяцев!

Если MVP продукта получится вывести на рынок в ожидаемые сроки, мы плавно начнём перемещать подход компании с проектного в сторону продуктового.

Набитые шишки и наполеоновские планы

Результаты пилота порадовали как его прямых участников, так и вовлечённые стороны; опыт оказался позитивным и в качественном, и в количественном плане.

Самое главное — мы смогли сделать так, что многие стейкхолдеры из других направлений, не включённых в пилотный проект, стали приходить к нам с долгожданными словами: «Сделайте нам так же, как у вас в пилоте».

Количественные показатели:

  • Lead Time (средн.): −17 %.

  • CSI (средн.): +18 %.

  • Ошибки функционала: −40 %.

  • Прямой экономический эффект: +264.5 млн руб.

  • Очередь задач: −8 %.

Отзывы ключевых стейкхолдеров вполне благожелательны:

Владелец продукта в департаменте поддержки бизнеса:

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


Scrum-мастер команды департамента поддержки бизнеса:

«Я была настроена скептически, так как у нас уже была неудачная попытка внедрения Agile. Мне не верилось, что эта методология сможет «лечь» на наши негибкие процессы. В итоге на обучении для меня стало неожиданностью, когда мы смогли решить неподъёмную на первый взгляд задачу всего за несколько итераций. Я осознала, что такое возможно. Мотивация выросла. Также очень большим сдвигом стало появление владельца продукта, который по максимуму освободил нас от решения несвязанных с работой нашей команды вопросов. Мне нравится приносить пользу, и сейчас эту пользу мы практически оцифровали, можем её измерить и почувствовать поддержку бизнеса!»

Положительный опыт даёт причины и мотивацию продолжать. В последнее время мы всё чаще слышим фразу: «Нужно масштабировать изменения».

В ходе прививания Agile в компании было создано нескольких кросс-функциональных команд для выпуска отдельных продуктов. Теперь мы стали всерьёз задумываться о глобальных изменениях:

  • Трансформация, уплощение оргструктуры компании в целом.

  • Применение «продуктового» подхода.

  • Больше in-house разработки; появление в командах выделенных Scrum-мастеров; развитие командных и продуктовых метрик.

  • Поднять уровень коллаборации между командами на новый уровень 

  • Разработка собственной IT-платформы (окончательный переход на in-house).

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

В 2020 г., благодаря гибкости в принятии решений, мой департамент смог реализовать идеи, эффект от которых составил почти на 3 млрд руб. больше, чем изначально планировалось. В 2021 г. мы хотим побить этот рекорд и дать нашей компании тот time to market, который ей необходим.

То, к чему мы теперь идём, получило в мировой практике название LeSS (Large-Scale Scrum), что означает «Scrum большого масштаба (масштаба крупной организации)».

При этом мы стараемся двигаться поступательно. После успешных «CRM корпоративного блока» и «Автоматизированной системы службы сопровождения клиентов» доводим до ума сервис «Автомобиль по подписке». Полная команда для работы над этим продуктом уже работает (аналитики, разработчики и др.). Дальше будем запускать новые продукты, последовательно переводя компанию на продуктовую разработку. Прямо сейчас формируются ещё три команды. У нас теперь есть свои Scrum-мастера, а также владельцы продукта, ответственные за видение и планы по развития своих продуктов на долгосрочную перспективу.

Послесловие

Убедить менеджмент принять Agile , безусловно, важно, но не слишком сложно при благоприятных обстоятельствах. Да, мне пришлось попотеть, но одобрение от руководства в итоге было получено (тут можно про них написать что-то хорошее типа «благодаря их дальновидности и вере в то, что это может сработать», но статья и так уже слишком длинная).

Гораздо труднее донести до всех остальных, что в Agile есть смысл, а потом суметь правильно привить им эту культуру.

Если воспринимать Agile как набор практик, которые просто нужно бездумно повторять, получится карго-культ. Когда я только пришёл в компанию, наблюдал последствия такого подхода. Восприятие Agile просто как методологи привело к тому, что люди натянули новые термины и определения на старый рабочий процесс (ведь бизнес у них никак не менялся) и перестали писать документацию, превратно истолковав одну из ценностей Agile-культуры. Потому-то мне и пришлось потрудиться, чтобы всех переубедить.

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

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

  • Нужно проводить как можно больше агитационной и разъяснительной работы. Производственная культура живёт не столько в нормативных документах, сколько в головах и сердцах сотрудников.

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

  • Изменения в компании не возможны без полноценного вовлечения в них и всесторонней поддержки ее топ-менеджмента. 

Давайте обсудим культуру Agile — особенно интересно было бы узнать о вашем опыте: удалось ли внедрить эти методы в вашей рабочей среде, как именно это получилось, или наоборот, почему Agile у вас так и не взлетел. Ну и, разумеется, если у вас есть вопросы, я могу подробнее рассказать о том, как сейчас устроена разработка в ВТБ Лизинге.

Теги:
Хабы:
+13
Комментарии 29
Комментарии Комментарии 29

Публикации

Информация

Сайт
www.vtb-leasing.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия

Истории