Сергей Щербинин, руководитель отдела стратегического управления, организации и контроля IT «Райффайзенбанка», рассказывает, как им удалось собрать 90% IT-разработчиков в штате банка и благодаря этому ускорить разработку продуктов в несколько раз.
Раньше над проектами работали смешанные команды
Еще шесть лет назад наша работа строилась по каскадному принципу, проекты были ограничены во времени, над ними трудились смешанные команды – специалисты банка, разработчики и внешний подрядчик. На реализацию любой масштабной задачи уходило около двух лет, потом команды формировались заново.
В штате банка IT-разработчиков было значительно меньше, чем за штатом. Такой подход был совсем неэффективным: отсутствовало постоянное продуктовое развитие, да и разработчиков на аутсорсинге – носителей ключевой экспертизы по проекту – могли в любой момент перевести на новую задачу. Не вызывали особого интереса у IT-специалистов и устаревшие технологии, которыми банк пользовался.
Вопрос назрел сам собой: как стать эффективнее?
- Значительно увеличить количество разработчиков в штате
- Переориентироваться с временных проектов на непрерывное продуктовое развитие
- Усовершенствовать технологии
Положительного результата в решении этих задач помогла добиться философия agile (методология scrum).
Не все с энтузиазмом восприняли изменения
В 2016 году мы решили создать кросс-функциональные команды scrum с привлечением коллег из бизнеса. Стали появляться новые роли scrum-мастера, владельца продукта. Но без трудностей, конечно, не обошлось: согласно методологии scrum, команды должны сидеть вместе. Далеко не все коллеги из бизнеса с энтузиазмом восприняли новость, что им придется покинуть их привычные кабинеты и переехать на один этаж к разработчикам. Однако после переезда многие увидели плюсы такого подхода: вопросы стали решаться намного эффективнее и без проволочек.
Раньше я был в роли заказчика, и когда мне говорили, что на выполнение задачи понадобится много времени, я этого не понимал – казалось, ерундовая работа, а делается так долго. Но потом, когда я во все окунулся, понял, какие есть подводные камни. После переезда мы стали теснее взаимодействовать с коллегами, я стал лучше понимать весь продукт и полный цикл его создания. Плюс я забрал себе какие-то задачи – например, где нужно кодить. С таким подходом процесс разработки ускорился.
«Сю Ха Ри»: как познать истину и стать мастером
Понять, почему изначально не все получалось, помог японский принцип «Сю Ха Ри». Ступень «Сю» – строгое следование правилам, на стадии «Ха» происходит осознание этих правил, когда им можно уже не так строго следовать. С переходом на этап «Ри» ты становишься мастером и можешь импровизировать. В самом начале нашего пути мы перешли сразу к стадии «Ри» – это была наша главная ошибка. Оказались на поверхности и причины других наших неудач.
Например, работе по scrum надо обучать командами: недостаточно из каждой группы отобрать 2-3 толковых сотрудника, отправить их обучаться и потом попросить поделиться знаниями с коллегами. При передаче информация сильно искажается. Гораздо продуктивнее обучать команду целиком, иначе придется потратить много времени на унификацию терминов.
Со временем пришло понимание, что в командах не удастся полностью избежать конфликтов. Сам scrum-процесс построен так, что провоцирует разногласия. Но, как говорится, в споре рождается истина. Важно вовремя вывести зарождающийся конфликт в конструктивную плоскость. Сейчас нам сложно представить, что наши команды два-три месяца не могут между собой договориться. В этом заслуга как самих команд, так и наших scrum-мастеров, которых мы сознательно подобрали с необычным профилем: в основном это люди без опыта работы в IT, но с образованием в области психологии, изначально более склонные к проявлению эмпатии и работе с конфликтами.
Ощутимые результаты
Мы стали быстрее. Раньше реализация небольшой задачи занимала 9 месяцев, теперь раз в две недели мы запускаем какой-то новый функционал по продукту. Владелец продукта и разработчик – часть одной команды, им не нужно тратить время на детализацию лишних требований. Такой подход экономит порядка 30% цикла разработки. Мы стали на три головы круче с точки зрения автоматизации всех внутренних процессов, на смену устаревшим технологиям приходят новые фреймворки.
Теперь у нас в банке разработка и IT-архитектура – это не просто сопровождение проектов, это ключевая экспертиза по любому банковскому продукту, поэтому 90% всех наших IT-специалистов работают в штате.
Чтобы иметь возможность совершенствовать свои профессиональные навыки и оттачивать мастерство работы в scrum-команде, мы создали IT Academy. У нас сформировалось сообщество чемпионов по инновациям и появилось собственное RND (Research and development). Теперь наши разработчики могут выходить за рамки своих компетенций, и собрав команду, проверять свои гипотезы или пробовать новые технологии. Это дает возможность увидеть, какую пользу твой продукт приносит банку в целом.
Нет предела совершенству
Сейчас внедрение agile идет в банке полным ходом: больше 30 команд работает по новой методологии. Теперь мы вплотную подошли к LeSS, который позволит нам масштабировать scrum внутри. Для крупного банка это важно: у нас сложные продукты, за которыми стоит множество приложений. Для работы с такими сервисами должна создаваться специальная команда, которая в состоянии взять любую задачу из backlog, независимо от того, на каком приложении или технологии она делается.
Внутри этой команды должны быть необходимые компетенции: юрист, маркетолог, пиарщик, бухгалтер, коллеги из бизнеса. Такая команда способна осуществить end to end product delivery.
Теперь у нас все продуктовое развитие будет строиться вокруг LeSS. Здесь мы видим как потенциал в изменении скорости выпуска продукта, так и новые интересные возможности для наших IT-специалистов.
Разница в отношении
Анализируя собственный опыт, мы ответили себе на вопрос: что делать банкам, которые изначально консервативные, чтобы стать привлекательным для разработчика? Для начала нужно понимать, что привлекательность – это не что-то аморфное, а вполне конкретные вещи, на которые IT-специалисты обращают внимание при выборе места работы:
- Масштабность задач
- Комфортная среда
- Человечность
Сегодня, попав в IT-отдел крупного банка, специалист должен оказаться в технологической компании. Главный фактор привлечения – это сложные задачи и новейшие технологии. Они рождают интерес к работе и заставляют развиваться. Обеспечьте своим IT-специалистам условия, к которым они привыкли: максимально упростите бюрократические процедуры, предоставьте возможность работать на современном качественном оборудовании.
Работа, выстроенная по методологии scrum, дает больше возможностей как для реализации интересных, практически значимых задач, так и воплощения в жизнь своих идей. И, конечно, важен ежедневный комфорт и человеческое отношение. Не стоит загонять digital-специалистов в узкие рамки дресс-кода и фиксированного графика. Создание технического продукта – в том числе, и творческий процесс, и чтобы он был успешным, нужна максимальная свобода.
Материалы по теме:
Эти простые решения помогут большим компаниям стать лидерами рынка
«С правильной тактикой можно выиграть у любого соперника»: создаем успешную бизнес-команду
Эти книги помогают внедрять Agile в «Сбербанке» и сократить время выхода нового продукта
Agile, scrum, kanban: в чем разница и для чего использовать?
Как я мотивирую свою команду, когда на это особо нет ресурсов
Фото на обложке предоставлено пресс-службой «Райффайзенбанка»
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
Материалы по теме
ВОЗМОЖНОСТИ
17 мая 2024
17 мая 2024
18 мая 2024