Раньше мы решали задачи за 9 месяцев, теперь — за 2 недели. Как нам это удалось?
Раньше над проектами работали смешанные команды Еще шесть лет назад наша работа строилась по каскадному принципу, проекты были ограничены во времени, над ними трудились смешанные команды – специалисты банка, разработчики и внешний подрядчик. На реализацию любой масштабной задачи уходило около двух лет, потом команды формировались заново. В штате банка 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: в чем разница и для чего использовать? Как я мотивирую свою команду, когда на это особо нет ресурсов Фото на обложке предоставлено пресс-службой «Райффайзенбанка»
