96 записей с тегом "engineering-management"

Согласно исследованиям 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 отвечает на три вопроса: доставляем ли мы? Здоровы ли мы? Улучшаемся ли мы? Вот как построить такой, который реально работает.

Опросы 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 связывают техническую работу с бизнес-результатами, а правильные метрики делают их реально измеримыми.

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

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

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

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

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