Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers - Part I (Рубрика #Management)
Недавно я с большим интересом прочел статью от ребят из Google на тему состояния потока, фокусной работы и friction, что мешает работать эффективно. Эта статья из колонки про "Developer Productivity" в журнале IEEE. В этой статье авторы описываются свой подход примерно так:
1) Авторы хотели сфокусироваться на восприятии инженеров двух концепций: flow и friction
2) Для этого они собрали данные напрямую от разработчиков, включая проведение интервью, опросов, ведения разработчиками дневников
3) Дальше они взяли эти данные и попробовали связать восприятие инженеров с данными из логов - другие исследователи обычно сразу начинали с этого этапа
4) У исследователей получилось создать эвристики для трансформации сигналов из логов в метрики, что значимо связаны с flow, focus и friction
5) Дальше авторы отвалидировали эти метрики относительно само-отчетов инженеров и данных из логов - это позоволило верефицировать, что метрики все еще связаны с тем опытом инженеров, что был интересен исследователям.
Ну а теперь немного подробностей:
1) Обычные исследования flow предполагали, что context switches между инструментами рушит этот flow. Авторы же пошли от целей инженеров и показали, что flow сохраняется, если контекст задачи сохраняется. Подробнее про статью "Measuring Developer Goals" я рассказывал раньше
2) Из diary studies и follow-up interviews стало ясно, что flow многограннее, чем думали авторы
- Инженеры испытывают состояние потока, только если они позитивно настроены относительно работы, что они выполняют
- Это может быть не только код, но и другие активности (написание дизайн доков, изучение документации, написание писем/сообщений, ...)
- Когда состояние потока достигнуто, то инженеры могут оставаться в нем даже при небольших отвлекающих факторах
3) Дальше авторы рассказывают, что они не смогли выделить как определить из логов состояние потока, но можно выделить состояние сфокусированной работы. Для этого надо посмотреть занимаются ли инженеры связными задачами (фокус) или несвязными (расфокус).
4) Концептуальная модель выглядела примерно так: сфокусированная работа нужна для достижения flow, но ее не достаточно. Одновременно из логов можно вытащить focus time, когда инженеры работали над связными задачами, но не факт, что это точно отображается на сфокусированную работу. Для анализа связности задач ребята использовали word2vec по данным из логов
5) Дальше шла валидация того, что инженеры заполняли в опросах или в diary data с тем, что насчитали авторы насчет flow и focus из логов. В итоге, метрики авторов показали хорошую связь между восприятием и этими метриками
Рассказ про метрику friction в продолжении этого обзора.
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
Недавно я с большим интересом прочел статью от ребят из Google на тему состояния потока, фокусной работы и friction, что мешает работать эффективно. Эта статья из колонки про "Developer Productivity" в журнале IEEE. В этой статье авторы описываются свой подход примерно так:
1) Авторы хотели сфокусироваться на восприятии инженеров двух концепций: flow и friction
2) Для этого они собрали данные напрямую от разработчиков, включая проведение интервью, опросов, ведения разработчиками дневников
3) Дальше они взяли эти данные и попробовали связать восприятие инженеров с данными из логов - другие исследователи обычно сразу начинали с этого этапа
4) У исследователей получилось создать эвристики для трансформации сигналов из логов в метрики, что значимо связаны с flow, focus и friction
5) Дальше авторы отвалидировали эти метрики относительно само-отчетов инженеров и данных из логов - это позоволило верефицировать, что метрики все еще связаны с тем опытом инженеров, что был интересен исследователям.
Ну а теперь немного подробностей:
1) Обычные исследования flow предполагали, что context switches между инструментами рушит этот flow. Авторы же пошли от целей инженеров и показали, что flow сохраняется, если контекст задачи сохраняется. Подробнее про статью "Measuring Developer Goals" я рассказывал раньше
2) Из diary studies и follow-up interviews стало ясно, что flow многограннее, чем думали авторы
- Инженеры испытывают состояние потока, только если они позитивно настроены относительно работы, что они выполняют
- Это может быть не только код, но и другие активности (написание дизайн доков, изучение документации, написание писем/сообщений, ...)
- Когда состояние потока достигнуто, то инженеры могут оставаться в нем даже при небольших отвлекающих факторах
3) Дальше авторы рассказывают, что они не смогли выделить как определить из логов состояние потока, но можно выделить состояние сфокусированной работы. Для этого надо посмотреть занимаются ли инженеры связными задачами (фокус) или несвязными (расфокус).
4) Концептуальная модель выглядела примерно так: сфокусированная работа нужна для достижения flow, но ее не достаточно. Одновременно из логов можно вытащить focus time, когда инженеры работали над связными задачами, но не факт, что это точно отображается на сфокусированную работу. Для анализа связности задач ребята использовали word2vec по данным из логов
5) Дальше шла валидация того, что инженеры заполняли в опросах или в diary data с тем, что насчитали авторы насчет flow и focus из логов. В итоге, метрики авторов показали хорошую связь между восприятием и этими метриками
Рассказ про метрику friction в продолжении этого обзора.
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes