Update avito-developer-practice.md

avito-developer-practice.md

@@ -2,6 +2,7 @@
 
 - [Live Site Review (LSR)](https://github.com/avito-tech/playbook/blob/master/avito-developer-practice.md#live-site-review-lsr) — разбор инцидентов
 - [Архитектурный комитет](https://github.com/avito-tech/playbook/blob/master/avito-developer-practice.md#архитектурный-комитет) — ревью архитектуры приложений и сервисов
+- [Team maturity model](https://github.com/avito-tech/playbook/blob/master/avito-developer-practice.md#Team-Maturity-Model) - Модель зрелости: как мы оцениваем и растим инженерные команды
 
 ## Live Site Review (LSR)
 Нам важно, чтобы Авито стабильно и надёжно работал. Но бывает, что несмотря на наши усилия, что-то ломается. Это может быть железо или какой-то архитектурный компонент под высокой нагрузкой. В этом случае важно починить возникшую проблему как можно быстрее. Для этого у нас есть развесистая система мониторинга и алертов, а также служба круглосуточных дежурных.
@@ -157,3 +158,93 @@
 
 ### Кто входит в состав комитета?
 Состав участников комитета заранее определён и периодически обновляется, в него входит около 40 человек, представляющие все важные функции и кластеры разработки. Присутствие всех членов комитета на встрече не требуется, состав подбирается модераторами для каждого конкретного кейса. Два человека выполняют роль Модераторов. 
+
+## Team Maturity Model
+
+Внутри Авито под моделью зрелости мы понимаем как раз список разных инженерных и продуктовых практик. Мы хотим, чтобы разные команды находились по этим практикам на едином базовом уровне или выше. Например, чтобы мы точно понимали, что все команды стремятся к пирамиде тестирования и регулярно проводят ретроспективы. 
+
+Чётко прописанная модель зрелости помогает быстро синхронизироваться и находить зоны роста команд. Её задача — выровнять в большом количестве инженерных команд одновременно глубину проникновения и полноту технологий и процессов, которые мы считаем нужными.  
+
+### Предпосылки к созданию инструмента
+Техническому директору важно понимать, в каком состоянии зрелости находятся инженерные команды компании, где нужно усиливать культуру и какие области требуют повышенного внимания. У нас есть задача системно прокачивать команды, и делать это на основе прозрачных и понятных правил. 
+
+Нам нужен был инструмент, описывающий базовые вещи по процессам, которые необходимы для работы команды, и практики, которые мы хотим сознательно внедрять. Этот инструмент также должен был помочь математически корректно измерить, насколько каждая команда близка к ожидаемому уровню зрелости.
+
+Мы хотели создать модель, которая помогла бы избежать ряда проблем в будущем: 
+- Развитие инженерных команд происходит, но понимание базового уровня у всех разное. 
+- Одни команды знают, что прокачивать, и им нужно лишь задать вектор. Другие команды считают, что они знают, что прокачивать, но качают не то, что нужно компании. - Есть и команды, которые не хотят прокачиваться, — нет времени точить пилу, потому что надо пилить.
+- Когда нет общего стандарта, одни команды могут убежать далеко вперед, а другие — стоять на месте. Через какое-то время им станет тяжело находить общий язык и скоординированно достигать результатов.
+- Если ничего не делать, то со временем будут увеличиваться расходы компании на качество. Внесение изменений будет становиться всё дороже и дороже. В итоге пострадает технический или продуктовый бренд. 
+- Мало кому интересно работать в незрелой команде. Хочется использовать последние технологии и лучшие практики. 
+
+### Модель зрелости Авито
+Модель зрелости — это техническое задание на то, какой в идеале должна быть инженерная культура компании. Маяк, к которому нужно стремиться, и набор лучших практик. Наша модель зрелости описана в гугл таблице по ссылке ниже. 
+
+# [Модель зрелости Авито в гугл-документе](https://docs.google.com/spreadsheets/d/1L2gWdJjXevbAvDqG5CkGOvdp_zQobeJ0ajABzPF3N-w/edit#gid=353319364)
+
+#### Вкладка «Критерии оценки»
+В первой вкладке документа собраны секции, по которым мы оцениваем свои команды. Cекции написаны экспертами в своей области: они определяют базовые уровни и до утверждения финальной формулировки проводят фокус-группы с командами, чтобы не улететь в космос по ожиданиями.  
+
+Мы оцениваем зрелость инженерных команд по шести основным блокам:
+- Информационная безопасность
+- Обеспечение качества
+- Перформанс
+- Фронтенд
+- Бэкенд
+- Продакт-delivery
+
+Delivery — процесс от продуктового бэклога до внедрения задачи в продакшен. 
+
+Когда мы запускаем новую команду, она изучает модель зрелости и сразу определяет, какие направления надо подтянуть. Уже действующим командам описания уровней дают возможность понять, как им стать круче и быстрее. 
+
+Компаниям, которые хотят адаптировать наш документ под себя, я рекомендую написать сначала от одной до трёх секций и попилотировать их в боевом режиме. Когда появится отлаженный процесс, можно будет добавить и другие секции в вашу модель. 
+
+#### Вкладка «Оценки команд»
+
+В строках вкладки прописан критерий, за который ставится оценка. Каждый столбец — название команды. В каждой ячейке для оценки есть выбор из шести значений. Вот что они значат:
+- 0 - Команда на уровне 0 по критериям оценки. 
+- 1 - Команда на уровне 1 по критериям оценки.
+- 2 - Команда на базовом уровне.
+- 3 - Команда на уровне 3 по критериям оценки.
+- ? - Команда не знает, какую оценку поставить. Нужно оценить уровень на встрече с экспертом. 
+- N/A - Not applicable — пункт неприменим к конкретной команде. Например, команда инфраструктуры поиска в Авито не ставит себе оценки в секции по фронтенду, так как им не занимается.
+
+### Процес оценки
+
+Процесс оценки устроен следующим образом: 
+- Команда встречается раз в квартал, смотрит на свои текущие показатели по модели зрелости и оценивает, насколько они изменились. 
+- Если произошли изменения, то команда назначает встречу с экспертом по секции. Эксперт комментирует обновлённые оценки и те задачи, которые команда поставила себе на будущее. При желании можно решить вопросы с экспертом асинхронно в чатах. Если команда на 100% уверена в новой оценке, эксперта она не зовёт. Это возможно, когда есть чёткое понимание и стабильный ритм роста по модели.
+
+Каждый квартал мы создаём новую вкладку с оценками. Команды собирает данные, заносят свои оценки в актуальную вкладку и ставят себе новые задачи по росту. Этот процесс повторяется циклично. На выходе мы получаем в таблице единую картину по всем командам и динамику по зрелости квартал к кварталу. 
+
+У нас много разных команд, и модель помогает всем, несмотря на то, что они разные. Это происходит за счёт того, что мы можем не ставить оценки по конкретным пунктам. В начале пути у нас были мнения, что для продуктовых команд и для технической платформы модели должны быть разными, но в итоге мы решили это противоречие через оценку N/A. Причём может быть так, что внутри одной секции половина пунктов к команде применима, а половина — нет. Ничего страшного в этой ситуации нет, оценка подтверждается через консультацию с экспертом, и в новых кварталах команда на такой пункт модели уже не смотрит
+
+Также могут быть команды, которые не хотят следовать стандартам в силу своих причин. Такие сложные ситуации должны точечно обрабатывать эксперты: их задача прийти и выяснить, почему команда считает так, а не иначе. Если стандарты действительно не подходят, то для конкретной команды модель зрелости мы не применяем. Но важно, чтобы это подтвердил эксперт, он отвечает за технологию и процесс, ведь именно он отвечает за установленные технологии и процессы.
+
+Модель зрелости — это своего рода световой меч. Он может может быть в руках повстанцев и в руках Империи. Для нас это ориентир, который помогает командам расти. Они сами определяют, что важно прокачать в первую очередь, что во вторую, и берут эти цели себе в [OKR](https://github.com/avito-tech/playbook/blob/master/goal-setting.md). Мы надеемся, что вы тоже будете использовать модель зрелости во благо.
+
+### Как не надо использовать модель
+Неправильно понимать модель зрелости как способ оценить, кто в компании лучше, кто хуже, а потом составить рейтинг, плохих поставить в угол, а хороших — премировать. Мы никого не сравниваем и наказываем команды за уровни ниже базового. 
+
+Не нужно затягивать в секции модели практики, которых еще вообще нет в компании и использовать её как инструмент масштабирования процессов или практик. Это инструмент выравнивания и улучшения того, что уже есть в компании. Он не подходит для раскатки нового.
+
+### Бизнес-польза модели
+Основная задача технического директора — сделать так, чтобы доставка фичей до клиентов работала как часы, а команда перформила с определённой скоростью и определённым качеством. 
+
+Выполнить задачу помогает зафиксированное техническое задание на то, какой должна быть инженерная культура. Модель зрелости это решает и позволяет понимать, что сотрудники действительно делают так, как написано в техническом задании. Это оцифрованная версия того, как работают все команды компании: на базовом уровне или нет. Причём как только команда достигают базового уровня, нужно повысить планку, чтобы у команд снова была мотивация расти. 
+
+Для самих команд модель зрелости — это инструмент для поддержки постоянного развития, измеримое понимание, куда стремиться и какого уровня мастерства нужно достичь. Если раньше чётких критериев у нас не было, то теперь легко понять, что значит крепкая инженерка. К списку секций любая команда Авито по желанию может добавить свои критерии и дополнительно стремиться к ним. 
+
+Конечная цель внедрения инструмента — сильная инженерная культура. Это просто способ, который позволяет системно прокачивать команды. 
+
+Бонусы модели зрелости — коммуникация между командами становится лучше, потому что они следуют одним и тем же стандартам. Нет зоопарка в технологиях и зоопарка в плане процессов. Благодаря общим правилам всем инженерам компании комфортнее работать друг с другом. 
+
+### Выученные уроки и итоги
+
+Чтобы модель зрелости работала и приносила компании пользу, нужны: 
+- Эксперты и их вовлечённость в процесс. Это ключ к росту и динамике.
+- Мягкие коммиты от команд, чтобы они сами говорили, что будут прокачивать и когда. 
+- Контроль процесса и его прозрачность. Нужно, чтобы всё было визуализировано в JIRA, Google Docs или любых других инструментах. 
+- Эпизодический пересмотр секций и повышение базового уровня. 
+- Ответственный за саму модель, который сделает так, чтобы шестерёнки проекта крутились на уровне компании.
+