Google GSM: Goals, Signals, Metrics

Проблема: метрики ради метрик

Большинство команд начинают измерять продуктивность с конца: берут то, что легко посчитать (количество коммитов, строки кода, время сборки), выводят на дашборд и надеются, что картина как-то сложится. Google в книге Software Engineering at Google называет это streetlight effect, эффект фонарного столба, когда человек ищет ключи не там, где потерял, а там, где светло. GSM-фреймворк (Goals/Signals/Metrics) решает эту проблему через простую, но строгую последовательность: сначала формулируете цель, потом определяете сигналы достижения, и только потом подбираете метрики как прокси для этих сигналов.

Три уровня GSM

Goals (цели)

Цель описывает желаемый результат на высоком уровне и намеренно не содержит упоминаний конкретных способов измерения. Например: «Разработчики быстро получают обратную связь на свои изменения» или «Инженеры тратят минимум времени на рутинные задачи, которые можно автоматизировать». Формулировка цели заставляет стейкхолдеров договориться, что именно они хотят понять про продуктивность, до того как кто-то откроет Grafana и начнёт строить графики.

Signals (сигналы)

Сигнал отвечает на вопрос: «Как мы узнаем, что цель достигнута?» Это то, что команда хотела бы измерить в идеальном мире, но не всегда может. Для цели «разработчики быстро получают обратную связь» сигналом будет: «Разработчик узнаёт, прошли ли тесты, в течение нескольких минут после отправки изменений». Сигнал может быть субъективным или объективным, и это нормально: на этом этапе важна семантика, а не техническая возможность сбора данных.

Metrics (метрики)

Метрика представляет собой измеримый прокси для сигнала. Для сигнала выше метрикой может стать «медианное время выполнения CI-пайплайна» или «p95 времени от создания PR до первого прогона тестов». Ключевое слово здесь: прокси. Команда осознанно признаёт, что метрика не идеально отражает сигнал, но приближает к пониманию ситуации. Этот сдвиг в мышлении (от «метрика показывает правду» к «метрика приближает к правде») стал одной из самых ценных идей GSM.

QUANTS: пять измерений Google

Внутри Google исследовательская команда Engineering Productivity Research использует GSM совместно с моделью QUANTS, которая выделяет пять аспектов продуктивности, по которым формулируют цели:

• Quality of the code: качество кода и артефактов
• Attention from engineers: сколько внимания инженеры уделяют задаче без отвлечений
• iNtellectual complexity (N): насколько сложные задачи требуют когнитивных усилий
• Tempo and velocity: скорость, с которой инженеры завершают работу
• Satisfaction: удовлетворённость инженеров процессами и инструментами

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

Связь GSM с другими фреймворками

GSM работает как метод построения метрик, тогда как DORA и SPACE предлагают конкретные наборы метрик. Они не конкурируют, а дополняют друг друга. Команда может взять GSM как процесс, сформулировать цели через призму QUANTS или SPACE-измерений, а в качестве итоговых метрик получить что-то похожее на DORA или что-то совершенно другое, специфичное для контекста организации. Именно в этом сила подхода: GSM не навязывает конкретные числа, а даёт структуру для того, чтобы команда сама пришла к метрикам, которые отвечают на её вопросы.

Фильтр «стоит ли вообще измерять»

Google перед запуском любого измерения задаёт критический вопрос: «Сможем ли мы что-то сделать с результатом, каким бы он ни оказался?» Если ответ отрицательный, измерение не проводят. Это правило отсекает огромное количество метрик, которые команды собирают «на всякий случай» и которые потом годами гниют на дашбордах, не приводя ни к каким решениям. Google также настаивает на том, что данные собирают из двух типов источников: логовых (CI-система, VCS, баг-трекер) и перцептивных (опросы разработчиков), потому что ни один тип данных в отдельности не даёт полную картину.

Как применить GSM в своей команде

Практический старт с GSM занимает одну встречу. Соберите стейкхолдеров (инженеров, тимлидов, менеджеров) и попросите каждого записать три вещи, которые, по его мнению, тормозят продуктивность команды. Сгруппируйте ответы и переформулируйте их как цели (без упоминания метрик). Для каждой цели определите сигналы: что изменится в поведении людей или систем, если цель будет достигнута. И только после этого подберите метрики, желательно по одной логовой и одной перцептивной на каждый сигнал. Результат: компактный набор из 5–8 метрик, каждая из которых привязана к конкретной цели и может привести к конкретному действию.