Если вы работали в больших компаниях, то знаете, что это за ощущение: у вас вроде бы есть всё для реализации себя как профессионала, все условия для воплощения в жизнь любых идей и задач — однако что-то неосязаемое не даёт планам исполниться, а в голову лезут мысли, что инициатива наказуема и что хата твоя с краю. Когда я полтора года назад пришёл в ВТБ Лизинг, решил, что в моём департаменте всё будет по-другому.
Меня зовут Константин Морозов (morozovvtbl), и я руководитель управления развития информационных систем — то есть отвечаю за всю разработку в ВТБ Лизинге, а также лидирую Agile-трансформацию в компании. В этой статье я расскажу о том, как мы внедрили гибкую разработку в крупную компанию консервативного толка.
Весь последний год мы погружались в культуру Agile. Направление новое и прогрессивное по меркам финансового сектора, где консерватизм традиционно считают залогом надёжности. Потому Agile в связанной с финансами разработке часто воспринимают как игрушку для IT-стартапов.
К тому же ВТБ Лизинг — компания с устоявшимися технологическими и бизнес-процессами. Менять производственную культуру в таких организациях — задача особенно интересная и увлекательная.
Еженедельные «комитеты по изменениям» проходили с большим накалом. Все участники от IT воспринимали эти встречи как «экзекуцию» — показательную порку кого-нибудь из айтишников или даже всех сразу: человек 30 заказчиков отчитывало наших IT-тимлидов. В результате люди пачками увольнялись, не выдерживая стресса (в частности, именно это случилось с одним из ведущих разрабов). Всем всё важно, всем всё срочно. Годовое планирование представляло собой огромную массу задач от всех департаментов, необходимо было поставить сроки исполнения, а потом ещё и уложиться в них. Но на деле требования были нечёткие, а заказчик далеко не всегда понимал, чего хочет. От семи подразделений накопился список из 650 задач.
К началу 2020 года у нас оставалось 456 задач в плане релизов со сроками. При этом условия были ограниченные. Сколько потребуется времени? Какой нужен бюджет? До 40% заявок, созданных заказчиками в Jira, ими же и отменялись, а все камни летели в сторону IT-департамента как главного виновника всех бед («делают ерунду, не понимая, чего от них хотят»).
К примеру, «Электронный архив» мы реализовывали в два раза дольше, чем должны были: вместо шести месяцев у нас ушёл на него год, потому что в процессе вылезали уточнения.
В годовом плане менеджеры хотели от меня прибитых гвоздями обещаний. При том, что требования от департаментов были разрознены и сформулированы сумбурно, напоминая скорее гипотезы. Представьте, что у вас тысяча заявок, и одна из них сместилась. Теперь нужно на диаграмме Ганта смещать весь следующий за ней хвост из 500 других заявок. В декабре утвердили план, а уже в январе его пересматривали.
От IT требовали окончательных ответов и точных сроков при отсутствии какой бы то ни было ясности задач. Это вызывало постоянные конфликты: дать план на год вперёд и попасть в него невозможно. Слишком переменчивые условия. Было совершенно очевидно, что «проектная» тактика тут не сработает и нужно искать иной подход. Waterfall во всех направлениях деятельности привёл к появлению кучи регламентов, за которыми люди стали прятаться, и это явно не шло на пользу делу.
В итоге команда управления развитием информационных систем поняла, что нам нужна итеративная разработка с горизонтом планирования в один месяц (более длительные сроки относятся уже к категории ви́дения, а не строгого планирования), разделённый на спринты по две-четыре недели (их точное число каждая команда выбирает сама). А это, соответственно, уже Scrum. Мне очень сильно повезло прийти в компанию в тот момент, когда там появился новый генеральный директор, и он уже начал изменять ее. Хотя до IT еще не дотянулся. Все-таки важно, в какую почву падает посеянное тобой зерно, в каменистой земле шансов у нас было бы немного. И все равно на то, чтобы топы приняли идею Agile, ушло около четырёх месяцев: нужны были доказательства.
Я использовал все инструменты, которые мог:
С января по май 2020 года я собирал команды для пилота и неустанно пропагандировал им ценности Agile. Сам пилот продлился с мая по декабрь 2020 года.
Поскольку у нас не было продуктов, на которых получилось бы доказать работоспособность идеи, в качестве пилотного проекта мы решили «локально оптимизировать» работу двух подразделений: департамента поддержки бизнеса и финансового департамента. Мы определили, что за сервисы/продукты есть в этих департаментах, определили бэклоги и на их основе сформировали StarMap для каждого из направлений. Это и был плацдарм для пилота.
Затем набирали людей в команду. Критериев отбора было всего два:
С самого начала мы пытались соответствовать ценностям Agile в работе и даже просто в общении. Снизили градус накала еженедельных встреч («комитетов по изменениям»), на которые собирались представители департаментов. На этих совещаниях мы действительно старались слушать друг друга. Вскоре решили попробовать Scrum: он хорошо подходит для тестирования гипотез и резкого изменения процессов, а ещё позволяет быстро выдавать результат и получать обратную связь. Последнее мы посчитали особенно важным: уж слишком много неопределённости было в пилотных целях и проектах.
Работали мы удалённо, используя Zoom, Miro и Jira; все команды запускались также в удалённом режиме. Честно говоря, тот ещё опыт: Agile — это ведь про людей и взаимодействие, а у нас эти люди раскиданы по всей стране.
В качестве метрик мы выбрали:
Да, в итоге именно отсутствие железобетонного плана помогло нам справиться. Мы быстро поняли, что, как и в любом другом проекте, эффективность нужно показывать на цифрах, и делали всё, чтобы понять, как наши действия влияют на ключевые метрики. После того как понимание пришло, мы действовали точечно, и результат не заставил себя долго ждать.
Раньше бизнес-процессы проходили через несколько систем, и каждое подразделение выпускалось порознь. Юзерам порой приходилось ждать месяцами (кусочек от CRM будет готов сегодня, 1С — через месяц, а Oracle — через два). Фактически, мы не могли поставить ценность, даже если все работали хорошо и быстро в рамках своих отделов.
В пилотном проекте мы несколько причесали процессы, добившись единого производственного цикла, когда все IT-системы обновляются синхронно. Это позволило добиться снижения сроков поставки интеграционных задач. Компетенции по IT-подразделениям постепенно начали выравниваться. Взаимодействие с заказчиками стало прозрачней и продуктивней для обеих сторон.
Коуч был найден, и всё завертелось. Тренинг и последующее сопровождение команд длились два месяца, после чего команды стали потихоньку брать процессы в свои руки. Мы увидели, что культура Agile начинает приживаться. Более того, среди участников пилота появились убеждённые адепты этого подхода, которые стали проповедниками Agile-ценностей и активными участниками дальнейшей трансформации своих направлений. Пошла-поехала самоорганизация.
У нас был очень скудный бюджет на запуск и тренинг, несколько фасилитаторов на аутсорсе и неисчислимое количество задач от семи департаментов
Дело в том, что, как выяснилось, компания ещё не оправилась от неудачных попыток «внедрить Agile», предпринятых много лет назад.
Тогда, в доисторические времена, мой предшественник видимо совершил классическую ошибку - он нёс свет Agile в массы под видом упрощения процессов разработки.
В итоге инструменты Agile применялись бездумно, с единственной целью — не делать обязательных вещей вроде написания документации или регрессионного тестирования.
Ввиду искажённого восприятия культуры как чего-то механически «внедряемого» люди думали, что речь идёт о наборе ритуалов, которые должны сработать как панацея (в общем, что-то вроде карго-культа). Итог предсказуем: полное отсутствие документации, огромный bus-фактор в IT (ведь каждому проще заниматься тем, что он уже знает и умеет; зачем ему изучать что-то новое и распространять компетенции, правда?) и все вытекающие от этого проблемы:
Всплывало всякое:
Сделать это было непросто ещё и потому, что в состав команд вошли сотрудники этих подрядчиков. Мы взяли их из-за нехватки ряда внутренних компетенций. Сотрудники подрядчика — это, по сути, работники с несколько иной мотивацией, нежели штатные сотрудники компании (и уж точно люди с другой культурой). Работа с ними просто не могла не давать сбоев. Например, вот что произошло с проектом «CRM корпоративного блока». Подрядчик неверно оценил сложность работы, а также не учёл систематически корректируемых ожиданий стейкхолдеров от системы и фактор изменчивости бизнес-среды. Чтобы исправить ситуацию, мы с нуля собрали команду из четырёх человек, запустили там итеративные процессы и начали прививать Agile-культуру. Сейчас эта команда разрабатывает новый лизинговый калькулятор для корпоративного блока, и мы ожидаем, что уже этой осенью до 80 % всех расчётов будет проходить на их продукте.
Есть мнение, что с подрядчиком реализовать успешную Agile-трансформацию нельзя в принципе, но мы вроде как справились — благодаря тому, что соблюдали баланс между штатными сотрудниками и работниками подрядчика в командах и старались, чтобы внутренние аналитики покрывали все компетенции с точки зрения понимания функционала, а программисты могли приходить извне. Правильная работа с людьми подрядчика и заключение договора T&M позволили создать одну команду, в которой подряд составлял целых 60 % от числа участников.
Перенос разработки внутрь и начало реализации по Scrum дали старт продуктовой разработке в компании; более того, на внутреннюю, домашнюю разработку мы теперь делаем ставку. Каждый год штат разработчиков растёт на 50 %. После ряда успешных кейсов в рамках Agile-пилота был выбран ещё один продукт, работу над которым мы начали строить по гибкой методологии: это конкурент каршеринга, который называется «Автомобиль по подписке». На рынке эта штука недавно, и сейчас её запускают в том числе и наши конкуренты. Было понятно, что столь сложную задачу, где нет времени на раскачку, нельзя запускать по классической модели Waterfall, и мы сделали ставку на Agile. Оперативно собрали команду из уже имеющихся заинтересованных сотрудников и начали работу. На разработку нам дали всего 5 месяцев!
Если MVP продукта получится вывести на рынок в ожидаемые сроки, мы плавно начнём перемещать подход компании с проектного в сторону продуктового.
Самое главное — мы смогли сделать так, что многие стейкхолдеры из других направлений, не включённых в пилотный проект, стали приходить к нам с долгожданными словами: «Сделайте нам так же, как у вас в пилоте».
Количественные показатели:
Владелец продукта в департаменте поддержки бизнеса:
«С появлением Agile-команды бизнес и IT начали говорить на одном, понятном друг другу языке, что способствует поступательному развитию операционной функции в компании. Команда разработки постепенно интегрируется с бизнес-средой, что позитивно сказывается на востребованности и качестве реализованного IT-продукта».
Scrum-мастер команды департамента поддержки бизнеса:
«Я была настроена скептически, так как у нас уже была неудачная попытка внедрения Agile. Мне не верилось, что эта методология сможет «лечь» на наши негибкие процессы. В итоге на обучении для меня стало неожиданностью, когда мы смогли решить неподъёмную на первый взгляд задачу всего за несколько итераций. Я осознала, что такое возможно. Мотивация выросла. Также очень большим сдвигом стало появление владельца продукта, который по максимуму освободил нас от решения несвязанных с работой нашей команды вопросов. Мне нравится приносить пользу, и сейчас эту пользу мы практически оцифровали, можем её измерить и почувствовать поддержку бизнеса!»
Положительный опыт даёт причины и мотивацию продолжать. В последнее время мы всё чаще слышим фразу: «Нужно масштабировать изменения».
В ходе прививания Agile в компании было создано нескольких кросс-функциональных команд для выпуска отдельных продуктов. Теперь мы стали всерьёз задумываться о глобальных изменениях:
То, к чему мы теперь идём, получило в мировой практике название LeSS (Large-Scale Scrum), что означает «Scrum большого масштаба (масштаба крупной организации)».
При этом мы стараемся двигаться поступательно. После успешных «CRM корпоративного блока» и «Автоматизированной системы службы сопровождения клиентов» доводим до ума сервис «Автомобиль по подписке». Полная команда для работы над этим продуктом уже работает (аналитики, разработчики и др.). Дальше будем запускать новые продукты, последовательно переводя компанию на продуктовую разработку. Прямо сейчас формируются ещё три команды. У нас теперь есть свои Scrum-мастера, а также владельцы продукта, ответственные за видение и планы по развития своих продуктов на долгосрочную перспективу.
Гораздо труднее донести до всех остальных, что в Agile есть смысл, а потом суметь правильно привить им эту культуру.
Если воспринимать Agile как набор практик, которые просто нужно бездумно повторять, получится карго-культ. Когда я только пришёл в компанию, наблюдал последствия такого подхода. Восприятие Agile просто как методологи привело к тому, что люди натянули новые термины и определения на старый рабочий процесс (ведь бизнес у них никак не менялся) и перестали писать документацию, превратно истолковав одну из ценностей Agile-культуры. Потому-то мне и пришлось потрудиться, чтобы всех переубедить.
Но если всё с самого начала сделать правильно, жизнь всей компании кардинально улучшится. Опыт пилота помог мне понять, что вкладываться в людей и команду — это самая правильная инвестиция. Вот некоторые уроки, усвоенные за время пилота, которым я теперь следую:
habr.com
Меня зовут Константин Морозов (morozovvtbl), и я руководитель управления развития информационных систем — то есть отвечаю за всю разработку в ВТБ Лизинге, а также лидирую Agile-трансформацию в компании. В этой статье я расскажу о том, как мы внедрили гибкую разработку в крупную компанию консервативного толка.
Весь последний год мы погружались в культуру Agile. Направление новое и прогрессивное по меркам финансового сектора, где консерватизм традиционно считают залогом надёжности. Потому Agile в связанной с финансами разработке часто воспринимают как игрушку для IT-стартапов.
К тому же ВТБ Лизинг — компания с устоявшимися технологическими и бизнес-процессами. Менять производственную культуру в таких организациях — задача особенно интересная и увлекательная.
Как было, когда я только пришёл
Большинство проектов, почти 80%, реализовывались с опозданием. Большинство заявок на автоматизацию (до 70%) исполнялись с задержкой. Структура компании вертикальная, с делением на департаменты по функциональности. Департамент IT работал на все подразделения и получал противоречивые требования от разных направлений. Продукт шёл через подразделения, преодолевая барьеры, вместо того чтобы готовиться одной командой.Еженедельные «комитеты по изменениям» проходили с большим накалом. Все участники от IT воспринимали эти встречи как «экзекуцию» — показательную порку кого-нибудь из айтишников или даже всех сразу: человек 30 заказчиков отчитывало наших IT-тимлидов. В результате люди пачками увольнялись, не выдерживая стресса (в частности, именно это случилось с одним из ведущих разрабов). Всем всё важно, всем всё срочно. Годовое планирование представляло собой огромную массу задач от всех департаментов, необходимо было поставить сроки исполнения, а потом ещё и уложиться в них. Но на деле требования были нечёткие, а заказчик далеко не всегда понимал, чего хочет. От семи подразделений накопился список из 650 задач.
К началу 2020 года у нас оставалось 456 задач в плане релизов со сроками. При этом условия были ограниченные. Сколько потребуется времени? Какой нужен бюджет? До 40% заявок, созданных заказчиками в Jira, ими же и отменялись, а все камни летели в сторону IT-департамента как главного виновника всех бед («делают ерунду, не понимая, чего от них хотят»).
К примеру, «Электронный архив» мы реализовывали в два раза дольше, чем должны были: вместо шести месяцев у нас ушёл на него год, потому что в процессе вылезали уточнения.
В годовом плане менеджеры хотели от меня прибитых гвоздями обещаний. При том, что требования от департаментов были разрознены и сформулированы сумбурно, напоминая скорее гипотезы. Представьте, что у вас тысяча заявок, и одна из них сместилась. Теперь нужно на диаграмме Ганта смещать весь следующий за ней хвост из 500 других заявок. В декабре утвердили план, а уже в январе его пересматривали.
От IT требовали окончательных ответов и точных сроков при отсутствии какой бы то ни было ясности задач. Это вызывало постоянные конфликты: дать план на год вперёд и попасть в него невозможно. Слишком переменчивые условия. Было совершенно очевидно, что «проектная» тактика тут не сработает и нужно искать иной подход. Waterfall во всех направлениях деятельности привёл к появлению кучи регламентов, за которыми люди стали прятаться, и это явно не шло на пользу делу.
В итоге команда управления развитием информационных систем поняла, что нам нужна итеративная разработка с горизонтом планирования в один месяц (более длительные сроки относятся уже к категории ви́дения, а не строгого планирования), разделённый на спринты по две-четыре недели (их точное число каждая команда выбирает сама). А это, соответственно, уже Scrum. Мне очень сильно повезло прийти в компанию в тот момент, когда там появился новый генеральный директор, и он уже начал изменять ее. Хотя до IT еще не дотянулся. Все-таки важно, в какую почву падает посеянное тобой зерно, в каменистой земле шансов у нас было бы немного. И все равно на то, чтобы топы приняли идею Agile, ушло около четырёх месяцев: нужны были доказательства.
Доказательства
Компания в тот момент была еще очень консервативная, плюс коллеги не верили в возможность подобных изменений, а топы, как обычно это бывает, просили всё подтверждать на цифрах, которые без пилотного проекта взять было неоткуда. Раскручивать этот маховик пришлось долго.Я использовал все инструменты, которые мог:
- Выступал на всех доступных мне площадках (таун-холлы бизнес-подразделений).
- При обсуждении каждой проблемной ситуации на совещаниях всех уровней подробно объяснял, как мы бы её решили при помощи Agile Scrum (а точнее, сделали бы так, чтобы проблема не возникла).
- Узнал, что в нашей «маме» (ВТБ) использовались эджайлоподобные практики, и начал обращать на это внимание других: раз «мама» применяет — значит это работает!
- Показывал на личном примере, как можно решать вопросы иначе, и стал собирать вокруг себя людей, которые действовали аналогично.
С января по май 2020 года я собирал команды для пилота и неустанно пропагандировал им ценности Agile. Сам пилот продлился с мая по декабрь 2020 года.
Пилотный проект
Любой человек сопротивляется новому. И один менеджмент для эффективного запуска переубедить было недостаточно: загореться идеей должны были все. Чтобы достучаться до них, пришлось выступать с убеждающими презентациями на всевозможных мероприятиях. Я напрашивался на собрания подразделений, которые с IT даже не связаны (риски, поддержка бизнеса, продажи), и в свои выступления всегда вставлял пару слов про то, как бы то, о чём я рассказываю, «сработало по Agile». Было крайне важно, чтобы про Agile начали говорить все; чтобы слово «agile» стало ассоциироваться у коллег с выходом из сложной ситуации.Поскольку у нас не было продуктов, на которых получилось бы доказать работоспособность идеи, в качестве пилотного проекта мы решили «локально оптимизировать» работу двух подразделений: департамента поддержки бизнеса и финансового департамента. Мы определили, что за сервисы/продукты есть в этих департаментах, определили бэклоги и на их основе сформировали StarMap для каждого из направлений. Это и был плацдарм для пилота.
Затем набирали людей в команду. Критериев отбора было всего два:
- Должны гореть глаза.
- Компетенции должны попадать в 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 (ведь каждому проще заниматься тем, что он уже знает и умеет; зачем ему изучать что-то новое и распространять компетенции, правда?) и все вытекающие от этого проблемы:
- негатив заказчиков;
- низкое качество функционала;
- непредсказуемая по объёму поставка;
- сложность в поддержке.
Всплывало всякое:
- разные KPI у смежных подразделений;
- постоянные попытки «остальной компании» вернуть создаваемые Agile-команды в старые процессы (приходилось оберегать эти команды от уже сложившейся корпоративной культуры);
- отсутствие в компании продуктовых и технических метрик (их пришлось создавать по ходу дела) и пр.
Отбираем продукты у подрядчиков
Хочу рассказать о кейсах, которые максимально наглядно показывают эффективность нашего подхода. Успех пилота дал нам повод забрать у не очень эффективных подрядчиков два продукта — «Автоматизированную систему службы сопровождения клиентов» и «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 прививали
Если вы работали в больших компаниях, то знаете, что это за ощущение: у вас вроде бы есть всё для реализации себя как профессионала, все условия для воплощения в жизнь любых идей и задач — однако...
habr.com