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

Спринт 47, команда из 8 человек. Стандартный нарратив ретро звучал бы так: «velocity упал на 20%, было много багов, в следующем спринте поприоритезируем лучше». Тот же вайб, что и в спринте 46. И в спринте 45. Теперь добавьте на то же ретро один показатель: общая стоимость спринта — $32 800, из них $11 600 (35%) ушли на тикеты с багами, против $14 200 (43%) на фичи. Скользящее среднее по багам у этой команды — 18%. Одна строка — «мы потратили на баги вдвое больше обычного» — переключила команду с «сделаем лучше» на «первые три дня спринта 48 — только bug-prevention, без исключений».

Этот пост показывает, как встроить один финансовый показатель в 30-минутное ретро так, чтобы оно производило решения, а не ощущения.

Команда из 6 инженеров с 15-минутным daily standup стоит вам 7,5 человеко-часов в неделю только в запланированном времени. Добавьте цену переключения контекста — Gloria Mark (UC Irvine) измерила ~23 минуты на возврат к задаче после прерывания — и реальная стоимость ближе к 15 часам в неделю. Для команды, тянущей фичу 10 недель, это 150 инженер-часов. Это не встреча. Это part-time инженер, которого вы наняли и сразу поставили говорить.

Standup'ы не плохи сами по себе. Они решают реальную задачу: выносят блокеры на поверхность, пока те не сгнили. Вопрос в том, единственный ли синхронный ежедневный формат её решает — и лучший ли. Отчёт State of Agile 2024 показывает, что 32% команд активно экспериментируют с async-first альтернативами, и наиболее чистые данные из IDE-телеметрии говорят, что эти альтернативы возвращают 1-2 часа focus time на разработчика в неделю без ущерба доставке.

Это сравнение 5 альтернатив standup, когда какая подходит, и как выбрать свою.

Большинство «remote-ритуалов» — это синхронные встречи в remote-костюме. Ежедневный стендап в 9 утра UTC, на который пятеро инженеров в четырёх часовых поясах ходят нехотя — это не ритуал, это офисный косплей. GitLab Remote Work Report 2024: 71% remote-инженеров называют «слишком много синхронных встреч» главным drain'ом продуктивности распределённой работы. Проблема не в remote; проблема в импортировании colocated-ритуалов целиком.

Это список из 7 ритуалов, которые реально выживают в remote-инженерных командах, которые мы измеряем — командах, где телеметрия показывает, что они не просто счастливее, но и шипают быстрее.

Sprint planning, запланированный "на 10 утра, чтобы всем было удобно", — быстрейший способ потерять инженерное время в распределённой организации. Математика простая: с инженерами в Americas, EMEA и APAC слота "все могут прийти" не существует — хотя бы одна таймзона теряет 3+ часа, встречаясь в неудобное время. Microsoft Work Trend Index 2022 по 61 000 сотрудников: встречи вне локального 9-17 снижают вовлечённость на 52% и увеличивают частоту последующих недопониманий в 2.4×.

Это чеклист — не философское рассуждение — как запускать sprint planning для команды из 3+ таймзон. Он построен на паттернах нашего IDE heartbeat датасета, конкретно на 62 командах, работающих с распределённым планированием.

Фредерик Брукс опубликовал «Мифический человеко-месяц» в 1975 году. Его главный тезис — «добавление людей в опоздавший проект делает его ещё более опоздавшим» — пережил пять десятилетий методологической моды: водопад, agile, DevOps. В 2026 году AI-ассистенты подняли индивидуальную продуктивность инженера на 30-55% в контролируемых исследованиях (GitHub/Microsoft Research, 2024-2025). Естественный вопрос: AI наконец сломал закон Брукса?

Короткий ответ: нет. Чуть менее короткий: AI ускорил именно ту часть инженерной работы, которая никогда не была узким местом, и почти не затронул ту, которая им является.

Самый живучий миф в индустрии: Engineering Manager — это senior-разработчик, которому дали права админа в GitHub и разрешили одобрять pull requests по пятницам. Миф ошибочный по двум причинам. Первая: медианный EM в 100+ B2B-командах, которые мы измеряем, пишет код примерно 18 минут в день, и это здоровая цифра. Вторая: самое ценное, что делает EM, к IDE отношения не имеет. Это разговор, который удержал senior'а от ухода. Переписанная спека, которая спасла квартал. Нанятый инженер на уровень выше, чем команда считала возможным. Will Larson, который строил инженерию в Stripe, Calm и Carta, в An Elegant Puzzle формулирует прямо: задача EM — сделать так, чтобы команда выдавала больше суммы своих частей. Руками на клавиатуре этого не сделать.

Эта статья — простое определение роли. Кто такой EM, что он делает в течение недели, чем отличается от Tech Lead, как попасть туда из senior engineer и по каким метрикам понять, что человек справляется.

Средний engineering manager тратит 4 часа в неделю на перетаскивание тикетов в Jira. Не планирование, не 1:1 — сортировку, напоминания, закрытие stale и гонки за полями, которые забыли заполнить. Мы опросили 31 EM у B2B-клиентов; 27 назвали Jira главной временной дырой после встреч.

Atlassian поставляет довольно мощный engine автоматизации в каждом плане Jira (да, даже в Standard). Команды его игнорируют. Или, что хуже, используют для одного правила — auto-close на "Done" — и упускают 11, которые имеют значение. Ниже — набор 12 правил, которые вместе сокращают admin-нагрузку EM с 4 ч/нед до ~40 минут. Мы используем варианты у себя в PanDev Metrics и у трёх on-prem клиентов.

Финтех на 40 инженеров, с которыми я говорил в прошлом месяце, платил $960 в месяц за GitHub Copilot Business на всю команду, но их юристы только что заблокировали использование после compliance-review: телеметрия code completion уходила через облако Microsoft. CTO задал мне обманчиво простой вопрос: «Можем ли мы self-host'ить эквивалент?»

Ответ — «да, но только если пройдёте три фильтра». Stack Overflow Developer Survey 2024 показал, что 76% разработчиков используют или планируют использовать AI-инструменты, но в регулируемых индустриях adoption отстаёт на 20-30 пунктов. Разрыв — не в скепсисе, а в инфраструктуре. Большинство команд хотят приватный inference, но недооценивают, во что «self-hosted» обходится по GPU capex, времени SRE и компромиссу в качестве модели.

Это фреймворк, который мы даём командам, обдумывающим переход: когда self-hosted LLM бьёт облако, когда нет, и три точки, где математика переворачивается.

Большинство нетехнических CEO относятся к инженерии либо как к чёрному ящику, либо как к театру. CEO-чёрный-ящик спрашивает «как дела у инженерки?» на исполкоме, принимает ответ «идём по плану» и через четыре квартала удивляется, когда уходит архитектор, а роадмап встаёт. CEO-театр становится самодеятельным инженерным менеджером — учит DORA-метрики, неправильно произносит «Kubernetes» и превращает любое обсуждение roadmap в технический спор, за которым сам не успевает.

Ни то ни другое — не про интеллект. Это про отсутствие короткого нетехнического словаря для оценки здоровья инженерии. First Round State of Startups 2023 показал, что 68% CEO-первопроходцев считают себя «скорее» или «очень» зависимыми от CTO по любым инженерным решениям — это нормально, пока CTO не уходит или не расходится с советом директоров во взглядах.

Этот гайд — минимальный словарь CEO: 6 вопросов, позволяющих проверить здоровье инженерии без попытки стать техническим.

Engineering Director, хорошо ведший организацию на 50 человек, обычно неверный человек, чтобы вести 500. Не потому что талантлив меньше — потому что на 500 это другая работа, а не та же с удвоенной интенсивностью. Исследования First Round Review по 300+ инженерным лидерам стабильно показывают: переходы на ~80, ~150 и ~300 инженерах — там, где кластеризуется большинство выгораний и тихих уходов старших лидеров.

Это гайд, основанный на данных, о четырёх переходах Engineering Director при росте от 50 до 500 — что отпустить, что взять, и что наши IDE heartbeat данные говорят о признаках Director'а, который не сделал сдвиг.