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 метрик, каждая привязана к конкретной цели и приводит к конкретному действию.