Интервью с Сергеем Кунцевичем, Digital CTO российского ретейлера

По результатам отчета «15^th State of Agile» SAFe® является самым популярным фреймворком масштабирования Agile в мире. В России также все больше крупных организаций переходит на Scaled Agile Framework. Почему компании выбирают именно SAFe? Что становится триггерным моментом? Как проходит SAFe трансформация? С какими сложностями организация сталкивается при переходе на SAFe? Какие рекомендации могут дать эксперты-практики, которые прошли весь путь трансформации с самого начала?

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

О Сергее Кунцевиче: Сергей давно работает в ИТ, прошел путь от разработки до управления проектами. Запускал большие e—commerce проекты в России, Европе и США. С 2018 года присоединился к команде крупного российского ретейлера (более 20 лет на рынке, более 1000 магазинов по всей стране — от Калининграда до Владивостока).

 Алексей Ионов: Сергей, что для тебя как профессионала «Scaled Agile Framework»?

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

Я где-то встречал фразу, что SAFe «превращает неясное в сложное». На мой взгляд, фраза не отвечает действительности. Безусловно, может сложиться такое впечатление, когда вы открываете описание фреймворка и видите там много текста и графики. Но важно понимать, что во многом это информация про разные дополнительные инструменты, про разные лучшие практики, которые сведены в этот фреймворк. А основа SAFe достаточно проста: проста для внедрения, проста для управления и прозрачна. Все остальные инструменты – это тот самый тюнинг, который вы потом добавляете и который делает еще лучше то, что и так начинает хорошо ехать. И поэтому не стоит пугаться. SAFe прост. В базе – это классический Scrum плюс надстройка для решения проблем масштабирования».

С чего все начиналось?

Алексей Ионов: У тебя опыт перехода на SAFe с нуля в крупном российском ретейлере. Расскажи, с чего все начиналось? Почему возникла необходимость изменений?

Сергей Кунцевич: Переход на Scaled Agile Framework был начат в середине прошлого года. Но здесь нужно сделать отсылку, что трансформация началась еще раньше с внедрения продуктового подхода и Agile в целом. Мы начали сначала с одной Agile команды, потом нескольких Agile команд, которые работали в соответствии с Agile Манифестом, принципами Agile и доставляли ценность. Однако поток запросов от бизнеса все нарастал, и в какой-то момент мы пришли к необходимости масштабировать процессы, которые сложились внутри компании. SAFe стал ответом, который мы нашли и благодаря которому за последнее время мы выросли многократно.

Алексей Ионов: Какие были этапы при переходе на новые подходы? Что стало триггерным моментом?

Сергей Кунцевич: Первым триггером и этапом стало то, что старый проектный подход перестал удовлетворять организацию с точки зрения скорости вывода товара на рынок (time—to—market). Проекты велись долго, по завершении они уже не соответствовали той действительности, которая изменилась за время разработки. Многие решения, которые необходимо было выводить на рынок для того, чтобы соответствовать быстро меняющимся ожиданиям клиентов – запаздывали. Компания это осознавала и стала искать способы, как можно изменить эту ситуацию.

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

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

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

Эти два триггера и ознаменовали сами собой два этапа Agile трансформации, которая проходила в компании.

Поиск решения. Почему SAFe?

Алексей Ионов: Как вы искали решение?

Сергей Кунцевич: Мы провели исследование рынка на предмет существующих методологий. Посмотрели разные фреймворки: Less, Less Huge, Spotify, SAFe. В качестве альтернативы также рассматривалась разработка собственных решений на основе имеющихся подходов и идеях, существовавших в компании.

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

Алексей Ионов: Почему остановились именно на SAFe?

Сергей Кунцевич: Основные вещи, которые привлекли нас в SAFe:

1. Во-первых, SAFe — это набор практик и стандартов, которые уже написаны и которые сразу же можно взять за основу, чтобы минимизировать те потенциальные ошибки, с которыми мы могли бы столкнуться на пути трансформации. Это выгодно отличает SAFe от какого-то другого фреймворка или собственного решения организации. SAFe проверен временем и множеством компаний. И была некая уверенность, что мы сможем, используя эти практики, достаточно оперативно поехать в нужном направлении с ожидаемой, а не упавшей скоростью.
2. Во-вторых, в SAFe есть инструменты для управления большими стратегическими инициативами, которые необходимы для нашей крупной и многоуровневой организации. Это не про спринты, а именно про инициативы, которые реализуются долго, месяцами.
3. В-третьих, SAFe помогает обеспечить плюс-минус точное планирование выхода важных изменений под ритм рынка и ожидания топ-менеджмента компании. Для организации важно понимать, что разработка, исследование и запуск не будет длиться дольше, чем необходимо, в соответствии с ожиданиями.

В большей части других фреймворков таких элементов не было. Например, Spotify – это больше про организационную структуру предприятия. LeSS – это скорее масштабирование большого потока небольших задач. Управление задачами уровнем недель и месяцев, управление стратегическими инициативами там отсутствовало как класс. А в SAFe есть инструменты управления такими инициативами, их декомпозиции и оценки, анализа их инвестиционной привлекательности и ROI, выравнивания ИТ со стратегией компании и т.д. – это все очень большая часть нашей работы. Нам это понравилось, и мы решили внедрить SAFe.

Как проходила SAFe трансформация?

Алексей Ионов: Как проходила SAFe трансформация? Какие были основные этапы?

Сергей Кунцевич: Первый Agile Release Train был запущен летом 2021 года.

Основные этапы внедрения:

• Обучение ключевых людей, лидеров внутри организации тем ролям SAFe, которые они должны будут выполнять. Это ключевой фактор: люди должны были понимать, что от них ожидается, что они должны сделать в рамках этой трансформации.
• Обновление подходов к беклогу: беклог был декомпозирован на те элементы, которые управляются на разных уровнях и разными ролями.
• Проведение PI Планирования и запуск первого продуктового инкремента, который на тот момент состоял из 5 итераций-спринтов (потом компания перешла на Инкремент Программы из 4 итераций: трех итераций разработки и четверной Итерации Инноваций и Планирования)

Алексей Ионов: С какими сложностями вы столкнулись на своей пути?

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

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

Здесь нам очень помогает практика SAFe — Inspect & Adapt. Все активно участвуют, всегда создается много идей по улучшениям и каждый инкремент мы меняемся, трансформируемся дальше — улучшаются процессы, улучшаются показатели, улучшается управляемость.

Алексей Ионов: Вносили ли вы какие-то изменения в предписания фреймворка? И если да, то какие?

 Сергей Кунцевич: Мы «докручивали» сами процедуры и некоторые процессы, чтобы сделать их эффективнее. Например, сейчас мы проводим несколько по-другому рассмотрение предварительных планов команд в рамках мероприятия PI-Планирования.

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

Запланировать идеально на 100% никогда не получится, всегда возникают какие-то изменения (что-то случится, что-то было упущено при планировании и т.д.). Соответственно, одна из проблем, которая периодически возникает: кто-то знает об этих изменениях, а кто-то не знает и продолжает работать без учета перемен. И именно для того, чтобы избегать подобных ситуаций, требуется правильная синхронизация.

Качество проведения мероприятий также изменилось со временем. Если вначале в силу какого-то предыдущего опыта мероприятия по синхронизации проходили в виде отчета перед Владельцем продукта или Скрам мастером о том, что они делали и что они будут делать, то сейчас акценты смещены на ответы на вопросы: «Что поменялось с момента прошлой синхронизации?», «На что и как мы будем реагировать?»

Что касается уровня Портфеля, то мы регулярно проводим мероприятие «Обзор Портфеля». LPM – очень полезный инструментарий для менеджмента компании. Именно здесь команда LPM управляет большими инициативами, согласовывает распределение ресурсов и емкости (сколько мы тратим и на что), уточняет метрики, по которым отслеживается движение портфеля в сторону доставки большей ценности и постоянного развития. Такое взаимодействие гарантирует, что основной ресурс, который мы тратим на стратегию, тратится туда, куда надо и тогда, когда надо.

Алексей Ионов: Что в результате получилось?

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

Один поезд является продуктовым. Он ориентирован на доставку бизнес-ценности, продуктовых историй и фич, стратегических бизнес Эпиков.

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

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

Результаты, выводы и планы.

 Алексей Ионов: Какие планируются дальнейшие шаги?

 Сергей Кунцевич: Основной следующий шаг – это тюнинг того, что уже есть, для достижения лучших результатов. С точки зрения SAFe это будет дальнейшая работа с метриками Measure & Grow, с тюнингом процессов, работа с инструментарием, который есть в SAFe, но пока еще не был использован в компании и в оценке его эффективности через Сообщества Практик (CoP). Например, улучшение внутренних технологических процессов в области качества, автоматизации, инфраструктуры и т.д.

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

Алексей Ионов: Какими уроками ты могли бы поделиться с теми, кто планирует переход на SAFe?

Сергей Кунцевич: Я бы выделили несколько моментов:

• Следите за метриками, процесс прежде всего нужно всегда измерять. В идеале нужно подумать и собрать метрики заранее, чтобы потом не принимать решения интуитивно или где-то контринтуитивно, просто на основе опыта или ощущений. Когда решения помогают принимать цифры — этот всегда более надежно.
• Важно не отвергать сразу не устраивающие практики, процессы и регламенты, которые составляют основу той или иной методологии. Это относится как к SAFe, так и к Scrum, XP и другим.

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

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

• Думайте о ценности и стройте организацию вокруг ценности, используя инструмент SAFe — Картографию Потоков Ценности (Value Stream Mapping). SAFe – это все-таки не про организационную структуру, а про потоки ценности.
• Работайте с бизнесом так, чтобы ему было понятно и прозрачно, вовлекайте его, и тогда все получится. Иначе возникнет сопротивление, возможно непреодолимое.

Алексей Ионов: Каких результатов удалось достичь?

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

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

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

Алексей Ионов: Прошел уже год с начала SAFe трансформации. Какие выводы можно сделать на данный момент?

Сергей Кунцевич:

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

Я всегда был противником изобретения велосипедов. Я всегда был сторонником брать велосипед, на нем ездить, а потом его доснабжать необходимыми аксессуарами, «тюнить», а не каждый раз изобретать его заново. Внедрение SAFe подтвердило это общее ощущение: что можно взять готовую систему, разобраться в ней, как и что работает, запустить, и она действительно будет работать. Самый главный вывод — оно действительно работает!

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

Каким компаниям подходит SAFe?

Алексей Ионов: Каким компаниям, на твой взгляд, подходит SAFe?

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

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

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

Отзыв о работе с «Ионов и Партнеры»

Алексей Ионов: Поделись своим опытом работы с компанией «Ионов и Партнеры»?

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

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

Во-вторых, хочу также отметить твою роль в персональном консультировании меня по всем вопросам, с которыми мы сталкивались. Ответы на вопросы — «а почему так?» и «зачем это надо?» — это ключевые моменты.  Мы должны всегда понимать, зачем мы что-то делаем. Мы здесь не делаем карго-культ из фреймворка и не делаем все по бумажке, «потому что там это прописано». А выполняем, осознавая, зачем это нужно. И если мы не понимаем, зачем это нужно, мы пытаемся в этом разобраться. Когда разбираемся и понимаем, что это действительно приносит ценность, проверяем. Ты помогал нам разобраться, зачем нам это надо и какие риски нам грозят, если мы это не сделаем. Ты также содействовал в решении насущных вопросов, которые вставали. Такая помощь, на самом деле, бесценна. Я бы сказал, что тренинги – это хорошо, но очень важно, когда есть кто-то, к кому можно обратиться и получить поддержку.» 

Блиц-вопросы

Какие были основные бизнес- и/или организационные проблемы до развертывания SAFe?

Большая зависимость между командами

Какие основные задачи стояли перед внедрением SAFe?

Масштабирование Agile подходов в рамках организации

Какие были ключевые вызовы (основные сложности) при внедрении SAFe?

Научить бизнес «ездить на велосипеде»

Следовала ли ваша организация дорожной карте внедрения SAFe?

В основном, да

Были ли вызовы и сопротивление изменениям культуры?

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

Является ли бережливое управление портфелем частью вашего внедрения SAFe?

Мы стараемся следовать тем практикам, которые описаны в LPM. Какие-то практики мы используем, какие-то нет. Например, мы не используем Participatory Budgeting (PB, самобюджетирование, оно же инициативное бюджетирование). Однако, мы регулярно проводим Обзор Портфеля, смотрим на рынок, смотрим на себя внутри для того, чтобы наилучшим образом соответствовать изменяющемуся контексту и быть эффективными.

Используете ли вы SAFe Measure & Grow Assessment для определения областей улучшения?

Да, обязательно. Используем все метрики потока, продуктовые метрики также используются. Измеряем также agility (team agility, organizational agility), чтобы понимать тренды, насколько мы двигаемся в сторону гибкой организации.

Какие основные 3-5 преимуществ, которые ваша организация увидела от внедрения SAFe?

• Предсказуемость
• Управляемость
• Управление крупными инициативами

Есть ли что-то уникальное или особенно примечательное в твоём опыте запуска SAFe, что другие профессионалы могут найти интересным для себя?

У меня теперь есть опыт создания Энейблер-Поезда, который «движется по рельсам» крайне эффективно. Такой выделенный технологический поезд является нестандартным решением в SAFe.