Финансовый отчет игровой студии: 5 шагов для быстрой проверки бюджета
70–80% бюджета игровой студии обычно расходуется на фонд оплаты труда и персонал. Платформы дистрибуции добавляют базовую комиссию 30% от поступлений, а маркетинг в современных инди-релизах способен занять до половины бюджета проекта.
Эти показатели имеют разные знаменатели: 30% считаются от выручки, тогда как доля маркетинга — от сметы. Смешивать их нельзя, иначе рентабельность проекта искажается на первом же листе отчетности.
Финансовый отчет студии собирается из пяти расчетных блоков. Каждый следующий зависит от предыдущего: ошибка в ФОТ искажает variance analysis, незафиксированный перерасход сокращает Runway, а пост-продакшн часто обнаруживается слишком поздно.
| Этап | Основной расчетный вопрос | Выход анализа |
|---|---|---|
| 1. Аудит ФОТ | Сколько стоит один человеко-месяц разработки? | Полная стоимость команды по проектам |
| 2. Variance Analysis | Сколько бюджет потеряет проект к завершению? | Forecast at completion и перечень перерасхода |
| 3. Net Burn и Runway | Сколько месяцев студия может финансировать текущую траекторию? | Календарь ликвидности и порог переговоров |
| 4. Пост-продакшн | Какие расходы появятся после основной разработки? | Скорректированный P&L и cash flow |
| 5. Стоимость задержки | Что будет стоить каждый месяц без релиза? | Сценарии задержки, сокращения и финансирования |
1. Аудит фонда оплаты труда и ключевые затраты на персонал студии
ФОТ — главный драйвер расходов студии и одновременно главный драйвер сроков. Один дополнительный месяц разработки не создаёт равномерную нагрузку на бюджет: он продлевает аренду рабочих мест, расходы на инфраструктуру, закупку оборудования, QA, локализацию и маркетинговый цикл.
Что включать в полную стоимость персонала
В финансовом отчете ФОТ шире списка зарплат программистов. Для полного анализа потребуются:
- базовые заработные платы и обязательные начисления на фонд;
- бонусы, привязанные к milestones, и оплата переработок;
- контрактные разработчики, артщики, аналитики и внешние тестировщики;
- рекрутинг, релокация, обучение и другие расходы, связанные с наймом;
- неоплачиваемые, но занятые сотрудниками месяцы;
- начисленные бонусы и обязательства, которые ещё не выплачены.
Devkit, лицензии на движки и middleware, серверы и подписки на облачную инфраструктуру имеют отдельный учёт. При смешивании с ФОТ теряется их капитальный или операционный характер, а задержка релиза начинает выглядеть дороже фактической стоимости команды.
Dev-month как единица сравнения
Dev-month показывает полную стоимость одного специалиста, занятого проектом в течение месяца. Единого норматива для индустрии нет: доступный диапазон оценки составляет примерно $2 000–$15 000+ в месяц в зависимости от страны, роли, квалификации и состава нагрузки. Это ориентир для сравнения; фиксированной ставки по отрасли не существует.
Расчёт удобнее вести через полные ставки эквивалента:
- один разработчик на проекте полный месяц — один dev-month;
- половина загрузки в течение двух месяцев — один dev-month;
- два сотрудника с разными ставками — два dev-month с разной полной стоимостью.
Такой подход отделяет численность headcount от фактической загрузки. Студия с десятью сотрудниками в календарном месяце может списать на проект шесть dev-month, если остальные занимались препродакшном, внутренними инструментами или поддержкой другого продукта.
Что должен показать аудит ФОТ
Полноценный аудит даёт четыре результата:
1. Фактическую полную стоимость каждого dev-month по направлениям и проектам.
2. Разницу между плановым и фактическим количеством человеко-месяцев.
3. Долю незагруженного или перераспределённого ресурса.
4. Соотношение штатных сотрудников, подрядчиков и внутренних переводов между проектами.
Отдельно проверяется, не скрывает ли сокращение штатного состава рост расходов на фрилансеров. Число FTE может упасть, а пропускная способность команды и общий ФОТ — вырасти.
Рентабельность проекта определяется полной стоимостью человеко-месяцев, а не количеством людей в презентации команды.
2. Сопоставление плановых смет и фактических расходов в геймдеве
Variance Analysis показывает, где именно проект теряет исходную экономику. Её проводят ежемесячно, пока расхождение ещё можно устранить перераспределением ресурсов. Ретроспективный разбор после завершения проекта фиксирует ошибку, но не защищает рентабельность.
Три слоя расходов
Финансовый контроль требует разделять три состояния затрат:
- Фактически оплачено. Деньги уже списаны со счетов студии.
- Принято обязательство. Контракт подписан, счёт выставлен или сотрудник отработал период, который будет оплачен.
- Прогноз незавершённых работ. Оставшаяся часть проекта оценивается по текущей модели трудозатрат и ставок.
Прогноз стоимости на завершение рассчитывается как сумма фактических расходов и прогноза незавершённых работ. Положительное отклонение от базовой сметы означает перерасход. Здесь нужен именно прогноз, поскольку текущие расходы сами по себе показывают лишь пройденную часть проекта.
Отклонения требуют разной реакции
Перерасход возникает из трёх источников:
1. Сдвиг сроков. Работа перенесена на следующий месяц, но общий объём остался прежним. Финансовая модель временно ухудшается, однако базовая стоимость проекта сохраняется.
2. Рост объёма работ. Добавлены механики, уровни, анимация, режимы, рейтинговые функции или серверные возможности. Это scope creep, permanently увеличивающий смету.
3. Рост удельной стоимости. Изменились ставки подрядчиков, структура команды, локализация, объём тестирования или стоимость лицензий.
Каждое изменение объёма проходит через журнал change request. В нём фиксируются влияние на бюджет, сроки, архитектуру production pipeline и предполагаемый эффект на продажи. Изменение без владельца, срока и финансовой оценки превращается в неуправляемый рост стоимости человеко-месяца.
Базовая смета должна оставаться неизменной
В рабочем финансовом отчете нужны три версии цифр:
- первоначально утверждённая смета;
- текущий прогноз на завершение;
- перечень формально согласованных изменений.
Если текущий прогноз каждый месяц записывается поверх исходной сметы, variance analysis теряет аналитическую функцию. Любое отклонение начинает выглядеть частью плана. Финансовый контроль требует сохранять исходную точку отсчёта и показывать, кто именно изменил экономику проекта.
Отдельно сверяются P&L variance и cash variance. Доход может быть признан в отчете, тогда как деньги поступят после релиза. Для Runway второй показатель важнее.
Замена базовой сметы текущим прогнозом превращает variance analysis в фиксацию post factum.
Тревожные сигналы выглядят достаточно конкретно:
- прогноз стоимости растёт, хотя список задач и milestones не менялся;
- рост расходов на разработку компенсируется сокращением маркетингового бюджета, хотя дата релиза не изменилась;
- число штатных сотрудников падает, а расходы на подрядчиков растут;
- оценочные резервы используются без отдельного изменения сметы;
- прогноз продаж повышается без подтверждения новых контрактов или данных о предзаказах;
- задержка QA и сертификации появляется в cash flow, но отсутствует в основном плане.
3. Расчёт чистого темпа сжигания средств и запаса Runway
Runway показывает, сколько времени студия способна финансировать текущую траекторию. Этот показатель часто рассчитывают с ошибкой: берут остаток денежных средств и делят его на валовые расходы, хотя у студии есть регулярные поступления от прошлых проектов или контрактов.
Net Burn вместо валовой нагрузки
Валовые денежные расходы показывают общий уровень потребления капитала. Для расчёта Runway используется Net Burn Rate = валовые расходы − поступления от проектов и контрактов.
Если поступления стабильны, деление остатка доступных денежных средств на ежемесячный Net Burn Rate даёт количество месяцев финансовой устойчивости. При нерегулярных выплатах средний показатель искажает риск. Тогда строятся отдельные сценарии по датам контрактов, релизам, платежам издателя и поступлениям после возвратов.
Если Net Burn Rate равен нулю или отрицателен, конечного Runway в такой формуле нет. Тогда аналитик проверяет ежемесячный остаток денежных средств, календарь обязательств, доступный кредитный буфер и зависимость cash flow от отдельных платежей.
Runway требует сценариев, а не одного числа
| Сценарий | Поступления | Расходы | Управленческий вопрос |
|---|---|---|---|
| Базовый | Текущие контракты и плановые поступления | Сметы по утверждённым milestones | Какой срок покрывает текущий план? |
| Стрессовый | Задержка релизных поступлений, рост возвратов | Дополнительные QA-итерации и задержка маркетинга | Когда cash flow опускается ниже критического порога? |
| Финансирование | Новый раунд или контракт с издателем | Текущие обязательства плюс условия сделки | Успевает ли финансирование закрыться до сокращения Runway? |
Доступный остаток денежных средств и Runway нужно обновлять вместе с выплатами. В расчёт попадают фактически доступные деньги. Restricted cash, привязанный к конкретным обязательствам, требует отдельной оценки ликвидности.
Когда начинать переговоры
Привлечение нового раунда финансирования или подписание контракта с издателем обычно занимает 3–6 месяцев. Поэтому переговоры стоит начинать, пока Runway составляет не менее 6–9 месяцев. Этот порог служит управленческим триггером: он оставляет время на согласование условий, юридическую подготовку и закрытие сделки.
Runway нельзя привязывать к дате релиза без резерва. Платёж может задержаться, а часть расходов уже станет необратимой. Финансовый план обязан учитывать резерв на обязательства по заработной плате, аренде, локализацию, QA, маркетинг и экстренные production-итерации.
4. Контроль скрытых пост-продакшн расходов и комиссий платформ
Финальная смета разработки часто выглядит законченной до появления продаж. Затем добавляются локализация, сертификация, продвижение, платформенные комиссии, возвраты и поддержка. Эти статьи способны изменить юнит-экономику проекта после завершения основного production.
| Статья | База расчёта | Что контролировать |
|---|---|---|
| Локализация | Объём текстов, UI, субтитров, store pages и поддержки | Число языков, итераций перевода, QA локализованной версии |
| QA и сертификация | Количество сборок, платформ и проверяемых релизов | Regression после каждого крупного изменения, cost of late certification |
| Маркетинг и продвижение | Доля бюджета проекта, способная достигать 50% в современных инди-релизах | Канал, дату запуска, обязательства перед агентствами и платформами |
| Комиссия платформы | Базовая ставка 30% для Steam и консолей в P&L | Расчёт от поступлений и переход к net receipts |
| Возвраты | В финмоделях обычно закладывается диапазон 5–12%; единой нормы по жанрам нет | Сценарии возвратов и их влияние на Net Burn |
| Софт и инфраструктура | Движки, middleware, CI, облако, devkits, серверы | Лицензии, облачные начисления, загрузка оборудования |
| Поддержка и patches | Количество итераций после релиза | Границы поддержки, стоимость hotfix и продление production-команды |
Комиссия платформ, возвраты и маркетинг живут в разных контурах P&L. Комиссия уменьшает поступления, возвраты снижают net revenue, а маркетинг и локализация формируют денежные расходы. Сложение этих долей в одну строку даёт искажённую рентабельность.
Собственная инфраструктура создаёт скрытый OpEx
Покупка GPU-серверов и мощных рабочих станций выглядит капитальной статьёй. Эксплуатация переносит расходы в электричество, охлаждение, обслуживание и резервирование. TDP помогает оценить power envelope, но реальная нагрузка зависит от загрузки GPU, конфигурации стенда и графика рендера.
Для сборочной фермы важна пропускная способность: объём параллельных сборок, время ожидания и загрузка конвейера. Простаивающее оборудование сохраняет CapEx, но резервирует мощность, электричество и место без отдачи. При росте команды этот эффект легко превращается в дополнительные ночные сборочные линии, подрядчиков и сорванные milestones.
Тот же принцип раздельного учёта действует за пределами геймдева. Реконструкция исторического квартала архитектурной практикой также требует самостоятельных смет для архитектурного, инженерного и отделочного контуров. В геймдеве аналогично отделяются production, localization, QA, marketing и post-launch support. Общая строка «прочие расходы» скрывает источник убытка.
5. Оценка стоимости человеко-месяца и рисков задержки релиза
Издатели и инвестиционные фонды оценивают разработку через dev-month. Эта метрика связывает трудозатраты с задержкой: если релиз сдвигается, команда продолжает сжигать бюджет, а партнёрский milestone и поступления смещаются.
Как посчитать cost of delay
Прямая стоимость задержки определяется по двум составляющим:
- числу затронутых dev-month;
- полной стоимости каждого dev-month.
В расчёт входят только роли, работа которых остаётся оплачиваемой во время задержки. Часть команды может параллельно переключиться на другой проект. Тогда полный размер команды используется для оценки cash flow студии, а cost of delay конкретного релиза считается по критическому пути.
К прямым затратам добавляются:
- сохранение аренды и внутренней инфраструктуры;
- продление лицензий и подписок;
- дополнительные QA-циклы;
- перенос маркетинговых обязательств;
- задержка поступлений от издателя или платформы;
- изменение стоимости финансирования.
Потерянная выручка не является расходом проекта, однако она сокращает Runway и меняет рентабельность инвестиций. Её следует показывать отдельно.
Три сценария управления задержкой
1. Сохранить объём и сдвинуть дату. Подходит, когда критический путь проходит через крупный передел, рынок остаётся доступным, а Runway покрывает новый график. Проверяются фиксированные обязательства, изменение campaign window и новые платежные даты.
2. Сократить scope. Удалённые функции должны уменьшать dev-month, QA, локализацию и post-launch support. Экономия на разработке часто компенсируется маркетинговыми расходами, поэтому сокращение content pipeline оценивается в полном P&L.
3. Привлечь финансирование или нового издателя. Договор закрывается в среднем за 3–6 месяцев, поэтому переговоры начинаются при Runway 6–9 месяцев. Контракт сравнивается по milestone-платежам, правам на интеллектуальную собственность, маркетинговым обязательствам и чистой рентабельности.
Выбор сценария определяется не размером запаса денежных средств. Сравниваются срок выхода на релиз, стоимость каждого дополнительного месяца, влияние на продажи, доступное финансирование и устойчивость cash flow.
Финальная позиция
Финансовый отчет игровой студии начинается с полной стоимости человеко-месяцев, продолжается variance analysis и заканчивается связкой Net Burn Rate, Runway и cost of delay. Эти показатели дают управленческий ответ на главный вопрос: позволяет ли текущая экономика проекта довести студию до релиза без потери рентабельности.
Главный сигнал риска возникает, когда прогноз стоимости на завершение растёт одновременно с сокращением Runway. Два показателя требуют немедленного пересмотра scope, даты или структуры финансирования. Универсального сценария нет; рентабельность определяется дисциплинированностью отчётности и скоростью, с которой студия переводит отклонения в управленческие решения.
