ИТ-службе часто предъявляют претензии по поводу того, что разработка обходится чересчур дорого и ведется слишком долго. Чтобы запускать новые идеи быстро, эффективно и чтобы клиентам это нравилось, современные организации берут на вооружение концепцию agile. В «Райффайзенбанке» в течение пяти лет пытались воспроизвести чей-нибудь позитивный опыт внедрения «гибкого подхода», пробовали разные подходы и прошли через несколько стадий осознания аgile. После череды экспериментов стало ясно, что вокруг agile сложился целый ряд мифов: что его можно взять на аутсорсинг, что для его внедрения достаточно всех обучить и что он может сам «прорасти» изнутри организации. Все эти гипотезы не выдержали проверки практикой.

О том, с какими иллюзиями пришлось расстаться на пути к «гибкой» организации и какие уроки удалось извлечь из неудач, Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка», рассказал на конференции ITMF 2017, организованной издательством «Открытые системы».

Гуру не достаточно

Первой провалилась попытка пригласить внешнего «гуру», чтобы привить культуру agile и вдохновить сотрудников банка. Две недели с ИТ-специалистами «Райффайзенбанка» плотно работал сам Дэвид Андерсон, придумавший Kanban. Однако энтузиазм угас очень быстро, полученного на тренингах заряда хватило всего на полтора месяца. В результате удалось только локально улучшить производительность: лишь одна ИТ-команда смогла использовать полученный импульс и построить классический Kanban. А на бизнес-партнеров – сотрудников бизнес-подразделений банка это не оказало практически никакого влияния.

Только для членов клуба

Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка»:
«Agile должен стать моделью работы всей организации, а не только ИТ-службы»

В банке попытались сделать команды гибкими, пригласив внешних консультантов, которые решали вместе с сотрудниками ежедневные проблемы. Но и на этот раз действительность разочаровала: консультанты не рассказывали, как делать правильно, а рассказывали, как написано в книгах, и их ответы на вопросы были слишком теоретическими и общими. Бизнес-партнеры воспринимали такое обучение как трату времени, и целый год после этого слово agile было ругательным. Так в банке осознали, что agile нельзя привнести извне, консультанты могут дать команде лишь первоначальный толчок, а за внедрение культуры аgile придется отвечать самим. И вовлечь людей, заставить их интересоваться аgile – это внутренняя задача организации.

«Мы нашли тех, кто верит в agile, живет по этим принципам, имеет опыт и пользуется Scrum, cобрали их всех в Аgile-клуб и раз в две недели разбирали вместе какую-нибудь практическую задачу, – рассказывает Кныш. – После этого каждый шел в свою команду с “домашним заданием”. Пренебрегающих выполнением заданий исключали из клуба, что впоследствии могло сказаться на их повышении по службе».

Клуб никак не анонсировался внутри банка, в нем состояли всего шесть человек, но они совершили прорыв, построив Scrum в шести командах. Затем члены Аgile-клуба стали ездить в Европу учиться и сертифицироваться, и у остальных ИТ-специалистов проснулось желание участвовать в работе клуба. «Сарафанное радио» сработало – на вторую волну набора пришли уже 60 человек, включая людей из бизнеса.

Эффективная гибкость

Agile, DevOps и Scrum зачастую обходятся дороже, чем классическая разработка, из-за увеличения численности ИТ-команды. Однако в банке ожидают, что вырастет и прибыль – за счет того, что ПО делается быстрее, больше и с фокусом на удовлетворении потребностей клиентов. «Когда цели – скорость запуска продуктов, клиентский опыт и повышение индекса потребительской лояльности, аргумент “дорого” отходит на второй план», – говорит Кныш.

Недостаток традиционного подхода в том, что когда бизнес-заказчик спрашивает, в какие сроки для него сделают необходимую доработку, ему отвечают: вот очередь твоих коллег, приходи через месяц или докажи, что твоя задача самая приоритетная. Вариант нанять еще 10 человек и сделать работу за месяц не проходит, потому что нет возможности наращивать расходы на ИТ. Запросов от заказчиков поступает очень много, и если не увеличить число разработчиков, то нужные продукты будут получены только к 2028 году.

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

Чтобы переход к agile был эффективен, необходимо, чтобы корпоративные ценности соответствовали этой концепции, а вся корпоративная бюрократия поддерживала трансформацию. Очень важно иметь собственную экспертизу в agile. Поскольку на рынке нет необходимых базовых специалистов, например Scrum-мастеров, их надо растить самим.

Изменениям подвергаются и система корпоративного обучения, и система карьерного продвижения людей в организации. Нужно нанимать людей с правильным складом ума и с правильными ценностями, смотреть, может ли человек работать в команде и нацелен ли он на общий результат.

 

Дефицит авторитета

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

Также не сработало предположение, что менеджерам, которые внедряли процессы, проще всего будет их и поменять. Отдел, отвечающий за процессы, не смог выступить в роли агента изменений и аgile-коуча. Выяснилось, что менеджеры процессов могут объяснить идею, но не обладают авторитетом в команде программистов, поэтому их советы не имеют веса.

Еще один урок был получен в ходе выбора поставщика услуг обучения. Дав командам право самостоятельно выбирать провайдера тренингов по аgile и Scrum, в банке исходили из того, что люди почувствуют доверие и выберут лучших. В итоге команды выбрали разных провайдеров, у них сформировался разный понятийный аппарат и сложилась собственная трактовка аgile и Scrum, что привело к конфликтам и накалу «религиозных войн» по поводу того, «чей Scrum правильнее».

Из опыта организации обучения аgile в банке сделали три основных вывода.

Во-первых, учить надо всех ИТ-специалистов, несмотря на то что в крупной организации это дорого. Средства на обучение единичных сотрудников все равно будут потрачены зря.

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

И в-третьих, выбирать поставщика тренингов нужно аккуратно и внимательно, сформировав программу и не допуская лоскутного подхода к обучению.

Управление на скорости

В процессе трансформации в гибкую организацию в «Райффайзенбанке» наряду с управлением проектами активно развивают управление продуктами. От попыток угадать, каким рынок будет через два года, и к тому времени выдать бизнес-заказчику продукт, который на 80% не соответствует его ожиданиям, в банке переходят к практике, когда заказчик в процессе разработки сам перечисляет свои ожидания и говорит, что конкретно ему надо прямо завтра. «Мы быстро тестируем идеи и начинаем зарабатывать сразу, если это возможно. А если это не нужно, то понимаем это не через три года, а через месяц и перестаем тратить деньги», – говорит Кныш. Проектное управление, конечно, никуда не денется, хотя его удельный вес снижается, так как во многих ситуациях нужна кросс-продуктовая координация. А вот роль проектного менеджера меняется, так как он становится членом продуктовой команды со своим набором задач, лежащих вне поля разработки конкретного продукта.

Тихо сам собою...

И последний развенчанный миф – о саморазвитии agile изнутри как модной молодежной субкультуры. Если обеспечить команды необходимыми тренингами, может, они с радостью внедрят аgile и Scrum самостоятельно? В действительности люди очень упорно следуют исторически устоявшимся процессам, и отношение к новым практикам обычно выражается словами «У нас это не заработает». «Корпоративная гравитация действует – правила всегда тащат назад», – заметил Кныш. По его мнению, cам по себе agile никогда не «прорастет». Внедрение гибкого подхода – дело тех, кто отвечает за выпуск продукта, аgile должен помогать решать их проблемы.

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

А концепция аgile в итоге трансформировалась из ИТ-процесса в организационную модель работы всей организации.

Через боль

Как же заставить agile работать? Любое изменение происходит через боль, когда человеку хорошо и комфортно, он не меняется, говорит Кныш. И в банке решили «сделать больно» менеджерам по продуктам, которые есть в каждой команде, одновременно дав им возможность избежать «боли» посредством agile. Им резко увеличили целевые показатели эффективности и поставили задачу повысить качество, сохранив хорошие отношения с бизнесом. Все эти параметры вполне измеримы, и только выполнив все условия, менеджер получит годовой бонус. А добиться этого можно с помощью agile и Scrum. И приходится переучиваться, поскольку старыми методами получается только давить на команду или обманывать бизнес, что легко обнаруживается метриками.

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

Главный его вывод таков: полагать, что гибкий подход надо именно внедрять, – ошибка, потому что это целая культура, стиль жизни. Agile должен стать моделью работы всей организации, а не только ИТ-службы. «Аgile в действительности – это работа в условиях неопределенности, как в целом принимаются решения, планируется бюджет, оцениваются люди, делегируются полномочия. Это история не про ИТ, а про банк в целом, и менять надо весь банк», – рассказал Кныш. На этом пути делаются только самые первые шаги.