[2/2] Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers (Рубрика Management)

Во второй части статьи, которую я начал рассматривать в прошлом посте, авторы обсуждают метрику friction.

1. Они решили опять начать отстраивать friction от восприятия инженеров, а не от данных из инструментов типа билдов, автотестов и иже с ним. В итоге, авторы построили метрику, используя

• Некоторое число компонентов, что включают ключевые активности инженеров
• Агрегировали эти компоненты по инженерам и вычислили среднее для каждого инженера
• Дальше для каждого из инженеров сравнили получившееся среднее с некоторым пороговым значением, рассчитанным в разрезе восприятия инженеров, а не просто условный 90 перцентиль
• Если пороговое значение было пробито, то считалось, что инженер испытывал friction в этот день

2. Раньше в Google уже были метрики friction, но они создавались для целей того, чтобы продемонстрировать помощь инфры или инструментов в деле снижения friction или для понимания того, а что мешает инженерам работать продуктивнее. Этим метрики отталкивались от количества или процента "плохих событий" относительно их большого количества, например, flaky tests в Google. Эти метрики имели смысл в сценариях инфра команд, но не очень матчились на опыт конкретных разработчиков.
3. Но оказалось, что если считать friction исходя из опыта разработчиков, то получаются все те же причины: test latency, flaky tests, issues with code changes being blocked due to CI failures. Это показывает, что старые метрики совпадали с новыми, но новый подход дал больше уверенности, что это отражает мнение самих разработчиков о том, что мешает им в работе.
4. Интересно, что разработчики отмечали, что до некоторой степени эти проблемы не являются причиной friction, а являются частью работы. Но при превышении некоторого порогового значения, например, flaky tests это становится проблемой и они классифицируют это как friction.
5. В итоге, метрикой friction стало

• Данные из логов о latencies для локальных билдов и тестов, latencies для change lists, проблемы с нестабильными тестами, проблемы с заблокированными submission attempts. Тут тоже пришлось поиграть с пороговыми значениями
• Данные из ежеквартальных опросов о том, испытывали ли они friction и насколько они удовлетворены со сложностью кода и скоростью разработки

В итоге, подход ребят позволяет создать базу для ответов на вопросы вида

• Можно ли улучшить focus и flow при уменьшении общекорпоративных встреч?
• Можно ли улучшить focus и flow делая дни или целые недели без встреч?
• Можно ли при помощи уменьшения длительности и слотов под сфокусированную работу добиться лучшего focus и flow?
• Как можно при помощи метрики friction определить какие процессы улучшать первыми?
• И так далее

Но сами исследователи пока в начале пути. Надеюсь, что они поделятся с нами результатами следующих шагов в очередных whitepapers.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes