Все статьи
SAFe® в нефтянке — легко! Или…
Дата: 23.01.2023
Легко ли внедрять продуктовые улучшения в строгой вертикально интегрированной компании? С чего начать и возможно ли закончить? Реальный опыт внедрения Scrum и инструментов SAFe® (Scaled Agile Framework®) в Газпром нефти.
Доклад на конференции Enterprise Agile Russia 2022.
Содержание статьи
Проблематика и немного цифр
- 5000+ человек задействовано в Change, который мы устроили в век цифровой трансформации.
- Уже сделано более 1200 IT-решений. Их делали огромное количество команд разного уровня зрелости и делают на данный момент.
- 65 программ цифровой трансформации (не так давно их стало 65). Они разного объема: от 80 до 150 человек, разделить их пока невозможно, а может и не нужно.
- Все выделяет нас за счет того, что у нас более 40 городов и большое количество площадок, на которых работают наши люди — наши команды.
Фактически проблемы или трудности, которые мы видим, они, так или иначе, похожи на кейсы других компаний.
Естественно, очень хочется вовлекать бизнес во всю IT-реализацию, которая присутствует у нас в компании, вместе с тем, менять бизнес-процессы, и менять их с помощью инструментов, которые мы делаем. Но есть изюминка. Она в том, что в разговоре с людьми, командами и непосредственно представителями бизнеса, все задают одни и те же вопросы: «Где это написано, где это утверждено? Как это работает? Дайте нам инструкцию. Да, мы прекрасно понимаем, что такое самоорганизующаяся команда, но вот если была бы инструкция — нам было бы гораздо удобнее и лучше жить».
Что же мы сделали?
Небольшая историческая справка. В 2018 году мы начали с команд: мы научили их жить в коротких итерациях, отдавать понятный результат, который действительно нужен людям и который что-то меняет. Для этого мы сделали стандарты, технические регламенты, как мы раскатываемся, что мы разрабатываем и как. Мы даже сделали интерактивный cookbook в виде веб-решения, и он до сих пор используется.
Дальше, непосредственно работая с этими самыми командами, а это заняло довольно продолжительное время, мы поняли, что та самая степень проникновения продуктовых практик в умы людей разная. Поэтому мы придумали вот такой радарчик — взяли лучшие мировые практики и адаптировали их непосредственно под нашу компанию. Поскольку в нашей компании главной ценностью и главным капиталом являются люди, мы сосредоточились на них, на их компетенциях, на том, что они должны делать и каких результатов добиваться.
Возвращаясь к инструкциям: появились профили компетенций, также появились составы проектных, продуктовых, программных команд. Было запущено огромное количество образовательных курсов, как для владельцев продуктов, так и для Scrum-мастеров. И вот совсем недавно был запущен образовательный курс для руководителей программ — это маленькие СРО (прим. ред. — Chief Product Officer), у которых есть в подчинении коллеги — Product Owners, которыми они управляют.
Чуть подробнее про продуктовую зрелость. Это нужно для того, чтобы с понятным качеством, с понятной историей и с конкретной скоростью отдавать результат. Появилась базовая модель. На самом деле она была бинарна, и говорила о том, используется ли или не используется тут практика. Мы не говорим про глубину использования. Там, где мы видели, что нужно глубинное интервью, приходили, разговаривали и составляли индивидуальные планы развития. Таким образом, мы поднимали зрелость команд. И в следующем году будет уже продуктовая зрелость версии 2.0, очередной релиз уже в продакшене. Мы немного поменяли компоновку, набор метрик и параметров, на который мы смотрим, а также нашли некий баланс между программным уровнем, то есть по факту бизнесовым и командным — уравняли их.
Самое главное, мы автоматизировали сбор этих метрик. Соответственно, теперь практически каждое утро, можно смотреть, что в конкретных командах меняется. Опять же, для чего? Для того чтобы иметь основательный диалог с Product Owner, с тем самым Scrum-мастером, который смотрит за этой командой, и вообще для того, чтобы поговорить с командой, понять, какие у нее боли.
Какой эффект это возымело? Топ-менеджмент, скажем так, лидеры наших бизнесовых функций, стали задавать очень понятный и классный вопрос: «Ребята, вы работаете хорошо, вы работаете много, огромное количество разных вещей делаете. Но что меняется у людей? Что меняется там «в полях»? Люди стали по-другому работать, или же им проще стало работать?» Эти вопросы стали основополагающими.
Таким образом, для 65 программ инкрементальный цикл стал равен 3 месяцам. Называть кварталом нельзя ввиду того, что есть некоторые смещения. Есть конкретные цели с конкретными цифрами с конкретным Definition of Done (прим. ред. — DoD, критерии готовности), по которым происходит оценка этого самого инкремента: достигли целей, либо нет.
Почему SAFe®?
Есть бизнесовый уровень, есть большой айтишный уровень, который может удовлетворять потребности этого самого бизнеса. Есть понятные циклы поставки, и, что самое главное, понятный контроль, в частности, за бизнесом. Наверняка многие слышали, видели и участвовали в том, когда приходит какой-то большой босс и выкладывает очень простую историю: «Вот есть задача, она максимально важная, берите и делайте». При этом никакие другие задачи, которые уже запланированы, не исчезают, с ними надо что-то делать.
Но чем чаще мы смотрели и с бизнесом, и с командами, и со всем IT-кластером на эту ситуацию, мы понимали одно — ничего не понятно. Поэтому было решено снизить свои ожидания и подумали про портфель.
В итоге пришли непосредственно к базовому уровню. Это оказалось эффективно.
Эксперимент по масштабированию
Небольшой эксперимент, который мы сделали 1,5 года назад в марте 2021 года. Все помнят про пандемийные ограничения. Очень важно было понять применимость всего этого фреймворка для нашей компании при таких вводных. Представитель бизнеса согласился на это и решил попробовать. Мы начали с трех программ общей численности около 400 человек суммарно, то есть мы обучали их. Буквально пара-тройка недель у нас ушла на подготовку целей, фич и прочего.
Параллельно другие начали смотреть и говорить: «Интересно… давайте мы тоже поучимся и попробуем».
После этого еще пришли люди. Мы пошли по своему пути: отучились, за 1,5 месяца подготовились, все получилось с точки зрения целеполагания и в итоге запланировались.
Позже настало демо, и все встали в ряд. Нас было совсем мало. Мы всячески привлекали наших уважаемых партнеров ScrumTrek, чтобы все прошло успешно.
Потом случились еще демо и буквально за 8 месяцев 2021 года у нас 12 программ превратились в 12 ARTs со своими целями, со своими цифрами, со своими DoD. Параллельно мы качали команды, качали бизнес, и качали именно с точки зрения компетенций.
Первый опыт был весьма скромным. У нас были техлиды из команд, Product Owners, и они что-то генерили. Сначала было тяжело, но со временем всё преображалось.
Удаленно — это, конечно, удобно планироваться, но гораздо круче, когда за эти два пандемийных года все соскучились по стикерам (хоть ранее они всем надоели) и наконец-то встретились. Важно, чтобы бизнес осознал, что нужно приходить очно, нужно с тех самых 200 площадок привозить всех людей очно, это имеет наиболее высокий эффект.
Планирование онлайн
Помните Jira, Confluence? Мы сделали из этого действительно глубокую настройку. Можно с помощью этих инструментов прямо в онлайне, не собирая всех вместе, планировать. Планирование проходили, в том числе, и во всей этой истории.
Этот большой борд, на котором видно, а что вообще с программами происходит, а планируются ли они, а релизятся ли они.
Это операционный борд непосредственно самой программы, где мы видим степень достижения целей, и метрики предсказуемости, а также все, что с этим связано.
Что мы получили, а главное – как?
Итого, что мы имеем буквально за 1,5 года — 65 активных программ, которые имеют инвест-решения:
- 45 из них уже на инкрементальных рельсах;
- 40 из них работают в Jira;
- остальные работают в других инструментах.
Что для этого сделали?
- Подготовили большое количество RTE (прим. ред. — Release Train Engineer). В той или иной степени кто-то перформит, кто-то пока нет, для этого развиваем сообщество.
- Огромное количество людей обучили вообще фреймворку, и что с этим делать.
- Scrum-мастеров точно так же в своих школах обучали, хотя я считаю, что все-таки Scrum-мастер в двух вариациях может быть — как отдельно выделенная роль в команду на какое-то количество времени, либо это все-таки «шапочка».
Что важно, все вот эти продуктовые практики, которые используются постоянно, ежедневно на программном, на командном уровнях, они описаны и стандартизированы. Что, опять же, для этого сделали? Огромнейшее количество людей обучили, не только IT-кластер, еще и бизнес. Удивитесь, но представители бизнеса тоже работают в Jira, неохотно, но делают это.
Фактически метрики выросли. Да, где-то немного и можно лучше (да, и правда можно), но мы к этому стремимся, это не финал.
Отвечая на вопрос топ-менеджмента, что у нас с частотой релиза произошло? Стало чаще в 4 раза. Важно, ФОТ (прим. ред. — фонд оплаты труда) не изменился. По факту есть затраты на все управленческие вещи, на вещи, связанные с непосредственно разработкой. И кто-то может сказать: «Да 100% он изменился». Да, но в пределах погрешности, поэтому будем считать его константой. И это большой плюс непосредственно для бизнеса.
Видео и слайды
