Привет!
Меня зовут Александр, и я руковожу ИТ разработкой в УБРиР!
В 2017 году мы в центре развития сервисов информационных технологий УБРиР поняли, что пришло время глобальных изменений, а точнее — agile-трансформации. В условиях интенсивного развития бизнеса и быстрого роста конкуренции на финансовом рынке два года – внушительный срок. Поэтому пришло время подвести итоги проекта.
Самое сложное – менять свое мышление и постепенно культуру в организации, где принято рассуждать: «а кто будет начальником в этой команде?», «начальник лучше знает, что нам нужно делать», «мы здесь работаем уже 10 лет и знаем лучше наших клиентов, знаем, что им нужно».
Agile-трансформация может произойти только, когда в ней меняются сами люди.
Я бы выделил следующие ключевые страхи, мешающие людям меняться:
Встав на путь трансформации, мы выбрали первых «опытных кроликов» — сотрудников retail-направления. Первым делом провели редизайн неэффективно работающей структуры ИТ. Придумав целевой концепт структуры, приступили к формированию команд разработки.
Архитектура в нашем банке, как и во многих других, мягко говоря “трэшевая”. Огромное количество приложений и компонентов, монолитно связанных между собой DB link, есть ESB шина, но она не выполняет своих предназначений. Также есть несколько АБС.
Перед тем, как формировать scrum-команды, встал вопрос: «А вокруг чего должна быть собрана команда?». Понятие, что в банке есть продукт, конечно, витало в воздухе, но на расстоянии недосягаемости. После долгих раздумий решили, что команда должна быть собрана вокруг направления или сегмента. Например, «Команда Кредиты», которая развивает кредитование. Определившись с этим, мы начали придумывать целевой состав ролей и набора компетенций, необходимых для эффективного развития этого направления. Как и многие другие компании, мы учли все роли кроме Scrum Master — на тот момент объяснить CIO, какова же роль этого чудесного человека, было практически невозможно.
В итоге после разъяснений о необходимости запуска команд разработки мы запустили три команды:
С набором ролей:
Следующим этапом нужно было определить, как команда будет работать. Мы провели agile- обучение всех участников команды, посадили всех в одну комнату. PO в командах не было. Наверное, все, кто делал agile-трансформацию, понимают, насколько сложно объяснить бизнесу роль PO, а ещё сложнее посадить его рядом с командой и дать полномочия. Но мы «шагнули» в эти изменения с тем, что было.
Так как в процессах кредитования и остальных направлениях розничного бизнеса было задействовано огромное количество приложений, мы начали думать, кто может подойти на роли? Разработчик одного стека технологий, а там смотришь — и нужен разработчик другого стека технологий! И вот ты нашёл тех, кто нужен, но желание сотрудника — тоже важная вещь, и заставить человека работать, там, где ему не нравится, довольно сложно.
После анализа работы бизнес-процесса кредитования и долгих разговоров с коллегами мы все-таки нашли золотую середину! Так появились три команды разработки.
Люди начали делиться на тех, кто хочет меняться, и тех, кто не хочет. Все привыкли работать в условиях «мне задачку дали, я ее сделал, отстаньте от меня», а командная работа этого не подразумевает. Но и эту проблему мы решили. Всего за время изменений уволилось 8 человек из 150!
Дальше началось самое интересное. Наши кросс-компонентные команды стали развивать сами себя. Например, есть задача, для которой нужно иметь скиллы в области разработчика CRM. В команде он есть, но он один. Также есть Oracle-разработчик. Что делать, если нужно решить 2 или 3 задачи в CRM? Учить друг друга! Ребята начали передавать свои компетенции друг другу, и команда расширяла свои возможности, минимизируя зависимость от одного сильного специалиста (к слову, в любой компании есть супермены, которые знают все и никому этого не рассказывают).
На сегодня у нас собрано 13 команд разработки на все направления развития бизнеса и сервисов. Мы продолжаем agile-трансформацию и выходим на новый уровень. Это потребует новых изменений. Мы будем редизайнить команды и архитектуру, будем развивать компетенции.
Наша итоговая цель: быстро реагировать на изменения продукта, быстро выводить на рынок новые фичи и улучшать сервисы банка!
Меня зовут Александр, и я руковожу ИТ разработкой в УБРиР!
В 2017 году мы в центре развития сервисов информационных технологий УБРиР поняли, что пришло время глобальных изменений, а точнее — agile-трансформации. В условиях интенсивного развития бизнеса и быстрого роста конкуренции на финансовом рынке два года – внушительный срок. Поэтому пришло время подвести итоги проекта.
Самое сложное – менять свое мышление и постепенно культуру в организации, где принято рассуждать: «а кто будет начальником в этой команде?», «начальник лучше знает, что нам нужно делать», «мы здесь работаем уже 10 лет и знаем лучше наших клиентов, знаем, что им нужно».
Agile-трансформация может произойти только, когда в ней меняются сами люди.
Я бы выделил следующие ключевые страхи, мешающие людям меняться:
- Страх потерять власть и “погоны”;
- Страх стать не нужным для компании.
Встав на путь трансформации, мы выбрали первых «опытных кроликов» — сотрудников retail-направления. Первым делом провели редизайн неэффективно работающей структуры ИТ. Придумав целевой концепт структуры, приступили к формированию команд разработки.
Архитектура в нашем банке, как и во многих других, мягко говоря “трэшевая”. Огромное количество приложений и компонентов, монолитно связанных между собой DB link, есть ESB шина, но она не выполняет своих предназначений. Также есть несколько АБС.
Перед тем, как формировать scrum-команды, встал вопрос: «А вокруг чего должна быть собрана команда?». Понятие, что в банке есть продукт, конечно, витало в воздухе, но на расстоянии недосягаемости. После долгих раздумий решили, что команда должна быть собрана вокруг направления или сегмента. Например, «Команда Кредиты», которая развивает кредитование. Определившись с этим, мы начали придумывать целевой состав ролей и набора компетенций, необходимых для эффективного развития этого направления. Как и многие другие компании, мы учли все роли кроме Scrum Master — на тот момент объяснить CIO, какова же роль этого чудесного человека, было практически невозможно.
В итоге после разъяснений о необходимости запуска команд разработки мы запустили три команды:
- Кредиты
- Карты
- Пассивные операции
С набором ролей:
- Менеджер разработки (Tech Lead)
- Разработчик
- Аналитик
- Тестировщик
Следующим этапом нужно было определить, как команда будет работать. Мы провели agile- обучение всех участников команды, посадили всех в одну комнату. PO в командах не было. Наверное, все, кто делал agile-трансформацию, понимают, насколько сложно объяснить бизнесу роль PO, а ещё сложнее посадить его рядом с командой и дать полномочия. Но мы «шагнули» в эти изменения с тем, что было.
Так как в процессах кредитования и остальных направлениях розничного бизнеса было задействовано огромное количество приложений, мы начали думать, кто может подойти на роли? Разработчик одного стека технологий, а там смотришь — и нужен разработчик другого стека технологий! И вот ты нашёл тех, кто нужен, но желание сотрудника — тоже важная вещь, и заставить человека работать, там, где ему не нравится, довольно сложно.
После анализа работы бизнес-процесса кредитования и долгих разговоров с коллегами мы все-таки нашли золотую середину! Так появились три команды разработки.
Что дальше?
Люди начали делиться на тех, кто хочет меняться, и тех, кто не хочет. Все привыкли работать в условиях «мне задачку дали, я ее сделал, отстаньте от меня», а командная работа этого не подразумевает. Но и эту проблему мы решили. Всего за время изменений уволилось 8 человек из 150!
Дальше началось самое интересное. Наши кросс-компонентные команды стали развивать сами себя. Например, есть задача, для которой нужно иметь скиллы в области разработчика CRM. В команде он есть, но он один. Также есть Oracle-разработчик. Что делать, если нужно решить 2 или 3 задачи в CRM? Учить друг друга! Ребята начали передавать свои компетенции друг другу, и команда расширяла свои возможности, минимизируя зависимость от одного сильного специалиста (к слову, в любой компании есть супермены, которые знают все и никому этого не рассказывают).
На сегодня у нас собрано 13 команд разработки на все направления развития бизнеса и сервисов. Мы продолжаем agile-трансформацию и выходим на новый уровень. Это потребует новых изменений. Мы будем редизайнить команды и архитектуру, будем развивать компетенции.
Наша итоговая цель: быстро реагировать на изменения продукта, быстро выводить на рынок новые фичи и улучшать сервисы банка!
