Привет! Я Владимир Крылов, продуктовый дизайнер и тимлид. В этой статье я поделюсь опытом проведения ретроспектив по методологии Squad Health Check, придуманной в Spotify. Расскажу, почему нам не подошел стандартный формат ретроспектив, в чём суть метода, какие темы для анализа проблем мы выбрали и к каким результатам в итоге пришли.

Почему классические форматы ретроспективы нам не подошли

За 7 лет работы в продуктовом дизайне я сталкивался с двояким отношением к ретроспективам. В одних командах их считают фундаментом процессов, в других — пустой тратой времени и «проделками скрам-мастеров».

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

Когда отвечаешь за результаты дизайн-команды, важно понимать реальное положение дел и знать, где болит сильнее всего. Разумеется, решить вообще все проблемы невозможно — многие из них лежат вне зоны влияния тимлида. Однако системная работа в этом направлении и сам факт того, что команду слышат, помогают дизайнерам чувствовать себя комфортно. А в творческой среде такой комфорт — это мощный драйвер эффективности.

Типичные ретро в стиле «Что было хорошо / Что было плохо / Что улучшить» быстро приедаются. Со временем они превращаются в рутину: карточки на доске становятся однотипными, обсуждения — поверхностными, а тимлиду всё сложнее оценить общую картину и динамику изменений. Ведь количество карточек в колонке «Плохо» не означает, что всё рушится, равно как и пустая колонка не гарантирует, что в процессах нет скрытых проблем. В поисках решения я наткнулся на методологию от Spotify — Squad Health Check (оценка «здоровья» команды). Этот формат обещал то, чего мне не хватало: структурировать темы для обсуждения, измерить общее «настроение» команды и наглядно увидеть его в динамике.

Коротко о том, как устроен Spotify Squad Health Check

В рамках этого формата работа команды делится на ключевые направления (сигналы) — например, «Качество дизайна», «Процессы», «Взаимодействие с разработкой» и другие.

Сама ретроспектива проходит в четыре простых этапа:

1. «Светофор» в закрытую: Мы берем конкретное направление, и каждый дизайнер индивидуально и скрыто от остальных ставит ему субъективную оценку: зеленый (все супер), желтый (есть вопросы/проблемы) или красный (всё совсем плохо). Голосование «в закрытую» критически важно, чтобы участники не влияли на мнение друг друга.

   

2. Анализ: После открытия карт формируется общая визуальная картина «здоровья» команды по каждому из направлений.

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

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

Главный плюс такого подхода — накапливаемая статистика. Проведя 3–4 подобные ретроспективы, вы сможете оцифровать субъективные ощущения команды, построить наглядный график динамики и системно отслеживать ее «здоровье».

Сигналы или темы обсуждений

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

Командная работа

? Зеленый: Мы постоянно сотрудничаем, обмениваемся опытом, проводим ревью и помогаем друг другу.

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

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

Качество дизайна.

? Зеленый: Я горжусь своей работой. Мои макеты смело можно класть в портфолио и показывать профессиональному сообществу.

? Красный: Получается посредственно. Такой дизайн стыдно кому-то показывать.

Дизайнеру недостаточно просто собирать аккуратные интерфейсы в Figma. Если продуманные решения регулярно режутся менеджерами, сильно упрощаются из-за сжатых сроков или просто не приносят пользы ни бизнесу, ни пользователям, любой дизайнер быстро превращается в «оператора Фигмы». Этот сигнал помогает тимлиду вовремя заметить, что творческий и профессиональный потенциал команды начинает угасать.

Атмосфера в компании.

? Зеленый: Компания полностью закрывает мои финансовые, карьерные и социальные потребности. Я чувствую стабильность и хочу развиваться именно здесь.

? Красный: Всё плохо. Я уже обновляю резюме на HeadHunter и ставлю плашку «Open to Work» в LinkedIn.

Самый сложный для влияния сигнал — тимлид не может изменить глобальную политику компании. Тем не менее, это критически важный индикатор. Если здесь постоянно загорается «красный», нужно идти обсуждать ситуацию с HR и закладывать время на будущий найм.

Процессы

? Зеленый: Дейлики, ретроспективы и встречи по дизайн-поддержке приносят реальную пользу. Они дополняют и структурируют работу, а не мешают ей.

? Красный: Большая часть созвонов и встреч — бесполезная трата времени, которая выбивает из состояния потока и мешает нормально работать.

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

Взаимодействие с другими командами

? Зеленый: Мы работаем со смежниками как единый механизм: вместе обсуждаем фичи на старте, разработчики вовлечены, помогают нам и не игнорируют дизайн-ревью.

? Красный: Половина задач уходит в продакшн без макетов или согласования. Требования приходят в виде готовых ультимативных решений, а результат на проде далёк от согласованного дизайна.

Часто дизайн-отдел оказывается зажат в рамки «внутреннего агентства/бюро», куда продуктовые команды просто приносят ТЗ на верстку. Этот пункт отлично вскрывает проблемы коммуникации на стыке дизайна, продакт-менеджмента и разработки.

Пешки или Игроки? (Pawns vs. Players)

? Зеленый: К нашему мнению прислушиваются. Мы с продуктовым менеджером работаем в синергии как сильная и равная креативная пара.

? Красный: Мы просто «руки». Делаем исключительно то, что спущено сверху, даже если это противоречит здравому смыслу, исследованиям и базовому UX.

Это классический вопрос из оригинального фреймворка Spotify. Когда дизайнер чувствует себя «игроком», влияющим на продукт, уровень его вовлеченности, ответственности и качество итоговых решений возрастают в разы.

Метрики

? Зеленый: У нас настроена аналитика, мы активно собираем данные и можем быстро узнать, как именно пользователи ведут себя в продукте.

? Красный: Мы проектируем вслепую. Никаких метрик нет, и внедрять их никто в ближайшее время не планирует.

Если мы не знаем, как люди пользуются новой фичей на проде (например, сложным фильтром в CRM-системе), мы не можем её качественно улучшить.

Пользовательский фидбек

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

? Красный: Делаем продукт как видим, пользователи ко всему привыкнут.

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

Миссия и видение дизайн-команды (Mission & Vision)

? Зеленый: Мы четко знаем цели нашего отдела на квартал или год и планомерно двигаемся в этом направлении.

? Красный: Мы просто «пилим» текущие задачи, совершенно не понимая общей картины и вектора развития.

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

Action Plan

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

Далее мы прогоняем все проблемы через два фильтра:

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

2. Фокус на красных зонах: В экшен-план на ближайшую перспективу уходят задачи по тем сигналам, которые набрали критически низкие баллы.

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

Как оцифровать «здоровье» и построить динамику?

Чтобы увидеть общую картину состояния команды в динамике, мы перевели цвета «светофора» в цифры:

• Красный цвет — 1 балл

• Жёлтый — 2 балла

• Зелёный — 3 балла

Для каждого направления мы считаем среднее арифметическое оценок всех участников и получаем итоговый балл. Повторяя этот упражнение, мы собираем наглядную динамику.

Вот как выглядит таблица динамики (для примера):

Здесь важно, что рост оценки — это не самоцель. Ретроспектива — не инструмент контроля и не способ «крутить» красивые показатели. Падение оценок нормальный и естественный процесс. На оценку в моменте влияет много вещей: усталость от сложной задачи, новые вводные или плохое настроение и.т.п.

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

Вместо вывода

Squad Health Check — отличный инструмент: он структурный, наглядный и оставляет после себя понятные, измеримые артефакты. Однако, как и любой другой фреймворк, его важно применять с умом.

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

Для тимлида такой подход — это способ системно работать с болями команды и поддерживать «здоровье» команды. Это важно для ребят, которым нужно не просто «пилить макеты по ТЗ», а гореть продуктом, генерировать идеи и развивать качество дизайна.

Давайте обсудим!

А как проходят ретроспективы в ваших дизайн-командах? Используете ли вы классический формат или адаптируете фреймворки под себя? Делитесь опытом в комментариях!

P.S. В своё время не смог вести типичный «экспертный» блог с вылизанными контентом, поэтому приглашу посмотреть личный Telegram-канал «Дела и Лес», который завёл недавно. Пишу там не только о дизайне, заходите пообщаться ?