Measuring Productivity: All Models Are Wrong, But Some Are Useful
Разбор принципов Google по измерению продуктивности: баланс speed/ease/quality, компромиссы модели и смешанный подход логов + опросов.
Практика чтения для этого источника ещё не опубликована
Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.
Открыть оригиналГотовый редакционный разбор
Он сохранён из прежней версии каталога и расположен после самостоятельной практики, чтобы не подменять чтение оригинала готовым пересказом.
Whitepaper
Measuring Productivity: All Models are Wrong But Some are Useful
Google Research, IEEE Software, 2025.
Whitepaper
Measuring Productivity: All Models are Wrong But Some are Useful
Google Research, IEEE Software, 2025.
Авторы из Google применяют принцип Джорджа Бокса к инженерной аналитике: продуктивность разработчиков нельзя измерить одной «идеальной» метрикой. Вместо этого нужен многомерный и осознанный model-driven подход.
Основа главы
Telegram пост #3549
Ключевые идеи whitepaper и практические выводы для management-контура.
Основа главы
Telegram пост #3549
Ключевые идеи whitepaper и практические выводы для management-контура.
Ограничения и риски моделей
- Любая модель продуктивности неполна и по определению упрощает реальную инженерную работу.
- Опасная избирательность (worrying selectivity) возникает, когда модель не покрывает важные аспекты труда разработчика.
- Узкие прокси-метрики вроде LOC или коммитов часто искажают управленческие решения.
- Измерение влияет на поведение: команды начинают оптимизировать то, что попало в метрику, а не всегда то, что важно бизнесу.
Треугольник продуктивности: speed, ease, quality
Speed
Скорость поставки изменений и прохождения задач через delivery-поток.
Ease
Простота и удобство работы инженеров в инструментах, процессах и коммуникациях.
Quality
Надежность и поддерживаемость результата: дефекты, rework, операционная устойчивость.
Компромиссы, которые нельзя игнорировать
- Можно ускорить velocity, если ослабить ревью и тестирование, но это часто бьет по качеству и долгосрочной скорости.
- Оптимизация только под скорость повышает риск технического долга и переработок.
- Ставка только на quality без учета speed/ease может сделать процесс чрезмерно тяжелым и снизить адаптивность.
Структура построения measurement-системы
- Формулировать цели измерения (Goals): какие решения и изменения должен поддержать measurement-контур.
- Определять сигналы (Signals): какие наблюдаемые проявления связаны с целями.
- Выбирать метрики (Metrics): достаточный, но не перегруженный набор индикаторов.
- Проверять баланс между парсимонией и полнотой покрытия, чтобы избежать worrying selectivity.
- Итеративно пересматривать модель на основе фактических результатов и обратной связи.
Почему важен mixed-method подход
- Количественные данные из инструментальных логов дают масштаб и воспроизводимость.
- Качественные методы (опросы, интервью) раскрывают контекст и человеческие факторы.
- Комбинация методов помогает валидировать выводы и снижает риск ложной интерпретации одиночных метрик.
Практические последствия для engineering-менеджмента
- Измерение продуктивности нужно проектировать как систему принятия решений, а не как dashboard ради dashboard.
- Лучше иметь многомерную модель с явными ограничениями, чем «идеальную» метрику, которой не существует.
- Для управленческой практики важны регулярные проверки эффекта: что реально улучшилось после изменений в процессе и тулинге.
Связанные главы
Enabling the Study of Software Development Behavior With Cross-Tool Logs
Про InSession и системный сбор кросс-инструментальных данных в Google.
What's DAT? ... at Meta
Прикладной пример экспериментов продуктивности на diff-level метриках.
Как собираются отчеты DORA
Методологический контекст для валидности и интерпретации инженерных метрик.