7 записей с тегом "metrics"

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

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

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

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

Опросы Stack Overflow Developer Survey неизменно показывают, что автономия и доверие разработчиков — одни из сильнейших предикторов удовлетворённости работой, и всё же большинство внедрений метрик полностью это игнорируют. С одной стороны — руководители, которые хотят понимать и улучшать работу команд. С другой — разработчики, которые слышат «мы внедряем метрики» и сразу думают «Большой Брат». У обеих сторон есть обоснованные опасения. Вопрос не в том, измерять или нет, а в том, как измерять, не разрушая культуру, которую вы пытаетесь улучшить.

Как документируют Matthew Skelton и Manuel Pais в Team Topologies, коммуникационный overhead между инженерами растёт квадратично: при 10 людях — 45 потенциальных каналов связи; при 100 — почти 5 000. При 10 инженерах вы знаете каждого. Слышите каждый разговор. Ревьюите большинство PR. Всё работает — потому что вы сами клей, скрепляющий систему. При 100 это невозможно. CTO, который пытается управлять 100 инженерами так же, как управлял 10, выгорит, создаст узкие места и будет наблюдать, как падает качество. Переход от 10 к 100 — самый сложный организационный вызов для CTO стартапа, и данные — единственный способ пройти его, не потеряв рассудок.

Исследования McKinsey по инженерной эффективности показали, что у самых высокопроизводительных организаций есть одна общая черта: их инженерные цели явно связаны с бизнес-результатами. И всё же большинство инженерных команд пишут OKR вроде «Улучшить качество кода» с key result «Увеличить покрытие тестами до 80%». Это не OKR. Это задача с числом рядом. Хорошие инженерные OKR связывают техническую работу с бизнес-результатами, а правильные метрики делают их реально измеримыми.

Developer Experience — DevEx или DX — превратился из нишевой концепции в тему для совета директоров. Такие компании, как Google, Spotify и Shopify, имеют выделенные DevEx-команды. Количество вакансий «Developer Experience Engineer» утроилось с 2023 года. JetBrains Developer Ecosystem Survey теперь включает вопросы, специфичные для DevEx, сигнализируя, что индустрия считает это измеримым параметром, а не просто модным словом.

Но что такое Developer Experience? Как измерить нечто, что кажется по своей природе субъективным? И почему VP of Engineering должен об этом заботиться?