Measuring Productivity: All Models are Wrong But Some are Useful (Рубрика #Management)

Этот whitepaper от исследователей Google Сьеры Джаспан и Коллина Грина, представляет собой текстовую версию их выступления на DPE Summit (Developer Productivity Engineering). В заглавие статьи они вынесли знаменитую цитату Джорджа Бокса "В сущности, все модели неправильны, но некоторые полезны", которая отлично применима и к вопросам измерения продуктивности инженеров тут к месту. Они рассказывают про принципы и методики, что выработали в Google для преодоления ограничений моделей и получения ценных инсайтов. Эта статья продолжает серию "Developer Productivity for Humans" в журнале IEEE, все статьи из которой рассмотрены в отдельном посте, а дальше поговорим про этот whitepaper.

1. Измерение продуктивности разработчиков — это построение моделей, где необходимо принять, что ни один подход к измерению не способен идеально охватить всю сложность разработки софта. Авторы утверждают, что модели продуктивности часто «опасно избирательны», поскольку опускают важные аспекты работы разработчиков, что приводит к неполным или искажающим оценкам. Важно понимать, что эффективное измерение продуктивности требует комплексного подхода, который охватывает несколько аспектов работы, а не опирается на примитивные метрики вроде количества строк кода или частоты коммитов.
2. Часто такой комплексный подход связан с компромиссами между разными сторонами разработки софта, например, легко ускорить velocity, если выкинуть этап код ревью и тестирования. Для нас это означает, что продуктивность следует рассматривать как баланс между несколькими факторами, в первую очередь скоростью, удобством и качеством, а не как единичный измеряемый результат. Интересно, что в Google этот компромисс представляется в виде треугольника: speed, ease, quality.
3. Исследователи в Google также смотрят и на социологические аспекты, учитывая их совместно с технологическими. Именно этот подход дал название всей серии статей, где измерение продуктивности должно учитывать сложную, творческую природу работы разработчика, а не рассматривать её как чисто механический процесс.
4. В этом исследовании лежит структурированная модель построения систем измерения продуктивности, которая избегает распространённых ошибок. Кажется, авторы используют подход Goals/Signals/Metrics (GSM), про который я уже писал, когда разбирал книгу "Software Engineering at Google", но они прямо об этом не говорят:)
5. Авторы учитывают два противоположных фактора: стремление к простоте (parsymony) и избегание опасной избирательности (worrying selectivity). Парсимония подталкивает к включению меньшего числа компонентов ради простоты, а worrying selectivity требует включения большего числа аспектов для охвата всех важных сторон продуктивности. Исследование советует склоняться к более полному охвату, а не к чрезмерной простоте.
6. Авторы комбинируют в своей методологии качественные и количественные методы, используя данные из инструментальных логов и опросов. Такой смешанный подход отражает их понимание того, что продуктивность разработчиков нельзя полностью охватить только количественными метриками или исключительно субъективными оценками. Вместо этого они предлагают комбинировать разные типы данных для более полного понимания картины. Интересно, что структура их модели учитывает влияние самих измерений на поведение: то, что измеряется, зачастую начинает влиять на поведение сотрудников, иногда вопреки изначальным целям.

В общем, авторы предлагают измерять продуктивность инженеров, понимая ограничения моделей измерений, и использовать комплексный, многомерный подход, фиксируя компромиссы и валидируя выводы с помощью разных методов.

#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes