В конце 2025 года вышел отчет по исследованию продуктивности и опыта разработчиков —
The State of Developer Experience and Developer Productivity in 2025, подготовленный компанией JetBrains, известной своими инструментами для разработки. Исследование посвящено практикам измерения Developer Productivity и Developer Experience в компаниях, существующим пробелам в этих практиках, а также ожиданиям и приоритетам в контексте развития процессов и внедрения AI.
Отчет основан на данных опросов Developer Ecosystem Surveys за 2024 и 2025 годы, в рамках которых на отдельные вопросы было получено от 146 до 6144 ответов от разработчиков, технических руководителей, а также инженеров по Developer Experience и Developer Productivity. Под разработчиками в отчете понимаются все Individual contributors (Developer, Programmer, Software Engineer, Architect, DevOps Engineer, Infrastructure Developer, DBA, Systems Analyst и др), тогда как к техническим руководителям отнесены специалисты на управленческих ролях (Team Lead, CIO/CTO/CEO, Developer Productivity Engineer, Developer Experience Engineer, Product Manager, Product Marketing Manager и др).
В начале отчета авторы дают определение Developer Experience (DevEx или DX) как общей удовлетворенности и ощущения продуктивности, которые разработчики испытывают при взаимодействии с инструментами, процессами, средами и платформами разработки. Подчеркивая, что DevEx напрямую связан с эффективностью разработки и становится критически важной практикой для технологических компаний, стремящихся сохранять конкурентоспособность, привлекать сильных специалистов и формировать устойчивые команды, при этом акцент делается не только на самом факте измерения, но и на корректном подходе к организации этого процесса.
Что интересного мы отметили в отчете:
- Проблемы развития Developer Productivity и Developer Experience. Технические руководители в основном отмечали отсутствие приоритетов по Developer Productivity и Developer Experience на уровне организации (27%), неэффективные и бюрократизированные процессы и политики, замедляющие работу разработчиков (24%), а также слабые практики лидерства, коммуникации и управления (20%), что в совокупности приводит к потере времени, снижению вовлеченности и ограничению продуктивности команд. Также отмечались отсутствие корректных метрик и системного измерения продуктивности разработчиков, негативное влияние организационной структуры и корпоративной культуры, недостаточные инвестиции и бюджет на инструменты продуктивности, фокус на сокращении затрат в ущерб потребностям разработчиков, недостаток обучения и профессионального развития, а также отсутствие выделенных команд, отвечающих за Developer Productivity;
- Активности по развитию Developer Productivity и Developer Experience. Технические руководители чаще всего отмечали внутреннее обучение и развитие навыков сотрудников (24%). Далее следуют внедрение GenAI инструментов (10%) и улучшение процессов и методологий разработки (9%). Также упоминаются поддержка инициатив снизу и обмен лучшими практиками (8%), устранение проблем внутреннего взаимодействия и коммуникации (7%), снижение технического долга (6%) и модернизация инструментов и инфраструктуры (5%). Инвестиции в отслеживание и анализ данных по продуктивности и DevEx, оптимизация циклов обратной связи и улучшение документации набрали по 2%. При этом 22% респондентов затруднились определить основное направление действий;
- Влияние технических и нетехнических факторов на Developer Productivity и Developer Experience. К техническим факторам авторы относят производительность инструментов разработки, отзывчивость редактора кода и другие характеристики технологического стека. К нетехническим факторам — командные процессы, прозрачная коммуникация, четкие цели, справедливая компенсация, общее благополучие и баланс между работой и личной жизнью. По оценке разработчиков и руководителей, оба типа факторов практически в равной степени формируют Developer Experience, а в контексте Developer Productivity нетехнические аспекты даже оказывают несколько более выраженное влияние, что подчеркивает значимость организационной среды наряду с качеством инженерных инструментов;
- Измерение Developer Productivity и Developer Experience. Чаще всего упоминаются фреймворки DORA и SPACE. По 35% респондентов указали метрики Deployment Frequency и Lead Time for Changes из DORA, а также Performance metrics из SPACE, отражающие стабильность и качество систем. 34% применяют Satisfaction metrics из SPACE, связанные с удовлетворенностью и благополучием разработчиков. Среди других показателей — Change Failure Rate (28%) и Time to Restore Service (26%) из DORA, а также Communication and Collaboration metrics (24%), Activity metrics (21%) и Efficiency and Flow metrics (20%) из SPACE. При этом 13% затруднились ответить, а 9% сообщили, что не используют ни один из перечисленных типов измерений;
- Метрики Developer Productivity и Developer Experience. В качестве конкретных метрик для оценки Developer Productivity и Developer Experience чаще всего используются показатели вовлеченности (Developer engagement) и удовлетворенности разработчиков (Developer satisfaction), а также метрики, отражающие настроение и самооценку продуктивности (Developer sentiment и Perceived / Self-reported productivity). Из инженерных показателей применяются Deployment Frequency и Lead Time for Changes, а также Change Failure Rate и Time to Restore Service. Компании также отслеживают Ease of Delivery, Adoption Rate, количество Pull requests или Diffs на разработчика и потери времени (Time loss). При этом 30% респондентов затруднились указать конкретные метрики;
- Методы измерения Developer Productivity. С точки зрения разработчиков, для измерения их продуктивности чаще всего используются KPI (35%), индивидуальные встречи One-on-one (33%) и различные формы самооценки, отличные от опросов и форм обратной связи (31%). Также применяются логи активности (Activity logs), такие как коммиты и Pull requests (23%), экспертные оценки (21%), опросы и формы обратной связи (20%), а также рабочие журналы или статусы (17%). При этом 12% сообщили, что их продуктивность не измеряется, 8% не знают, измеряется ли она, а 5% отметили, что измерение проводится, но им неизвестны используемые методы. Использование телеметрических данных, включая отслеживание активности мыши или клавиатуры, указали лишь 3% респондентов;
- Измерение удовлетворенности инструментами разработки. Удовлетворенность разработчиков инструментами разработки чаще всего либо не измеряется вовсе (33%), либо оценивается неформально — в ходе спонтанных разговоров (27%). Формальные подходы включают опросы и формы обратной связи (24%), индивидуальные встречи One-on-one (21%) и экспертную оценку (13%). При этом 16% респондентов не знают, измеряется ли их удовлетворенность инструментами;
- Отношение разработчиков к оценке продуктивности и удовлетворенности. Большинство разработчиков в целом спокойно относятся к измерению своей продуктивности: 42% чувствуют себя комфортно, 40% занимают нейтральную позицию и 18% испытывают дискомфорт. Оценка удовлетворенности инструментами разработки воспринимается еще более спокойно: 57% чувствуют себя комфортно, а 39% — нейтрально. Однако при этом 66% либо не считают используемые метрики точным отражением своего вклада и продуктивности, либо сомневаются в их корректности. Уровень прозрачности также остается ограниченным: лишь меньшая часть (22%) полностью понимает, как используются данные о продуктивности, тогда как значительная доля (32%) имеет лишь общее представление или вовсе не осведомлена об этом (46%);
- Ожидания разработчиков от процесса измерения продуктивности. Чтобы чувствовать себя более комфортно в процессе измерения продуктивности, разработчики прежде всего ожидают большей прозрачности и ясности самого процесса (21%), а также получения конструктивной обратной связи по результатам для профессионального развития (19%). Значимыми факторами также являются используемый метод измерения (15%) и конкретные метрики (12%), справедливость процедуры (10%) и то, как результаты применяются при принятии решений (9%). В меньшей степени упоминаются вопрос о том, кто проводит оценку (6%), частота измерений (4%) и возможность предлагать изменения в сам процесс (2%);
- Частота измерения Developer Productivity и Developer Experience. В 2024 году частота оценки продуктивности разработчиков значительно различалась между компаниями: наиболее распространены были квартальные (25%), ежемесячные (18%) и еженедельные (17%) измерения. В отношении удовлетворенности инструментами разработки, являющейся ключевым компонентом DevEx, наблюдается сдвиг к более структурированным подходам. Если в 2024 году 53% разработчиков сообщили, что их удовлетворенность измеряется нерегулярно, то в 2025 году этот показатель снизился до 29%, при одновременном росте доли команд, использующих регулярные форматы — квартальные (28%), ежемесячные (18%) и еженедельные (9%) оценки. Также влияет размер компании: крупные организации чаще измеряют, чем средние и малые. В компаниях с численностью более 1000 сотрудников лишь 30% опрошенных технических руководителей сообщили, что такие измерения не проводятся. В компаниях среднего размера (от 50 до 1000 сотрудников) этот показатель составляет 34%, а в малых компаниях с численностью менее 50 человек — уже 41%;
- Ответственные за измерение Developer Productivity и Developer Experience. В 2025 году 56% разработчиков и около половины технических руководителей различных ролей указали, что именно тимлиды (Team leads) являются основными драйверами этих инициатив. Такая картина характерна для компаний всех размеров и выглядит логично, поскольку тимлиды работают в тесном контакте с разработчиками и хорошо понимают рабочие процессы и болевые точки команд. При этом остаются открытыми вопросы о том, насколько тимлиды готовы к такой роли, обладают ли необходимыми инструментами и полномочиями для влияния на решения на уровне компании и получают ли достаточную поддержку для выполнения этой задачи. В крупных компаниях чаще отмечали, что ответственность за измерение DevEx и Developer Productivity несут платформенные команды или специально выделенные специалисты, а не только тимлиды;
- Влияние AI на процессы разработки. В горизонте 1-3 лет разработчики ожидают, что AI в первую очередь сократит время на освоение новых фреймворков, инструментов и API (47%), позволит делегировать повторяющиеся задачи (44%) и будет использоваться для генерации черновых версий кода (42%). Также ожидается усиление фокуса на решении задач и высокоуровневом проектировании за счет передачи низкоуровневой реализации AI (39%), заметное улучшение процессов отладки и оптимизации и более легкий переход к новым ролям и технологиям. Часть респондентов предполагает, что рабочие процессы в целом сохранятся, но станут эффективнее в отдельных областях, при этом 29% считают, что AI станет неотъемлемой частью большинства этапов разработки, а 21% ожидают радикальной трансформации с переходом к роли надзора и оркестрации;
- Области применения AI в разработке. Разработчики чаще всего хотели бы получать помощь от AI при генерации шаблонного и повторяющегося кода (62%), анализе ошибок и поиске их исправлений (58%), создании тестов и улучшении качества кода, включая рефакторинг (по 57%). Значительный интерес также связан с написанием и редактированием кода, профилированием и проверкой на потенциальные проблемы, созданием небольших скриптов для автоматизации, а также с генерацией документации, API спецификаций и обучением новым технологиям. AI рассматривается как помощник при создании CRUD API и UI-компонентов, выполнении ревью кода, навигации по коду, интеграции с внешними сервисами, анализе логов и метрик, настройке CI/CD, работе с базами данных, контейнеризацией и инфраструктурой как кодом.
Основные инсайты из отчета The State of Developer Experience and Developer Productivity in 2025 приведены ниже: