Критерии приёмки, из-за которых не приходится переделывать

Критерий должен быть проверяемым

Формулировка:

«Модель должна выглядеть качественно»

не является критерием приёмки.

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

То же самое относится к формулировкам:

• сделать красиво;
• улучшить анимацию;
• добавить больше деталей;
• сделать современно;
• приблизить к AAA;
• сделать эффектнее;
• оптимизировать модель.

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

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

Например:

• модель укладывается в согласованный polygon budget;
• используются texture sets указанного разрешения;
• количество материалов не превышает установленный лимит;
• pivot расположен в согласованной точке;
• naming соответствует правилам проекта;
• исходники входят в поставку;
• модель корректно импортируется в целевую версию движка;
• LOD переключаются без заметных визуальных ошибок;
• skeleton совместим с существующей системой анимации;
• ассет проверен непосредственно в игровой сцене.

Для персонажей и существ критерии могут дополнительно включать topology, UV, texture sets, rig, skinning и набор тестовых поз. Для окружения и локаций — размеры модулей, pivots, collision, LOD, streaming, материалы и бюджеты производительности.

Хороший тест качества критерия очень простой:

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

Если для проверки необходимо позвать автора задачи и спросить: «Ты примерно это имел в виду?», критерий сформулирован недостаточно точно.

Описывайте результат, а не способ работы

При этом критерии приёмки не должны превращаться в микроменеджмент.

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

Например:

Плохо: художник должен три раза использовать инструмент X, затем экспортировать через Y.

Если конкретный workflow не является обязательным ограничением pipeline, такое требование только мешает исполнителю выбрать наиболее эффективный способ работы.

Намного полезнее:

Модель после импорта в Unreal Engine должна корректно использовать согласованный skeleton, материалы и LOD.

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

Исключение — требования pipeline.

Если проект использует конкретную структуру файлов, naming convention, систему source control или обязательный формат исходников, это нужно зафиксировать. Но уже как техническое ограничение проекта, а не пожелание по организации чужой работы.

Технические ограничения важнее художественных пожеланий

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

Технический бюджет — нет.

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

Поэтому до начала работы стоит собрать технические требования в одном месте.

Для 3D-ассета такой список может включать:

• polygon budget;
• texture resolution;
• количество texture sets;
• разрешённые форматы;
• количество материалов;
• UV-требования;
• naming;
• scale и единицы измерения;
• ориентацию;
• pivot;
• LOD;
• collision;
• требования к skeleton;
• исходные файлы;
• версию движка;
• правила импорта.

Для VFX набор будет другим. Для анимации — третьим.

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

Сценарий:

«Кстати, у нас здесь максимум два материала»

после того, как десять ассетов уже готовы, — это не правка подрядчика. Это новое ограничение, которое не было передано в начале.

Поэтому при передаче проекта подрядчику технический контекст, доступы, правила pipeline и критерии готовности лучше собирать до первого рабочего дня. Тогда внешняя команда принимает решения в рамках реальных ограничений продукта, а не восстанавливает их методом проб и ошибок.

Референс должен объяснять, что именно в нём важно

Одной картинки недостаточно.

Заказчик отправляет референс персонажа. Художник смотрит на форму одежды, заказчик имел в виду уровень детализации материалов. Или команда показывает кадр из другой игры как ориентир по lighting, а подрядчик воспринимает его как пример всей стилистики.

Поэтому референсы полезно подписывать.

Например:

Референс 1 — пропорции персонажа.

Референс 2 — уровень детализации ткани.

Референс 3 — обработка металла.

Референс 4 — только цветовая палитра.

Так референс превращается из источника догадок в часть постановки.

Если важный параметр нельзя показать одним изображением, полезно сделать небольшой visual guide: несколько примеров «подходит» и «не подходит» с короткими пояснениями.

Это особенно важно перед масштабированием art production. Чем больше художников начинают работать параллельно, тем сильнее небольшие различия в понимании превращаются в заметный разброс результата.

Пилот перед объёмом

Первый ассет почти всегда стоит производить отдельно.

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

Представим, что необходимо создать 30 персонажей.

Можно сразу отправить в производство всю партию.

Через несколько недель выясняется, что:

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

Теперь любое изменение нужно распространять на десятки уже созданных объектов.

Гораздо безопаснее сначала сделать один характерный asset.

На пилоте проверяется не только качество результата.

Проверяется весь рабочий процесс:

Насколько понятна постановка.

Достаточно ли референсов.

Понятны ли технические требования.

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

Кто собирает feedback.

Сколько времени занимает один цикл.

В каком виде передаются исходники.

Как результат интегрируется в проект.

Как выглядит финальная приёмка.

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

Проблема обнаружена на одном ассете, а не на тридцати.

Именно поэтому на страницах NoPanic Studio по производству персонажей и другим art-направлениям отдельно используется логика эталона до масштабирования production: сначала фиксируются правила и уровень результата, а уже затем увеличивается поток.

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

Принимайте промежуточные этапы

Необязательно ждать финального файла, чтобы понять, что работа идёт не туда.

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

Например:

Blockout.

High poly.

Retopology.

Texturing.

Rig.

Integration.

И на каждой стадии зафиксировать, что именно принимается.

На blockout проверяются силуэт, пропорции и основные формы.

На high poly — детализация.

На retopology — техническая структура.

На текстурах — материалы и визуальное соответствие.

На финале — интеграция.

Это значительно дешевле, чем согласовать только готовый результат.

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

Это возврат на ранее принятый этап.

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

«Принято» должно означать принято

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

Художник показывает этап.

Заказчик отвечает:

«Да, вроде нормально, идём дальше».

Через неделю команда возвращается к тому же решению и просит его изменить.

Поэтому полезно различать:

Комментарий — результат посмотрели, но этап ещё не закрыт.

Принято — этап утверждён, команда переходит дальше.

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

Это дисциплинирует обе стороны.

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

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

Правки должны быть конечными

Фраза «правки до полного согласования» выглядит комфортно для заказчика, но часто создаёт проблему для обеих сторон.

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

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

Поэтому ещё до начала работ полезно договориться:

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

Например:

Раунд правок — один консолидированный список замечаний, переданный после очередной версии.

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

Один список замечаний лучше десяти сообщений

Подрядчику сложно работать, когда feedback выглядит так:

В понедельник арт-директор оставил комментарий в Figma.

Во вторник producer написал в Telegram.

В среду game designer добавил ещё одно замечание в Jira.

В четверг другой lead попросил вернуть решение из предыдущей версии.

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

Поэтому со стороны заказчика желательно иметь одного человека, который консолидирует feedback.

Он не обязательно самостоятельно принимает все художественные решения.

Его задача — собрать мнения участников и передать подрядчику один непротиворечивый список.

Замечания удобно разделять хотя бы на:

Blocker — без исправления результат нельзя принять.

Required — необходимо исправить в текущей итерации.

Optional / polish — улучшение, которое можно обсуждать отдельно.

Так исполнитель понимает приоритет, а заказчик не смешивает технический дефект с пожеланием сделать вариант «чуть интереснее».

Отличайте ошибку от изменения scope

Это один из самых важных моментов в работе с подрядчиком.

Если в требованиях было:

Texture 2048×2048

а исполнитель передал 4096×4096, это несоответствие критерию.

Оно исправляется в рамках исходной задачи.

Если после получения 2048×2048 заказчик решил, что теперь хочет 4096×4096, это уже изменение требования.

То же самое с художественными решениями.

Если утверждённый дизайн реализован неверно — это исправление.

Если после реализации утверждённого дизайна заказчик решил заменить броню персонажа — это изменение scope.

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

Нормальный процесс делает границу прозрачной.

Acceptance Criteria и Definition of Done — не одно и то же

Эти понятия полезно разделять.

Acceptance Criteria относятся к конкретной задаче.

Например:

• персонаж соответствует утверждённому концепту;
• модель имеет три LOD;
• texture set — 2048×2048;
• используется максимум два материала.

Definition of Done — общие правила, которые применяются ко всем задачам определённого типа.

Например:

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

Так не нужно копировать одни и те же требования в каждую постановку.

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

Приёмка — это чек-лист, а не мнение

Финальный review удобно превращать в обычную таблицу или checklist.

Например:

Теперь вместо:

«Нам кажется, работа ещё не совсем готова»

есть два конкретных несоответствия.

Исполнитель исправляет naming и передаёт исходники.

После этого задача закрывается.

Такая форма особенно полезна, если внешняя команда производит поток контента. Через несколько ассетов checklist превращается в стандарт, а новые задачи ставятся быстрее.

Критерии должны появляться до оценки

Есть ещё один важный эффект.

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

«Нужно сделать десять персонажей» — недостаточно информации.

Неизвестно:

• какого уровня качества;
• какой complexity;
• нужны ли concept art;
• нужен ли rig;
• нужны ли facial blendshapes;
• сколько LOD;
• какой texture budget;
• требуется ли интеграция;
• какие исходники входят в поставку.

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

Поэтому критерии приёмки помогают не только финальному QA, но и оценке.

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

И наоборот: если на старте невозможно сформулировать, каким должен быть результат, это уже один из ранних сигналов риска проекта.

Что подготовить перед передачей задачи подрядчику

Для большинства art-задач достаточно следующего набора.

Контекст

что это за проект;

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

Референсы

утверждённый concept;

• style guide;
• примеры нужного качества;
• пояснение, что именно смотреть в каждом референсе.

Технические требования

бюджеты;

• форматы;
• naming;
• scale;
• движок;
• структура файлов;
• требования к исходникам.

Этапы

какие стадии показываются;

• кто их принимает;
• что проверяется на каждой стадии.

Финальная поставка

какие файлы должны быть переданы;

• где они размещаются;
• нужно ли интегрировать результат в движок;
• какие preview или документация нужны.

Правки

число включённых итераций;

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

Приёмка

конкретный checklist;

• ответственный за финальный sign-off;
• срок review.

Такого документа обычно достаточно, чтобы радикально уменьшить количество спорных ситуаций.

Хорошая приёмка начинается не в конце задачи

Главная ошибка — думать о критериях приёмки как о проверке готового результата.

К этому моменту наиболее дорогие решения уже приняты.

Хорошая приёмка начинается до production:

с понятной постановки → пилота → промежуточных согласований → консолидированного feedback → финального checklist.

Тогда заказчик понимает, что именно получит.

Подрядчик понимает, что именно должен сделать.

А разногласия обнаруживаются тогда, когда их ещё дёшево исправить.

NoPanic Studio подключает игровых художников как к отдельным задачам, так и к постоянному production-потоку. Перед масштабированием фиксируем визуальный эталон, технические бюджеты, формат исходников и правила приёмки, а затем выстраиваем процесс так, чтобы новая партия контента не требовала заново объяснять требования всей команде.

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