Как бельгийский банк внедрял agile — кейс про большую трансформацию

Опыт внедрения Agile на примере живого кейса крупной компании — отличный пример, который сможет помочь вам понять, как начать работать по этой методологии.

Попытки создать идеальную систему управления данными начались еще в середине девяностых годов прошлого века.

Даже ФБР попыталось придумать что-то новое для замены каскадной модели управления (Waterfall), но, потратив600 млн долларов, отказалось от этой затеи.

Почему же за10 лет так ничего и не удалось сделать? Проблема была в самой методике работы «по каскадам» (ступеням), когда следующий этап запускается только после того, как реализован предыдущий: если останавливался один из этапов, то замирал весь проект.

В 2001 году появился «Манифест гибкой методологии разработки программного обеспечения» (англ. Agile Manifesto), и ситуация изменилась. За счет итерационной модели удалось наладить непрерывную работу всех участников проекта, и проклятье Waterfall исчезло. А пример ФБР и выброшенных на ветер600 млн долларов научил всех.

Важно!

С помощью старых подходов нельзя решать современные задачи.

На примере кейса компании Ticketland попробуем выяснить, как применять методологию Agile, чтобы минимальными деньгами и ресурсами эффективно справляться со сложными проектами.

Ticketland занимается продажей билетов онлайн. Компания — один из лидеров рынка. По количеству проданных билетов за счет регионального присутствия конкурирует только с «Кассир.ру», но доходы в Ticketland явно выше.

  • Устаревшее программное обеспечение, заменить которое казалось практически невозможным из-за сложной работы сервиса.
  • «Сакральные» знания о проекте сосредоточены в руках нескольких сотрудников. Это делало их практически незаменимыми: когда люди уходили, компания сталкивалась с трудностями.
  • Низкая скорость разработки и низкое качество продуктов.
  • Отставание от конкурентов в технологическом плане и потеря ключевых клиентов.
  • Текучка среди разработчиков. Молодые специалисты зачастую уходили, не проработав в компании даже года. Это проблема всего рынка.

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

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

Agile — это гибкая методология в разработке ПО. В ее основе лежит4 принципа:

  1. Люди и взаимодействие важнее процессов и инструментов.
  2. Работающий продукт важнее исчерпывающей документации.
  3. Сотрудничество с заказчиком важнее согласования условий контракта.
  4. Готовность к изменениям важнее следования первоначальному плану.

Scrum — одно из направлений в Agile, которое более четко описывает эти принципы. В Scrum и Agile не приветствуются иерархические структуры. Командное взаимодействие позволяет добиваться результата с помощью небольших итераций.

Для работы организовываются маленькие группы, направленные на конкретный результат и принимающие самостоятельные решения. Работа таких групп проходит небольшим периодами — от недели до месяца. В это время выполняется конкретная задача. При этом членов группы никто не контролирует, кроме них самих. Важно: команда не слепо выполняет приказы руководства, а работает на бизнес.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

В Agile как таковых руководителей нет, но у каждой команды есть ответственное лицо — Product Owne

Они оказались не нужны в чистом виде. Им нужно было или быть разработчиками, или становиться Product Ownerʼами.

Важно!

В Agile нет иерархии — нет человека, который говорит, как нужно делать ту или иную задачу, и все контролирует. Есть команда, в которой все контролируют друг друга. Здесь работает социальная ответственность.

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

Например, сервис отчетов, которым пользуются клиенты компании, устарел; решили создать новый и красивый. Раньше руководитель мог отдать приказ: сделайте новый сервис отчетов. Но теперь в компании стали работать иначе. Сперва Product Owner обсуждает с клиентами разные гипотезы — например, как может выглядеть новый сервис отчетов. То есть осуществляет сбор пожеланий пользователей.

Дальше команда делает маленькие шаги. К примеру, принимает решение сделать backend — разобраться, как эти данные будут храниться и показываться, как будет выглядеть меню. То есть разрабатывается простой, примитивный продукт, с которым тем не менее уже могут взаимодействовать пользователи. После этого приступают к следующему шагу разработки.

Это дискуссия о том, что пошло не так и что можно улучшить. Важно, чтобы она была командной, чтобы все участвовали и каждый мог поделиться своим мнением.

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

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

То есть если разработчики говорят, что надо работать над фичей, они должны объяснить, как эта фича принесет компании деньги.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

В Agile нет места хаосу, каждое нововведение должно быть четко обосновано

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

Это, в свою очередь, сэкономит деньги на инфраструктуре и повысит надежность в случае падения системы. Таким образом, новый сервис отчетов мог принести прибыль, поэтому было принято решение о его внедрении.

Человек должен объяснить, почему хочет работать в компании. Если у него нет никакой цели в жизни, никакого плана — это плохой знак, его надо будет «качать».

Среди ценностей Ticketland есть получение удовольствия от работы. Если новичок мрачный (очень многие IT-специалисты мрачные, брутальные, суровые), не реагирует на шутки, не может адаптироваться к изменению ситуации, то, наверное, ему и всей команде будет трудно, даже если он отличный специалист.

Для разработчиков есть специальные тесты и отдельные люди, которые задают нужные вопросы.

Этот элемент Agile, он означает осваивание новых знаний. Все в команде должны «говорить на одном языке», каждый должен стремиться расширить свой бэкграунд. Участники проекта должны быть специалистами в какой-то области, но при этом хорошо понимать кросс-дисциплинарные вещи.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

Схематическое отображение t-shape

К примеру, если человек занимается продажами, он может прокачать другой навык — создание наглядных презентаций. Также можно начать писать блог для клиентов или совершать выездные консалтинг-сессии. Чем больше смежных навыков освоит сотрудник, тем лучше он сможет показать себя в качестве специалиста в основной деятельности.

Важно!

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

Это человек, который умеет находить общий язык с людьми, работать в команде, понимает технологии и знает, как с ними взаимодействовать. Product Owner — связующее звено между бизнесом, разработчиками и пользователями. Таких специалистов на рынке труда сейчас мало, поэтому многие компании выращивают их самостоятельно.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

Положение Product Owner в бизнес-процесса и в команде

Ключевые навыки Product Owner:

  • обладает видением продукта;
  • является владельцем бэклога продукта;
  • умеет расставлять приоритеты;
  • управляет ожиданиями заинтересованных лиц;
  • представляет пользователя;
  • взаимодействует с командой;

То есть каждое обновление рассматривали не только со стороны бизнеса, но и со стороны пользователя.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

Схематическое отображение пользовательской истории

К примеру, разработчик предлагает внедрить функцию возврата билета. Мы пытаемся выяснить, зачем компании такой сервис, как поможет бизнесу тот факт, что люди не будут стоять в очереди, чтобы вернуть билеты, и так далее. Здесь есть ценность: это эксклюзивный функционал, его нет у конкурентов. Компания решает заниматься ее внедрением, потому что она может принести новых клиентов.

Разбили backend на части: сервис отчета, сервис унификации, сервис хранения данных и так далее. Эти небольшие элементы общего продукта должны соединяться между собой. Такой принцип нужно изначально закладывать в архитектуру проекта.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

Разница между монолитной архитектурой проекта и использованием микросервисов

Раньше в компании все работало монолитно. Любая хранимая процедура могла поменяться, и дальше становилось невозможно разобраться в процессах. Когда начали работать в микросервисах, данные перестали путаться и теряться, новым специалистам было легче в них разобраться.

Так, в компании полностью виртуализировали структуру, своих тяжелых серверов практически не осталось. Это и дешевле, и удобнее: если нужна дополнительная мощность, она появляется сразу. Все должно быть учтено при создании архитектуры. Это и есть микросервис. Рассмотрим основные преимущества и недостатки их использования:

Возможность экспериментов

Поддержка любым разработчиком

Респределительная система

Все поставленные задачи были решены. Сервис Ticketland вошел в двадцатку Forbes, компанию оценили в 84,2 млн долларов. Для бизнеса такого рода это отличный результат.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

Agile — это большая трансформация, которая идет во всем мире уже давно. Кто-то скажет, что Scrum и Agile — просто модные слова, оттюнингованный менеджмент и искусственный бум. Но есть классический кейс ФБР, где было потрачено600 миллионов долларов, а результат появился только после перехода к гибкой методологии управления проектами.

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

Больше узнать про Agile и другие актуальные методологии управления процессами, применяемые в IT, маркетинге и медиа, вы сможете, пройдя наш курс «Управление digital-проектами».

Курс «Управление Digital-проектами»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

  •  32 часа теории и 16 практических заданий
  • Живая обратная связь с преподавателями
  • Неограниченный доступ к материалам курса
  • Стажировка в компаниях-партнёрах
  • Дипломный проект от реального заказчика
  • Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Внедрить нельзя залить деньгами

О том, можно ли извлечь двойной эффект от совмещения классической и Agile-моделей, при этом не удвоив негатив, рассказывает Кирилл Булгаков, управляющий директор Т1 Консалтинг.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

«Классика» по-прежнему актуальна для крупных компаний, особенно госкорпораций — там, где нужны комплексные решения, охватывающие десятки ИТ-систем и процессов.

Читайте также:  Какие белорусские предприятия объявили забастовку или вышли на акции солидарности

Например, один из кейсов Т1 Консалтинг — внедрение централизованной системы для энергетической компании, которое требовало объединения 18 наборов ИТ-систем нескольких брендов.

При таких масштабах именно алгоритм классического («водопадного») внедрения с требованиями, четко зафиксированными в техническом задании, обеспечивает результат. Ключевым условием является высокая детализация технического задания.

После внедрения системы каждый пункт будет скрупулезно проверяться по установленным критериям. Места для разночтений при сдаче работы нет. Успех такого рода внедрений достигается и за счет жесткой управленческой вертикали: принятие решений сосредоточено в руках нескольких руководителей высшего звена, которым поступает конкретная, высоко детерминированная информация.

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

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

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

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

Как показывает практика, в классическом проекте внедрения компетентность подрядчика отчасти может компенсировать незрелость заказчика.

В Agile-проектах заказчик, как правило, оставляет функцию управления проектом в своих руках, привлекая только ресурс подрядчика.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

Agile-подход подстраивает требования к ИТ-системам к меняющимся запросам бизнеса, реализация решения происходит сравнительно небольшими итерациями. Но он не лишен особенностей, которые не позволяют модели стать универсальной.

Так, гибкий подход предполагает, что правом принимать решения наделяются product owners — обычно это менеджеры среднего звена, узкие специалисты. Однако распространенная в России вертикальная культура управления (принятие решений не делегируется) становится естественным препятствием на этом пути.

В результате в случае с крупным бюрократизированным заказчиком Agile-внедрение если и не обречено на провал, то осязаемый результат может отложиться на неопределенное время.

В классическом проекте внедрения компетентность подрядчика отчасти может компенсировать незрелость заказчика. В Agile-проектах заказчик, как правило, оставляет функцию управления проектом в своих руках, привлекая только ресурс подрядчика.

В условиях, когда делегирование невозможно, расцветает blaming culture (культура поиска виноватых). Никакие решения не делегируются, соответственно у нескольких топ-менеджеров образуется никогда не уменьшающийся стек решений к принятию.

Неизбежно, что часть из них не рассматривается в срок, — время искать виноватых. Это очень характерная ситуация не только для нашей страны, но и для целого ряда культур. В итоге происходит определенная профессиональная деформация менеджеров.

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

Отсутствие жесткого плана, фиксированного бюджета, просчеты в управлении — все эти факторы зачастую приводят к избыточности затрат.

При Agile-подходе затраты заказчика могут в несколько (от двух до шести, а иногда и более) раз превышать затраты классического проекта внедрения. С одной стороны, естественно переплачивать за скорость получения результатов, когда часть работы приходится переделывать.

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

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

Как бельгийский банк внедрял agile — кейс про большую трансформацию

При выстраивании модели управления проектом важен выбор правильной комбинации: в каких частях управляем внедрением сами и применяем Agile (в быстро изменяющихся процессах), в каких привлекаем внешнюю экспертизу и управление по принципу fix price (сложная специфическая экспертиза, результат важнее скорости).

В ряде случаев может быть применен гибридный подход, когда управляющий проектом от подрядчика привлекается также в рамках модели time & material, когда эксперт по управлению привлечен от подрядчика, но ответственность за результат подрядчику не делегирована.

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

Есть и другие слагаемые уравнения по проработке проектов на старте. Например, типичная отечественная проблема внедрения бизнес-приложений — изобретение велосипеда.

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

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

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

Правильный микс внешних и внутренних ресурсов и эффективная схема управления с развитой системой делегирования обеспечивают успех проекта.

Как бельгийский банк внедрял agile — кейс про большую трансформацию

Под влиянием моды на Agile ИТ-индустрия меняется: крупнейшие заказчики, создавая инсорсинговые подразделения, забирают у игроков рынка функцию управления ИТ-проектами и оставляют им функцию body shopping (предоставление рабочей силы).

ИТ-компании оказываются ограниченными и в своей классической функции «кузницы кадров», когда вчерашние студенты, приходя на позиции стажеров, включаются в проекты и через относительно короткое время становятся востребованными (но не переплаченными) специалистами. В случае, когда у вас приобретают ресурсы на условиях time & material, заказчик заинтересован получить в свое управление опытные кадры, для стажеров места просто не находится.

В свою очередь «конвейерный найм» как ответ на необходимость в быстром покрытии ресурсных потребностей клиентов в принципе не позволяет формироваться на стороне компании-подрядчика ни вменяемой корпоративной культуре, ни содержательной экспертизе, отделяемой от конкретных носителей.

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

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

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

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

Как внедрить Agile в банке

Как бельгийский банк внедрял agile — кейс про большую трансформациюКак внедрить Agile в банке или финансовой организации

  • В этой статье я разберу предпосылки для внедрения Agile подходов в банке, с точки зрения методов гибкого управления.
  • При этом следует понимать, что внедрение методологии Agile включает в себя не только корпоративное обучение руководителей и сотрудников банка, но и подразумевает под собой содействие в разрешении проблемных моментов и корректировка теоретических вопросов под конкретные задачи банка или любой другой компании.
  • Мои образовательные курсы:
  • ➡️ AGILE: базовый курс для руководителя — основные вопросы применения методов гибкого управления Agile (эджайл) в работе компании — подробная информация.
  • ➡️ AGILE: Создание команд и управление процессом внедрения — ключевые вопросы построения Agile команд для внедрения методов гибкого управления в различные бизнес-процеccы — подробная информация.

Зачем банку нужен Agile

  1. Конечно можно сказать, что Agile методы в банковскую структуру привез Герман Греф, начав внедрять Agile в Сбербанк, за ним последовал Альфа банк, но действительно ли это важно?
  2. Agile методы гибкого управления важны не только для банка, но и практически для любой компании, которая ориентирована на конкурентоспособность в современных условиях экономики, а именно в условиях постоянных изменений.
  3. Для тех, кто не знает, что такое Agile рекомендую ознакомиться со статьёй:
  • Что такое Agile (Эджайл): 9 причин задуматься о гибких методах управления

Дополнительно рекомендую ознакомиться:

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

Читайте также:  Как выстраивать бизнес-отношения с Китаем. Опыт Альберта Нитиевского, который занимается этим больше 20 лет

Agile (Эджайл) можно использовать практически везде, начиная от стратегии и оперативного управления, заканчивая backoffice. Разумеется, это будет сделать достаточно тяжело, так Agile прежде всего меняет мышление, но сделать это просто необходимо.

Я думаю, что в ближайшее время по другому работать просто не получится:

  1. слишком быстро меняется среда,
  2. слишком быстро меняется внимание клиентов,
  3. конкуренция увеличивается стремительными темпами.

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

Agile маркетинговый инструмент банка

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

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

Можно сказать, что Agile это система управления талантами в современной компании, а не только в банке.

Есть очень интересное высказывание:

если Вы не хотите внедрять Agile, значит Вы хотите потерять клиентов

Click to Tweet

И скорее всего в ближайшее время данное высказывание станет аксиомой.

Конечно, внедрение и обучение сотрудников Agile для многих компаний вызов и прежде всего вызов самим себе, так как придется перестраивать мышление персонала, мышление руководителей,  своё мышление, а изменять мышление это проблематично, но возможно, при правильном подходе к корпоративному обучению.

Agile команды в банках

  • Что мешает компании быть успешной?
  • Что мешает быть успешной банковской структуре?

Прежде всего неумение работать в команде, различные барьеры, недоверие, бюрократия, казалось бы ничего нового, но двумя словами это определяется как неэффективное управление.

Кто виноват в неэффективном управлении банка?

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

Командообразование Agile

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

С одной стороны это размытие ответственности, а с другой стороны это ответственность совершенно другого уровня.

Через Agile практически устанавливается доверие и общая заинтересованность в достижении результата: Agile позволяет сформировать команды, вовлечь всех в процесс, а при необходимости выделить слабое звено и устранить его.

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

Среднее время на внедрение Agile в банке составляет 1,5 года, но в рамках пилотного проекта результат можно получить за 2-3 месяца.

Ретроспективы Agile

  • Когда процесс внедрения Agile завершен необходимо регулярно проводить ретроспективы, вносить необходимые изменения и корректировать продукт или услугу, периодичность проведения ретроспектив определяется рынком, на котором работает компания, для банка это может составлять 1 раз в месяц или в квартал, опять все зависит от целевой аудитории клиентов банка.
  • Agile команды всегда работают как единое целое: вместе добиваются успеха и в вместе терпят поражение, конечно это преимущество позволяет увеличить скорость разработки новых решений и повысить ответственность, но при условии правильно сформированной команды.
  • Команды Agile в банке могут достигать намного лучшие результаты, чем внешние вендоры, а более того вы не будете тратить время и другие ресурсы на закупку, утверждение и выбор вендора и кстати полностью сохраните контроль над всеми вашими идеями и решениями, так как передавать конфиденциальные данные сторонним подрядчикам больше не требуется, а для любого банка это очень важно.

Преимущество Agile команд в банке

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

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

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

Результат работы Agile команды

Результат работы Agile команды будет Agile продукт, продукт адаптированный под задачи рынка и имеющий несколько проекций:

  • Функциональность, набор функций необходимых для клиента.

И две производные проекции, которые мы не видим, но которые являются чрезвычайно важными:

  • Удобство применения.
  • Приятный в использовании.

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

Чашка кофе — это дешевая роскошь, которую каждый может позволить себе в кризис — именно так сказал мне ТОП-менеджер одной кофейной компании, которая работает по Agile, сама того не осознавая.

Agile и управление талантами

  1. Конечно нельзя смотреть на Agile методы как на панацею от всех проблем, но как инструмент, позволяющий сплотить талантливых людей ради общей цели методы гибкого управления Agile являются довольно неплохим решением.
  2. Agile методы позволяют создать правильную атмосферу и среду, в которой можно работать быстрее и эффективнее, а следовательно вы сможете увеличить количество своих клиентов или выйти на качественно новый уровень прибыли, что может оказаться очень важными для небольших компаний.
  3. Будущее Agile довольно интересно и это будущее за командами профессионалов, которые ориентируются на достижение результата в разных отраслях бизнеса.
  4. Agile методы позволяют вам скорректировать бизнес-процессы, сделав их более эффективными, а также определить проблемные моменты.
  5. Конечно, в рамках данной статьи мы говорили не только про внедрение Agile в банке, а рассматривали много других вопросов по проблематике внедрения Agile в бизнесе, что позволяет получить сторонний взгляд на Agile методологию, задуматься и приступить к действию.
  6. Мои образовательные курсы:
  7. ➡️ AGILE: базовый курс для руководителя — основные вопросы применения методов гибкого управления Agile (эджайл) в работе компании — подробная информация.
  8. ➡️ AGILE: Создание команд и управление процессом внедрения — ключевые вопросы построения Agile команд для внедрения методов гибкого управления в различные бизнес-процеccы — подробная информация.
  9. Спасибо за внимание, ваше мнение приветствуется, пишите в х.

Agile в ???? Банкинг: Agile-трансформация крупного банка. Промежуточные итоги

Три основных цели — снижение времени вывода продуктов на рынок, увеличение удовлетворенности клиентов и вовлеченности сотрудников.

  • Снижение Time To Market. Со старыми процессами мы не успевали за ожиданиями пользователей. Когда выходили на рынок с новым продуктом, там уже почти всегда были конкуренты.
  • Увеличение CSI (удовлетворенность клиента). Все бьются за клиента. Даже в организациях нашего размера применяют Customer Development и Дизайн-мышление. Agile помогает приблизить разработчиков продуктов к пользователям, лучше понимать потребности.
  • Повышение вовлеченности сотрудников. Все это становится возможным, когда люди, работающие в организации, вовлечены и видят напрямую результаты работы, непрерывно общаясь с пользователями.

Как в компании выстроен процесс разработки продуктов?

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

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

Есть большие планирования (квартальные, месячные), где представители команд (владельцы продукта и инженеры) рассказывают о сделанных вещах и планах другим командам. При обсуждении выявляются зависимости и выравниваются приоритеты задач. Все это валидируется бизнесовым лидером, чтобы все изменения соответствовали продуктовой стратегии.

Как поменялась организационная структура?

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

Читайте также:  Какие книги читает миллиардер Рыбаков

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

Какие сложности возникали при запуске новой модели работы в формате Agile?

Одна из основных — собрать людей из разных подразделений и офисов в одном месте. В то же время это одна из «быстрых побед» — существенно упростились коммуникации и ускорилось принятие решений.

Другая сложность — люди не понимали, как объединение в команды поможет достичь тех целей, которые ставились в начале трансформации. Поэтому много внимания уделили обучению сотрудников, запуску пилотов для достижения «быстрых побед».

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

И еще одна. Agile, с его инструментами самоорганизации команд, подразумевает «уплощение» организационной структуры. Это заставляет middle-менеджмент искать новые для себя роли, иногда за пределами компании.

Сколько времени заняла Agile-трансформация?

Она еще не закончилась 🙂

Трансформация в Agile не имеет конечной точки — это путь непрерывных улучшений, которым теперь идет компания. В зависимости от вовлеченности руководителей и оказываемой коучинговой поддержки, существенные сдвиги становятся видны через полгода-год после начала изменений.

О каких плюсах и минусах следует знать тем, кто будет внедрять Agile-подход в своей компании?

Частично плюсы уже озвучили, но добавим один момент.

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

Из минусов… скорее, это риск — процесс трансформации, как уже говорили, достаточно долгий. И если у нас (и наших клиентов) высокие ожидания от изменений на старте, то через какое-то время возникает разрыв между этими ожиданиями и реальностью. Просто потому, что ментальные и культурные изменения для людей сложны.

Поэтому так важно планировать и достигать «быстрые победы», а также обязательно закреплять изменения на системном уровне.

Как компании стать гибкой: три варианта аджайл-трансформации — Школа скрам-мастера Unusual Concepts

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

Важно: правильного или неправильного варианта нет. Какой бы путь вы ни выбрали, самое главное — не собрать на старте все грабли. Обходить их мы учим на базовом тренинге. Приходите.

Босс решает «внедрить» Аджайл

Скорость: ⬛ ⬜ ⬜ ⬜ ⬜
Сопротивление: ⬛ ⬛ ⬛ ⬛ ⬛
Владелец компании, который что-то слышал или читал об Аджайле, запускает трансформацию сверху.

Он ещё не до конца понимает, как перемены повлияют на результаты бизнеса и сотрудников, но верит, что это нужно сделать. Босс может начать айджализацию как имиджевую историю или «внедрить» Аджайл, чтобы вытащить компанию из кризиса.

При таком раскладе он объявляет об аджайлизации сотрудникам и нанимает опытных коучей.

Что хорошего: быстрые бизнес-результаты. Компания, которую поставили на новые рельсы, поменяется стремительно. Сотрудники объединятся в автономные команды, оптимизируется структура, сократятся издержки. За короткий период компания сможет выпустить инновационный продукт или выйти на новый рынок.

Что плохого: жёсткое сопротивление сотрудников переменам, увольнения. Многим будет сложно перестроиться: не все увидят в переменах ценность и смогут быстро разделить идеи Аджайла, поэтому будут саботировать процессы. Больше всего пострадают мидл-менеджеры, которые окажутся не нужны в обновлённой компании.

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

Он объявил о переходе на Аджайл и отправил на тренинг сразу сто человек — каждого третьего сотрудника. На изменения отвёл полгода и предупредил, что уволит всех, кто не адаптируется. Это привело к напряжённости и недовольству сотрудников, а потом и к увольнениям.

Через полгода в банке появились самоорганизующиеся команды, но сменилась половина коллектива. Отбор и найм сотрудников пришлось пересмотреть, чтобы брать тех, кто точно приживётся. Несмотря на то, что «Банк24.ру» всё-таки закрылся, опыт перехода на Аджайл пригодился Дьяконову в «Точке» — новом банке для предпринимателей.

Трансформация сверху — это айджализация компании по инициативе босса, когда компания получает быстрые бизнес-результаты, но прессует сотрудников. Если сотрудники не сумеют проникнуться новой для них философией, то уйдут сами или их придётся уволить.

Сотрудники объединяются в аджайловые команды

Скорость: ⬛ ⬛ ⬛ ⬛ ⬛
Сопротивление: ⬛ ⬜ ⬜ ⬜ ⬜
Аджайл может распространяться снизу, если инициатива исходит от рядовых сотрудников. Кто-то из них попадает на тренинг по Аджайлу и проникается идеями.

Он убеждает коллег попробовать, и в офисе медленно зарождается Скрам. Соседние отделы интересуются, что происходит, и тоже заражаются идеей. Постепенно об Аджайле в компании узнают руководители и сами отправляются на тренинг.

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

Что хорошего: переход более естественный, потому что Аджайл распространяется медленно — от сотрудника к сотруднику. Несогласных не заставляют быстро перестраиваться, и они не увольняются из-за стресса. Руководители могут какое-то время игнорировать чудаков, которые странно организуют работу, но постепенно втягиваются сами.

Что плохого: длительность перехода, потому что многие сотрудники инертны и не считают, что нужно что-то менять. Заинтересованные в переменах могут годами бороться с равнодушием коллег и непониманием начальства.

Разработчики делали программу расчёта агентского вознаграждения и стоимости страхования. Они прошли тренинг по Аджайлу и после него организовали две микрокоманды. Потом согласовали перемены с руководством и пригласили коуча на деньги компании. Через полгода начали работать по Скраму.

В другом отделе заинтересовались подходом и захотели Канбан. Сотрудники ненадолго пригласили тренера, но не стали глубоко вникать в суть Канбана. В отделе появилась доска, которой они пользовались неправильно: собирались возле неё, чтобы по старинке раздать ЦУ. В итоге инициатива не прижилась, потому что команду никто не коучил.

Первая команда продолжала работать по Скраму, и постепенно соседние отделы начали перенимать опыт. Через три года руководители сами отправились на тренинг. Они поняли, что сотрудники уже подготовили почву для перехода на Аджайл.

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

Руководители и сотрудники хотят Аджайл

Скорость: ⬛ ⬛ ⬛ ⬜ ⬜
Сопротивление: ⬛ ⬛ ⬜ ⬜ ⬜
Смешанный вариант трансформации, когда руководители и сотрудники что-то знают об Аджайле и понимают, что компании надо меняться.

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

Участники «пилота» делятся успехами на публичных собраниях, а потом обучают следующие команды.

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

Что хорошего: переход не слишком быстрый и без сильного сопротивления. Трансформация идёт медленнее, чем при внедрении сверху, но быстрее, чем при внедрении снизу. Её ход можно прогнозировать и контролировать. Аджайловый образ мышления не насаждается, а распространяется естественным образом. Больше людей проникается ценностями и меньше уходит из компании.

Что плохого: как и в предыдущих вариантах, сопротивление или инертность сотрудников. Кого-то придётся уволить или распределить на другие проекты, не требующие работать по фреймворку. Но при этом Аджайл не распространяют насильственно, поэтому люди меньше нервничают и быстрее приспосабливаются к новым условиям.

Разные департаменты банка самостоятельно ходили на тренинги по Аджайлу. Топ-менеджеры два года проникались идеями и в итоге тоже прошли тренинг по Аджайлу и Скраму. После него об айджализации объявили в рассылке, интранете и на внутренних митингах.

В банке собрали три пилотные команды по 10 человек. Выбрали задачу — буксующий проект по открытию счетов. Пригласили коуча, который раз в неделю приходил на внутренние встречи команд.

Сотрудникам пришлось бороться с системой. Например, чтобы заказать какую-нибудь программу, надо было собрать подписи от начальства. Заинтересованные сотрудники выясняли, как сократить бюрократию. Они придумали «Библиотеку чит-кодов» — способы обойти систему и сделать её более дружелюбной. «Библиотеку» одобрило руководство, и любой мог ей воспользоваться.

Пилотный проект завершили за полгода — в практике банка это очень быстро. Люди начали интересоваться Аджайлом, а тех, кто не захотел работать по Скраму, распределили на другие проекты.

Трансформация изнутри — это айджализация компании по инициативе руководителей и сотрудников.

В этом варианте у всех больше времени, чтобы проникнуться философией Аджайла и научиться работать по фреймворкам.

Пилотные команды создают ощущение эксперимента и пробуждают интерес у остальных сотрудников. Участники команд делятся успехами, а потом сами становятся коучами и помогают перейти на Аджайл.

В любом из вариантов трансформация пройдёт быстрее и менее драматично, если нанять команду сертифицированных коучей.

Они помогут пилотным командам наладить работу, а заинтересованным сотрудникам объяснят, что происходит. Ваша задача — действовать, не отклоняясь от курса, и помогать сотрудникам адаптироваться.

Аджайлизация компании решит задачи бизнеса только тогда, когда сотрудники поймут, в чём её ценность.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *