ShotGrid для управления производством контента: настройка статусов

С чего начинается беспорядок в продакшене и как ShotGrid помогает

Как выглядит хаос без единой системы

Беспорядок обычно начинается не с «плохих людей», а с разрозненных договоренностей. Задачи живут в чате, статусы - в голове у продюсера, дедлайны - в таблице, а файлы - на сервере в папках с названиями вроде «финал_точно_последний_v7».

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

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

Чем ShotGrid закрывает эти дыры

ShotGrid помогает собрать в одном месте три опоры: задачи, статусы и контекст (обсуждения, версии, файлы). Обычно им пользуются сразу несколько групп: продакшен (планирование и контроль), креатив (сдача версий и комментарии), техотдел (пайплайн, шаблоны, интеграции).

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

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

Базовые понятия ShotGrid простыми словами

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

Минимальный словарь, который нужен почти всем:

• Project: проект, общий контейнер для людей, этапов и данных.
• Asset: объект, который создают и переиспользуют (персонаж, локация, логотип, 3D-модель).
• Shot: конкретный кадр или сцена в монтажной структуре.
• Task: кусок работы по Asset или Shot (моделинг, риг, композ, саунд).
• Version: результат работы, который можно посмотреть и сравнить (рендер, превью, плейбласт).
• Note: комментарий или замечание, привязанное к задаче, версии или кадру.

Чаще всего путают Task и Version. Task отвечает на вопрос «что нужно сделать и кто отвечает». Version - «что получилось на текущий момент». У задачи может быть много версий. У версии обычно есть автор, дата и короткое описание того, что изменилось.

Для ежедневной работы не нужно заполнять десятки полей. Обычно хватает названия, статуса, исполнителя, срока, приоритета и двух связей: с Asset или Shot, и с последней Version. Остальные поля (бюджеты, метрики, кастомные атрибуты) лучше добавлять позже, когда команда поймет, чего реально не хватает.

Чтобы не плодить дубликаты, заранее договоритесь о правилах имен. Например: единый формат для шотов (SC010_SH020), единые названия ассетов (CHAR_Anna, PROP_Cup) и запрет на «финал_самый_финальный». Простая проверка: если сущность нельзя быстро найти поиском, значит названия уже «поехали».

Проектируем статусы под ваш пайплайн

Статусы в ShotGrid нужны не для красоты, а чтобы за 10 секунд понять, что происходит с задачей и кто делает следующий шаг. Начинайте не со списка статусов, а со списка этапов вашего процесса: моделинг, UV, текстуры, риг, анимация, FX, композит, звук, монтаж. Этапы описывают работу, статусы описывают состояние работы.

Хорошее правило: статусов должно быть меньше, чем этапов. Этапов может быть 15, а статусов - 6-8. Так система не превращается в набор мелких ярлыков, в которых никто не ориентируется.

Чаще всего хватает такой базы:

• Не начато (ожидает)
• В работе
• На проверке
• Нужно исправить
• Готово (утверждено)

Дальше решите, что будет общим для всех, а что останется внутри отделов. Общие статусы должны одинаково значить для моделинга и композа. А внутренние состояния вроде «собираю кэш» или «рендер в очереди» часто удобнее вести как поле, тег или заметку, чем как отдельный статус для каждой команды.

Чтобы статусы работали, зафиксируйте правила переходов: кто меняет статус и когда. Например, художник переводит задачу в «На проверке» только после прикрепления версии на ревью; супервайзер меняет на «Нужно исправить» или «Готово». Продюсер не трогает рабочие статусы, а следит за сроками и рисками.

Проверьте правила на живом кейсе: текстурщик сделал первую версию, отправил на проверку, получил правки, вернул в работу, повторно отправил, получил утверждение. Если на этом пути появляются лишние статусы - убирайте. Если не хватает одного состояния (например, «Блокер») - добавляйте, но только когда оно решает конкретную проблему.

Роли и права доступа: настройка без лишней сложности

Права в ShotGrid проще настраивать не «по людям», а по ролям. Тогда при смене сотрудников вы меняете роль, а не пересобираете систему.

Начните с 3-6 ролей, которые реально есть в продакшене. Обычно хватает продюсера, супервайзера, артиста и клиента. Если есть подрядчики, это отдельная роль, даже если они делают ту же работу: разница чаще всего в уровне доверия и в том, что им можно показывать.

Дальше связывайте роли с группами доступа и видимостью сущностей. Логика простая: человек видит только те проекты, шоты, задачи и версии, которые ему нужны для ежедневной работы. Артисту не обязательно видеть бюджеты и внутренние поля планирования, а клиенту - чужие шоты и внутренние заметки.

Чтобы права не превратились в хаос, заранее ответьте на несколько вопросов и придерживайтесь решений:

• Кто может менять статусы задач - только супервайзер или еще и артисты.
• Кто может создавать Versions и публиковать их на ревью.
• Кто может писать заметки всем, а кто только внутри своей команды.
• Какие поля считаются «внутренними» (например, причины задержек) и скрываются от внешних.
• Кто имеет право удалять или переименовывать сущности.

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

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

Уведомления и подписки: чтобы ничего не терялось

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

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

• смена статуса задачи (например, «В работе» -> «На проверке»)
• новый комментарий с упоминанием
• загрузка новой версии
• назначение или переназначение задачи
• смена дедлайна

Дальше решите, кому это должно приходить. По умолчанию уведомления часто «размазываются» по всем, и их перестают читать. Рабочее правило: уведомление получает исполнитель, его лид и тот, кто поставил задачу. Остальные подписываются сами, если им правда нужно следить.

Чтобы не было спама в почте, разделите каналы: срочное приходит письмом, все остальное - как подписка в ShotGrid (на задачу, шот или плейлист). Удобный ориентир: письмо только тогда, когда без реакции процесс встанет.

Пример: художник загрузил новую версию и поставил статус «На проверке». Супервайзер получает уведомление, оставляет комментарий и меняет статус на «Правки». Исполнитель видит это сразу, и работа не зависает на сутки.

Правила хорошего тона в комментариях простые, но они экономят часы. Пишите одно действие на сообщение (что исправить или что подтвердить), добавляйте контекст (где смотреть: версия, кадр, элемент), ставьте срок или приоритет, если это важно, и используйте упоминания только для тех, кто должен ответить.

Связь задач с файлами на сервере: понятная схема

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

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

Пример схемы, которую легко объяснить команде:

• 01_Source (исходники: камера, аудио, референсы)
• 02_Work (рабочие файлы по задачам)
• 03_Renders (рендеры, превью, playblasts)
• 04_Publish (утвержденные версии, готовые к передаче дальше)
• 05_Delivery (финалы для сдачи заказчику)

Дальше важный шаг: привяжите результат к задаче не «в голове», а в ShotGrid. В карточке задачи удобно хранить минимум три вещи: путь к папке, имя файла по правилу и текущую версию. Например: Project/02_Work/Shot010/Comp, Shot010_comp_v012.nk, v012.

Чтобы всегда было ясно, что лежит внутри папки, держите простое разделение: исходники живут в 01_Source и не редактируются; рабочие файлы - только в 02_Work; превью и тестовые рендеры - в 03_Renders; то, что можно считать «опубликованным», попадает в 04_Publish. Финалы для клиента уходят в 05_Delivery и не смешиваются с рабочими.

Правило «единственного источника правды» лучше сделать жестким: актуальный файл смотрим не в переписке и не в «последнем письме», а в ShotGrid в сущности Published/Version (или в вашем поле «Актуальный файл»), где указан путь и номер версии. Если файл не опубликован или не прикреплен к версии в ShotGrid, значит он еще не существует для пайплайна, даже если лежит на сервере.

Пошаговая настройка с нуля за один спринт

Если выделить один спринт (обычно 1-2 недели), ShotGrid реально поднять с нуля так, чтобы команда начала работать в нем, а не «когда-нибудь потом». Важно делать только минимально нужное и сразу проверять на живом примере.

План на спринт: от пустого проекта до пилота

Начните с каркаса и наращивайте его по мере проверок.

Сначала создайте проект и согласуйте этапы работ. Затем заведите короткий список статусов (например: To Do, In Progress, Review, Approved, On Hold) и договоритесь, кто и когда меняет статус.

Дальше подготовьте шаблоны задач для Assets и Shots. Лучше 6-10 типовых задач на сущность, чем 30 «на всякий случай». Шаблоны экономят время и уменьшают число ручных ошибок.

Затем назначьте роли и ответственных. У каждой задачи должен быть один владелец, а не «все немного отвечают». Сразу включите подписки на ключевые события: назначение задачи, смена статуса на Review, комментарии, отклонение ревью.

И, наконец, зафиксируйте структуру папок на сервере и правила именования. Пример: Project/Assets/Character/Name/Work и Project/Shots/Seq/Shot/Publish. Важно, чтобы ShotGrid ссылался на одни и те же пути, а не на «где у кого лежит».

После базовой настройки прогоните мини-проект на 1-2 дня: один Asset и один Shot, с одним циклом правок.

Во время пилота быстро станет видно, что нужно поправить: статусов слишком много (или не хватает одного), задачи дублируются или непонятно названы, уведомления шумят или не приходят на важные события, правила именования не выдерживаются на практике, ссылки на файлы ведут в разные места или ломаются.

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

Частые ошибки и ловушки при внедрении

Основная проблема при внедрении ShotGrid обычно не в том, что «система сложная», а в том, что правила внутри команды не успевают за настройками. В итоге люди продолжают жить в таблицах и мессенджерах, а ShotGrid остается «для отчетности».

Ошибки, которые быстро ломают процесс

Чаще всего процесс разваливается из-за нескольких типовых вещей.

Статусов слишком много, и часть из них означает одно и то же. Например, «На проверке», «Ждет ревью», «Апрув у лида» различаются только названием, и команда каждый раз спорит, какой выбрать.

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

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

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

Нет правила именования и версионности. В результате «final_final_2.mov» невозможно однозначно сопоставить с задачей, шотом и конкретной правкой.

Один простой пример: художник грузит превью в ShotGrid, но исходники держит у себя. Супервайзер ставит «Нужно исправить», но не может понять, какую именно версию править, потому что в задаче нет пути к папке и нет единого формата имени.

Противоядие тоже простое: ограниченный набор статусов для одного типа сущности, 2-3 роли с понятными правами, уведомления только по назначению и по изменениям статуса, единая схема хранения (где лежит исходник, где превью, где финал) и обязательная привязка пути или публикации к задаче. Когда базовая дисциплина закрепится, расширять систему становится безопаснее.

Быстрый чеклист перед запуском в работу

Перед тем как сказать команде «теперь работаем в ShotGrid», пройдите короткую проверку. Она занимает 20-30 минут, но экономит дни на исправлениях после старта.

5 проверок, которые ловят 80% проблем

• У каждой задачи назначен владелец, и срок выглядит реальным. Задачи без исполнителя или с дедлайном «когда-нибудь» почти наверняка зависнут.
• Статусы трактуются одинаково в разных отделах. Попросите 2-3 людей из разных ролей объяснить, что значит «In Progress», «Review», «Approved». Если ответы разные, нужно уточнить названия или описание.
• Понятно, что происходит после смены статуса. Для ключевых переходов (например, «Готово к проверке») должно быть ясно: кто следующий, что он делает, и какой результат считается приемлемым.
• Путь к файлам виден там, где его ищут в реальной работе. Откройте карточку задачи и проверьте: есть ли поле с понятным путем, названием версии или привязкой к нужной папке, и совпадает ли это с тем, как команда реально открывает материалы.
• Уведомления не шумят. Сделайте тест: поменяйте статус на одной задаче и посмотрите, кому пришло сообщение. Если уведомление получает «вся студия», люди начнут игнорировать все.

Живой тест помогает быстрее всего: возьмите одну типовую задачу (например, «рендер шота» или «подготовка макета»), проведите ее по всем статусам и убедитесь, что каждый шаг понятен без объяснений в чате.

Пример сценария: небольшой проект от старта до сдачи

Представим короткий рекламный ролик: 10 шотов, команда 6 человек (продюсер, супервайзер, 2 артиста, композер, монтажер), срок 2 недели. ShotGrid полезен тем, что всем видно одно и то же: что уже сделано, что на проверке, где правки и где лежат актуальные файлы.

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

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

• Not Started (не начато)
• In Progress (в работе)
• WIP Review (черновая проверка)
• Client/Sup Review (проверка супервайзером)
• Changes (правки)
• Final (принято)

Как это выглядит на одном шоте. Артист по анимации делает Version v001 и отправляет на WIP Review. Супервайзер оставляет комментарии прямо к версии (по кадрам, если нужно), ставит Changes и отмечает, что именно поправить. Артист выпускает v002, цепочка повторяется. Когда шот принят, задача переходит в Final, и для композа сразу понятно, что можно брать последнюю принятую версию.

Чтобы новый человек включился за 30 минут, важнее всего простая и одинаковая структура на сервере. Один рабочий вариант:

/PROJECT
  /shots
    /sh010
      /anim
        /work
        /publish
      /comp
        /work
        /publish
      /review

Правило: в /publish попадает только то, что соответствует версии в ShotGrid (название файла и номер версии совпадают). В /work можно держать черновики, но они не должны путать команду.

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

Следующие шаги после пилота: закрепляем процесс и инфраструктуру

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

Зафиксируйте правила и снимите напряжение

Сразу после пилота соберите короткую обратную связь: что мешало, что экономило время, где чаще всего возникали вопросы. Дальше «заморозьте» правила статусов на 1-2 месяца. Это дает команде время привыкнуть и перестать спорить о названиях, а вам - собрать реальные данные: где статусы работают, а где нужен новый шаг.

Полезно записать мини-регламент на одну страницу. Он не обязан быть идеальным, он должен быть понятным:

• кто имеет право менять статус и в какой момент
• как именуем версии (например, shot010_comp_v003)
• где лежат рабочие файлы и где финалы
• что обязательно пишем в комментарии при передаче (какую версию смотреть, что проверять)
• как действуем при блокере (кому пишем, какой статус ставим)

Поддержите процесс инфраструктурой

Когда задачи начинают привязываться к файлам, слабые места инфраструктуры всплывают быстро: права доступа, скорость сети, потерянные версии, отсутствие резервного копирования. Заранее проверьте три вещи: надежное хранилище (сервер или NAS), регулярные бэкапы и понятные роли доступа на уровне папок.

Если вам важен on-prem подход (локальное хранение, требования безопасности, работа с тяжелыми сценами), стоит заранее обсудить схему: где будет храниться продакшен, как подключаются рабочие станции, как делаются копии и кто отвечает за доступы.

Иногда удобно, когда инфраструктуру и поддержку можно собрать в одном месте. Например, GSE.kz (gse.kz) как производитель серверов и рабочих станций в Казахстане и системный интегратор может закрыть базовые задачи по «железу», внедрению и дальнейшей поддержке, чтобы выбранная схема хранения и доступа не развалилась через пару месяцев.