На днях я слушал подкаст Microsoft Research (New Future of Work: How developer collaboration and productivity are changing in a hybrid work model — https://www.microsoft.com/en-us/research/podcast/new-future-of-work-how-developer-collaboration-and-productivity-are-changing-in-a-hybrid-work-model/)
Примечание — Кстати, это очень интересный подкаст сам по себе, мой комментарий на 100% опционален и основан лишь на наблюдениях
Одна из затронутых там тем — продуктивность разработчиков, и я хотел сосредоточиться на ней, просто чтобы поделиться мыслями.
Модель
Метрику проще оценивать, если думать о ней как о свойстве несовершенной модели. Значение в измерении, представляющем одно из качеств.
Разберём пример модели и её свойства.
Самолёт отрывается от земли. Нужно объяснить почему.
- Физик, вероятно, построит модель, объясняющую взлёт через законы Ньютона, принцип Бернулли, аэродинамический профиль (форму крыла, помогающую поднять самолёт) и т. д.
- Экономист, вероятно, просто скажет, что это потому, что есть смысл переместить самолёт из A в B, может быть, измеряя это деньгами: цена выхода или потенциального выхода с учётом рисков больше, чем вход. Буквально, люди купили билеты, так что самолёт полетит (я часто использую это как шутку, чтобы объяснить разницу между моделями).
- Инженер космической эры мог бы сказать, что даже старый бабушкин комод хорошо полетит, если есть нужный двигатель и возможность менять вектор приложенной силы.
- Объяснение на основе химии, вероятно, сосредоточится на топливе и тоже на физике
Все эти объяснения хороши, мне кажется; они просто используют разные модели, которые могут помочь тем, кто ими пользуется, узнать что-то, что стоит починить. Но опасно чинить что-то, исходя только из односторонней точки зрения, особенно если у самой модели всего несколько измеримых свойств. Чем проще модель, чем меньше набор свойств для измерения, тем труднее быть уверенным, что изменение моделируемой вещи не приведёт к катастрофе. Хороший пример — попытка починить физическую проблему кодом, игнорируя решения на основе физики, или решение настроить компьютеры разработчиков, исходя только из финансовой модели. Должна быть обратная связь, модель более низкого уровня или хотя бы обратная связь от людей.
Также, когда модели не хватает большого набора свойств для измерения, есть риск выстроить структуру, которая будет стараться давать хорошие измерения вместо реального результата (строки кода, исправленные баги, завершённые pull request — если фокусироваться только на них — теоретическое измеряемое сообщество, вероятно, адаптируется, создавая больше строк, багов для исправления и ненужных изменений ради кубка эффективности).
Контекст
Простая математика говорит: 2 * 5 = 5 * 2, но для человека это может быть совсем по-разному в зависимости от контекста, например при покупке продуктов, когда у вас есть выбор: сходить к машине 5 раз, неся по 2 пакета, или 2 раза, неся по 5 пакетов, и т. д.
Даже если вы моделируете отдельного водителя машины, даже если он окажется очень талантливым экземпляром, контекст всё равно легко может снизить его качество (пример: хороший водитель может буксовать там, где все водят не очень хорошо).
В смысле, хорошая ли идея измерять вне контекста? Не думаю. Метрика количества pull request — не очень хорошая вещь, когда измеряется в одиночку и выражается числом. Граф pull request, где один порождает другой, может быть лучше (одно изменение может позволить сделать множество других), но всё же — справедливо ли говорить, что только разработчик решает, делать ли большие, значимые изменения? В отношении продуктивности разработчиков контекст — это команда, запросы — результат команды, так что трудно сказать, что работу разработчиков легко выразить числом.
Вход и результат
Результат (продукт, ПО, свойства и т. д.) не должен быть единственным, что измеряется, я думаю. Похоже, необходимо думать и о входе, и измерять его тоже.
Пример: были времена в прошлом, когда у меня одновременно шло 5+ разговоров в Teams. В какой-то момент я думал предложить фичу приложения, которая позволит разработчикам легче управлять очередью, в том числе дать менеджеру решать, какой приоритет лучший. Думаю, человеку очень трудно фокусироваться на слишком многих вещах одновременно из-за слабости нашей кратковременной рабочей памяти (шимпанзе, кстати, в этом лучше).
Удалённая эпоха усложнила людям возможность видеть, сколько у вас сейчас разговоров, и думаю, это можно исправить, просто позволив другим видеть, насколько велика ваша очередь решений. Это хорошее измерение, но, может быть, не для навыков разработчиков — возможно, для изучения коммуникационного графа, чтобы упрощать процессы в целом (например, направленные ациклические коммуникации могут быть быстрее, без «туда-сюда»).
В целом
Думаю, имеет смысл моделировать/измерять вместо этого команды и то, что они поставляют (выход), на основе входа и контекста, и одно это потенциально может помочь организациям получить достаточно обратной связи, чтобы улучшаться. Продуктивность разработчиков можно измерять через их команды.
Если кому-то нужно вывести число, которое будет коррелировать с продуктивностью отдельного разработчика, он может в итоге получить число, которое ничего не значит, что-то вроде абстрактного индекса производительности компьютера. Ок, индекс 10, но настоящий вопрос — смогу ли я запустить новый улучшенный Skyrim или нет.
Так что для меня ответ таков: просто поговорите с членами команды, если хотите больше узнать об их продуктивности и помочь им быть продуктивными, но не используйте эти данные вне контекста их команды. Добрый старый 1–1 может помочь сильно, пожалуй, больше, чем автоматизация на основе выхода.
Изначально опубликовано на Medium: https://medium.com/@nettsundere/on-how-to-measure-the-developers-productivity-b7df7d572d2a