Текст книги "Менеджмент цифрового мира"

Альфа-банк пошел по принципиально другому пути. Крупными мазками об этом на той же 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-трансформации.
Часть 2 – корпорации и госструктуры

Ранее я рассказывал про кейсы банков, сейчас – про корпорации и госструктуры: Ростехнадзор, Пенсионный фонд, Банк России, Росатом, Северсталь. Как я уже писал, мои источники – доклады на профильных конференциях AgileDays, Agile Business и других, а также разговоры в кулуарах конференций и другие частные разговоры. Конечно, рассказ на конференциях часто дает идеальную картину, однако разница с реальностью обычно не слишком велика. К тому же присутствие среди участников сотрудников компаний, о которых рассказывают в докладе и общение с ними позволяет оценить объем лакировки. В любом случае, если у кого-то есть иная картина – напишите в комментариях, читателям будет интересно, и мы сможем обсудить разницу. Все написанное – моя собственная интерпретация, однако в статье много ссылок на видео докладов и мои конспекты, так что вы можете составить свое собственное мнение.

Рассказ про кейсы госструктур я начну с интересной истории о том, как Ростехнадзор заставил своего IT-подрядчика перейти на Agile-методы от классической проектной разработки. Обычно в историях ситуация ровно обратная: компания-разработчик применяет Agile-методы, и у нее возникают проблемы при взаимодействии с государственными заказчиками, потому что те мыслят в терминах классического подхода. А здесь – наоборот. Кейс старый, о нем рассказывала Марина Макарчук на уже упоминавшейся Agile Kitchen по Agile в госпроектах в конце 2015 года (мой отчет), и тогда ему было уже два года. Кстати, на AgileDays-2016 она тоже делала доклад об этом опыте.

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

Кстати, зарубежный опыт тоже говорит, что упертых защитников старого можно убедить только директивно. Во всяком случае, истории зарубежного опыта, которые я услышал то той же AgileKitchen в докладе Асхата Уразбаева говорит, что именно так были вынуждены поступить правительства Великобритании и Штатов, когда после крупных провалов проектов, управляемых традиционно, делали применение Agile обязательным для госпроектов, в 2011 и 2014 годах соответственно. В Англии подробности можно посмотреть на сайте Government Digital Service, а в Штатах – на сайте United State Digital Service в разделе The USDS origin story. Вообще на той встрече довольно много говорили о практиках IT-разработки для государства. Вопреки распространенному мнению, заказчики это тоже часто хотят. И при взаимной воле сторон это вполне возможно, включая контрактование по 44-ФЗ – это научились делать в Тюменской области, о чем рассказывал в докладе Иван Дубровин, у него в презентации были ссылки. Отметим, что уже прошло много времени, и практика может быть шире.

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

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

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

Еще один кейс Agile в госструктурах рассказывали Светлана Иванова, Дарья Корнеева и Николай Арапов в докладе «Банк России: знать путь и пройти его – не одно и то же» на AgileDays-2018 (мой отчет). Я уже говорил немного про него, рассказывая про Kanban-доску в одном из департаментов в главе «Доска – визуализация текущего состояния работы», но в докладе было еще несколько кейсов. Есть феерические эффекты, когда по проекту, который не запускался полгода, после перезапуска в скрам-команде за 1.5 месяцев получали первую версию, или когда проект создания распределенной структуры, который сделать «за год – точно не реально» тоже выдавал первые результаты через пару месяцев. А в среднем производительность повысилась на 30—40%. Отметим, что все кейсы в докладе касались не IT-подразделений, а операционной работы и проектов изменений. В целом, насколько я понимаю, решение о применении Agile-методов дано руководителем подразделений и проектов, что логично: они отвечают за конечный результат, и значит могут выбирать способ его достижения. И есть те. кто делает ставку на Agile-методы.

В Росатоме Agile применялся для адаптации проекта АЭС в Финляндии под требования Евросоюза, об этом на Agile Business-2017 рассказывал Сергей Малоземов в докладе «Применение Agile в проектах атомной отрасли» (мой конспект). Понятно, что сначала это попробовали сделать классическим способом, но адаптация оказалась недопустимо дорогой, а время ушло. И потребовалось за 3 месяца придумать способы снижения стоимости адаптации при соблюдении требований и без увеличения размеров здания. И здесь кроссфункциональные команды и открытое agile-общение в сочетании с легкой, но достаточно жесткой scrum-структуризацией процесса сыграли свою роль, результат был достигнут, проработка порожденных идей дало 26% экономии. Что важно – Agile был встроен в корпоративную среду крупной корпорации, принципиальных противоречий – не обнаружено, а наоборот, отмечен позитивный эффект от использования. Как сказал Сергей в заключении, они попробовали Agile-методы, представляют их возможности и будут и далее применять там, где это уместно.

Еще один кейс Александр Колобов, директор по развитию Севергрупп и Виталий Сухарев «Agile в металлургии – ускоряем Северсталь» на Agile Business-2018 (мой конспект). Рассказ об изменении организации, был рассказ о принципах и о том, что инициировало трансформацию. Проблема понятна: Северсталь – это регулярный менеджмент в достаточно жесткой форме: производство, безопасность, нормативы, правила и контроль. Но при этом нужны новые продукты и идеи.

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

Принципы, которыми они руководствуются:

– единая сквозная цель, вдохновляющая и объединяющая

– культура доверия – обеспечивает самостоятельность команд

– радикальная прозрачность

– понятные границы

– постоянные эксперименты

При этом проектный офис организационно сохранился, просто часть Project Manager стали Scrum Master и начали работать по-другому. Разные проекты идут по разным путям, это зависит от характера проекта. Около 70 продуктов сейчас разрабатывают по-новому. И изменения успешны: на входе было Time to market разработки продуктов был 2—2.5 года, сейчас 1—1.5 года, и видят, что он еще будет сокращаться. Принципиальный фактор – людей собрали в команду по продукту, вместо функциональных подразделений – А

Интересно, что концерн Калашникова тоже применят Scrum при разработке нового оружия. Я узнал на этом на встрече в PMO club в сентябре 2017, там было три человека оттуда, приехали из Ижевска. У них в составе проектного офиса уже год как работают Scrum-команды. И за двухнедельный спринт успевают сделать в железе реальный кусочек, который можно пощупать и оценить, и благодаря этому получается быстро скорректировать маршрут движения проекта – а в обычном подходе это бы было проявлено через полгода.

Кейсы Agile-трансформации.
Часть 3 – производство

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

Свой рассказ про Agile-трансформации производственных компаний я начну с кейса издательства МИФ (Манн, Иванов, Фабер), о котором на IT Spring-2017 рассказывал Владимир Горшунов, а осенью на Agile Business-2017 у него был совместный доклад с Артемом Степановым «На пути к Business Agility. Трансформация издательства МИФ».

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

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

Заметим, что речь идет не об одной книге, а именно о серии, которая образует value stream: сначала запускается первая книга, но все готово к тому, чтобы при успехе можно было выпустить и другие, а при неудаче – наоборот, свернуть с ограниченными потерями. Отдельные проектные потоки (value stream) объединены в три крупных value stream по направлениям бизнеса: розничный, корпоративный и online, при этом за счет каскадирования каждый проект понимает свое место и значение в реализации стратегии в целом. И эта комплексная картина собирается и транслируется на компанию в целом.

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