22 записи с тегом "engineering-metrics"

Каждый руководитель разработки задаёт один и тот же вопрос: сколько времени разработчики реально тратят на написание кода?

Microsoft Research выяснили, что разработчики тратят на код всего 30-40% рабочего времени. Исследование Haystack Analytics 2019 года показало ближе к 2 часам. Наши собственные данные IDE heartbeats по B2B-командам подтверждают медиану в 78 минут в день.

Вот что реально показывают данные и почему это важно.

В апрельском номере Forbes Kazakhstan за 2026 год (страницы 104–107) вышла статья «Доверься «большому брату»», посвящённая инженерной аналитике и PanDev Metrics. Материал рассматривает, как подход к управлению разработкой на основе данных набирает обороты в Центральной Азии и за её пределами.

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

Фред Брукс предупреждал в Мифическом человеко-месяце (1975), что измерять продуктивность программистов объёмом кода — ловушка: больше кода не значит больше ценности. Пятьдесят лет спустя некоторые организации всё ещё приравнивают написанные строки к выполненной работе. Фреймворк SPACE (Forsgren et al., 2021) прямо предостерегает от одномерных метрик активности — и всё же потребность, которую они адресуют, реальна: как понять, что ваша инженерная команда доставляет результат?

Ответ — не очередная vanity-метрика. Это составной сигнал, который мы называем Delivery Index.

«Это должно занять два дня.» Три недели спустя фича всё ещё в работе.

Стив Макконнелл в книге Software Estimation: Demystifying the Black Art обнаружил, что программные проекты обычно превышают первоначальные оценки на 28–85%. Закон Брукса из Мифического человеко-месяца объясняет часть причины: сложность растёт нелинейно с объёмом, а добавление людей в опаздывающий проект делает его ещё более опаздывающим. PM расстроен. Разработчик чувствует вину. Дорожная карта — фикция. И вся организация молчаливо приняла, что инженерные оценки ненадёжны.

Это не проблема людей. Это проблема измерения. И она решаема.

Глобальный опрос Deloitte по аутсорсингу неизменно называет «недостаток видимости» одной из главных причин провала аутсорсинговых отношений. Ваш клиент платит за 160 часов в месяц на разработчика. Но в глубине души он задаётся вопросом: были ли эти 160 часов действительно продуктивной работой? Это единственное сомнение убило больше аутсорсинговых контрактов, чем сорванные дедлайны.

Проблема не в доверии — а в отсутствии доказательств.

Глобальный опрос Deloitte по аутсорсингу показал, что недостаток прозрачности — главный фактор неудовлетворённости клиентов в аутсорсинговых отношениях. Две аутсорсинговые компании делают питч одному клиенту. Одинаковый стек, похожие ставки, сопоставимые портфолио. Одна говорит: «Мы доставляем качественную работу в срок.» Другая: «Вот live-дашборд, показывающий, что ваши разработчики делают прямо сейчас.» Кто побеждает?

В 2026 году ответ очевиден. Прозрачность — не «приятный бонус», а дифференциатор.

Исследования переключения контекста показывают, что в среднем требуется 23 минуты для полного восстановления фокуса после прерывания. Теперь умножьте это на пять проектов, каждый со своим Slack-каналом, Jira-доской и ожиданиями стейкхолдеров. Вы — менеджер проектов в аутсорсинге, ведущий пять проектов для пяти разных клиентов. Каждый клиент считает, что его проект — ваш главный приоритет. И каждый понедельник утром вы тратите первые два часа, пытаясь вспомнить, на чём каждый проект остановился в пятницу.

Знакомо? Это проблема мультипроектного управления — и она является определяющим вызовом для менеджмента в аутсорсинге.

Исследование McKinsey по продуктивности разработчиков показало, что software-инженеры тратят только 25-30% рабочего времени на активный кодинг. Остальное уходит на встречи, планирование, ожидание и переключение контекста. В аутсорсинге, где каждый час имеет прямое влияние на выручку, это распределение крайне важно. В вашей компании 40 разработчиков. Вы выставляете клиентам счета за их время. Но какая часть доступного времени каждого разработчика реально оплачивается? Если ответ — «не уверен», у вас есть слепое пятно в рентабельности, которое может стоить сотни тысяч долларов в год.

Утилизация разработчиков — самая важная финансовая метрика в аутсорсинге. И большинство компаний измеряют её неправильно — или не измеряют вовсе.

Staff augmentation — сейчас самый быстрорастущий сегмент рынка аутсорсинга, согласно Deloitte Global Outsourcing Survey. Однако эта модель создаёт парадокс, который большинство заказчиков обнаруживают слишком поздно. Вы усилили свою инженерную команду внешними разработчиками. Они ходят на ваши стендапы, пушат в ваши репозитории и выставляют ежемесячные счета. Но когда приходит инвойс, вас посещает неудобная мысль: «Я понятия не имею, как эти люди реально проводят свои рабочие дни.»

Вы доверяете своей штатной команде, потому что видите их в Slack, в code review, в офисе. Аугментированные разработчики? Они — чёрный ящик. И этот чёрный ящик стоит вам десятки тысяч долларов в месяц.

Jira — самый распространённый инструмент управления проектами в разработке ПО. Здесь живут тикеты, планируются спринты и отслеживается работа. Неудивительно, что руководители инженерных команд обращаются к отчётам Jira за инженерными метриками.

Проблема? Jira измеряет поток тикетов. Она не измеряет разработку.

Тикет Jira, перемещённый из «In Progress» в «Done», говорит о том, что кто-то пометил его завершённым. Он не говорит, сколько времени заняло написание кода, сколько стоила работа, сколько итераций потребовал code review или насколько гладко прошёл деплой. А ведь именно эти метрики важны для оценки инженерной эффективности.