Почему игровые проекты срывают сроки

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

ПРИЧИНА 01Оценить можно задачу, но не «стало ли весело»

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

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

Планировать нужно не «сделать весело», а количество попыток, которое команда может себе позволить.

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

ПРИЧИНА 02Сначала собирают всё по частям, а играть нечего

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

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

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

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

ПРИЧИНА 03Двигают дату, хотя двигать надо объём

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

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

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

ПРИЧИНА 04Непонятно, кто принимает решение

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

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

Невынесенное решение стоит дороже, чем неидеальное.

ПРИЧИНА 05Тестирование задвинуто в конец

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

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

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

ПРИЧИНА 06Релиз считают финишем

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

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

Короткий чек-лист

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

Ни один из пунктов не гарантирует, что проект выйдет в срок. Но каждый убирает одну из причин, по которым сроки разъезжаются предсказуемо и повторяемо — из проекта в проект.