Управление организацией из 500+ разработчиков в телекоме — как управление маленьким городом. У вас есть инфраструктурные команды, поддерживающие критически важные сетевые системы, продуктовые команды, создающие клиентские приложения, платформенные команды, поддерживающие внутренний инструментарий, и команды интеграции, соединяющие всё это воедино. Они распределены по нескольким офисам, часовым поясам, а иногда и странам.

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

AI/ML-команды не похожи ни на одну другую инженерную организацию. Половина команды исследует новые подходы, где большинство экспериментов проваливаются — и это ожидаемо. Другая половина строит продакшн-системы, где важны надёжность и скорость. Многие участники делают и то, и другое, переключаясь между Jupyter notebooks и продакшн-кодобазами в течение одного дня. MLOps maturity model описывает этот спектр — от ad hoc экспериментов (Level 0) до полностью автоматизированных ML-пайплайнов (Level 2) — и большинство организаций находятся где-то посередине.

Традиционные инженерные метрики не охватывают эту двойственность. Измерять ML-исследователя по Deployment Frequency — всё равно что измерять повара по скорости мытья посуды. Но полное отсутствие метрик означает, что вы не можете определить, приносят ли исследовательские инвестиции результат и надёжны ли ваши продакшн-системы. Данные Papers with Code показывают, что разрыв между state-of-the-art исследованиями и production-ready ML растёт — что делает мост research-to-production важнее, чем когда-либо.

Вот как построить фреймворк метрик, который уважает разницу между research и engineering, давая руководству необходимую видимость.

EdTech-платформы — обманчиво сложные инженерные задачи. Данные HolonIQ о глобальном финансировании EdTech показывают, что сектор привлекал более $10 миллиардов ежегодно в последние годы — и этот капитал требует инженерного выхода, соответствующего ожиданиям инвесторов. На поверхности это «просто» LMS или онлайн-платформа курсов. Под капотом — потоковое видео в реальном времени, адаптивные алгоритмы обучения, управление контентом для тысяч курсов, движки оценивания, аналитические дашборды, соответствие стандартам доступности и интеграции со школьными IT-системами, которые не обновлялись с 2010 года.

CTO в EdTech управляют командами, охватывающими frontend, backend, контент-инженерию, data science, DevOps и часто выделенную команду интеграций. Работа варьируется от высокотворческой (создание увлекательного учебного опыта) до глубоко технической (пайплайны транскодирования видео, движки совместной работы в реальном времени) до раздражающе рутинной (интеграция с очередной LMS через плохо документированный API).

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

Каждый рейтинг «топ языков программирования», который вы видели, основан на звёздах GitHub, опросах Stack Overflow или вакансиях. Ни один из них не измеряет, на что разработчики реально тратят своё время.

Мы измеряем. Вот рейтинг, основанный на тысячах часов реального времени кодирования в IDE по 200+ языкам программирования, отслеженных у активных B2B-разработчиков в 100+ B2B-компаниях.

Одни разработчики клянутся, что лучшее начало дня — 6 утра с кофе и тишиной. Другие не открывают IDE до 10 вечера. Менеджеры спорят: вводить «core hours» или позволить людям работать когда угодно.

Мы проанализировали обширные данные активности разработчиков из более чем 100 B2B-компаний, чтобы узнать, когда разработчики на самом деле пишут код — и имеет ли значение время суток.

У каждого engineering-менеджера есть интуитивное ощущение недельного ритма команды. Понедельник кажется медленным. Пятница — временем сворачивания. Но что на самом деле показывают данные?

Мы проанализировали тысячи часов кодинга от разработчиков из более чем 100 B2B-компаний, чтобы построить карту продуктивности по дням недели — и результаты ставят под вопрос некоторые распространённые убеждения.

Спор об IDE вечен. Фанаты VS Code говорят, что он быстрый и расширяемый. Приверженцы JetBrains клянутся глубокой языковой поддержкой. А теперь Cursor — новый претендент, оседлавший волну AI. Stack Overflow Developer Survey стабильно ставит VS Code на первое место как самый популярный редактор, в то время как JetBrains Developer Ecosystem Survey показывает высокую лояльность среди своих пользователей. Но опросы измеряют настроения, а не реальность.

Но что разработчики на самом деле используют, когда садятся за работу? Не то, что они пишут в Twitter. Не то, что они отметили звёздочкой на GitHub. То, в чём они пишут код, час за часом, день за днём.

У нас есть данные. Тысячи часов отслеженного времени написания кода в 100+ B2B-компаниях, с разбивкой по IDE.

«Добавление рабочей силы к запаздывающему программному проекту задерживает его ещё больше.» Фред Брукс написал это в 1975 году. Пятьдесят лет спустя руководители инженерных команд всё ещё спорят, правда ли это.

Мы проанализировали реальные данные кодирования из 100+ B2B-компаний на PanDev Metrics, чтобы понять, как размер команды соотносится с индивидуальной продуктивностью разработчика. Ответ оказался более нюансированным, чем предполагал Брукс — но его ключевая идея по-прежнему верна.

AI-ассистенты для кодирования за три года прошли путь от новинки до необходимости. GitHub Copilot, Cursor, Cody и десятки альтернатив теперь находятся внутри редакторов разработчиков, предлагая код, отвечая на вопросы и генерируя шаблонный код. По оценкам Deloitte, ~70% enterprise-команд разработки уже используют ту или иную форму AI-ассистированного кодирования.

Но действительно ли они делают разработчиков продуктивнее? Или просто более зависимыми от автодополнения?

Мы проанализировали реальные данные использования IDE из 100+ B2B-компаний, чтобы выяснить, как выглядит AI-ассистированное кодирование на практике.

Вы только что наняли senior-разработчика. Он выходит в понедельник. Когда он выйдет на полную продуктивность?

HR говорит «30 дней». Нанимающий менеджер говорит «пару недель». Сам разработчик говорит «дайте мне кодовую базу и всё будет нормально».

Реальность другая. Данные активности кодирования рассказывают более честную историю о том, как на самом деле выглядит адаптация нового разработчика — и она длится дольше, чем планирует большинство организаций.