Инженерный бюджет на 12 месяцев без догадок

Почему расчёты рунаве быстро становятся запутанными

Инженерный бюджет на 12 месяцев красиво выглядит в таблице. Но как только начинается реальная работа, числа перестают быть послушными. Затраты редко растут по прямой линии, и один плохой месяц может испортить следующие три.

Первое подводное течение — расходы на людей. Основатели часто закладывают только зарплату и считают, что дело сделано. Обычно нет. Налоговые отчисления, льготы, комиссии рекрутеров, оборудование и затраты на подготовку стоят рядом с зарплатой. Один найм может стоить гораздо дороже, чем кажется по строке "оплата", особенно если вы пользуетесь агентством или нужно быстро заменить сотрудника.

Траты на софт растут так же. Один инструмент для дизайна, один для оповещений, один для тестирования, хостинг репозиториев, а потом несколько мест для экспериментов с AI. По отдельности они не кажутся серьёзными. Вместе они тихо съедают деньги, которые вы считали отложенными на продукт.

Облачные счета портятся ещё быстрее, потому что они реагируют на трафик, ошибки и любопытство. Запуск увеличивает потребление. Также может подстать импорт данных у клиента, шумный запрос, дополнительное окружение или неделя интенсивного тестирования. AI-фичи усложняют прогнозы: команды часто проводят эксперименты задолго до того, как знают стабильную ежемесячную стоимость.

Поздние релизы создают другую проблему для бюджета. Штат остаётся прежним, поэтому бёрн выглядит одинаково, но наличность утекает. Зарплаты продолжают уходить, а фича, которая должна приносить выручку, удержание или обратную связь клиента, появляется с опозданием на недели. Переделки, багфиксы и поддержка заполняют разрыв, и рунаве укорачивается, хотя в графике новых наймов не видно.

Поэтому поспешные сокращения часто дают обратный эффект. Под давлением основатели обычно сначала режут самые заметные статьи, а потом хватаются за дешёвого кандидата, фрилансера-патч или дорогое замещение, когда доставка снова сдвигается. Плохие кадровые решения стоят компании дважды: когда вы их принимаете и когда исправляете.

Сложность не в математике. Сложность — во времени. Затраты приходят раньше, экономия — позже, а задержки спрятаны в месяцах, которые на бумаге всё ещё выглядят нормально.

Что включать в бюджет

Большинство стартап-бюджетов ломаются, когда разные расходы сваливают в одну расплывчатую строку. Чёткий инженерный бюджет начинается с четырёх корзин: люди, облако, софт и риск доставки. Держите их раздельно. Тогда вы сможете сокращать расходы взвешенно, а не гадать в спешке.

Расходы на людей — это не только зарплаты. Включайте счета подрядчиков, налоги на зарплату, льготы, рекрутинговые комиссии и любую неполную занятость, связанную с инженерной работой. Учитывайте время основателей только когда оно действительно заменяет оплачиваемую работу. Если основатель тратит по десять часов в неделю на управление релизами, что в противном случае вы бы платили инженеру или fractional CTO, запишите это. Если основатель вмешивается время от времени, не используйте это, чтобы сделать бюджет искусственно меньше.

Облако и софт не должны жить в одной общей строке "инструменты". Облако обычно включает хостинг, базы данных, хранение, трафик, бэкапы, CI-раннеры и объёмы мониторинга. Софт покрывает подписки: дизайн-инструменты, хостинг репозиториев, трекинг задач, системы поддержки и продукты безопасности. Разделяйте ежемесячные платежи и годовые продления или одноразовые расходы — иначе они удивят вас позже.

Используйте два вида одного и того же бюджета: текущие расходы (что уходит из банка сейчас) и запланированные расходы (одобренные наймы, ожидаемый рост использования и запланированные изменения инструментов). Вторая перспектива важна, потому что основатели часто смотрят только на текущий месяц и пропускают расходы, которые уже запущены. Подписанный контракт с подрядчиком, который начнётся в следующем квартале, уже принадлежит плану сегодня.

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

Простая таблица работает, если в каждой строке указан владелец, месяц начала, месяц окончания, ежемесячная сумма, одноразовая сумма и короткая заметка. Тогда видно, что тяготеет сейчас, что запланировано и какие сокращения бьют по доставке сильнее, чем по наличности.

Как оценивать затраты на людей

Зарплата — лишь начальная цифра. Если основатель заложил $120,000 на инженера, реальная стоимость часто значительно выше, когда добавляются налоги, страховки, оборудование, бонусы, комиссии подрядчиков и оплачиваемые отпуска. Используйте полную нагрузку (fully loaded cost) для каждого человека, а не базовую зарплату.

Простое правило: начните с наличной компенсации, затем добавьте все расходы, которые компания оплачивает из-за того, что этот человек работает у вас. Для сотрудников это обычно налоги, льготы, доступ к софту, стоимость ноутбука и любые бонусы. Для подрядчиков ставка уже включает часть накладных, но в годовой сводке итог всё равно может удивить. Подрядчик за $90 в час может в итоге стоить больше годового найма, особенно если он работает дольше, чем планировалось.

Затраты на людей меняются до и после даты найма. Рекрутинговые комиссии, время основателей на интервью, недели на онбординг и пониженная отдача в первый месяц — всё это должно быть в модели. Если есть уведомления о увольнении или компенсации, добавьте и их. Замена никогда не просто одно зарплатное значение на другое: возможно, получится пересечение, потеря скорости и ещё один цикл найма.

Полезно маркировать роль по её вкладу в доставку. Некоторые роли непосредственно выпускают продукт: инженеры, дизайнеры, продуктовые менеджеры. Некоторые поддерживают возможность доставки: DevOps, QA, финансы или админ-поддержка. Другие можно отложить на квартал без блокировки релизов. Такое разделение делает сокращения менее случайными. Если две роли стоят одинаково, но только одна снимает узкое место в релизах, более дешёвое решение может оказаться неверным.

Протестируйте несколько сценариев перед окончательным принятием плана. Что будет, если отложить найм senior backend на три месяца? Что если через четыре месяца заменить дорогого подрядчика штатным сотрудником? Что если один из ранних инженеров уйдёт, и вы потратите шесть недель на его замену? Небольшие изменения часто движут рунаве больше, чем основатели ожидают.

Бюджет становится честнее, когда у каждого человека есть реальная годовая стоимость, реалистичная дата начала и явный эффект на скорость доставки.

Как оценивать облако и софт

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

Соберите все счета за последние 6–12 месяцев. Используйте реальные счета, а не числа из памяти. Один месяц может ввести в заблуждение, если в нём был запуск, провалённый эксперимент или всплеск трафика, который не вернулся.

Затем разделите траты на две корзины. Первая — стабильные ежемесячные расходы: хостинг, базы данных, мониторинг, хостинг репозиториев, дизайн-инструменты, поддержка и другие повторяющиеся платежи. Вторая — переменные расходы: оплата использования, всплески трафика, миграции, тестовые окружения и короткие триалы.

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

Большинство команд экономят в скучных местах. Проверьте неиспользуемые места, два инструмента для одной задачи, старые staging-машины, переразмеренные базы и простаивающие окружения, которые работают всё выходные. Если инженер поднял большой тестовый кластер три месяца назад и забыл про него — это бюджетная дырка, а не просто инфраструктура.

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

Здесь опытный технический обзор окупается. Некоторые компании экономят, консолидируя наблюдаемость, правильно подбирая размеры облачных ресурсов или заменяя несколько платных сервисов одним хорошо управляемым стеком. Но самохостинг не бесплатен, если команда затем тратит часы каждую неделю на его поддержку.

Оценивайте облако и софт в базовом и стрессовом сценариях. Если обычное потребление — $8,000 в месяц, смоделируйте, что будет при $10,000 или $12,000 во время релиза или всплеска. Это делает расчёты рунаве спокойнее и честнее.

Где в числах проявляется риск доставки

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

Начните с работы, которая напрямую навредит бизнесу при сдвиге на месяц. Обычно это всё, что связано с выручкой, нагрузкой поддержки или соответствием требованиям. Поздний фикс биллинга может отложить получение денег. Отсутствие self-serve флоу заставляет оставлять продажи ручными ещё месяц. Пробел в безопасности или комплаенсе может сорвать сделку.

Опишите такую работу простым языком: элементы, нужные для запуска или расширения выручки; элементы, уменьшающие тикеты поддержки или риск возвратов; элементы, требуемые для контрактов, аудитов или проверок безопасности; и вещи, которыми владеет один человек без дубляжа.

Поставьте рядом грубую стоимость сдвига на один месяц. Держите это просто. Если задержка релиза вероятно отложит $15,000 MRR, запишите $15,000. Если поддержка остаётся ручной и это стоит основателю 40 часов плюс счет подрядчика, оцените это время. Если клиент не подпишет контракт до исправления по комплаенсу, считайте упущенные деньги, а не только инженерные часы.

Затем посмотрите на внутреннее сопротивление команды. Бэклог багов, технический долг и хрупкие передачи повышают шанс переработки. Небольшой стартап может думать, что у него два месяца фич, но 25 старых багов, медленные тесты и неаккуратные деплои тихо съедают 20–30% времени.

Одно правило помогает: если команда касается той же области дважды до релиза, считайте второй проход переработкой и заложите его в бюджет. Если релизы часто ломаются — добавьте время простоя. Если оценки регулярно ошибаются на неделю — перестаньте называть это невезением и добавьте буфер.

Для большинства команд небольшой буфер достаточен при здоровой системе. Если передачи хрупки или продакшн шумен — используйте больший буфер. В 12-месячном инженерном бюджете такой буфер часто защищает лучше, чем ещё один поспешный найм, потому что показывает, где задержка действительно стоит денег.

Постройте 12-месячную модель шаг за шагом

Используйте таблицу с 12 месячными колонками и одной стартовой суммой наличности. Поставьте наличность в банке сверху, затем добавьте общий бёрн компании ниже. Проблема с рунаве часто начинается вне продуктовой команды и проявляется там позже.

Затем постройте инженерные расходы по строкам. Разделите зарплаты, комиссии подрядчиков, налоги, облако, софт, рекрутинг, оборудование и небольшой резерв в разные строки. Если одно число прыгает, вы должны увидеть причину за секунды.

Начните первый месяц с реальной наличности в банке, а не с ожидаемой выручки. Добавьте текущие ежемесячные расходы по категориям и посчитайте итог. Поместите каждый запланированный найм в месяц, когда он действительно начнётся, а не в месяц надежды. Добавляйте изменения в облаке и инструментах в тот месяц, когда они реально попадают в счёт. Затем вычислите конечную наличность для каждого месяца и отметьте первый месяц ниже вашей безопасной линии.

Временные рамки найма важнее, чем многие основатели думают. Если вы планируете нанять в мае, а рекрутинг обычно занимает шесть недель и ещё месяц на адаптацию, смоделируйте это задержание. То же относится к подрядчикам: если вы продлеваете их для сдвинутого релиза, впишите дополнительные расходы в тот месяц, когда они реально появятся.

Запустите три версии модели, чтобы сравнивать решения вместо споров о догадках: базовый сценарий, где найм и доставка идут примерно по плану; сценарий с медленными продажами, где выручка приходит позже; и сценарий с замедленной доставкой, где релизы сдвигаются, подрядчики остаются дольше или ещё один найм стартует раньше.

Выберите безопасную линию до того, как смотреть результат. 4–6 месяцев рунаве — распространённая зона предупреждения, но выберите число, которое соответствует вашему риску. Если таблица показывает пересечение линии в 8-м месяце, начинайте действовать в 5–6-м. Это даст время сократить верные статьи, вместо того чтобы замораживать найм в панике.

Простой пример для небольшого стартапа

Представьте стартап с $900,000 в банке и одной целью: сохранить 12 месяцев рунаве, продолжая при этом ежемесячно доставлять продукт.

Продуктовая команда рассчитана на пять мест, но заняты только четыре. Открытая позиция — senior инженер, которого основатель хочет закрыть быстро, потому что роадмап отстаёт.

Месячный бюджет выглядит так:

• Люди: $50,000 за 4 заполненных позиции, с учётом налогов и накладных подрядчиков
• Открытая senior позиция: $16,000 при заполнении
• Облако: $10,000, из которых около $3,000 — это простые базы, переразмеренные инстансы и старые preview-окружения
• Софт: $6,000, из которых примерно $2,000 уходит на перекрывающиеся инструменты для аналитики, мониторинга и AI-кода
• Резерв на риски доставки: $4,000 на кризисы релизов, багфиксы и внешнюю помощь

Без нового найма бёрн ~ $70,000 в месяц. Это даёт компании чуть меньше 13 месяцев. Напряжённо, но работоспособно.

Если заполнить senior позицию сейчас, бёрн растёт до $86,000. Рунаве падает до ~10.5 месяцев. Вот что основатели часто не замечают. Один сильный найм может ускорить команду, но может и толкнуть компанию ниже линии, где каждая задержка начинает мешать.

Чаще всего более прагматичный ход — скучный: убрать расточительность сначала.

Если команда уберёт $2,000 перекрытия инструментов и $3,000 избыточных облачных затрат, месячный бёрн упадёт примерно до $65,000 без изменения состава, кто строит продукт. Это даёт почти ещё один месяц запаса за год, при том скорость доставки останется примерно той же.

Теперь сравните это с сокращением строителя. Если основатель уволит одного инженера и сэкономит $12,000 в месяц, на бумаге рунаве улучшится сильнее, но релизы замедлятся, код-ревью встанет и баги накопятся. Маленькая команда ощутит это быстро.

Так что реальное решение не просто «нанять или резать». Вопрос в том, действительно ли стартап заблокирован отсутствием senior-скилла, или текущая команда может выпускать ещё один квартал после уборки расточительности. Во многих малых стартапах лучше заморозить найм senior, убрать лишнее и пересмотреть роадмап через 60 дней.

Ошибки основателей при сокращениях

Сокращение затрат красиво смотрится в таблице и мерзко в реальности. Основатели режут одну строку, радуются неделю, а потом платят за это задержками, багами или экстренным наймом. Самая дешёвая статья не всегда самая безопасная для урезания.

Обычная ошибка — сначала резать тестировщиков или поддержку платформы. На бумаге эти роли выглядят опосредованно. На практике они защищают скорость релизов. Если некому держать покрытие тестами, пайплайны сборки и инцидентный фоллоу‑ап, инженеры перестают строить продукт и начинают нянчить стек. Маленькая зарплатная экономия может превратиться в поздний релиз, отток и недели переделок.

Ещё плохой ход — заморозить найм после увольнения и назвать это экономией. Если уходит один инженер, роадмап не сжимается вместе с ним. Работа сваливается на оставшихся. Сроки сдвигаются, очереди поддержки растут, команда устает. Замена может казаться дорогой, но оставление реальной пробоины в маленькой команде почти всегда обходится дороже.

Проблема инструментов тише, но не менее опасна. Основатели сохраняют каждое приложение, потому что каждая месячная плата кажется маленькой. Один дизайнерский слот, один add-on мониторинга, одна дополнительная подписка репо, один забытый AI-инструмент — по отдельности ничего страшного. Вместе они едят серьёзную часть годового бюджета. Маленькие платежи заслуживают такого же ревью, как и зарплаты.

Перед сокращением проверьте четыре вещи: что остановится, если уйдёт этот человек или инструмент; какие условия контрактов останутся в силе после сокращения; сколько месяцев команда выдержит задержку; и действительно ли экономия — реальный отток наличности или просто желаемая арифметика.

Условия контрактов подводят команды постоянно. Выходные выплаты, сроки уведомлений, годовые обязательства по софту, минимумы агентств и зарезервированные облачные расходы не исчезают по желанию. Запланированное сокращение может вызвать единовременную выплату, которая ударит по рунаве сейчас, а не позже.

Худший вид бюджетного отрицания — это использование наилучших ожиданий по выручке, чтобы защищать текущие траты. Если вам нужно, чтобы каждая сделка закрывалась вовремя, ваш бюджет уже слишком тонкий. Используйте консервативные допущения по выручке и считайте upside просто upside. Это даёт пространство для спокойных решений вместо паники.

Бычная ежемесячная проверка перед изменением плана

Инженерный бюджет реален лишь тогда, когда он соответствует деньгам, вышедшим из банка. Раз в месяц ставьте рядом четыре числа: зарплаты, облако, софт и траты подрядчиков. Многие основатели останавливаются на зарплатах. Здесь начинаются плохие сокращения.

Используйте одну простую проверку кассы:

Начните с прошлого месяца, а не с плана. Если бюджет говорит, что инженерия потратила $48,000, а по банку вышло $55,000, пропишите разрыв по строкам. Маленькие расхождения важны, потому что они повторяются.

Перед заморозкой найма или сокращением роли проверьте базовые вещи:

• Сверьте бюджет с реальными оттоками за последние 30 дней.
• Проверьте, добавил ли новый найм или подрядчик платные места, устройства, CI-потребление или дополнительные окружения.
• Спросите, какой проект застопорится, если один человек уйдёт или заболеет завтра.
• Сначала урежьте расточительность: простаивающие облачные ресурсы и неиспользуемые места.
• Запишите эффект на рунаве от каждой открытой роли перед её утверждением.

Изменения в команде часто приносят скрытые затраты. Один инженер может добавить место в системе контроля версий, доступы к дизайн‑инструменту, рост объёма трекеров ошибок, staging‑базу и дополнительные минуты сборки. По отдельности эти вещи не кажутся страшными, но вместе они могут стереть неделю рунаве за пару месяцев.

Риск доставки тоже должен быть в проверке. Если один человек владеет деплоем, клиентским биллингом или процессом релиза мобильного приложения, ваш бюджет может выглядеть экономным, но риск доставки высок. Такой риск превращается в экстренные траты позже: подрядчик, пропущенный релиз или и то, и другое.

В большинстве случаев сначала вырезайте расточительность, а не мощность доставки. Отключите неиспользуемые превью‑окружения. Уберите неактивные места. Откажитесь от дублирующих инструментов. Очистите облачные инстансы, которых никто не касался неделями. Эти шаги снижают расходы, не замедляя работу над продуктом.

Открытые позиции требуют того же подхода. Не спрашивайте только «потянем ли мы эту зарплату?». Спросите, на сколько месяцев рунаве влияет полная стоимость роли после налогов, инструментов и настройки. Потом спросите, что сдвинется, если вы не наймёте. Если ответ «ничего срочного», держите роль открытой подольше и защищайте уже имеющуюся команду.

Что сделать в следующие две недели

Начните с таблицы, которая уже есть, даже если она грязная. Грубая модель, которую можно исправить сегодня, лучше красивой фантазии через месяц. Цель проста: убрать догадки, ранжировать затраты по влиянию и принять спокойные сокращения до того, как денежный стресс заставит вас принимать плохие решения.

Дни 1–5

Откройте бюджет и отнесите каждую строку к одной из четырёх корзин: люди, облако, софт и риск доставки. Если число — догадка, пометьте его. Если за стоимостью никто не отвечает, пометьте снова.

Потом быстро почистите таблицу:

• Замените диапазоны одним числом и короткой заметкой об источнике.
• Уберите дублирующие инструменты, старые подписки и «временные» сервисы, которые никогда не отключались.
• Разбейте расходы подрядчиков по реальной работе, а не одной общей сумме.
• Добавьте даты продлений, минимумы по контрактам и незавершённые планы найма.

Одна лишь эта очистка часто меняет картину. Основатели обычно режут разработчика из‑за видимой большой зарплаты, в то время как куча неиспользуемого софта и переразмеренное облако продолжает съедать деньги каждый месяц.

Дни 6–14

Теперь ранжируйте каждую роль и инструмент одним вопросом: что произойдёт с доставкой и выручкой в следующие 90 дней, если это убрать? Будьте честны. Некоторые расходы кажутся важными просто потому, что команда к ним привыкла — это не то же самое, что помогать компании выжить.

Используйте три ярлыка для каждого пункта:

• Keep (Оставить): защищает выручку, доставку или доверие клиентов сейчас.
• Pause (Приостановить): можно остановить на несколько месяцев без разрушения плана.
• Delay (Отложить): хочется иметь, но не до тех пор, пока рунаве не станет безопаснее.

Простой пример: если один senior инженер еженедельно закрывает клиентские проблемы, оставьте роль. Если платный инструмент экономит 5 минут и стоит несколько тысяч в год — приостановите. Если планируемый найм имеет смысл только после запуска — отложите его теперь, а не когда наличности станет мало.

К концу второй недели ваш инженерный бюджет должен уместиться на одной странице и показывать реальные компромиссы. Если нужен второй взгляд перед сокращениями, Oleg Sotnikov на oleg.is предлагает Fractional CTO advisory и может просмотреть модель, риски доставки и очевидные источники расточительности, прежде чем вы сделаете шаг, который придётся отменять позже.