Чего хотят рекламодатели?

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

М. Твен "Как лечить простуду"

Проблема познания желаний

"Концепций нам не надо, мы не знаем, что с ними делать".
из писем Заказчика Разработчику

Думаю, каждый из нас, работников обслуживающего цеха (а это ведь так, обслуживаем мы, что там скрывать), хоть раз задавал себе этот вопрос: "Чего хотят наши клиенты, т. е. Заказчики¹? Потому что только Заказчик может сделать работника Разработчиком². Если заказывает ему Разработку³.

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

2 - Разработчик - лицо (или группа лиц), занимающееся разработкой в рамках технического задания для последующей ее продажи Заказчику.

3 - Разработка - результат совместного труда Разработчика и Заказчика, соответствующим образом оформленная и оплачиваемая Заказчиком

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

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

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

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

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

Теперь дело другое. Пришло время подумать о конкуренции на новом качественном уровне - "конкурируем мозгами!"

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

Ан, нет!

Да, об имидже фирмы, но не о том, который продается или продает.

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

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

Вот тут и начинается разброс целей.

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

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

А какого заказа?

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

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

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

Итак, две основные силы, которые обычно подвигают Заказчика к общению с Разработчиком.

1. Заказчик хочет самоутвердиться за счет Разработчика.
   В этом случае за словами Заказчика о возможном сотрудничестве стоит только одна задача: еще раз доказать самому себе и всем окружающим, что он отлично справится с поставленной задачей сам. (Нормальная задача, кстати. Только она находится не в компетенции Разработчика. Хотя большинство Заказчиков почему-то уверены в обратном.)
2. Заказчик хочет получить от Разработчика то, что будет удовлетворять остальные его желания. (Тоже нормальная задача. Тоже не всегда находится в компетенции Разработчика. Но здесь Разработчик все же может попытаться получить от общения с Заказчиком удовольствие. И деньги.)

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

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

Обычно почти сразу видно, по какому пути двинулся Заказчик.

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

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

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

Две главные задачи Разработчика:

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

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

И для этого наша Разработка должна выполнить основную задачу - удовлетворить желания Заказчика.

Чем грозит невыполнение этого условия? В лучшем случае - отсутствием оплаты за Разработку. В худшем - к отсутствию оплаты прибавляются: неудовлетворенность обеих сторон, неуверенность Разработчика в собственном профессионализме, неуверенность Заказчика в том, что обратился к профессионалам, и много других дополнительных печалей.

Скверный анекдот в тему

Приходит раз к нам Заказчик. Известный ранее хороший знакомый. Очень умный, "продвинутый" менеджер, заметим. Приходит он с хорошим заказом.

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

Дает этот Заказчик нам задание: «Ребята, я вас знаю, вы делаете хорошие, даже «крутые» вещи, я вам доверяю, делайте, что считаете нужным, но чтобы оно работало».

«Как работать должно?» - спрашиваю. Отвечает: «Все должны видеть, что это - фирма-лидер на рынке в предоставлении данной услуги, пришла сюда надолго, навсегда, в ней работают «крутые» профессионалы».

ОК.

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

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

А хочет быть Повелителем Вселенной. Или (на худой конец) самым «крутым» в нашем городе.

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

Дилемма. Сделать то, что требуется явно, - Заказчик останется неудовлетворен не полностью выполненной работой. Мы ведь не будем бегать за ним с ТЗ и показывать, что все формальности соблюдены.

Напоминаем сами себе, что Заказчик должен быть доволен результатами труда Разработчика (см. выше).

Принимается рискованное решение - делать то, чего хочет Заказчик, а в отчете показать, то, что заказывал. Квалификации Разработчика на это хватит.

Промежуточный результат работы с Заказчиком.

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

Квалификации Разработчиков хватило на то, чтобы желаемое Заказчиком выдать за декларируемое.

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

Итоговый результат работы с Заказчиком.

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

Аргументы Заказчика - не понравилось.

Аргументы Разработчика - в данном случае отсутствуют.

Какие же выводы предлагается сделать из выше написанного?

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

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

Ведь до начала разработки надо составить ТЗ. Разработчик обычно зрит в корень лежащей на поверхности задачи и выдает на гора соответствующие тому вопросы.

И из этих вопросов обычно выливается следующее.

1. «Продвинутый» Заказчик уже на стадии интервью из умных вопросов Разработчика сам хорошо поймет, что ему надо. Он, конечно же, не будет знать, как ему это сделать, он ведь не Разработчик. Но зачастую даже «продвинутый» Заказчик не отличает одного от другого и гордо уносит полученные знания вместе с собой.
2. Обычный Заказчик может испугаться умных вопросов Разработчика, пытающегося выведать у него ту правду, которую он всеми силами хотел бы скрыть. И такой Заказчик тоже уносит свои знания с собой, но уже испуганно и быстро.

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

Но мы, настоящие Разработчики, не сдаемся! Мы найдем выход из любой ситуации, предлагаемой нам рынком.

И что же требуется от Разработчика в наше время на нашем рынке?

Получается, что надо быть:

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

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

Да и не его это дело, вести переговоры.

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

Что нужно Заказчику на самом деле - мы не знаем. И никогда не узнаем. И хорошо, что не узнаем.

Но мы точно знаем, что нужно Разработчику. Ему нужен Переговорщик⁴.

4 - Переговорщик - лицо (реже - группа лиц), умеющее вывернуть карманы Заказчика со счастливым выражением на его, Заказчика, лице.

Кто такой Переговорщик?

"Кто его учил так вести переговоры?"
из к / ф "Пятый элемент"

В англо-русском словаре зафиксированы такие слова, как negotiant - «купец, ведущий крупные сделки», и negotiator - «человек, ведущий переговоры», которые демонстрируют, что между Разработчиком и Заказчиком должен стоять некто, выполняющий совсем иные функции, чем Разработчик.

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

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

А во-вторых, мы пытаемся понять: а не появился ли на нашем рекламном рынке новый тип менеджера, не детерминированный ранее штатными расписаниями и субординационными связями?

Да, верно, в лучшем случае за спиной у Разработчика стоит Муза, в худшем - постановщик задачи.

Но ведь они оба - это и есть Разработчик. Каковому нельзя вариться в соку собственной рефлексии на тему исполнения заказа. Его от этого должен охранять... Кто?

Традиционно это - так называемый account manager, менеджер по работе с клиентами или руководитель службы по работе с клиентами, если таковая имеется, директор заказов, наконец.

Он обычно стоит щитом, охраняя нервы Заказчика и силы Разработчика (либо наоборот, в зависимости от заказа). Он делает постановку задачи, доводя истинный смысл технического задания или креативного брифа до ума Разработчика, а готовую Разработку - до подписи к оплате.

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

Откуда же взялся Переговорщик?

Мы уже испорчены мировым рыночным опытом. У нас существует субординационный набор, опробованный на практике нашими соседями по ту сторону красных флажков. Он опробован и выверен многолетними шагами и ошибками. Их ошибками. У нас на это времени не было, мы скалькировали этот опыт, рассчитывая на то, что они все сделали за нас. Видимо, не все. Конечно, Разработчик должен разрабатывать. А формировать ТЗ должен account manager (менеджер по работе с клиентами). На основании показаний того менеджера, который точно знает, что нужно сделать для нашего Заказчика.

Этот менеджер и есть Переговорщик.

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

Почему именно Переговорщик? Потому, что то, что должен делать Переговорщик, - это не совсем переговоры. Это даже совсем не переговоры.

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

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

Но водка и черный хлебушек в два часа ночи на 6-тиметровой кухне кого хочешь разговорят. А ты попробуй сделать то же в девять утра на 26-ом этаже в 50-тиметровом зале для переговоров!

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

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

Итак, Переговорщик - это лицо, которое:

• может получить от Заказчика информацию о его требованиях к Разработке;
• трансформирует данную информацию в техническое задание или креативный бриф, в соответствии с которым Разработчик изготавливает Разработку;
• умеет объяснить Заказчику, что Разработка, которую он получил, - это именно то, что он и заказывал.

История из жизни.

Раз звонит мне Заказчик из другого города.

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

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

«Шли логотип», - говорю.

Присылает. Мама, не горюй! Детская почеркушка неизвестного назначения. Для «крутой» фирмы данного профиля не годится никак.

«Не годится, - говорю ему. - Никакие сценарии это не спасут. Кто логотип делал?»

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

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

А если мы сделаем новый логотип и под него уже идеи и сценарии, с обоснованием?

«Делайте, - говорит. - Если будет внятно-понятно - пройдет, заплатим по вашему прайсу. Если не пройдет - заплатим за участие».

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

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

Результат работы: Разработка была принята в течение двух часов.

Примечания.

1. В процессе работы мы обменялись с нашим Заказчиком (каковой на самом деле оказался Переговорщиком) двумя-тремя телефонными звонками и пятью-шестью письмами, а также бухгалтерскими документами и деньгами.
2. Никогда ранее мы не виделись c Переговорщиком, не разговаривали с ним и вообще не были знакомы. Решение о совместной работе было взаимно принято на основании полученных со стороны рекомендаций.
3. Когда нам захотелось подробностей о принятии Разработки (восторгов, комментариев или хотя бы чего-нибудь от того непосредственного Заказчика, которого мы тоже никогда не видели, но который стал почти родным за время изготовления Разработки), наш Переговорщик сухо отметил, что принято все, кроме одного из четырех сценариев.
   «А какой был не принят?» - спросили мы, все еще надеясь узнать детали.
   «Не знаю точно,- говорит, - кажется, самый первый».

Чего на самом деле хочет рекламодатель, т. е. наш Заказчик, - мы не знаем.

И хорошо, что не знаем. Да и не нужно нам это знать.

Мы знаем главное.

Для того чтобы наш Заказчик отдавал нам деньги со счастливым выражением на своем лице, нам нужен Переговорщик. Тот, кто в задушевной (или любой другой - можно называть ее как угодно) беседе сможет выведать у нашего Заказчика то, что мы, Разработчики, должны сделать для достижения этого счастья.

Так да здравствует Переговорщик - двигатель креативного процесса в российской рекламе!

Ирина Мезенцева, Открытое бюро