Источник
book_cube: Measuring Engineering Productivity (1/2)
Ключевые идеи из главы Software Engineering at Google про измерение инженерной продуктивности, triage вопросов и модель GSM.
Источник
book_cube: Measuring Engineering Productivity (1/2)
Ключевые идеи из главы Software Engineering at Google про измерение инженерной продуктивности, triage вопросов и модель GSM.
Productivity / Leadership / Google
В этой главе зафиксирован подход из Software Engineering at Google: измерение продуктивности нужно не для контроля людей, а для поиска неэффективностей в инженерной системе и принятия управленческих решений на данных.
TL;DR
- Google измеряет продуктивность как системную способность делать инженеров эффективнее, а не как рейтинг людей.
- Перед исследованием команда проходит triage: если результаты не приведут к действиям, измерение не запускают.
- Базовая модель формализации измерений: Goal -> Signal -> Metric (GSM).
- Для продуктивности используется набор QUANTS: Quality, Attention, Intellectual complexity, Tempo/velocity, Satisfaction.
- Кейс readability review показал пользу даже для языков с сильной инструментальной поддержкой (C++, Java).
1. Зачем вообще измерять productivity
В логике Google рост инженерной организации нельзя масштабировать линейно: издержки коммуникации между людьми растут быстрее, чем сама команда. Интуитивная формула полного графа n * (n - 1) / 2 хорошо показывает, почему фокус смещается на системную продуктивность каждого инженера.
Data-driven решение
Решения принимаются на объективной информации, а не на субъективных впечатлениях о «скорости команды».
Human side of engineering
Отдельная исследовательская команда объединяет инженеров и social scientists (когнитивная психология, поведенческая экономика и др.), чтобы измерять не только pipeline, но и поведение людей в процессе.
2. Triage: стоит ли это вообще измерять
What result are you expecting, and why?
Фиксируем изначальные ожидания и предубеждения до старта исследования, чтобы не подгонять выводы постфактум.
If the data supports your expected result, what action will be taken?
Измерение имеет смысл только если у команды есть конкретный план действий при подтверждении гипотезы.
If we get a negative result, will appropriate action be taken?
Если негативный результат ничего не меняет в решениях, исследование превращается в формальность.
Who is going to decide to take action on the result, and when would they do it?
Нужны понятные ЛПР, сроки и формат доказательств, которым ЛПР доверяет (опросы, интервью, логи, смешанный подход).
Когда измерение лучше не запускать
- Сейчас нет ресурса менять процесс или инструменты, даже если проблема подтвердится.
- Результаты быстро обнулятся из-за параллельных крупных изменений в организации.
- Метрика нужна только как vanity-аргумент под уже принятое решение.
- Доступные метрики слишком шумные и не отделяют эффект от внешних факторов.
3. Framework GSM: Goal -> Signal -> Metric
| Компонент | Что это | Пример |
|---|---|---|
| Goal | Ожидаемый результат в терминах ценности и поведения системы, без привязки к конкретной метрике. | Ускорить поставку изменений без деградации качества. |
| Signal | Наблюдаемый признак, который показывает, что цель действительно достигается. | Команда быстрее проходит цикл review и реже откатывает изменения. |
| Metric | Измеримый прокси-сигнал, который доступен в данных здесь и сейчас. | Медианное время readability review + доля повторных правок + ответы в опросе. |
4. QUANTS: пять измерений developer productivity
Q — Quality of the code
Качество кода, тестов и архитектурных решений.
U/A — Attention from engineers
Фокус и частота прерываний; сколько времени инженеры могут работать в потоке.
N — Intellectual complexity
Когнитивная нагрузка: баланс между естественной сложностью задачи и сложностью, созданной процессами/инструментами.
T — Tempo and velocity
Темп поставки, throughput и скорость прохождения рабочих циклов.
S — Satisfaction
Удовлетворенность инженеров инструментами, процессами и ощущением смысла работы.
5. Кейс readability review из Software Engineering at Google
Readability review в Google фокусируется на идиоматичности и единообразии кодовой базы. Исследование проверяло гипотезу: могут ли современные линтеры и статические анализаторы полностью заменить человеческий слой этого процесса.
Цели исследования, разложенные по QUANTS
Quality
Инженеры пишут более качественный и идиоматичный код.
Attention
Отдельная цель в исследовании явно не фиксировалась.
Intellectual complexity
Инженеры быстрее осваивают кодовую базу Google, паттерны и best practices через менторинг.
Tempo/velocity
Задачи выполняются быстрее и стабильнее благодаря единым практикам кодирования.
Satisfaction
Инженеры видят пользу readability-процесса и позитивно оценивают участие в нём.
Основные источники метрик
- Квартальные опросы разработчиков.
- Специализированный readability survey.
- Логи процесса review (в частности медианное время review changelist).
По пересказу авторов, значимая доля выводов была получена через опросы, а не только из activity-based логов.
Итог исследования: readability-процесс сохранили, так как он демонстрировал практическую пользу даже в инструментализированных языках вроде C++ и Java (состояние на момент выхода книги в 2020 году).
6. Типичные антипаттерны
Собирать данные, когда решение уже принято и результат не повлияет на действия.
Подменять сигнал одной удобной метрикой и игнорировать её ограничения.
Считать «люди медленные» вместо проверки системных факторов: инструменты, переключения, очереди review.
Оценивать команды по метрикам вне контекста класса задач и доменных ограничений.
7. Рекомендации
Стартовать исследование только при наличии конкретных решений, которые вы готовы принять по итогам.
Фиксировать цепочку Goal -> Signal -> Metric до запуска эксперимента и переоценивать её на ретро.
Комбинировать количественные и качественные источники (логи + опросы + интервью), а не выбирать один.
Проверять, снижает ли процесс привнесенную когнитивную сложность, а не только «ускоряет ли доставку».