{"id":13658,"url":"\/distributions\/13658\/click?bit=1&hash=55a0ae942a6f0754e0f6ffd8c6e3e2daa97f8e8d757f7370c1f8975eceed6c21","title":"\u041f\u043e\u0447\u0435\u043c\u0443 \u043f\u0440\u0435\u0434\u043f\u0440\u0438\u043d\u0438\u043c\u0430\u0442\u0435\u043b\u044e \u0432\u044b\u0433\u043e\u0434\u043d\u043e \u0441\u0442\u0430\u0442\u044c \u0447\u0430\u0441\u0442\u044c\u044e \u0431\u0438\u0437\u043d\u0435\u0441-\u043a\u043e\u043c\u044c\u044e\u043d\u0438\u0442\u0438","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"fa465a98-71b1-5a0d-8f7a-4b0e1990409a","isPaidAndBannersEnabled":false}

Кейсы agile-трансформации, часть первая: банки

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

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

Поэтому в этой, девятнадцатой статье серии «Менеджмент цифрового мира» (оглавление) я начинаю рассказ о кейсах, чтобы в совокупности дать многовариантную картину. Я думал, что статья будет одна, но материала – много, и будет продолжение. В этой статье речь пойдет о трансформации банков, при чем не IT-подразделений, многие из которых применяют Agile-методы уже 7+ лет, а работы бизнеса в целом.

Мои источники – доклады на профильных конференциях – AgileDays, Agile Business и других, а также разговоры в кулуарах конференций и другие частные разговоры. Там, где это возможно, в статье будут ссылки на конкретные доклады. По конференциям я публикую отчеты, они есть на моем сайте, и конспекты большинства упомянутых здесь докладов есть в отчетах с соответствующих конференций.

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

Disclaimer: все изложенное – моя личная интерпретация событий

Сберджайл

Итак, начну я с истории Agile-трансформации Сбербанка. Публичным началом этой истории является выступление Германа Грефа на Гайдаровском форуме-2016 (ссылка на запись 28 минут, в сети есть другие), которое существенно повлияло на распространение Agile-методов в России и заслуживает отдельного анализа. В большинстве выступления изложений в СМИ фокус был на то, что «Греф назвал Россию страной-дауншифтером», в то время как реальным сообщением была необходимость перестройки госсистем и, особенно образования, если Россия не хочет оказаться в числе стран-дауншифтеров (07:40-12:00). Это как раз к вопросу о том, почему полезно смотреть первоисточники, а не изложения СМИ. Но в контексте этой статьи интересно то, что говорится дальше.

Несколько лет Сбербанк вел централизацию своей IT-разработки, сосредоточив ее в отдельной структуре Сбертеха. Отдельные команды могли работать по-разному, в том числе по agile, но в целом применялось классическое проектное управление. И из него было выжато все, что возможно, при этом получилось достичь квартальных релизов для всего комплекса систем Сбербанка. Это – очень часто по тем временам, Microsoft примерно тогда говорил о переходе к квартальным релизам Visual Studio как о супердостижении.

При этом весь цикл реализации запроса на разработку, если он требует изменений в нескольких основных системах, получилось сократить от нескольких лет до 9 месяцев. Но вот меньше – не получалось. По сравнению с крупными глобальными банками это все равно достойный результат, и Греф в своем докладе говорит о том, как они гордились своими достижениями. Но при этом оказалось, что по сравнению с Google, Amazon и другими лидерами цифрового мира это – совсем не достижения (14:00-15:00).

И вот в 15:40-16:40 Греф говорит про ставку на Agile и Scrum: «Все будет построено на Agile», «Те, кто не освоят Agile в текущих бизнес-процессах, будят лузерами завтра». А дальше, с 17:20 он говорит про горизонтальную культуру. Незадолго до этого Герман Греф прочитал Джеффа Сазерленда «Scrum» и Фредерика Лалу «Открывая организации будущего», и эти книги были рекомендованы для прочтения всему Сбербанку. И на Гайдаровском форуме он публично объявил о ставке на эти технологии управления.

Герман Греф: Все будет построено на Agile. Те, кто не освоят Agile в текущих бизнес-процессах, будят лузерами завтра.

На мой взгляд, это вовсе не было пиаром или данью какой-то моде, про Agile в широких кругах в то время вообще почти никто не говорил, хотя AgileKitchen в Аппарате правительства по применению Agile в госпроетах и была раньше, в конце 2015 (мой отчет). Да и достижения Сбера были реальными, если кто помнит разницу между его отделениями конце нулевых и в 2016, то изменения разительны. А позиции Сбера в стране – устойчивы.

Моя гипотеза в том, что Грефу поставили задачу сделать Сбербанк глобальным банком. Он начал готовить IT-инфраструктуру классическим образом, достиг сопоставимого с глобальными банками уровня. А потом обнаружил, что на западные рынки Сбербанк не пускают административно, а на восточных надо конкурировать не с банками, а с Телекомом и Али-бабой, а у тех развитие идет гораздо быстрее. Это, конечно, лишь гипотеза. В любом случае, ставка на Agile была публично объявлена.

Теперь о том, что было дальше. Первый такт развития Agile в Сбербанке – 2016 год. Трансформацию консультировали McKinsey и ScrumTrek, McKinsey обеспечивал политику в большой корпорации и референс-визиты по всему миру, а ScrumTrek – собственно Agile-процесс на основе SAFe. Основная задача – максимально расширить Agile-сообщество, начали они с 16 команд в мае, осенью их было уже 75. При этом в Agile был вовлечен не только IT, но и бизнес, создавались совместные команды бизнеса и IT, нацеленные на вывод новых банковских продуктов, в них вместе работали сотрудники Сбербанка и Сбертеха. Команды были организованы в крупные племена, работали в общем пространстве и культурная трансформация относительно традиционной корпоративной культуры была очень сильной.

Точкой синхронизации является 8-недельный PI planning, и они учились его проводить в форме однодневной встречи на 80 человек на первой сессии до 260 осенью, с эффективной фасилитацией. Обо всем этом рассказывали Юлия Молостова вместе с Алексеем Пименовым в сентябре на AgileBusiness-2016 (мой конспект), процесс вовлечения новых команд развивался и далее, но до самой интересной инженерной части вовлечения архитекторов, ответственных за старые legacy-системы дело не дошло.

Второй такт начался весной 2017 с приходом в феврале Барта Шлатмана. На AgileDays-2017 делал доклад уже он, хотя рассказывал о том, что сделано ранее. Барт пришел из нидерландского банка ING, в котором для организации работ применялась собственная версия Agile, и он ставил в банке именно ее, отчасти отказываясь от того, что было раньше, например, от роли Scrum Master. Что-то пошло не так, и ожидания не оправдались, потому что через год, в феврале 2018 Барт покинул Сбербанк. Скорее всего при бурном росте все-таки была потеряна прозрачная результативность. И начался третий такт.

Трансформация не свернута, она продолжается, и не только потому, что процесс развития самоорганизующихся команд, в общем-то, можно остановить только вместе с увольнением сотрудников. Главное – те вызовы, для ответа которым была сделана ставка на Agile, по-прежнему актуальны, а альтернативных вариантов не существует. Насколько я знаю, Scrum Master снова появился, в некоторых племенах пророс LeSS, идет разнообразная активность. А на верхнем уровне Банк силами собственных сотрудников пробует обеспечить прозрачность потока ценности через Kanban и работу с метриками, и вроде продвигается в этом направлении успешно. Впрочем, публичных выступлений по дальнейшему развитию Сберджайл я в последние два года не слышал.

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

А главное – без внимания к ценности результата. Именно это отличает классическое проектное управление, в нем главное – выполнить запланированный объем работ, а не получить ценность на выходе. И это зафиксировано в методологии: вопрос использования созданного в проекте вынесен за его рамки, на уровень программы, несколько лет назад я писал об этой проблеме статью «Проекты — для достижения результата, а не для освоения бюджета» для профильного журнала «Управление проектами». И потому результатом такой трансформации будет выполненная перестройка организации, а вопрос о результативности перестроенной организации для тех, кто ведет проект, будет вторичен. Этим кейс Сбербанка отличается от следующего кейса трансформации Альфа-банка.

Трансформация Альфа-банка

Альфа-банк пошел по принципиально другому пути. Крупными мазками об этом на той же AgileBusiness-2016 рассказывали Алексей Марей (главный управляющий директор Альфа-Банк) и Сергей Дмитриев (Unusual Concept) (видео, мой конспект). Когда было принято решение об Agile-трансформации, то на добровольной была собрана команда топ-менеджеров, ответственных за ее проведение, проведены тренинги и другая подготовка. А дальше выбрано два пилотных сегмента – обслуживание среднего и мелкого бизнеса и обслуживание VIP- физ.лиц, и в них начали запускать смешанные команды бизнеса и IT в том темпе, в котором получалось обучать и запускать команды при ограниченном ресурсе коучей.

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

А вот опции отправить по старому регламенту, где определены сроки прохождения процедур по закупки или другие правила у них нет. Они, конечно, могут это сделать, объяснив, что помочь невозможно, тогда команда эскалирует на Product Owner, а тот решает сам или подключает свое руководство. В целом таким образом Agile-культура, которую несут команды, пускает щупальца по всему банку.

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

А задача топа, который взял тикет со стены плача за месяц решить проблему системно, а не в частном случае. Если не смог – то дальше точка решения уже для него: он может заниматься еще месяц, если решение близко, или должен попросить помощи у других топов из команды трансформации, объяснив сложность. Если он не решил проблему и не просил помощи, то желтая карточка уже у него – зачем он в команде изменений, если не решает проблемы, которые сам взял. И это – тоже преодоление психологического барьера для топа: они привыкли рассчитывать на себя и действовать индивидуально, а тут надо работать в команде и просить помощи. Марей об этом изменении говорил отдельно.

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

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

Другие банки

Из других кейсов Agile-трансформации банков очень интересным, на мой взгляд, является банк Агророс. Это небольшой региональный банк, в нем 350 сотрудников, есть региональные отделения. Трансформации подверглось операционная деятельность банка. Об этом на AgileDays-2019 рассказывал председатель правления банка Дмитрий Кондрацков, а доклад так и назывался «550 дней Agile в операционном управлении!» (мой конспект).

Неожиданно то, что применялся Scrum в чистом виде. Он был выбран потому, что хорошо работает с запутанной системой по Кеневин (подробности есть в моей статье «Место Agile-команд в компании»), а именно к таким системам относится банк: надо экспериментировать и отрабатывать варианты для новых продуктов и решения для проблемных точек.

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

Параллельно - трансформация центрального офиса, отделы по Scrum. Стратегия в офисе - идти от проблемных отделов: кредитный отдел, просрочки, информационная безопасность и далее. Если отдел работает неплохо - не надо менять. Стабильный поток задач хорошо обрабатывает Kanban. Продуктовые команды тоже работают по Scrum. Взаимодействие идет через демо, на нем возникает вовлеченность и сопричастность, а текущее взаимодействие обеспечивают Product Owner. На уровне банка в целом все это синхронизировано через по OKR (Objectives and Key Results).

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

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

Если говорить про другие известные кейсы Agile в банках, то сразу вспоминаешь Райффайзен и Тинькофф. Я не буду много говорить, хотя каждый из них типичен по-своему. Райффайзен – это организация, открытая ко всему новому и активно экспериментирующая с этим. Agile в нем имеет свою историю с успехами и отступлениями. Можно посмотреть выступления на Agile Business-2017, на Agile Days-2018 и другие.

А Тинькофф сразу организовывался как цифровой банк, в котором IT – это главное и нет ничего удивительного в том, что Agile там активно используется. При этом работа идет с постоянным мониторингом метрик продвижения, характерных для цифрового мира. Цифровой мир живет в реальном времени, характерное время изменений – часы, максимум дни, а не месяцы и годы, как в традиционных компаниях. И именно это является принципиальным отличием.

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

На этом я завершаю первую часть рассказа про кейсы Agile-трансформации. Продолжение следует…

0
33 комментария
Написать комментарий...
Вася Бездомный

"трансформация займет не меньше 5-7 лет, а результат на таком масштабе не гарантирован" - отличная фраза, можно отливать в граните. Не знаю как там Альфа, но судя потому, что рассказывают ребята на местах, Сберджайл это такая личная игрушка Грефа и присосавшихся к процессу консалтеров-паразитов.

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

Некоторые ребята по секрету грят, что своего ажаль-кучера видели только 1 раз - на этапе запуска команды. После запуска сберджайла кучер ни разу не появлялся, потому как, цитата: "у нас мишн критикал активность, нам некогда в этот маразм играть, дело делать надо иначе всё колом встанет".

Ответить
Развернуть ветку
Максим Цепков
Автор

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

"Шаг вперед - два шага назад" - это не соответствует действительности. Реально наоборот, несколько шагов вперед, часть из них оказались ложные - отступаем. Но те, которые оказались истинными - сохраняем. Нормальная работа для создания того, чего раньше никто не делал. Дальше вопрос к выбору конкретных шагов. Сбертех был ДО Agile-трансформации, в статье это явно написано. И это была попытка достичь тех же целей методами регулярного менеджмента, при этом высосав с рынка компетентный персонал зарплатами. И да, с моей точки зрения, не реалистичная, но это уже другой вопрос. Принимая решение полагали, что шансы на успех есть. Провели эксперимент, не получилось, выбрали другой путь.

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

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

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Ответить
Развернуть ветку
Денис Качнов

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

С одной стороны, т.к. "классический" менеджмент критикуют за сложный процесс создания нового и преобразований: 
"1. Определить бизнес-кейс
2. Разработать сложное решение
3. Пройти через долгосрочную реализацию
4. Жить с очевидными последствиями: затяжная боль долгосрочной реализации, долг нереализованных ожиданий и неудобное осознание того, что окружающий мир уже продвинулся вперед" (почти цитата).

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

Очень странно это видеть - заявки на гибкость оказываются вполне себе реализациями "гранд дизайна" по требованиям конкретного фреймворка.

Ответить
Развернуть ветку
Максим Цепков
Автор

Ну, тут проблема в том, что менеджмент часто хочет изменить других, а не меняться сам, как это Александра Баптизманская сказала недавно в выступлении "что за бред, проблемы у менеджеров а измениться должны сотрудники". Вот и подходит к проектам привычными способами. У Дмитриева в Альфе получилось изменить подход топов, и там все было динамично. И он, кстати, Сбером, отказался заниматься именно потому, что не увидел у топов готовности меняться. 

Что касается глобальности преобразования, то не совсем, обычно есть пилот и постепенное тиражирование. Но сложность в том, что при трансформации сильно меняется корпоративная культура, возникает разрыв новых и старых подразделений. При этом известно, что "культура ест стратегию на завтрак" (Друкер) и способна любые изменения обесценить

Ответить
Развернуть ветку
Денис Качнов

Я о другой проблеме написал.

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

Пилоты - окей. Но проблема в их масштабируемости. Далеко не все можно без искажений масштабировать из небольшого эксперимента. Пример: масштабирование Скрама (Less, Less Huge, SAFe и т.д.). 
 

Ответить
Развернуть ветку
Максим Цепков
Автор

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

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

Иной, эволюционный путь с самого начала предлагает Kanban. Но, возможно, именно недостаточный радикализм первого шага и неопределенность целевой конструкции заставляет заказчиков выбрать SAFe или Less Huge. А реально Kanban обеспечивает, что мы не внедряем обобщенную систему, а строим систему для конкретного предприятия. И это - более перспективно. Вроде это начинают понимать.

Ответить
Развернуть ветку
Денис Качнов

"Отпишись и не читай."

Ответить
Развернуть ветку
Тинькофф

Спасибо за упоминание и интересную статью!

Ответить
Развернуть ветку
Максим Цепков
Автор

Рад, что понравилось!

Ответить
Развернуть ветку
vic buynoff

Я вот не пойму, с какого бодуна, прямо сразу после новогодних, нам тут на VC распродают  аджайл, канбан и скрам? Фейерверки все распродали, теперь этот неликвид?...

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Ответить
Развернуть ветку
Andrei Kiladze

А твой голова может породить? Что именно породить и зачем?

Ответить
Развернуть ветку
Максим Цепков
Автор

А мой голова порождает уже девятнадцатую статью про менеджмент в цифровом мире. Чтобы объяснить людям, как оно там будет устроено. И в целом люди читают и находят много интересного, а местами мы обсуждаем с ними фактуру, хотя на facebook больше чем здесь. Ну а некоторые люди не прост живут в парадигме "есть моя точка зрения и неправильная", но и "я не могу сформулировать, что именно тут неправильного, поэтому скажу, что автор с бодуна"

Ответить
Развернуть ветку
Vl Al

У консультантов бабло закончилось после новогодних пьянок.

Ответить
Развернуть ветку
Дмитрий Кондрацков

Спасибо автору (прим. Максиму Цепкову) за интересный материал об Agile, который раскрывается на примерах организаций финансового сектора. В 2017 году региональный Банк «Агророс» стал применять подход Agile в своей работе. С тех пор мы постоянно развиваемся и растем. Кроме того, мы активно участвуем в создании сообщества Agile в Поволжье. Запускаем новые проекты в бизнесе (в производственной, научной, управленческой сфере) и системе образования - подробнее об этом я расскажу на AgileDays 26-27 марта 2020 г. в Москве.

Ответить
Развернуть ветку
Максим Цепков
Автор

Дмитрий, спасибо, что откликнулись! Я слушал ваш доклад в прошлом году, и был впечатлен и самим кейсом и качеством доклада!

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Максим Цепков
Автор

Спасибо! Я, в общем, знал какие люди в интернетах встречаются... Но и конструктива тоже много.

Ответить
Развернуть ветку
Vl Al

"Итак, начну я с истории Agile-трансформации Сбербанка."

Свежий пример. Совсем свежий. Зашел в местное отделение. Шесть ATM на площади в два раза меньше, чем нужно. Я стою за спиной чувака, который снимает бабло и нервно оглядывается. Мне отойти некуда. 

Так что, все эти трансформации хороши только на презентациях.

В жизни - жопа была, жопа трансформировалась, жопа осталась.

Ответить
Развернуть ветку
Максим Цепков
Автор

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

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

Ответить
Развернуть ветку
Vl Al

"Так что качество - приемлемое, люди - ходят." - Зарплатные карты. Поэтому ходят.

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Ответить
Развернуть ветку
Vl Al

"Зарплатные карты можно в любом банке."

Это в теории, для компании.

На практике, для работника - что дали в бухгалтерии, то и жуй.

Ответить
Развернуть ветку
Максим Цепков
Автор

Не, ну если работник хочет жевать, что дают, то он жует. А если не хочет - то меняет это дело. Или место работы. И это - не так сложно.

Ответить
Развернуть ветку
Andrei Kiladze

Но добавились ценности агила же! Гибкая жопа?

Ответить
Развернуть ветку
vic buynoff

Ценности... Вот если бы ими расплачиваться можно было

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Ответить
Развернуть ветку
Vl Al

"только сначала заработать надо"

Сбер - труба для прокачки собранных налогов.

И для конвертации "воздуха" в ипотечные кредиты.

"А в приличном обществе через взаимное уважение можно получить то, что через деньги не получишь."

В приличном обществе проценты по ипотеке несколько меньше, чем цена квартиры.

Ответить
Развернуть ветку
Максим Цепков
Автор

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

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

Ответить
Развернуть ветку
Andrei Kiladze

Понятно же, что это не ценности а "ценности".

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Ответить
Развернуть ветку
Timur Batyrshin

Максим, в копилку кейсов - поинтересуйся историей Акбарс банка. Они очень хорошо перестроились за последние года три. Они сейчас много где про это рассказывают. Ключевые слова safe и enterprise architecture. Один из факторов успеха - поддержка топов

Ответить
Развернуть ветку
Максим Цепков
Автор

Тимур, большое спасибо! Быстро посмотрел статьи по Agile в Ак Барс Банке - да, интересный кейс. Произошло реальное сращивание бизнеса и IT. Если будут весной рассказывать на AgileDays или других конференциях, где я буду - то и услышу вживую.

Ответить
Развернуть ветку
Читать все 33 комментария
null