Как грамотно давать правки. Чек-лист

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

Я уже около более 10 лет делаю рекламные и брендинговые проекты. Во время реализации этих проектов мне очень часто приходится общаться со многими специалистами - чаще всего, удаленно - иллюстраторами, ретушерами, моушн-дизайнерами, 3D-моделерами/аниматорами и т.д. То есть со специалистами, которые вовлечены в финальное производство.

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

Хотя в общем-то казалось бы, что тут трудного давать правки?

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

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

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

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

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

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

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

1. Споры

2. Рефлексия (когда человек вместо того, чтобы делать проект, идет в курилку переваривать ваши комментарии)

3. Демотивация (ну, люди, которым на все наплевать, хуже работают!)

Во всех этих вещах чаще всего (не всегда! но чаще всего) виновата неадекватная обратная связь. И это ИСКУССТВЕННО удлиняет проект. Именно это я и начал исправлять.

Я заметил, что многие специалисты (особенно молодые) боятся случайно задеть чувства дизайнера или иллюстратора и т.д. Поэтому они стараются текстом как-то смягчить свою критику, сгладить углы. И вместо того, чтобы сказать прямо, что нужно сделать - они пытаются как-то мягко и полунамеками сказать, что надо что-то переделать.

Согласно моему опыту, это приводит к тому, что человек:

- или не всегда понимает, что конкретно от него хотят. И начинает делать что-то не то. А потом снова возвращаться назад и снова переделывать.

- или же видит лазейку. Если качественно поныть или поспорить, то можно и не переделывать ничего. Ну, просто потому написать пару предложений проще, чем все переделывать.

Споры съедают очень много времени на проектах. Поэтому я делаю по-другому.

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

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

Как пишутся инструкции! У них есть несколько стилистических принципов. Но я использую только только два:

Первое, используются только активные и обезличенные глаголы. Это глаголы, которые отвечают на вопрос: «Что делать?» (изменить, подвинуть, убрать, использовать). Эти глаголы обезличены и безэмоциональны. Это просто императив, инструкция, что нужно сделать. И все.

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

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

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

Вместо этого я предпочитают писать - «Глаза сделать меньше». Активный глагол, никакой экспрессивной лексики и оценки того, как человек сделал работу.

По сути, это все, что техническому специалисту нужно знать. Я убираю всю экспрессивную лексику из комментария - ну, насколько это возможно. Совсем избавиться от оценки нельзя, потому что иногда надо что-то с чем-то сравнить. Но зато экспрессию всегда можно убрать!

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

Зачем я это делаю?

Я не хочу, чтобы, прочитав мои комментарии, человек потом пошел в курилку переваривать их. Мне нужно, чтобы он сразу приступил к работе и не тратил время на рефлексию. Потому что это замедляет работу.

Кстати, о рефлексии.

Я всегда использую правило зеленой ручки. Звучит глупо, но это работает.

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

Я пишу комментарии на макетах зеленым. Самые обычные мои комментарии выглядит так.

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

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

Когда человека ткнули носом в ошибку (пусть даже справедливо ткнули), все равно это демотивирует. А демотивированные люди просто хуже работают.

В конце концов поменять цвет на зеленый - это попросту не трудно!

Следующий пункт - никакой фантазии в комментариях. Этот пункт крайне важный. Потому что именно из-за этого происходит очень много конфликтов.

Многие дизайнеры, даже те, кто сами умеют делать 3D модели и анимацию, - они не до конца понимают специфику работы технических специалистов.

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

Однако все технические! (не творческие) специалисты, которых я знаю, - все как один ненавидят, когда люди так делают.

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

Во-вторых, эти люди не очень любят, когда их просят попробовать что-то самим, подумать, поискать. Потому что это означает угадывать решение, а угадывать и пробовать можно до бесконечности. А значит, изначальный график, на который они согласились в начале проекта, может увеличиться. Это значит, что проект делается дольше, а гонорар больше не становится. Это неприятно!

В-третьих, если вы написали в комментариях что-то неполно, неконкретно, абстрактно, общо и как-то витиевато намекнули, что хорошо бы поискать решение - то опытный специалист сделает по принципу, - «Я художник, я так вижу».

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

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

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

И справедливости ради, надо сделать поправку. Бывает такое, что в процессе реализации я не всегда знаю, чего я хочу. Да, так бывает. Я не всегда знаю, как будет лучше.

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

Во всех остальных случаях, я просто пишу, что нужно сделать.

ПРАВКИ ПОВЕРХ МАКЕТА.

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

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

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

Если я считаю, что текста, скорее всего, будет не достаточно, то я прикладываю референс прямо на макет. Я ставлю его на картинку, рядом с комментарием.

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

Чего я избегаю:

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

а) Я стараюсь не использовать двойные отрицания. То есть я не пишу что-то вроде «Не забудь не менять цвет». Двойные отрицания приводят к тому, что люди понимают смысл наоборот.

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

Поэтому я предпочитаю писать или «Сделать так» или «Так не делать».

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

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

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

То есть можно, конечно, и встать в позу - мол, пусть учат. А можно - сделать проект быстрее. Я выбираю «второе»

в) Я не пишу предложение длиннее 15 слов. Чем длиннее предложение, тем быстрее ты забываешь, что было в его начале. Надо перечитывать и вдумываться. Да, вхоже не сложно, но это удлиняет проект.

Например, целые фразы типа «После этой процедуры необходимо переместить…» можно заменить на один простой глагол «переместить». Так проще.

г) Если уж быть совсем дотошным, то я также не использую

Я стараюсь писать настолько примитивно, насколько это в принципе возможно.

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

Но самое главное, чего нет в моих комментариях - это каких-либо эмоций. Чем меньше экспрессии, тем меньше шансов, что человек примет это на свой счет.

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

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

Если еще два момента, которых важно коснуться:

Первый. Я никогда не ругаю за инициативу. Даже если это затянуло проект, а в общем было бесполезно. Я не ругаю за инициативу по нескольким причинам. Вообще говоря, чаще всего люди и правда лучше вас знают, как сделать быстрее какие-то технические моменты, а может, и лучше. И если вы будете ругать их за инициативу, то они станут просто вашими руками. В лучшем случае, вы просто упустите хорошую возможность. В худшем - проект будет получаться неважным и вы будете тыкать пальцем в небо, просить поправить то или то, но ничего не будет получаться. И вы не будете понимать, как это исправить. Зато будете считать, что все вокруг вас бездарные идиоты. А специалист, который знает, что делать, будет попросту сидеть и молчать, потому что инициатива в вашем обществе - наказуема. На мой взгляд, ругать за инициативу - означает затягивать проект.

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

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

Что это значит?

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

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

Вы можете считать как хотите, но лично мне не сложно еще раз нажать cntrl+C cnrl+V, если это ускорит проект.

И, наконец, последнее и самое главное. Лично я всегда стараюсь найти в сделанной работе что-то, что сделано действительно хорошо.

Я обвожу это место также, как и правки и пишу, что вот это сделано ХОРОШО! На мой взгляд, похвала мотивирует людей лучше, чем палка.

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

1) Пиши комментарии, рисуй и отмечай - прямо на макете/скриншоте.

2) Используй зеленый цвет для комментариев.

3) Приложи к комментарию референс.

4) Прикрепляй референс прямо на макет.

5) Не забудь приложить референсы отдельными файлами к письму.

6) Пиши сухим текстом, как в инструкции по сборке мебели.

7) (Для этого) Используй активные и обезличенные глаголы (подвинуть, убрать).

8) Никакой оценочной лексики (не оценивай сделанную работу).

9) Если тебя спрашивают то, что ты уже говорил или писал - повтори ответ, а не отправляй его искать! Твоя задача не наказать за невнимательность, а сократить время выполнения проекта.

10) Похвали за то, что сделано хорошо!

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

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

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

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

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

Все они преследуют только одну цель - ускорить время исполнения задачи. Я не хочу, чтобы люди тратили время на конфликты, поиск информации и рефлексию в курилке. Я хочу, чтобы они начали делать работу сразу после прочтения обратной связи и были мотивированы сделать ее быстро и качественно.

На этом все. Спасибо!

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