Как писать технические задания для продакшенов, чтобы не получать ХЗ в результате

Всем привет! Меня зовут Михаил Раков. Я креативный директор рекламного и брендингового агентства Jekyll & Hyde. В своих публикациях я рассказываю о креативном менеджменте. В этой статье я поделюсь своим опытом о том, как готовить технические задания для разного рода специалистов, вовлеченных в продакшн.

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

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

Лично меня удивляет, то как креативные директора агентств сквозь пальцы смотрят на кое-как сделанные технические задания. Ведь агентства из-за этого теряют деньги.

Если вам лень читать дальше, то вот ролик:

Как бы то ни было, у продакшенов и фрилансеров даже есть такая поговорка:

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

Это прозвучит странно, но лично мой опыт говорит, что это не всегда взаимосвязанные вещи. Можно получить отличный результат, имея в самом начале довольно слабое ТЗ.

Давайте посмотрим на пример не очень, на мой взгляд, хорошего ТЗ. А затем взглянем, что из него вышло.

Это пример технического задания на продакшн принтов для бургерной Джон&Федор. Да, та самая, которой студия Лебедева делала логотип.

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

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

В техническом задании была подробно описана идея:

Показаны детали по реализации и материалам:

Слайд, посвященный форматам и где на макете будут располагаться кое-какие элементы:

И референсы по атмосфере и цветовой гамме:

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

Не так уж и плохо.

В связи с чем напрашивается вопрос, с чего я взял, что это не очень хорошее ТЗ?

Дело в том, что в этом ТЗ было хорошо все, кроме того, что оно не полное. В нем нет самого важного элемента принта — скетча самой сцены или композиции, если вам так удобнее.

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

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

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

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

Но если это так, то зачем тогда вообще делать хорошее ТЗ?

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

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

Хорошее ТЗ сокращает время исполнения задачи, а значит, это экономически выгодно.

Благодаря детализированному и продуманному ТЗ у всех участников появляется единое видение результата. Мы все становится на одной волне.

Кроме того, в хорошем ТЗ есть ответы почти на все вопросы и больше не нужно постоянно дергать людей, которые заняты чем-то еще. Иногда из-за какого мелкого вопроса или непонятного нюанса стопорится вообще весь процесс. И всем приходится ждать, пока необходимый человек освободится — закончит свои дела, переговоры и прочее, — и наконец, внесет ясность. Это не очень удобно и искусственно растягивает проект.

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

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

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

• Сложность проекта
• Необходимые инструменты/умения/скилы
• Привлечение сторонних специалистов
• Продолжительность проекта
• Условия проекта

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

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

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

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

Если подвести итог этого пункта, то подробное и детальное ТЗ дает более полное понимание для обеих сторон, о чем вы вообще договариваетесь и что именно должно получиться в итоге.

Как показывает практика, хорошее ТЗ уменьшает количество потенциальных недовольств и конфликтов по ходу проекта — потому что все заранее знают, на какие условия они соглашаются.

Это, на мой взгляд, архи-важно.

Если вы написали плохое ТЗ — вы будете постоянно нужны в процессе производства. Многие вещи вам придется постоянно контролировать и вручную отлаживать. Вас всегда все будут ждать, потому что без вас ничего не будет решаться.

У меня был опыт работы с очень плохими ТЗ, и мне буквально пришлось уделять этому процессу всё время.

На другие проекты времени, соответственно, не оставалось: их приходилось откладывать.

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

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

Давайте теперь посмотрим на хорошее, с моей точки зрения ТЗ, а затем — какой результат из него получился.

Это ТЗ для иллюстратора, который должен был «придумать» персонажей и сделать скетч для 3D-моделера.

Описание продукта (названия бренда не всегда достаточно):

Описание идеи:

Описание самой задачи:

И если вы заметили, каждая мысль находится на отдельном листе — это тоже важно.

Потому что если куча текста находится на одном листе — очень сложно сосредоточиться на важных моментах. Я предпочитаю не экономить электронную бумагу.

Скетч сцены, как мы это себе представляем:

Как видите — рисунок очень неважный. И я специально взял это ТЗ, чтобы показать, что важно не стесняться делать скетчи, даже если у вас не академический рисунок.

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

Далее мы показываем референсы взрыва, который хотим:

И дополнительно прописываем, что это должен быть за взрыв — что он не должен быть криповым.

Референсы по анатомии персонажей и текстурам:

Референс финальной реализации:

Степень проработки ожидаемых скетчей:

Единственное, чего тут, возможно, не хватает — это референсов по свету.

Но в целом — это весьма неплохое ТЗ, хотя и не самое подробное.

Теперь посмотрим, что по ходу работы получалось у иллюстратора:

То, что вы видите сейчас, — это промежуточные итерации по придумке персонажей к данному принту.

А вот финальный результат:

Хорошее ТЗ и хороший, на мой взгляд, результат.

Можно было бы добиться такого же результата с плохим ТЗ? Да, вполне возможно. Однако на это ушло бы значительно больше времени, а вся команда бы в этом случае занималась только одним проектом.

Иногда в ТЗ более подробно прописываются даже детали стиля.

Вот например, в ТЗ для проекта упаковки маффинов мы детально разбирали особенности диснеевского стиля 30-х годов.

Нам было важно показать, что персонажи должны быть гибкими:

Мы не только это описали, но показали на референсах:

Отдельно указали на глаза:

И опять же дали референсы и показали, чем визуально отличается стиль того времени от «новодела»:

Особо обратили внимание иллюстратора на фон:

И опять же дали описание и референсы:

А вот, что получилось в результате:

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

И вот мой персональный чек-лист, что должно быть в хорошем ТЗ:

1/ контекст

• Опиши продукт / основную идею / проблему / бэкграунд.
  Человек должен быть максимально погружен в контекст, чтобы понять ход ваших мыслей и лучше понять, как ему сделать свою работу.

2/ СТИЛЬ реализации

• Опиши стиль реализации (стиль иллюстрации / 3D и т. п.).
• Приложи несколько референсов этого стиля (не много — главное, чтобы они максимально точно передавали то, что ты хочешь получить).
• Добавь описание важных, на твой взгляд, моментов касательно стиля.
• Если в каких референсах важно смотреть не на все, а только на какой-то участок или элемент — обязательно отметь это и укажи письменно.
  

3/ СКЕТЧ

• Сделай свой скетч композиции или макета.
  Не важно, насколько ты хорошо рисуешь! Главное, — никогда не начинайте работу без скетчей. Когда вы делаете скетчи — вы заранее видите, что будет работать, а что — нет. И когда вы, наконец, сделаете скетч, который максимально соответствует вашей задумке — это, скорее всего, и будет наилучшее решение.
• Укажите, все, что должно быть на макете (лого / пэкшот / текст / лайн и т. д.).
• Укажите, где эти элементы должны располагаться на макете (например, иллюстратор должен знать, на каких участках лучше не делать сильную детализацию, т. к. там, возможно, будет пэкшот).
• Приложи все тексты, участвующие в макете в отдельном файле (doc, pages) (его нужно будет отправить вместе с ТЗ).

4/ СКЕТЧ рендеров

• Сделай скетчи композиции для каждого рендера со всеми объектами (например, если вы делаете рендер упаковки для подачи, то лучше сразу нарисовать скетчи всех ракурсов или сюжетов, как вы это видите).
• Распиши каждый материал, который будет на этих рендерах (стекло / пластик / сталь / дерево / камень / ткань).
• Приложи к каждому этому материалу референс, чтобы была четко видна фактура материала и другие визуальные аспекты.
• Приложи описание, на что именно надо обратить внимание в каждом материале.

5/ СВЕТ

• Опиши требования по свету (об этом очень часто забывают).
• Приложи референсы желаемого освещения.
• Добавь описание по освещению, какие именно его аспекты важно учесть.

6/ результат

• Приложи референс, по которому ясно, какое качество результата ты ожидаешь (качество рендера/уровень детализации и проработки и т.д.).

7/ ЭТАПЫ производства

• Если у проекта есть последующие этапы, в которые будет включен этот исполнитель (для которого вы делаете ТЗ) или ему стоит их знать, — распиши их.
  Например, сначала придумываем персонажей, а после их утверждения прорисовываем сцены с их участием и т.д.

8/ дедлайн

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

9/ передача файлов

• Напиши, в каком виде должны быть переданы итоговые макеты (например, объекты на альфа-каналах и т.п.).

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

Но в общем и целом, главный принцип, которым мы пользуемся при составлении ТЗ:

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

На этом всё. Хорошего дня!

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