Раньше мы решали задачи за 9 месяцев, теперь — за 2 недели. Как нам это удалось?

Раньше над проектами работали смешанные команды

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

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

Вопрос назрел сам собой: как стать эффективнее?

• Значительно увеличить количество разработчиков в штате
• Переориентироваться с временных проектов на непрерывное продуктовое развитие
• Усовершенствовать технологии

Положительного результата в решении этих задач помогла добиться философия agile (методология scrum).

Не все с энтузиазмом восприняли изменения

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

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

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

Станислав ФилипповСтарший менеджер проектов «Райффайзенбанка»

«Сю Ха Ри»: как познать истину и стать мастером

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

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

Ощутимые результаты

Мы стали быстрее. Раньше реализация небольшой задачи занимала 9 месяцев, теперь раз в две недели мы запускаем какой-то новый функционал по продукту. Владелец продукта и разработчик – часть одной команды, им не нужно тратить время на детализацию лишних требований. Такой подход экономит порядка 30% цикла разработки. Мы стали на три головы круче с точки зрения автоматизации всех внутренних процессов, на смену устаревшим технологиям приходят новые фреймворки.

Чтобы иметь возможность совершенствовать свои профессиональные навыки и оттачивать мастерство работы в scrum-команде, мы создали IT Academy. У нас сформировалось сообщество чемпионов по инновациям и появилось собственное RND (Research and development). Теперь наши разработчики могут выходить за рамки своих компетенций, и собрав команду, проверять свои гипотезы или пробовать новые технологии. Это дает возможность увидеть, какую пользу твой продукт приносит банку в целом.

Нет предела совершенству

Сейчас внедрение agile идет в банке полным ходом: больше 30 команд работает по новой методологии. Теперь мы вплотную подошли к LeSS, который позволит нам масштабировать scrum внутри. Для крупного банка это важно: у нас сложные продукты, за которыми стоит множество приложений. Для работы с такими сервисами должна создаваться специальная команда, которая в состоянии взять любую задачу из backlog, независимо от того, на каком приложении или технологии она делается.

Теперь у нас все продуктовое развитие будет строиться вокруг LeSS. Здесь мы видим как потенциал в изменении скорости выпуска продукта, так и новые интересные возможности для наших IT-специалистов.

Разница в отношении

Анализируя собственный опыт, мы ответили себе на вопрос: что делать банкам, которые изначально консервативные, чтобы стать привлекательным для разработчика? Для начала нужно понимать, что привлекательность – это не что-то аморфное, а вполне конкретные вещи, на которые IT-специалисты обращают внимание при выборе места работы:

• Масштабность задач
• Комфортная среда
• Человечность

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

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

Материалы по теме:

Эти простые решения помогут большим компаниям стать лидерами рынка

«С правильной тактикой можно выиграть у любого соперника»: создаем успешную бизнес-команду

Эти книги помогают внедрять Agile в «Сбербанке» и сократить время выхода нового продукта

Agile, scrum, kanban: в чем разница и для чего использовать?

Как я мотивирую свою команду, когда на это особо нет ресурсов

Фото на обложке предоставлено пресс-службой «Райффайзенбанка»