46 записей с тегом "guide"

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

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

Команда из 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. Выбор инструмента не нейтрален: он определяет, будет ли документация написана, найдена и доверяема.

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) формулирует резче: топ-квартиль инженерных организаций тратит не только меньше на единицу выхода — они точнее прогнозируют, и поэтому могут аллоцировать капитал агрессивно там, где нижний квартиль вынужден держать запас наличных как страховку от собственной плохой математики.

Фича опаздывает на две недели. Продакт-менеджер пожимает плечами: «Всё равно тот же квартал». 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 ответят «не знаю». Математика достижима. Просто никто её не считает.

Команда из 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-инженерных командах, которые мы измеряем — командах, где телеметрия показывает, что они не просто счастливее, но и шипают быстрее.

14-минутный CI-пайплайн — это не просто 14 минут ожидания. GitHub Octoverse 2024 отчитался: медианный enterprise-репозиторий прогоняет pull request через CI 4.2 раза перед merge — ретраи, пуши после ревью, починка flaky-тестов. Это почти час компьюта на один PR. В команде, шипящей 200 PR в неделю, CI-бюджет вам ничего не приносит, а context-switch налог стоит вам четверга senior-разработчика.

Это how-to. Шесть шагов, которые стабильно режут время GitHub Actions CI на 50%+ на реальных репо, которые мы помогали оптимизировать. Без теории; у каждого шага есть патч, который можно адаптировать.

Финансовый лид команды из 12 разработчиков открывает дашборд расходов. Общий burn за месяц: $58 000. Четверо в штате на месячном окладе, пятеро контракторов на почасовой ставке, ещё трое работают через вендора с месячным инвойсом. Дашборд показывает одно среднее значение стоимости разработчика. Это неверная цифра, и каждое решение по cost-per-feature, построенное на ней, тоже неверное.

Стандартное решение — конвертация 160 часов: делим месячную ставку на 160, получаем «эквивалентную часовую» и сравниваем. По данным US Bureau of Labor Statistics, средний работник реально отрабатывает 1 791 час в год. Это 149 часов в месяц, не 160. В Казахстане 24 рабочих дня отпуска плюс 13 праздничных дней дают эффективную цифру ближе к 144 часам. 160 — это наследие, которое уже не соответствует данным даже в стране-источнике.

Senior backend разработчик в Алматы получает $5 000/мес. gross. CFO, который оценивает новый проект, делает очевидную арифметику: $5 000 ÷ 160 = $31.25/час. Эта цифра попадает в Excel, потом в борд-дек, потом в коммерческое предложение клиенту.

Реальная стоимость часа этого инженера, с учётом накладных расходов, ближе к $46/час. Разрыв в 48%. DORA State of DevOps Report 2024 фиксирует non-coding overhead в инженерных организациях на уровне 35–55% от ФОТ. McKinsey Developer Velocity Index (2023) даёт примерно тот же диапазон. Большинство компаний этот множитель просто не применяют. Они квотят, скоупят и бюджетируют по «голой» цифре, а потом удивляются, почему юнит-экономика не сходится.

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

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

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