Мини-бюджет спринта: сколько стоит одна итерация разработки

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

Что такое мини-бюджет спринта

Мини-бюджет спринта — это сумма, необходимая, чтобы завершить одну короткую итерацию разработки с понятным, измеримым результатом: например, сделать боевую механику, собрать прототип локации, довести UI до рабочего состояния или подготовить вертикальный срез. Для инди-команды это гораздо полезнее, чем пытаться планировать «бюджет на игру вообще». На ранних этапах почти всегда есть неизвестные, и именно спринт показывает реальную цену производства. Мы в студии пришли к этому через боль: когда пытались оценить весь проект целиком, постоянно промахивались в 2-3 раза. А когда разбили на двухнедельные итерации, стало видно, куда уходят часы и деньги.

Что входит в спринт

Обычно в одну итерацию мы закладываем:

• работу программиста;
• работу геймдизайнера;
• арт или анимацию;
• звук;
• тестирование;
• софт и сервисы;
• резерв на правки и переделки.

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

Почему считать нужно не месяцы, а итерации

Месячный бюджет удобен для бухгалтерии, но плохо помогает в разработке. В игре нельзя честно сказать: «в этом месяце делаем всё». Гораздо реалистичнее ответить на вопрос: что именно будет готово через 1–2 недели и сколько это стоит. Такой подход даёт три преимущества:

• проще контролировать расход денег;
• легче резать scope без паники;
• быстрее видно, какие задачи дают результат, а какие только съедают время.

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

Из чего складывается стоимость одной итерации

1. Человеческое время

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

2. Внешние подрядчики

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

3. Инструменты и подписки

Даже маленький спринт часто требует платных сервисов:

• движок и плагины;
• графические редакторы;
• инструменты для анимации;
• аудиоредакторы;
• bug tracker;
• облако для сборок;
• сервисы для плейтестов.

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

4. Тестирование и доработка

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

• баги;
• конфликт с уже готовыми системами;
• изменения UI;
• балансные правки;
• повторные проверки.

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

Пример расчета мини-бюджета спринта

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

Если упростить, то именно резерв часто спасает бюджет. Без него спринт почти всегда «дожирается» в минус.

Как считать стоимость спринта на практике

Шаг 1. Зафиксируйте результат

Не «доделать бой», а, например:

• добавить ближнюю атаку;
• настроить анимацию попадания;
• сделать базовый UI здоровья;
• проверить 10 минут стабильной игры без критических багов.

Чем точнее формулировка, тем честнее оценка. Мы часто ловили себя на том, что под «доделать бой» скрывалось ещё пять подзадач, которые всплывали только к концу спринта.

Шаг 2. Разбейте результат на подзадачи

У каждой подзадачи должны быть:

• исполнитель;
• время;
• зависимость от других задач;
• критерий готовности.

Я обычно рисую простую схему на доске или в Miro, чтобы видеть, где задачи блокируют друг друга.

Шаг 3. Назначьте цену часа или вилку

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

Шаг 4. Добавьте коэффициент неопределенности

Для новых механик разумно закладывать запас:

• 10–15% — если задача типовая;
• 20–30% — если это новая система;
• 30% и выше — если есть риск переработки архитектуры.

Я обычно добавляю коэффициент 1,2 к любой задаче, с которой раньше не работал, и это спасало не раз.

Шаг 5. Проверьте, не скрыта ли в задаче еще одна задача

Очень частая ловушка: кажется, что вы делаете одну фичу, а на деле нужно ещё:

• обновить интерфейс;
• подправить анимации;
• изменить обучение;
• переработать сохранения;
• адаптировать под геймпад или мобайл.

Проверяйте каждую задачу на скрытые зависимости — это сэкономит вам кучу времени.

Типовые ошибки при планировании мини-бюджета

По моему опыту, вот что чаще всего приводит к перерасходу:

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

Что дешевле: делать самим или отдавать подрядчику

Единого ответа нет. В инди-проекте дешевле не всегда означает выгоднее.

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

Мини-чек-лист перед стартом спринта

Перед каждым спринтом я прохожусь по этому чек-листу. Он не раз спасал от неожиданных сюрпризов:

• Есть четкий результат спринта.
• Все задачи разбиты на подзадачи.
• У каждой задачи есть исполнитель.
• Время оценено в часах.
• Учтен тестовый прогон.
• Есть резерв 15–20%.
• Понятно, что можно выкинуть при перерасходе.
• Зафиксированы критерии готовности.

Когда бюджет итерации начинает расти

Бюджет спринта обычно увеличивается не из-за одной «дорогой фичи», а из-за накопления мелочей. Тревожные признаки:

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

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

Практическая формула для оценки

Удобная базовая схема выглядит так:

Мини-бюджет спринта = сумма часов по задачам × ставка + софт + тестирование + резерв

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

Вывод

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

FAQ

Сколько резервировать на неожиданные расходы?

Обычно 15–20% от стоимости спринта. Для новых или рискованных задач лучше больше. Я для экспериментов всегда закладываю 30% — лучше пусть останется, чем не хватит.

Что считать самым дорогим в итерации?

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

Можно ли считать спринт только по деньгам подрядчиков?

Можно, но это даст искажённый результат. Внутреннее время тоже имеет цену, и если его не учитывать, вы рискуете обнаружить, что «бесплатная» работа на самом деле съела ресурсы, которые можно было потратить на что-то более важное.

Сколько длится типичный мини-спринт?

Чаще всего 1–2 недели. Для инди-проекта этого достаточно, чтобы проверить одну гипотезу или одну игровую систему. Длиннее — теряется фокус, короче — не успеваешь получить значимый результат.

Что делать, если бюджет спринта начал расти?

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