Что будешь делать если времени до дедлайна не хватает?

Стратегия управления кризисом дедлайна в разработке на Unity

Когда дедлайны становятся нереалистичными, я применяю методологию, основанную на приоритизации, коммуникации и технической адаптации. Вот мой пошаговый алгоритм действий:

1. Немедленная прозрачная коммуникация

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

• Предоставляю объективную аналитику: «У нас осталось 40 часов, а на завершение физики движения персонажа требуется ~60 часов. Без корректировок мы рискуем получить нестабильный билд».
• Предлагаю варианты решений, а не просто сообщаю о проблеме:
  • Сдвиг дедлайна на X дней
  • Сокращение объема работ (см. пункт 2)
  • Усиление команды дополнительными ресурсами

2. Жесткая приоритизация и «обрезание» функционала

Я использую метод MoSCoW (Must have, Should have, Could have, Won't have) совместно с командой:

// Пример из практики: вместо полноценной системы диалогов
// на кризисный срок реализуем минимально рабочую версию

// БЫЛО (полноценная система):
// DialogueSystem.LoadBranchingTree(), DialogueSystem.SaveChoices(), etc.

// СТАЛО (минимальная версия):
public class CrisisDialogueSystem : MonoBehaviour
{
    [SerializeField] private string[] _linearDialogueLines;
    private int _currentLine;
    
    public void ShowNextLine()
    {
        if (_currentLine < _linearDialogueLines.Length)
        {
            UI_Manager.Instance.ShowDialogue(_linearDialogueLines[_currentLine++]);
        }
    }
}

Критерии приоритизации:

• Без чего игра не запустится? (Core gameplay loop)
• Что критично для первого впечатления? (Стабильность, основные механики)
• Что можно добавить пост-релизом? (Дополнительный контент, оптимизация)

3. Технические адаптации и «быстрые победы»

• Временные решения: Использую прототипные ассеты из Asset Store или простые примитивы вместо финальных моделей.
• Упрощение архитектуры: Откладываю рефакторинг, пишу более прямолинейный, но рабочий код с пометками // TODO: Refactor post-release.
• Фокус на стабильности: Отключаю необязательные системы (детальные статистики, сложные системы сохранений) в пользу минимально рабочего продукта.

4. Оптимизация рабочего процесса

• Убираю перфекционизм: «Работает → стабильно → красиво» — новый порядок приоритетов.
• Автоматизирую рутину: Быстро настраиваю Editor Scripts для массовых операций:

// Автоматизация проверки префабов перед билдом
#if UNITY_EDITOR
public static class PrefabCrisisValidator
{
    [MenuItem("Tools/Quick Validate Missing Components")]
    public static void ValidateScenePrefabs()
    {
        // Быстрая проверка на отсутствующие компоненты
        // вместо глубокого ревью каждой системы
    }
}
#endif

• Усиливаю тестирование: Внедряю smoke-тесты для проверки самых критичных путей (запуск уровня, основная механика, сохранение).

5. Пост-кризисный анализ и предотвращение

После сдачи проекта (даже в урезанном виде) я обязательно провожу ретроспективу:

• Что привело к нехватке времени? (неадекватная оценка, changing requirements, технические долги)
• Какие временные решения стали постоянными и требуют рефакторинга?
• Как улучшить процесс оценки на будущее?

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