Мы продолжаем делиться внутренними документами Авито. Сегодня это будет модель зрелости. Она может пригодиться как трекер внедрения инженерных практик всем компаниям, где есть своя разработка.

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

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

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

Предпосылки к созданию инструмента

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

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

Мы хотели создать модель, которая помогла бы избежать ряда проблем в будущем: 

1. Развитие инженерных команд происходит, но понимание базового уровня у всех разное. 

2. Одни команды знают, что прокачивать, и им нужно лишь задать вектор. Другие команды считают, что они знают, что прокачивать, но качают не то, что нужно компании. Есть и команды, которые не хотят прокачиваться — нет времени точить пилу, потому что надо пилить.

3. Когда нет общего стандарта, одни команды могут убежать далеко вперед, а другие — стоять на месте. Через какое-то время им станет тяжело находить общий язык и скоординированно достигать результатов.

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

5. Мало кому интересно работать в незрелой команде. Хочется использовать последние технологии и лучшие практики. 

Грабли и решения процесса по созданию модели 

В основу идеи модели зрелости лёг Squad Health Check компании Spotify. В процессе работы он сильно эволюционировал. 

Базово модель зрелости — это описание ожиданий от команд по тем или иным параметрам и оценка для каждого параметра. Описание ожиданий составляют эксперты в своей области. В Авито есть центры экспертизы по разным областям: Information Security, QA, Performance, Frontend, Backend и Delivery. При создании модели мы оттолкнулись от этих существующих центров и предложили им вместе создать системный инструмент. Пилотные описания и прогоны сделали на двух секциях, а потом добавляли в модель остальные. 

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

1. Без очень чёткого разделения уровней в модели командам непонятно, какой именно бейзлайн и как его достичь. Поэтому нужно точно описывать уровни 0, 1, 2 и 3. А не «1 — частично соответствует базовому уровню, 2 — полностью соответствует». 

2. Самооценка команд не оправдала ожиданий из-за низкой точности результатов. Получалось так, что кто-то оценивал себя лучше, кто-то — хуже. Мы поняли, что самостоятельная оценка имеет смысл только с экспертной валидацией.

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

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

5. Время экспертов, которые помогают командам с оценками и планами по своим секциям, не масштабируется. Но вовлечение экспертов резко падает после первой волны оценок. В самом начале процесса нужно пройтись по всем командам и всё объяснить. А дальше существующие команды двигаются квартал к кварталу по модели, обращаясь к экспертам только эпизодически. Также внимание экспертов нужно новым командам, но это не драматически большие временные затраты. 

6. Описания секций не всегда понятны на 100%. Всегда будет кто-то, кто их не поймёт, поэтому экспертам нужно много и часто объяснять формулировки на встречах в самом начале процесса и уточнять описание по обратной связи от команд.

7. Непонятно, что делать с собранными данными дальше. Нужна система, которая поможет отслеживать результаты: цели в ОКРах и задачи в JIRA, показатели в Google Docs. И чтобы это было связано одним процессом. 

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

9. Часть вопросов в секциях не применима к отдельным командам. Для них должен быть способ не оценивать себя по таким вопросам, чтобы не было искажения общего результата. 

В итоге процесс работы с моделью зрелости выстроился так: команда оценивает саму себя по шкале от 1 до 3, после этого есть встреча с экспертами, которые корректируют и подтверждают оценки команды. Эксперты объясняют, куда идёт Авито, что командам нужно делать и почему всё устроено как устроено. Главная задача экспертов — обучать команды и подтягивать их на нужный компании уровень зрелости. 

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

Задача на создание модели зрелости появилась до того, как мы ушли на удалёнку, но на удалёнке стала критически важной. Тренд таков, что при распределённой работе нужно перевести многие вещи в текст, например, онбординг нового инженера или даже онбординг инженерной команды. И здесь использовать модель зрелости очень удобно: новые люди и команды сразу могут узнать, какой в идеале должна быть инженерка и что от них ожидает компания.  

Модель зрелости Авито и как её адаптировать для своей компании

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

Чтобы начать адаптировать документ для своей компании, сделайте его копию. Для этого выберите в верхнем меню «Файл» → «Создать копию». В документе мы оставили только те секции, которые напрямую связаны с инженеркой.

Вкладка «Критерии оценки»

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

Мы оцениваем зрелость инженерных команд по шести основным блокам:

1. Информационная безопасность.

2. Обеспечение качества.

3. Перформанс.

4. Фронтенд.

5. Бэкенд.

6. Продакт-delivery.

Delivery — это процесс от продуктового бэклога до внедрения задачи в продакшен. 

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

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

Вкладка «Оценки команд»

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

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

Процесс оценки устроен следующим образом: 

1. Команда встречается раз в квартал, смотрит на свои текущие показатели по модели зрелости и оценивает, насколько они изменились. 

2. Если произошли изменения, то команда назначает встречу с экспертом по секции. Эксперт комментирует обновлённые оценки и те задачи, которые команда поставила себе на будущее. При желании можно решить вопросы с экспертом асинхронно в чатах. Если команда на 100% уверена в новой оценке, эксперта она не зовёт. Это возможно, когда есть чёткое понимание и стабильный ритм роста по модели.

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

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

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

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

Как не надо использовать модель

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

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

Бизнес-польза модели

Напоследок финализируем, зачем оно всё бизнесу. Основная задача технического директора — сделать так, чтобы доставка фичей до клиентов работала как часы, а команда перформила с определённой скоростью и определённым качеством. 

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

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

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

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

Выученные уроки и итоги

Чтобы модель зрелости работала и приносила компании пользу, нужны: 

1. Эксперты и их вовлечённость в процесс. Это ключ к росту и динамике.

2. Мягкие коммиты от команд, чтобы они сами говорили, что будут прокачивать и когда. 

3. Контроль процесса и его прозрачность. Нужно, чтобы всё было визуализировано в JIRA, гугл.документах или любых других инструментах. 

4. Эпизодический пересмотр секций и повышение базового уровня. 

5. Ответственный за саму модель, который сделает так, чтобы шестерёнки проекта крутились на уровне компании.

Благодаря внедрению модели нам удалось обналичить ситуацию такой, какая она есть. Мы поняли, где есть отставание от базового уровня и какое оно в разных командах. В самом начале пути на базовом уровне не было никого. За последний год нам удалось поднять до него 20% инженерных команд Авито.