21 запись с тегом "engineering-management"

Отчёт McKinsey о продуктивности разработчиков (2023) показал, что инженеры тратят лишь 25–30% времени на написание кода. Остальное исчезает в митингах, переключении контекста и ожидании. Если вы Engineering Manager и полагаетесь на интуицию — вы не видите, куда уходит 70% мощности вашей команды.

Вот 10 метрик, которые заточат ваши решения. Без воды и совета «отслеживайте всё» — только то, что отличает управление на основе данных от гадания.

Большинство попыток внедрения DORA проваливаются не из-за инструментов или данных — а потому что превращаются в 6-месячные проекты, умирающие в комитетах. Исследование Accelerate (Forsgren, Humble, Kim, 2018) показало, что организации с видимыми метриками доставки улучшаются быстрее. Ключевое слово — видимыми: дашборд, на который никто не смотрит, хуже, чем отсутствие дашборда, потому что создаёт иллюзию измерения. Вот пошаговый план: от нуля до рабочих DORA-дашбордов за две недели — достаточно быстро, чтобы инерция не рассеялась.

Исследование Глории Марк из UC Irvine показало, что после одного прерывания требуется в среднем 23 минуты 15 секунд, чтобы вернуться к задаче. А теперь представьте типичное утро разработчика: в 9:07 пришло сообщение в Slack, в 9:15 — напоминание о стендапе, в 9:45 — «быстрый вопрос» от PM. К 10:30 он «работал» 90 минут, но написал ровно 11 строк кода. Три прерывания съели примерно 70 минут когнитивного восстановления.

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

Никто не увольняется в понедельник. Заявление об увольнении, которое вы получите в случайный четверг, было написано — эмоционально — шесть недель назад. Отстранение началось три месяца назад. И данные видели это всё время.

Опрос Stack Overflow Developer Survey 2023 показал, что более 70% разработчиков отметили те или иные симптомы выгорания. Замена среднего разработчика обходится примерно в 50–200% его годовой зарплаты, если учесть рекрутинг, онбординг и потерю институциональных знаний. Фреймворк SPACE (Forsgren et al., 2021) прямо включает «Удовлетворённость и благополучие» как ключевое измерение продуктивности — признавая, что выгоревшие разработчики не просто несчастны, они существенно менее продуктивны. Но сигналы видны в данных активности задолго до заявления об увольнении.

Вот пять паттернов, которые проявляются в данных активности IDE за недели — иногда месяцы — до того, как разработчик выгорит или уволится.

Ваш сениор-разработчик назначен на три проекта. Вы полагаете, что он отдаёт каждому проекту треть времени. Джеральд Вайнберг посчитал реальную математику в Quality Software Management (1992): при трёх параллельных проектах каждый получает около 20% времени разработчика — а оставшиеся 40% испаряются в виде накладных расходов на переключение контекста.

Это не предположение. Это хорошо задокументированный когнитивный феномен, подтверждённый данными нашей платформы по B2B-инженерным командам и согласующийся с исследованиями Глории Марк из UC Irvine, показавшими 23 минуты восстановления после каждого прерывания. Переключение контекста — одна из самых дорогих невидимых затрат в разработке ПО.

Согласно исследованиям McKinsey о продуктивности разработчиков, инженеры тратят лишь 25–30% времени на написание кода. Поэтому то, где работают разработчики, должно значить куда меньше, чем как структурировано их время. Тем не менее спор «удалёнка или офис» длится уже шесть лет: CEO ссылаются на «коллаборацию», разработчики — на «фокус», и обе стороны аргументируют убеждениями, а не доказательствами.

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

Исследования Gallup неизменно показывают, что качество менеджера — главный фактор вовлечённости сотрудников, и всё же большинство инженерных менеджеров проводят 1:1 одинаково: «Как дела?», за чем следует неловкая тишина, а потом разговор сползает в обновление статуса по проекту. Это не 1:1 — это стендап с лишними шагами. Настоящие 1:1 должны быть самыми ценными 30 минутами в неделе вашего разработчика, и данные делают их кратно лучше.

Анализ Harvard Business Review показал, что более 90% менеджеров признают: процесс performance review в их компании не даёт точных результатов. В инженерии проблема ещё хуже: менеджеры пишут размытые абзацы на основе того, что помнят за последние две недели. Тихие высокоэффективные сотрудники остаются незамеченными. Громкие слабые — получают оценки выше заслуженного. И все уходят с ощущением, что процесс был произвольным. Данные это исправляют — но только если использовать их правильно.

Отчёт Stripe «Developer Coefficient» оценил, что компании по всему миру теряют более $300 миллиардов ежегодно из-за неэффективности разработчиков — в значительной мере из-за недоукомплектованных команд, борющихся с техническим долгом вместо выпуска фич. Вам нужно больше инженеров. Команда перегружена, дедлайны сдвигаются, технический долг растёт. Вы это чувствуете интуитивно. Но вашему CFO плевать на вашу интуицию — его волнуют цифры, ROI и риски. Большинство запросов на штат проваливаются не потому, что они неправильные. А потому, что аргументируются на неправильном языке.

По оценкам Gartner, менее 30% инженерных лидеров имеют эффективную видимость реальной производительности своей команды. У каждого CTO есть дашборд. Большинство из них бесполезны. Они или забиты 47 графиками, которые никто не читает, или содержат один график velocity, который ничего не говорит. Хороший дашборд CTO отвечает на три вопроса: доставляем ли мы? Здоровы ли мы? Улучшаемся ли мы? Вот как построить такой, который реально работает.