Самостоятельное внедрение SAFe®: 5 кейсов российского рынка

Руководитель группы Agile-трансформации в компании-разработчике платформы по управлению интернет-рекламой eLama, руководитель отдела разработки биржи грузоперевозок АвтоТрансИнфо, руководитель отдела корпоративных продуктов и руководитель отдела тестирования корпоративных продуктов Лаборатории Касперского, директор дивизиона «Розничное взыскание и урегулирование» Сбербанка и CEO сервиса автоматизации процессов предприятий общественного питания iiko рассказывают о том, как они внедряли фреймворк SAFe® в своей компании, не прибегая к помощи внешних консультантов.

1. Почему вы решили внедрять SAFe? Какие цели преследовали?

Иван Лавров, руководитель группы Agile-трансформации eLama:

В какой-то момент возникла задача: соединить стратегические цели компании и направления, в которых двигались маркетинг и разработка. Следовательно, нужен был такой подход и набор практик, которые бы позволили командам вместе и планировать, и работать над проектами, и достигать квартальные цели. В SAFe мы нашли то, что нам нужно, — идеи, связанные с PI-планированием и System Demo (мы внедряли только эти элементы фреймворка).

Егор Попов, руководитель отдела разработки АвтоТрансИнфо:

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

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

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

Денис Кузнецов, директор дивизиона «Розничное взыскание и урегулирование» Сбербанка:

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

Роман Аврамов, CEO iiko:

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

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

Что такое SAFe? Планирование спринта на примере iiko (28 минут)

2. Как строилась работа по внедрению?

Иван Лавров (eLama):

Сформулировав стратегические цели компании и получив две недели на подготовку к общему планированию, мы создали команду волонтеров из топ-руководства: СТО, CPO, представителей HR. Поскольку само планирование — задача более простая, чем подготовка сотрудников (и с точки зрения мотивации, и чисто технически), — мы в первую очередь сосредоточились на подготовке сотрудников.

Что мы сделали:

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

В процессе у нас появлялись идеи адаптации предложенного по умолчанию варианта планирования под нашу компанию. Очень полезным было изучение кейса компании Lego, где процесс планирования внедрял Хенрик Книберг (прим. ред. — этот кейс описан в книге Совместное планирование).

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

Егор Попов (АвтоТрансИнфо):

Мы не пользовались внешним консалтингом, но обучались. Было две волны. На первой, я лично присутствовал, проходя тренинг у Анны Обуховой в мае 2017. Вторая волна обучения проходила для двух других сотрудников компании уже после запуска SAFe. Выходя с обучения, я был уверен, что внедрить SAFe в полном объеме не удастся из-за нехватки квалифицированных и погруженных в данную методологию людей. Поэтому выбрал несколько инструментов, с которых началось построение нового процесса. Сделал вводный доклад в конце года на внутренней конференции, и с января 2018 запустили первый PI. На мой взгляд, успех трансформации зависит во многом от руководства, от его поддержки и доверия сотрудникам. С этим нам очень повезло — спасибо огромное Святославу Вильде.

Как SAFe® помогает справляться с выгоранием, Екатерина Засухина (37 минут)

Александр Колесников и Антон Киселев (Лаборатория Касперского):

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

На подготовку первого PI отвели неделю, но быстро поняли, что за это время полноценную подготовку провести маловероятно, и решили ограничиться внедрением только элементов SAFe в одном из крупных проектов. PI назвали «Купе» — от QP, то есть Quarter Planning (квартальное планирование). Название к тому же перекликается с термином Agile Release Train. В общем, полноценный поезд не строили, а делали отдельные вагончики.

После этого перераспределили функциональные группы разработчиков и тестировщиков, добавили к ним аналитиков и архитекторов. Назвали каждую такую команду «фича-тим». Сделали подобие системных команд, которые назвали экспертными командами.

Для работы над самыми важными фичами приглашали ключевых заинтересованных лиц, с которыми впоследствии тесно взаимодействовали. Аналитики становились фича-оунерами, лиды команд — Scrum-мастерами, проектные и тест-менеджер — кем-то вроде RTE,  продуктовые менеджеры — остались продуктовыми менеджерами. В итоге мы провели два «Купе» со всеми необходимыми встречами и артефактами.

Денис Кузнецов (Сбербанк):

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

Роман Аврамов (iiko):

Все началось с обучения: курсы по SAFe прошли топ-менеджеры, в том числе и я, а также все проектные менеджеры. Мы шли в комфортном для себя темпе и не пытались внедрить весь SAFe сразу. Примерно через месяц после обучения у нас была очередная трехмесячная итерация. Мы провели её уже с применением некоторых методик SAFe, а именно PI-планирования и WSJF для приоритизации фич. В следующих итерациях выделили роли владельцев продукта и запустили метапроцесс: после каждой итерации проводили ретроспективу и оценивали, что можно улучшить. Так в ходе каждой итерации мы постепенно внедряли по 2-3 новых элемента SAFe.

«No pain, no gain» или история одного внедрения команды эксплуатации в SAFe, Сергей Гнутов (36 минут)

3. Какие изменения произошли за прошедшее время? Можно ли подвести итоги внедрения?

Иван Лавров (eLama):

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

Как вернуть веру в Agile через совместное планирование бизнеса и команд, Иван Лавров (28 минут)

Егор Попов (АвтоТрансИнфо):

Можно выделить два ключевых изменения:

1. Средний уровень закрываемости задач вырос до 80%, у двух команд — до 100%.
2. Каждую вторую пятницу проводим и записываем демо. Запись помогает, потому что к ней всегда можно вернуться и уточнить нужные моменты.

Александр Колесников и Антон Киселев (Лаборатория Касперского):

Положительные итоги:

• Стали тратить меньше времени на мусорные требования: команды из модели push перешли в модель pull.
• Work Time и Lead Time уменьшились в два раза: не из-за ускорения, а из-за ограничений каденции.
• Впервые за многие годы выпустили релиз в срок, что отметили коллеги. Релиз проходил гораздо спокойнее.

Отрицательные итоги:

• По неопытности допустили много ошибок.
• Перегрели часть команды.
• Стали тратить гораздо больше времени на коммуникации, иногда слишком много. В некоторых командах в этом отношении даже развился карго-культ.
• Не смогли довести инфраструктуру до нужного уровня CI/CD.
• SAFe в рамках одного изолированного проекта не работает: не удалось вовлечь коллег из соседних подразделений.
• Не все смогли внутренне перестроиться на работу по новому подходу.
• Учиться на RTE пошли в самом конце эксперимента.

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

Денис Кузнецов (Сбербанк):

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

Роман Аврамов (iiko):

Положительные результаты стали заметны уже после первой итерации с применением методик SAFe. Мы стали лучше попадать в сроки, а качество продукта стало выше. Раньше бывало так, что в релиз попадало не более 80% от запланированного функционала, а сроки выпуска сильно сдвигались: 3 месяца легко превращались в 4. То есть, сейчас мы стали делать быстрее и больше, чем раньше: теперь релиз на 90-95% соответствует плану.

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

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

4. Насколько легко внедрять SAFe самостоятельно?

Иван Лавров (eLama):

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

Егор Попов (АвтоТрансИнфо):

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

Александр Колесников и Антон Киселев (Лаборатория Касперского):

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

Денис Кузнецов (Сбербанк):

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

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

Роман Аврамов (iiko):

Не могу сказать, что было очень сложно, но могу сформулировать несколько советов, которые точно облегчат жизнь тем, кто решится внедрять SAFe самостоятельно:

1. Обучите ключевых сотрудников основам SAFe.
2. Выявите основное ограничение в текущем процессе разработки. Если команда проводит ретроспективу — её результаты могут натолкнуть на нужные мысли, если нет — пройдите самостоятельную оценку по ScrumButt Test или подобной методике.
3. Выберите не больше пяти элементов SAFe, которые могут помочь преодолеть это ограничение, и внедрите именно их в ближайшей итерации.
4. Повторяйте пункты 2 и 3.

Кроме того, для успешного внедрения SAFe важны:

• Корпоративная культура организации и внешняя среда, допускающие работу по Agile. Успешное внедрение SAFe вряд ли возможно, например, в «красных» организациях (по классификации Фредерика Лалу).
• Чёткая и понятная цель предстоящих изменений в процессах.
• Мотивированная команда, которая осознаёт несовершенство текущей методики и готова активно участвовать в изменениях.

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

Результаты спринта iiko SAFe. Тренды ресторанного IT (29 минут)

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.