Сколько оказывается неучтенных наработок при реализации после Preprod?

Анализ неучтённых наработок после Preprod

Количество неучтённых наработок после этапа Preprod — это критический показатель зрелости процессов разработки и планирования. В идеально управляемом проекте их должно быть ноль, но на практике они возникают всегда. Их объём может варьироваться от 5% до 30% и более от общего бюджета разработки, в зависимости от факторов, о которых я расскажу ниже.

Ключевые категории неучтённых работ

Вот основные типы задач, которые чаще всего «всплывают» после Preprod:

• Технический долг и рефакторинг: В погоне за демо на Preprod часто используют быстрые, но неоптимальные решения.
• Внезапные требования к производительности: В Preprod тестируют на малом количестве устройств. После начинается оптимизация под целевые минимальные характеристики.
• Системные и интеграционные баги: Баги, связанные с сохранениями, сетевым кодом, взаимодействием систем, проявляются при полноценной сборке.
• Доработка контента под финальную сборку: Адаптация анимаций, эффектов, звуков и уровней под итоговую оптимизацию и стабильность.
• Работа с обратной связью: Ключевые изменения по фидбэку от фокус-групп, издателя или внутреннего тестирования.

Ключевые факторы, влияющие на объём работ

Объём этих работ напрямую зависит от трёх основных факторов:

1. Качество и глубина Preprod-этапа:

    *   Была ли собрана **вертикальный срез** (vertical slice), отражающий финальное качество?
    *   Проводилось ли **стресс-тестирование** на целевых устройствах?
    *   Были ли прототипированы и проверены **критические игровые циклы**?

1. Культура разработки и процессы:

    *   Используется ли **Continuous Integration** с автоматическим прогоном тестов?
    *   Ведётся ли **активный учёт технического долга** и есть ли на него резерв?
    *   Существует ли чёткий **Definition of Done** для задач на Preprod?

1. Человеческий фактор и коммуникация:

    *   Насколько команда **дисциплинированно документирует** возникающие проблемы?
    *   Есть ли понимание, что **Preprod — это не прототип, а этап подготовки к производству**?

Технический пример: Внезапная оптимизация

Рассмотрим классическую ситуацию: в Preprod объекты на сцене уничтожались через Destroy(). В финальной сборке с большим количеством объектов это привело к просадкам FPS из-за сборки мусора. Появляется неучтённая задача по внедрению пулинга.

// Быстрое решение на Preprod (создаёт нагрузку GC)
public class Projectile : MonoBehaviour
{
    void OnCollisionEnter()
    {
        Destroy(gameObject); // Каждый вызов - потенциальная просадка
    }
}

// Оптимизированное решение после Preprod (использует пул)
public class Projectile : MonoBehaviour
{
    public void ReturnToPool()
    {
        gameObject.SetActive(false);
        // Возврат в пул для повторного использования
    }

    void OnCollisionEnter()
    {
        ReturnToPool(); // Избегаем аллокаций и вызовов Destroy
    }
}

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

Как минимизировать риски?

Чтобы свести неучтённые работы к минимуму (5-10%), необходимо:

• Выделять в Preprod время на задел под оптимизацию (архитектура систем, план пулинга).
• Проводить регулярные перфоманс-ревью на целевых платформах.
• Резервировать буфер времени (15-20%) в плане после Preprod именно на такие доработки.
• Формализовать критерии выхода из Preprod, включая стабильность и производительность.

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