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

VP инжиниринга защищает на совете директоров миграцию на микросервисы за $1.2M. Прогноз ROI: «экономим 30% на инфре, релизим в 2 раза быстрее». CFO задаёт один вопрос: «Покажите математику». В ответ — единственное число 240% и никакого метода за ним. Совет говорит нет. Через два квартала конкурент закрывает ту же миграцию за восемь месяцев и начинает выигрывать enterprise-сделки на латентности. Проект был хороший. Проблема — в математике.

Никакой единой «формулы Engineering ROI» не существует. Есть пять разных методов расчёта, каждый собран под свой вопрос. Исследование McKinsey Developer Velocity Index показало, что команды верхнего квартиля генерируют в 4–5 раз больше выручки на разработчика, чем команды нижнего. Но это соотношение ничего не значит без указания, как вы это измерили. Возьмёте не тот метод под вопрос, потеряете защитимый проект. В статье разобраны все пять, с реальными цифрами.

В инженерной культуре Google есть правило: до первой строчки кода для любой нетривиальной задачи пишется design doc. Не 40-страничный монумент, а обычно 5-12 страниц, с двумя ревьюерами и комментариями на полях. Команда Engineering Practices из Google публично называла это одним из самых дешёвых рычагов качества в компании.

Большинство команд вне Google либо пропускают этот шаг, либо прикручивают шаблон в Confluence к существующему процессу и смотрят, как он атрофируется. Шаблон ниже — тот, который реально выживает при встрече с уставшим ревьюером в 16:45 в четверг. Это тот момент, когда спека живёт или умирает.

Команда из 40 инженеров за 8 месяцев приняла одно и то же архитектурное решение дважды — в июне и в феврале, оба раза откатила. После второго отката наконец внедрили RFC-процесс. Разбирая историю коммитов, они обнаружили: оригинальный контекст остался в Slack-треде, который автоматически архивировался через 90 дней, а инженер, который владел решением, уже уволился. RFC-документ стоил бы 4 часа на написание и сэкономил бы примерно 3 инженеро-недели переделок.

RFC-процессы существуют потому, что технические решения переживают людей, которые их приняли. Stripe, Cloudflare, Oxide Computer и проект Rust публично описывают свои RFC-форматы — и общая структура уже, чем кажется большинству команд. Эта статья — тот самый шаблон, к которому они сходятся, плюс реалистичный ревью-цикл для команд 10-80 человек, плюс честные цифры о том, когда RFC просто тратят время.

Команда из 6 инженеров, 60 рабочих дней, по 8 часов. PM приходит на планирование со слайдом «2 880 dev-часов capacity». Q3 roadmap влезает в 2 400. Комфортный буфер. Через три месяца 40% roadmap не успели, а в постмортеме пишут «scope creep».

Никакого scope creep не было. Цифра capacity была неверной с первого дня. Стэнфордский экономист Джон Пенкавель в исследовании по часам и продуктивности показал, что output-per-hour начинает падать после 49 часов в неделю, задолго до 60. Microsoft Research и UC Irvine с Глорией Марк добавили второе лезвие: каждое прерывание стоит в среднем 23 минуты 15 секунд на восстановление фокуса. Сложите эти два факта поверх любого 8-часового календаря и вы получите заметно меньше 8 продуктивных часов.

Команда из 60 инженеров, с которой я работал в прошлом году, имела 1400+ страниц Confluence, Notion-воркспейс на 380 страниц, GitHub wiki в каждом из 22 репозиториев и Google Drive с «командными знаниями». Задачей новой сотрудницы на второй неделе было найти runbook стейджинга. Ушло четыре часа. Он существовал во всех четырёх системах, с тремя разными URL, двумя противоречивыми версиями и одной корректной, но устаревшей на три года инструкцией в wiki.

Это сравнение четырёх подходов к knowledge management — Confluence, Notion, GitHub Wiki, Git-native docs (Obsidian/MkDocs/Docusaurus поверх репозитория) — и фреймворк выбора. Microsoft Research в отчёте по productivity 2024 назвал «не могу найти документацию» фактором трения №3 после медленных билдов и сломанных тестов, выше задержек code review. Выбор инструмента не нейтрален: он определяет, будет ли документация написана, найдена и доверяема.

Две инженерные организации одинакового размера шипят одним темпом. Организация A: у каждого файла есть владелец, PR требуют его аппрува. Организация B: любой может смержить любую часть кода после peer review. У A на 40% меньше багов на KLOC. B восстанавливается после ухода senior-инженера в 3× быстрее. Microsoft Research (Bird et al., 2011, Don't Touch My Code) провели этот эксперимент на 3000+ файлах в Windows Vista/7 и показали: файлы с чётким владельцем имеют значительно меньше post-release отказов — но также чаще становятся бутылочным горлом.

Эта статья сравнивает три реальные модели владения — strong, collective, hybrid — по данным Microsoft, Google 2018 по code review и 100+ компаниям из нашего IDE-датасета. Цель — выбрать модель под этап и работу команды, а не ту, что была в блогпосте на прошлой неделе.

R&D-организация на 50 инженеров, с которой мы работали в прошлом фискальном году, верстала годовой бюджет так же, как большинство: взять прошлогодний расход ($5.4M), прибавить 10%, получить $5.94M. К концу третьего квартала финансы согласовывали с советом директоров дополнительно $700K. Недостача оказалась почти ровно $710K — 12% сверх top-down цифры — и постмортем привязал каждый доллар к допущениям, которые никто не записывал. Праздничные месяцы шли с повышенным overhead. Двое контрактников официально были part-time, по факту биллили 0.9 FTE. Одна команда выросла на трёх человек в марте, и стоимость накопилась за девять месяцев, а не за четыре, как заложил планировщик.

Gartner в IT Spending Forecast 2025 оценивает рост R&D в софте на 9-11% год к году, но разброс по конкретным компаниям шире — Deloitte в отчёте CFO Insights: Budgeting in Volatile Times (2024) зафиксировал медианную ошибку прогноза 18% в софт-ориентированных компаниях, использующих top-down, а худший квартиль промахивается больше чем на 30%. McKinsey в Tech Talent Tectonics (2023) формулирует резче: топ-квартиль инженерных организаций тратит не только меньше на единицу выхода — они точнее прогнозируют, и поэтому могут аллоцировать капитал агрессивно там, где нижний квартиль вынужден держать запас наличных как страховку от собственной плохой математики.

Fintech-команда в Варшаве сократила средний рабочий день на 45 минут — и стала катить больше фич. SaaS из 40 человек в Сингапуре запретил митинги до 11 утра — медиана lead time на PR упала на 22%. Ни одна команда ничего не изобрела — они внедрили защищённые блоки deep work. UC Irvine, Gloria Mark, почти два десятилетия публикует (The Cost of Interrupted Work: More Speed and Stress, 2008, и follow-ups): одно прерывание стоит ~23 минут на рефокус. Cal Newport Deep Work (2016) популяризировал термин у инженерных лидеров. Данные устоялись; имплементация — там, где команды расходятся.

Эта статья проходит по 5 реальным расписаниям команд. Что сработало, что сломалось, и что мы увидели в IDE-телеметрии, когда паттерн стабилизировался.

Фича опаздывает на две недели. Продакт-менеджер пожимает плечами: «Всё равно тот же квартал». Tech lead кивает. CFO не узнаёт. Две недели превращаются в шесть. К этому моменту enterprise-клиент, которому фича была нужна под цикл закупок, подписывает с конкурентом. Реальная цена этой задержки для бизнеса — около $192 000, и ни один из этих долларов не появится в инженерных отчётах.

Cost of Delay (CoD) — самая обсуждаемая и самая неподсчитываемая концепция в современной разработке продукта. Дон Райнертсен заложил математику в The Principles of Product Development Flow (2009, глава 2), а SAFe оформил её в WSJF (Weighted Shortest Job First). Исследование McKinsey Developer Velocity 2023 показало, что лидеры B2B SaaS выпускают фичи в 4–5 раз быстрее аутсайдеров и непропорционально больше pipeline ARR на инженера. Но спросите у 10 PM сколько им стоила последняя задержанная фича — 9 ответят «не знаю». Математика достижима. Просто никто её не считает.

Медианный срок работы инженера в B2B-компании — 2.3 года (Stack Overflow Developer Survey 2025). Медианная неожиданность менеджера этого инженера при увольнении — тоже высокая. Мы сопоставили IDE heartbeat, Git-активность и сигналы из таск-трекера с 43 подтверждёнными увольнениями в 11 командах клиентов PanDev Metrics за 2025. Семь поведенческих паттернов проявились в данных за 30-90 дней до письма об увольнении.

Один из них почти никогда не попадает в стандартный список "сигналов выгорания". Из-за него этот пост и существует.