SAFe® our souls – опыт и выводы Ренессанс Жизнь

Доклад на конференции Enterprise Agile Russia 2021 29 ноября 2021 года.

Всем привет! Меня зовут Александр Мольский. Я — IT-директор компании «Ренессанс Жизнь». Последние пять лет я занимаю эту должность. В целом в IT-сфере у меня примерно семнадцать лет опыта. Я начинал с технической поддержки и сейчас, соответственно, являюсь IT-директором «Ренессанс Жизнь». В гибкие методологии я попал в качестве участника порядка шести лет назад. Примерно четыре года назад я решил их возглавить, поэтому на текущий момент я действующий SPC (прим. ред. — SAFe Program Consultant).

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

С чего мы начинали? Всем знакома ситуация, когда бизнес и IT как два противоборствующих лагеря. Бизнес говорит, что IT-шники странные, ничего не делают. IT-шники говорят, что бизнес «достал». Соответственно, это постоянная смена приоритетов. Прилетает какая-то задача, ее начинают делать. Потом прибегает бизнес и говорит, что срочно начинаем делать вторую задачу. Не доделали вторую задачу – появляется третья задача и т.д.

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

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

В 2016 году были отделы: IT-департамент, бизнес и т.д. В 2017 году постепенно начали формироваться команды. В 2018 году пришли к Scrum, появились первые Scrum-мастера. В 2019 году мы осознали, что у нас достаточно команд, мы хотим синхронизироваться и выходить на масштабный уровень. Посмотрели по сторонам, нашли разные методологии: Nexus, LeSS, SAFe и Disciplined Agile.

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

В 2020 году мы полностью разочаровались в том, что мы сделали. Мы просели. Та самая волшебная J-Curve, про которую все говорят. Но мы начали анализировать, что пошло не так, где мы ошиблись. Это происходило на протяжении всего 2020 года, в конце которого мы осознали, что именно не так. Весь 2021 год мы живем в SAFe. Такой RenLife Way SAFe.

Наш контур на текущий момент — это примерно 300 человек, четыре поезда. Эти поезда влияют на 5 000 пользователей в день, которые работают в наших системах.

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

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

Когда мы запустили первый поезд (команд было минимум пять), мы планировали запускать дальше.

SAFe говорит: запустили первый – сразу запускайте второй. И мы решили, что все задачи, которые есть у бизнеса на стыке с IT, туда добавим. В какой-то момент проектный офис сказал: «Контрольная точка — 18 число. Нам не важно, что у вас поставка в конце итерации. И нам совершенно неважно, что у вас тут две зависимости. А еще: что значит «самоуправляемая команда»? Кто у вас тут ответственный? Мне нужен конкретный человек, кто будет здесь ответственный. Скажите мне его фамилию!» И мы такие: «Оказывается, все задачи разные…».

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

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

И никому не рекомендуем класть такие задачи в SAFe. Да, это команды, но они отдельные и находятся рядом с поездами, а не внутри них. Да, они участвуют на планировании; да, они слушают, что происходит, потому что платформенные команды могут влиять на их работу. Может быть, планы других команд могут повлиять на их работу, но и они как таковые не планируются.

SAFe говорит, что не нужно планировать на 100% команды. Планируйте чуть-чуть меньше, оставляйте запас. Это всем известный факт. Мы на команды планируем не только change, но и run. Те самые дефекты и мелкие задачи. Мы их называем ad hoc задачи. Вначале мы говорили, что у нас будет на команды примерно 20% таких задач.

По факту в каких-то командах через несколько инкрементов появляется ad hoc 50%, 60% и произошло это по причине характера работы команд. Мы осознали, что если в команде начинает переваливать за 40% ad hoc, то нужно эту команду разделить или создать еще одну рядом, которая возьмет на себя тот самый run, который был поставлен изначальной команде.

Потому что команда, которая планирует 60% ad hoc, не имеет возможности заниматься change, они погрязнут в ad hoc.

Ad hoc уровня ART — это наше нововведение. Это история про то, чтобы не получилось ситуации, когда приходится перепланировать фичи после PI-планирования. Сейчас мы пришли к тому, что у нас есть одна команда. Эта команда каждый инкремент разная. Это как переходящее знамя. На эту команду мы планируем не очень важные задачи, которыми мы в принципе готовы пожертвовать.

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

Я не буду говорить про высокоуровневые роли: архитектора, RTE, business owners, стейкхолдеров, продакт-менеджмент. Когда компания начинает трансформацию, на мой взгляд, тут все очень просто. Был архитектор — остался архитектором. Был начальник разработки или кто-то, отвечающий за процессы в IT, — стал RTE. Был какой-то человек в бизнесе, кто не управлял бюджетом, но принимал продуктовые решения, — будет продакт-менеджмером.

И тут мы приходим к ролям, которые есть внутри команд: Владелец продукта, Scrum-мастер и команда разработки. Мы говорим: «Нам нужен Владелец продукта. Кто тут самый сообразительный из заказчиков, кто поставлял нам задачи? Вот этот вот линейный руководитель. Прекрасно. Маша, ты будешь теперь Владельце продукта. Мы тебя отправим на курсы». Мы отправляем Машу на курсы. Маша приходит с курсов и говорит: «Там рассказывают про какие-то метрики, про клиентскую ценность, про MAU, DAU и прочее. А у нас тут кровавый энтерпрайз. У меня тут операционные системы, у меня тут транзакции. Я не понимаю, как это вообще в принципе коррелирует. Вы меня чему там научили?»

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

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

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

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

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

Вы хотите именно Scrum? Делайте, как Scrum говорит. Если нужен человек, который будет секретарем команды, который будет водить на встречи, собирать и что-то записывать, протоколировать, то это не Scrum-мастер. Заведите секретаря, который будет приходить на встречи команд и протоколировать их действия.

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

Второй момент. Если вы захотели сделать Scrum-мастера как Scrum-мастера, нужно просто понимать: Scrum-мастер сам не сможет стать Scrum-мастером. Это точно так же, как если я попрошу человека: «Держи, вот тебе трубка и баян. А теперь научись играть на баяне и курить трубку». Что человек сделает, что у него получится? Он научится курить трубку.

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

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

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

И последний момент. Scrum-мастер — это, как мы на своем опыте поняли, не многостаночник. История про то, что будет Scrum-мастер на две, три, четыре команды, абсолютно не работает. Точно так же, как и Scrum-мастер, выделенный на 100% на одну команду. Такой Scrum-мастер либо обалденный психолог, который проводит с каждым членом команды one-to-one, который читает тонну литературы, который прокачивает и себя, и всю свою команду. Но это кто-то другой, точно не Scrum-мастер. Поэтому мы на своем опыте поняли, что Scrum-мастер — это либо аналитик, либо разработчик, либо тестировщик. Одним словом, это лидеры мнений с прокачанными soft skills, которые на такую работу по развитию команды тратят примерно 30-40% своего времени. Остальное время они помогают команде непосредственно по своей компетенции.

Когда вы запускаете трансформацию, у вас есть иерархическая структура компании. SAFe говорит: «Мы не претендуем на вашу оргструктуру, на вашу иерархию. Мы — вторая операционная система, мы строим функциональную структуру и эта функциональная структура нам даст ту самую гибкость». На самом деле, это не так. SAFe фактически трансформирует организацию. Да, остается оргструктура, но на уровне членов правления. Примерно C и C-1. Ниже все меняется.

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

И важный момент. Когда формируется поставка, в ней участвует не только IT. В этой поставке бизнес участвует наравне с IT. А чтобы бизнес наравне с IT участвовал, придётся тратить примерно 30% времени рядовых сотрудников, представляющих интересы бизнеса на общение с командами поставки.

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

Второй момент. Команды могут собираться сами. Мы сделали так: выписали все направления, которые у нас есть, все value streams, выписали абсолютно всех наших сотрудников. Дали 10 баллов каждому и сказали: «Вот эти 10 баллов вставляйте, куда хотите. Можете 10 поставить в одну, можете везде поставить по 1, можете вообще никуда ничего не ставить». Так мы собрали команды на основании их предпочтений. Это дало результат. Команды буквально через первый инкремент прибавили 20% в продуктивности.

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

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

Что получилось в результате за это время? Мы каждый год, даже иногда чаще, чем раз в год, во всей компании проводим очень большое исследование. Там не только метрика вовлеченности, там порядка 17 метрик. Проводит его сторонняя компания. За последние два года вовлеченность людей, которые участвуют в процессе трансформации и в процессе поставки, выросла на 35%. На текущий момент у разработчиков, сотрудников IT и т.д. средний стаж 3,5 года. Более того, самая приятная для меня метрика — это то, что 80% ребят, которые уходили от нас, вернулись.

Они возвращаются со словами: «Мы туда пришли, а там — как у нас было пять лет назад. Мы не хотим. Мы познали все в сравнении. У нас очень классно!» И предсказуемость возрастает. Да, она у нас возросла до 91% за последний инкремент. И такая метрика — замена целей. Как я говорил, первый наш инкремент: было PI-планирование, собралось много людей, мы поставили PI-цели.

Прошло две недели и шесть задач поменялось. Постепенно количество задач и качество планирования росло. За счет той самой ad hoc команды уровня поезда. Вторая причина — планирование и вовлеченность людей. Люди теперь понимают, что они делают, зачем это делают.

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

Видео и слайды

Слайды доклада.

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