Всем привет! Я Светлана Давыдова, работаю менеджером проектов в команде Поиска. В моём отделе поисковых интерфейсов работает 24 команды. За 5 лет мы выстроили множество процессов, но перед нами всё ещё стоят вызовы: разный уровень развития команд, специфичные задачи и нехватка времени на улучшения. Из‑за этого не все команды могут одинаково эффективно развиваться и повышать качество своих продуктов.
Чтобы избежать стагнации и обеспечить более высокий уровень работы всех команд, мы разработали модель зрелости команд. Это инструмент, который помогает определить направления развития, внедрить необходимые процессы и ускорить адаптацию новых команд. Модель позволяет выявлять слабые места в рабочих процессах, улучшать качество разрабатываемых продуктов и, как следствие, повышать удовлетворённость пользователей.
В статье расскажу, как мы отбирали ключевые критерии для модели, проводили оценку текущего состояния команд, составляли планы развития и что из этого получилось.
Как мы пришли к такой жизни
За 5 лет процессы в нашей команды пережили многое. Мы ускоряли cycle time, искали узкие места в процессе, автоматизировали рутинные действия, повышали качество, тратили много усилий для погружения команды в продуктовую работу.
Но нет предела со��ершенству. Однажды мы обратили внимание на несколько проблем:
У нас много разных команд, которые отвечают за тестирование, фронтенд, бэкенд. И у каждой внутри есть своя специфика и особенности: работа с тестами, релизы, эксперименты, мониторинги. И все они находятся на разных уровнях зрелости и работают над разными проектами и задачами.
Не всегда есть достаточно времени заниматься улучшениями процессов — мы бежим в продукт, на остальное мало фокуса.
Сложно найти быстрое решение, как улучшить процесс delivery — нужно глубоко погружаться, исследовать, искать лучшие практики.
Всё это может привести к стагнации развития и разнице в скорости работы команд. Сценарий не внушает оптимизма.
Мы решили, что помочь с задачей погружения в специфику могут эксперты — это опытные сотрудники, которые были хорошо погружены в особенности своих областей и уже работали над проектами по развитию и помогали командам с ростом экспертизы. План был такой:
Выделить самые важные, сложные этапы разработки в отделе.
Сформировать группу ответственных экспертов с большим опытом и знаниями в своих сферах.
Найти оптимальные решения для каждого этапа разработки продукта.
После пары месяцев работы мы создали модель зрелости команд. Это инструмент, который помогает определить, в каком направлении двигаться, какие процессы внедрять, показывает командам, как стать лучше. Модель может пригодиться не только для развития текущих команд, но и как гайд для сетапа новых — готовый процесс, проверенный временем и опытом.
Структура модели
Модель состоит из семи блоков, за каждый из которых отвечает эксперт или группа экспертов. Блоки делятся на секции с «лесенкой» роста, которая показывает, как можно развиваться — с примерами и ссылками на документацию.
Какие навыки и активности мы развиваем у команд:
Процессы. Работа с целями, планирование, декомпозиция задач, использование базовых инструментов и активностей, ускорение cycle time, проведение Design Review.
Качество. Работа с инструментами контроля качества и тестирования, развитие QA‑экспертизы, вовлечение QA на ранних этапах, написание и поддержание актуальной тестовой документации, работа с обратной связью пользователей.
Фронтенд. Оптимизация релизного процесса, поддержка переиспользуемости кода, улучшение работы дежурных, использование дизайн‑системы, сокращение технического долга.
Бэкенд. Внимание к информационной безопасности, системная работа над производительностью, покрытие функций автоматическими тестами, планирование и распределение ресурсов.
Инфраструктура. Автоматизация тестирования проектов, стабильные и регулярные релизы, использование актуальных технологий, мониторинг состояния сервисов.
Эксперименты. Работа с логированием, создание и контроль метрик, запуск и анализ экспериментов.
9999 (управление надёжностью сервиса). Ведение актуального каталога команд, сервисов и функциональностей, мониторинг продакшена, управление инцидентами, кросс‑функциональное взаимодействие в части управления надёжностью.
В каждой секции есть базовый уровень — минимум, которого должна достичь команда. Секции отличаются по приоритетам от critical до minor и влияют на финальный балл блока. Баллы внутри минорных секций — от 0 до 10, в средних — от 0 до 100 и в критичных — от 0 до 1000.
Мы считали максимальный балл по каждой секции, баллы каждой команды по блоку делили на максимальный балл, и в итоге у нас получилась лепестковая диаграмма, каждая ось которой показывает текущее положение команды внутри блока. Например, максимальный балл секции 9999 — 2210, команда набирала балл 1380, и таким образом 1380 / 2210 = 0,624 — положение на оси.
В начале работы над моделью мы выделили самые важные и сложные этапы разработки. Под каждый этап составляли блок для оценок и рекомендаций роста.
Перед тем как составить блок, эксперт отвечал на вопрос — что важного должны уметь делать команды внутри этой области. Выписывал плоским списком, потом делил на смысловые секции, расставлял приоритеты и определял базовые требования. В каждой секции для каждой ступени составлял рекомендации для роста, наполнял примерами хороших практик и ссылками на документацию.
В итоге, коротко, что делали эксперты каждого блока:
составляли и описывали секции;
определяли базовые требования;
давали советы и рекомендации для перехода команды на новый уровень;
поддерживали информацию по блоку в актуальном состоянии, дополняли в соответствии с развитием индустрии.
Состав блоков и приоритеты ревьюила рабочая группа руководителей, через несколько итераций был готов первый вариант. Вот несколько примеров блоков:
Первый вариант модели мы показали широкому кругу руководителей, чтобы собрать обратную связь. После внесения правок финальную версию презентовали командам, чтобы все понимали, к чему мы стремимся в отделе.
Как мы работаем с моделью
Для успешной работы над улучшением процессов необходим баланс между заказом от руководителей и интересом от самих команд. Заказчиком роста по модели выступает, как правило, руководитель отдела. При этом руководители команд самостоятельно выбирают, какие аспекты нуждаются в улучшении в первую очередь. Этот выбор обсуждается и челленджится ближайшим руководителем.
Мы проводим опрос для оценки текущего положения каждой команды. Руководитель команды отвечает на вопросы, и на основе ответов начисляются баллы по различным блокам и секциям. Ответы собираются в Трекере и обрабатываются в общей таблице. После того как все проходят опрос, мы строим медиану по отделу.
Баллы конкретной команды сравниваются с медианой.
На основе результатов и положения относительно медианы руководитель команды составляет план развития по секциям, требующим внимания, после чего вносится в цель о здоровье производства команд, продвижение трекается на гринлайте (встреча, где мы смотрим на статусы целей команд).
Этапы работы с моделью
Рассмотрим реальный пример. Команду интересовали две зоны роста: «9999» и «Процессы».
9999. Нужно вывести мониторинг продакшена в зону ответственности команды.
Инфраструктура процессов. Рефайнменты и планирование завязаны на продукт и смежные команды. Нужно поправить и настроить процессы на уровне всего Vteam, а не только отдельных команд.
Эти идеи обсудили на уровне руководителя и составили подробный план, как их плавно и логично реализовать в работе. Спустя несколько месяцев получилось добиться таких результатов:
9999. Настроили базовые алерты на необходимую функциональность и добавили разнообразное логирование для отдельных флоу. Также поработали над улучшением дежурств внутри команды.
Инфраструктура процессов. Ввели общие дейлики со смежными командами. Так как команда большая, одна большая встреча была разбита на три отдельных дейлика по проектам. Планирования стали более детально разбиты по продуктам — в них принимают участие только те разработчики, которые задействованы в конкретных проектах.
И что теперь
Внедрив модель в работу, мы получили:
экономию времени на поиск решений проблем;
масштабирование полученных знаний;
любая команда на любом этапе развития теперь знает, как решить проблему, с которой она столкнулась или может столкнуться в будущем;
процесс поддержки и развития накопленных знаний.
Мы регулярно пересматриваем базовые требования и состав блоков, чтобы идти в ногу со временем и поддерживать рост команд по «лесенке» эффективности. Например, в новом полугодии мы добавили новый блок про AI. Немного поменяли концепцию выбора точек роста, теперь есть один общий вектор у всех команд и дополнительные векторы, которые выбирают руководители команд. Например, один из флагманских векторов — повышение эффективности разработки за счёт внедрения AI‑инструментов.
Наш инструмент — это один из способов построить и развивать процессы в командах нашего отдела. Он помогает найти оптимальные решения и сэкономить время других команд, чтобы они лишний раз не придумывали свои методы, когда уже есть готовое решение. Если у вас есть похожие наработки — делитесь опытом в комментариях.
