Research Insights Space
К каталогу
paper
survey
telemetry

Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers

Разбор подхода Google к flow/focus/friction: как связать diary/interview данные с логами, валидировать метрики и приоритизировать улучшения в инженерных процессах.

Открыть оригинал

Практика чтения для этого источника ещё не опубликована

Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.

Открыть оригинал

Готовый редакционный разбор

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

Whitepaper

Measuring Flow, Focus, and Friction for Developers

Публикация Google в IEEE Software (2023).

Перейти на сайт

Основа главы [1/2]

Пост в tg-канале book_cube

Первая часть обзора с методологией flow/focus.

Перейти на сайт

Эта глава разбирает подход Google к измерению developer productivity через человеко-центричную модель: сначала опыт инженеров, затем связь с логами. Главный практический результат работы - операционализируемые метрики focus и friction с валидацией на self-reports.

Контекст серии

Developer Productivity for Humans

Колонка IEEE по human-centric измерению продуктивности.

Перейти на сайт

Связанный разбор

Measuring developer goals

Предшествующая идея про приоритет контекста задачи над переключениями инструментов.

Перейти на сайт

Исследовательский подход

  • Авторы начали с восприятия инженеров (flow, focus, friction), а не с готовых инструментальных метрик.
  • Собрали данные через diary studies, интервью и опросы, чтобы сохранить контекст повседневной работы.
  • Связали qualitative-сигналы с логами инженерных инструментов и построили эвристики преобразования данных.
  • Отдельно валидировали полученные метрики через self-reports, чтобы проверить соответствие реальному опыту инженеров.

Что показали данные про flow

  • Переключение между инструментами не обязательно разрушает flow, если сохраняется контекст задачи.
  • Flow возникает не только при написании кода: в него входят дизайн-доки, чтение документации и коммуникации.
  • Состояние потока связано с позитивным отношением к выполняемой работе, а не только с фактом занятости.
  • Небольшие отвлекающие факторы не всегда выбивают из flow, если инженер удерживает цель и контекст.

Модель focus из логов

Flow трудно снять напрямую из логов

Исследователи не нашли надежного logs-only прокси для состояния потока.

Focus как наблюдаемое приближение

Из логов можно оценивать, работают ли инженеры над связными задачами и как долго удерживают этот контекст.

Связность задач через embeddings

Для анализа семантической близости активностей использовался word2vec по кросс-инструментальным данным.

Концептуальная связка

Сфокусированная работа нужна для flow, но сама по себе не гарантирует его.

Как авторы построили метрику friction

  • Сконструировали метрику из нескольких компонентов, отражающих ключевые инженерные активности.
  • Агрегировали компоненты в среднем по инженеру и дню.
  • Порог определяли не механически (например, не просто p90), а относительно self-reported восприятия friction.
  • Если персональный показатель превышал порог, день классифицировали как день с friction.

Сигналы, которые вошли в модель

  • Latency локальных build/test циклов.
  • Latency change lists и задержки в review/submit циклах.
  • Нестабильные (flaky) тесты.
  • Заблокированные submission attempts из-за CI failures.
  • Квартальные опросы о perceived friction и удовлетворенности скоростью разработки/сложностью кода.

Что подтвердилось при валидации

Новый human-centric подход подтвердил те же болевые зоны, что и старые infra-метрики (latency, flaky tests, CI blocks).

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

Связка опросов и логов дала более уверенную интерпретацию того, что именно инженеры считают friction.

Практические вопросы для engineering-менеджмента

  • Можно ли повысить focus и flow, сократив общий объем корпоративных встреч?
  • Работают ли в конкретной организации форматы «дней/недель без встреч»?
  • Как распределять слоты под глубокую работу, чтобы реально уменьшать friction?
  • Какие процессы и tooling-проблемы стоит улучшать первыми по данным friction-метрик?

Связанные главы

RIMS #8 - Measuring developer goals

База про goal-centric подход и значимость контекста задач.

RIMS #10 - Measuring Developer Experience With a Longitudinal Survey

Контекст про hybrid-модель измерений: опросы + логи.

DevOps Metrics. Your biggest mistake might be collecting the wrong data

Почему выбор исходных сигналов критичен для управленческих решений.