# Инженерные бюджетные категории для основных расходов и чрезвычайных ситуаций

> Инженерные бюджетные категории разделяют постоянную ответственность, специализированные проекты и резервы на инциденты, чтобы стартапы могли финансировать поставку без сокрытия операционного риска.

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

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

Вместо этого разделите расходы на три категории: **основные**, **переменные** и **резерв на чрезвычайные ситуации**. Основные расходы оплачивают регулярную ответственность. Переменная категория финансирует нерегулярную экспертизу и проекты с ограниченным объёмом. Резерв нужен для восстановления сервиса, когда обычные планы не сработали. Категории звучат просто. Честно применять их сложнее, потому что многие инженерные расходы выглядят временными до того момента, когда внезапно становятся постоянными.

Я видел команды, которые называли работу старшего подрядчика краткосрочным расходом в течение восемнадцати месяцев, считали дежурства «просто частью работы» и оплачивали из бюджета на выпуск исправление сбоя, вызванного системой, которую никто не успевал сопровождать. Это не особенности бухгалтерского учёта. Так компании скрывают операционный риск.

## Основные расходы оплачивают незаменимую ответственность

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

Отнесите расход к основным, если верны все три утверждения:

- Работа повторяется каждый месяц, квартал или цикл выпуска.
- Для принятия решений, а не механического следования инструкции, человеку нужен достаточный контекст системы.
- Если работа остановится, компания столкнётся с существенным риском.

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

Фраза «регулярная ответственность» важнее, чем «штатный сотрудник». Человек может работать один день в неделю и при этом владеть продакшен-системой. Другой может трудиться полный день над шестинедельной миграцией и ничего не отвечать после передачи результата. Категория определяется обязательством, а не форматом трудовых отношений.

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

Именно здесь основатели часто занижают стоимость. Они закладывают разработчика, который пишет функции, но забывают о времени на проверку pull request, исправление сбоев развёртывания, обновление зависимостей, проверку доступа, реакцию на уведомления и решение о том, создаёт ли запрос клиента неприемлемый технический долг. Эти обязанности не исчезают, если их нет в дорожной карте. Они накапливаются у самого ответственного инженера, пока тот не превращается в незаметную единственную точку отказа.

### Назначьте владельца для каждой основной статьи

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

Базовая таблица основных расходов может выглядеть так:

| Основная статья | Ежемесячная стоимость | Ответственный владелец | Что перестанет работать после удаления? |
|---|---:|---|---|
| Ресурс на разработку продукта | $X | Руководитель инженерной команды | Разработка и сопровождение замедлятся или остановятся |
| Продакшен-хостинг и сервисы данных | $X | Владелец платформы | Обслуживание клиентов станет ненадёжным |
| Мониторинг и инструменты для инцидентов | $X | Ответственный за дежурства | Сбои будут длиться дольше, а диагностика ухудшится |
| Контроль исходного кода и конвейер поставки | $X | Руководитель инженерной команды | Изменения станут небезопасными или ручными |
| Резервные копии и проверки восстановления | $X | Владелец данных | Потеря данных может стать необратимой |

Используйте собственные цифры. Важнее всего последние два столбца. Если у расхода нет владельца, у вас, вероятно, есть затрата, а не операционная способность. Если никто не может описать последствия его удаления, возможно, вы платите за удобство и не осознаёте этого.

## Переменные расходы покупают результат, а не заимствованный ресурс

Переменная категория финансирует важную, но нерегулярную работу: специализированные проверки, проекты с ограниченным сроком, временные пики нагрузки, миграции, независимое тестирование или экспертизу, которая не нужна компании каждую неделю.

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

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

Плохие переменные задачи звучат так:

- «Нам нужен опытный человек, который будет присматривать за бэкендом».
- «Поможете с DevOps, пока мы не вырастем?»
- «Нам нужны дополнительные инженеры, потому что дорожная карта перегружена».
- «Пожалуйста, отвечайте за надёжность какое-то время».

Эти запросы описывают постоянные обязанности. Название «проект» не делает их временными. Компании нужен основной владелец или ей нужно уменьшить масштаб системы до уровня, который может поддерживать существующая команда.

### Определите точку завершения до утверждения счёта

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

Например:

```text
Engagement: Production database performance review
Outcome: Identify and fix the causes of checkout latency under expected load
Internal owner: Engineering lead
Deadline: June release window
Spending ceiling: $X
Acceptance condition: Load test results, changed query plan, rollback notes,
and a documented operating threshold handed to the internal owner
```

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

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

## Резерв на чрезвычайные ситуации нужно защищать от давления дорожной карты

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

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

Обычно это снова приводит к сокращению обслуживания. Следующий инцидент становится вероятнее.

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

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

### Рассчитайте резерв по правдоподобной тяжёлой неделе

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

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

Этот сценарий даёт исходную цель для резерва. Он может не покрыть событие, способное уничтожить компанию. Но он должен покрывать болезненный, хотя и правдоподобный инцидент без панических финансовых решений.

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

## Одинаковый риск может скрываться в зарплате, договоре и инструменте

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

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

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

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

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

## Расчёт времени работы компании должен учитывать системы, которые вы уже обещали поддерживать

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

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

Используйте таблицу со следующими входными данными:

```text
Monthly core engineering cost      = C
Planned variable work this quarter = V
Emergency reserve balance          = R
Cash available for operations      = K
Non-engineering monthly burn       = N

Normal monthly burn                = C + N + (V / 3)
Stressed first-month burn          = C + N + R
Normal runway in months            = K / normal monthly burn
```

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

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

В AppMaster.io сокращение операционной команды с 25 человек до двух инженеров с поддержкой AI потребовало гораздо большего, чем просьба к меньшей команде печатать быстрее. Работу пришлось разделить на повторяемую ответственность за продакшен, автоматизацию с ограниченным объёмом и исключения, где по-прежнему требовалась опытная оценка. То же упражнение по сортировке нужен стартапу, прежде чем заявлять, что AI снизил инженерные расходы.

## AI снижает часть расходов на продакшен и быстрее выявляет слабую ответственность

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

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

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

Не закладывайте бюджет на основании гипотетических заявлений о продуктивности. Измеряйте собственную систему поставки. Отслеживайте время от утверждения изменения до его попадания в продакшен, нагрузку на старших инженеров при проверке, дефекты, прошедшие в продакшен, частоту откатов и объём работы, который возвращается из-за ошибочной первой реализации. Если инструмент сокращает время написания кода, но вдвое увеличивает время проверки, ваши расходы не уменьшились.

Популярная рекомендация «заменить команду на AI» не работает, потому что считает единственным ограничением объём результата. Компании, создающей продукт, также нужны память о системе, полномочия во время инцидентов, оценка качества и человек, который может сказать «нет» изменению, выглядящему убедительно на демонстрации, но опасному в продакшене.

## Пересмотр бюджета должен открыто показывать изменения категорий

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

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

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

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

1. Какие переменные статьи повторялись достаточно часто, чтобы считать их регулярной ответственностью?
2. У каких основных статей нет назначенного владельца или актуального описания последствий отказа?
3. Использовали ли мы деньги из резерва и выявил ли инцидент постоянную обязанность?
4. Какие запланированные обязательства предполагают инженерную мощность, которую мы не профинансировали?
5. От чего мы откажемся или что перенесём, если стрессовый расчёт запаса станет реальностью уже в следующем месяце?

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

## Проблема начинается с бюджета, который выглядит эффективным

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

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

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

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

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

## Начните с обязательств, которые уже создал ваш продукт

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

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

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

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