Пять признаков того, что проект столкнётся с проблемами через месяц

Признак №1. Backlog перестал быть картой проекта

Хороший backlog отвечает не только на вопрос «что команда делает сейчас».

По нему должно быть понятно:

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

Если для понимания состояния проекта нужно отдельно спрашивать нескольких lead-разработчиков, продюсера и game designer, backlog уже перестал выполнять свою функцию.

Особенно опасны задачи вроде:

Доделать инвентарь

Поправить управление

Оптимизировать уровень

Подготовить мультиплеер

Такие формулировки нельзя нормально оценить и практически невозможно принять.

Намного полезнее, когда задача имеет конкретный проверяемый результат.

Например:

После reconnect игрок получает актуальное содержимое инвентаря с сервера без дублирования предметов.

Или:

На минимальной конфигурации тестовая сцена держит установленный frame-time budget.

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

Если acceptance criteria существуют только в голове автора постановки, задача ещё не готова к работе.

Что проверить

Возьмите ближайший milestone и попробуйте ответить по backlog:

Какой конкретно билд команда собирается показать через две недели?

Если ответ получается только после встречи на час, это уже сигнал риска.

Дальше проверьте:

• есть ли owner у каждой критической зоны;
• обозначены ли зависимости;
• существуют ли definition of done;
• отделены ли обязательные задачи от желательных;
• понятно ли, что команда выкинет первым при сокращении срока.

Главный принцип: сначала сделать риск видимым, затем принимать решение о сроке, scope и составе.

Признак №2. Стабильная сборка появляется только перед демо

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

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

В отдельных ветках всё может работать.

Но после интеграции оказывается, что:

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

Чем дольше такие проблемы остаются незаметными, тем дороже становится их исправление.

Рабочая ветка должна регулярно превращаться в проверяемый билд.

Не обязательно каждый такой билд отдавать внешнему пользователю. Достаточно, чтобы CI мог воспроизводимо его собрать, а основные сценарии проходили минимальный smoke-test.

Если сама сборка постепенно становится слишком долгой и нестабильной, это уже отдельная зона риска. В таком случае стоит разбирать, где именно теряется время в build pipeline, а не воспринимать двадцатиминутное или часовой ожидание как неизбежную особенность большого проекта.

Минимальный контроль

Для активного production полезно иметь:

• автоматическое создание сборок;
• идентификатор версии и commit;
• smoke-test критических пользовательских сценариев;
• список известных blockers;
• историю успешных и неуспешных builds;
• ответственного за состояние основной ветки.

При этом «CI зелёный» ещё не означает «игра работает».

Автоматическая сборка подтверждает, что проект собирается. Проверяемый playable build подтверждает, что результат разработки действительно существует как продукт.

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

Признак №3. Сроки называют без допущений

Фраза:

Это займёт две недели

выглядит гораздо увереннее, чем:

Это займёт примерно две недели, если backend API останется без изменений и не потребуется переделывать систему сохранений.

Но второй вариант намного полезнее для управления проектом.

Оценка без допущений создаёт ложную точность.

Особенно если задача зависит от:

• неизвестного API;
• внешнего подрядчика;
• новой платформы;
• чужой системы;
• ещё не утверждённого дизайна;
• производительности;
• результатов прототипирования;
• стороннего SDK.

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

Хорошая оценка показывает не одну красивую дату, а диапазон и условия.

Например:

Оптимистично: 7 рабочих дней.

Реалистично: 10–12.

Риск: ещё 5 дней, если потребуется миграция текущих данных.

Теперь producer может принимать решение.

Например:

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

Одна из функций нормального production-процесса — не обещать, что рисков не существует, а показывать их достаточно рано, чтобы у команды оставался выбор.

Признак №4. Критическая система держится на одном человеке

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

Само по себе это нормально.

Проблема начинается, когда без конкретного человека команда не может:

• собрать проект;
• выпустить сервер;
• изменить экономику;
• обновить Addressables;
• починить multiplayer;
• сделать console build;
• разобраться в сохранениях;
• обновить определённый pipeline.

Если специалист недоступен несколько дней и целое направление останавливается, это уже не просто экспертность, а bus factor.

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

В этот момент выясняется, что архитектурные решения нигде не описаны, инструкции устарели, deployment существует в виде набора локальных скриптов, а часть важного контекста хранится только в переписке.

Проверить ситуацию довольно просто.

Спросите:

Если владелец этой системы завтра не сможет работать две недели, кто сможет продолжить?

Если ответ «никто», риск уже существует.

Необязательно срочно документировать каждую строчку проекта. Достаточно начать с критических зон:

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

То же правило особенно важно перед подключением подрядчика. Хорошая передача проекта внешней команде начинается не с большого архива исходников, а с product context, roadmap, доступов, владельцев систем и понятных правил приёмки.

Признак №5. Команда постоянно двигает scope, но milestone не меняется

Самый незаметный способ сорвать проект — постепенно увеличить объём работы, сохраняя первоначальную дату.

Одна новая задача редко выглядит опасно.

«Добавим ещё один экран».

«Здесь нужно небольшое обучение».

«Давайте всё-таки сделаем gamepad support».

«Нужен ещё один тип противника».

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

При этом milestone в плане может оставаться прежним.

Возникает скрытое противоречие:

scope растёт → команда остаётся прежней → дата остаётся прежней → ожидаемое качество тоже не меняется.

Что-то из этих четырёх параметров неизбежно придётся изменить.

Но если решение не принимается явно, корректировка происходит сама собой: через overtime, технический долг, сокращение QA или перенос проблем на этап стабилизации.

Поэтому каждое существенное изменение scope должно сопровождаться вопросом:

Что меняется взамен?

Есть четыре основных варианта:

Увеличить срок.

Увеличить состав.

Уменьшить другой scope.

Принять больший риск или более низкий уровень качества.

Пятого варианта, в котором команда бесконечно добавляет работу без последствий, обычно не существует.

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

Отдельный тревожный сигнал: одинаковые проблемы повторяются каждый спринт

Ошибки неизбежны.

Системный риск начинается тогда, когда одна и та же проблема возвращается регулярно.

Например:

• каждый merge ломает сборку;
• QA снова находит ошибки сохранений;
• одна категория ассетов постоянно приходит с неправильными настройками;
• оценки одной команды почти всегда расходятся в два раза;
• release candidate регулярно собирается вручную;
• задачи постоянно возвращаются из review;
• одна система создаёт большую часть production incidents.

Если проблема повторилась три раза, перестаньте воспринимать её как отдельный случай.

Ищите процесс или архитектурную причину.

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

Именно так появляется опасный технический долг перед релизом: команда долго закрывает симптомы, пока накопленные компромиссы не начинают одновременно влиять на сроки, стабильность и скорость разработки.

Риски должны обсуждаться раньше статуса

На многих статусных встречах команда отвечает на стандартные вопросы:

Что сделали?

Что делаем?

Есть ли blockers?

Но blocker — уже поздняя стадия риска.

Если задача полностью остановилась, пространство для решений резко сокращается.

Гораздо полезнее обсуждать ещё и:

Что может стать blocker через неделю?

Например:

• SDK пока не протестирован на целевой платформе;
• backend API должен измениться;
• память уже близко к лимиту;
• новая система зависит от ещё не готовой архитектуры;
• QA не успевает закрывать regression;
• внешняя команда задерживает первую поставку;
• производительность механики пока проверялась только на ПК разработчика.

Эти проблемы ещё не блокируют production.

Именно поэтому сейчас с ними удобно работать.

Сделайте risk review коротким и регулярным

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

Иногда достаточно раз в неделю собирать пять–десять основных рисков.

Для каждого фиксировать:

Риск: что может произойти.

Вероятность: насколько сценарий реалистичен.

Влияние: что будет, если он реализуется.

Сигнал: по какому признаку станет понятно, что ситуация ухудшается.

Действие: что команда делает сейчас.

Owner: кто следит за риском.

Например:

Риск: версия для Android может выйти за memory budget.

Сигнал: peak memory контрольной сцены превышает установленный порог.

Действие: провести profiling до интеграции следующего контентного пакета.

Теперь это уже не абстрактное «может быть проблема с производительностью», а контролируемый объект.

Не превращайте risk register в кладбище проблем

Большая таблица рисков сама по себе ничего не улучшает.

Если в ней 70 пунктов и никто не понимает, какие три действительно могут сорвать ближайший milestone, инструмент перестаёт помогать.

Риски полезно ранжировать по влиянию.

Например:

Красный

Если проблема реализуется, milestone или релиз оказывается под угрозой.

Жёлтый

Проблема потребует дополнительной работы или сокращения scope, но пока остаётся управляемой.

Зелёный

Риск известен, есть запас и понятный mitigation plan.

Именно верхние несколько пунктов должны регулярно обсуждаться на production-встречах.

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

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

Когда нужно остановиться и провести аудит

Отдельный тревожный симптом — когда невозможно понять первопричину происходящего.

Backlog перегружен.

Сроки движутся.

Сборки нестабильны.

Команда постоянно занята, но milestone не становится заметно ближе.

В такой ситуации добавление ещё нескольких разработчиков не всегда помогает. Иногда оно даже увеличивает количество коммуникаций и интеграционных проблем.

Сначала стоит разобраться:

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

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

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

Чек-лист: проект ещё управляем?

Раз в несколько недель полезно пройти короткую проверку.

Backlog

Понятен ли ближайший milestone?

Есть ли definition of done?

Зафиксированы ли зависимости?

Известно ли, что можно убрать из scope?

Build

Есть ли регулярная рабочая сборка?

Создаётся ли она воспроизводимо?

Видны ли критические дефекты?

Проверяются ли основные сценарии?

Сроки

Записаны ли допущения?

Есть ли диапазон оценки?

Понятны ли основные неизвестные?

Изменяется ли план после изменения scope?

Команда

Есть ли single points of failure?

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

Документированы ли основные процессы?

Понятны ли зоны ownership?

Риски

Известны ли три главных риска ближайшего milestone?

Есть ли у каждого owner?

Понятен ли ранний сигнал ухудшения?

Есть ли конкретное действие до возникновения blocker?

Если большая часть ответов отрицательная, проекту не обязательно нужен кризисный режим.

Наоборот, это хороший момент исправить процесс, пока проблемы ещё остаются прогнозируемыми.

Риск полезен, пока команда видит его заранее

Сильный production-процесс не гарантирует, что сроки никогда не изменятся, сборки не будут ломаться, а разработчики не ошибутся.

Он делает другое: сокращает количество неприятных сюрпризов.

Команда заранее знает, где находится неопределённость, какая система требует внимания, где scope больше доступной ёмкости и какой milestone начинает уходить из-под контроля.

Тогда риск становится входными данными для решения, а не объяснением после сорванного срока.

Если проект уже регулярно сталкивается с неожиданными задержками, нестабильными сборками или ростом backlog без заметного прогресса, полезно дополнительно подключить QA и тестирование и проверить не только количество дефектов, но и то, на каком этапе они появляются и почему команда узнаёт о них так поздно.

NoPanic Studio подключается к проектам на разных стадиях — от pre-production и active production до стабилизации уже работающей игры. Разбираем технические и production-риски, существующий backlog, состояние сборок и реальные ограничения команды, после чего формируем приоритеты и план дальнейшей работы.

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