Копать глубже, чем в ТЗ
В моей жизни было несколько случаев, когда я ощущала полную беспомощность. Один из них — заказ кухни в новую квартиру.
— Здрасьте! Мне нужна кухня, вот макет.
— Так-так.. МДФ, ДСП, пластик? Эмаль, пленка? Фурнитура какая? Блюм? Китай? Из чего кромка? Доводчики надо?
— *Памагите*
Менеджер пытался понять, что мне нужно, а у меня случился настоящий взрыв мозга. В этой статье я поделюсь двумя инструментами, которые помогают досконально разобраться в задаче клиента и при этом не заставляют его чувствовать себя идиотом.
Инструмент №1: ТЗ
ТЗ, оно же техническое задание, — это ответ на вопрос «Что нужно сделать». ТЗ составляют и для разработчиков, и для маркетологов, и для дизайнеров. Заявка на изготовление кухни с указанием размеров, материалов и всех сопутствующих прибамбасов — это тоже ТЗ.
Кажется, что подробное техзадание нужно в основном исполнителю — этакая письменная грамота с указанием цели, во имя которой его нанимают. Но на мой взгляд, для заказчика ТЗ даже важнее, потому что вынуждает:
- дополнительно структурировать свои мысли,
- конкретизировать желаемый результат,
- обдумать и записать критически важные пожелания.
Иногда после такой подготовительной работы добавляются новые задачи, а иногда отпадает нужда к кому-либо обращаться.
Плохо, когда для исполнителя ТЗ превращается в священную корову. Представьте, клиент задает короткий вопрос, а в ответ получет «Сперва заполните бриф» и анкету в пять страниц с вопросами а-ля «Какое настроение у вашего бренда?» Не надо так. В своей работе я обычно использую ТЗ всего из шести вопросов:
1. Кто целевая аудитория?
Речь идет о конечном пользователе продукта: кто зайдет на ваш сайт, прочтет вашу статью или будет играть в вашу игру.
Так, например, аудитория этого поста — начинающие редакторы, контент-менеджеры и маркетологи. Для опытных редакторов тут вряд ли что-то покажется откровением. Если бы я изначально выбрала их своей ЦА, то пришлось бы менять и тему статьи, и глубину аргументации, и примеры.
2. Какая у пользователя проблема? Чего он хочет?
Если у пользователя нет проблемы, ему не нужен ваш продукт. Например, боль предполагаемых читателей этого поста — согласования, правочки или вовсе отказ заказчика принимать получившуюся работу.
3. В чем будет наша польза?
Грубо говоря, нафига это вообще делать? Как улучшится жизнь после использования вашего продукта (прочтения статьи и т.д.)? Благодаря этому пункту понимаешь, почему задача важна — это сильный психологический момент. Никто не хочет заниматься ненужной и неважной работой.
Еще с проработанным ТЗ удобно сверяться: «У меня получается то, что нужно? Или нет?» Когда нет четкого ориентира, приходится полагаться лишь на собственную интуицию. И ждать правок.
4. В каком виде нужен результат и когда?
Казалось бы, тут все просто. Но бывает и так:
Думать, что и так все ясно — большая ошибка. О сроках и формате готовой работы лучше договориться на берегу и чем конкретнее, тем больше шансов остаться довольными друг другом.
5. Какие есть ограничения?
Это могут быть жесткие сроки, после которых выполнение работы потеряет смысл, максимальный вес приложения для смартфона или требования бренд-менеджеров — в общем, все то, что обязательно нужно учесть, иначе вся работа псу под хвост.
6. Примеры (референсы, рефы)
Тут работает правило «Показывайте, а не рассказывайте». Попросите клиента дать ссылки на похожие работы или те, что ему нравятся, и попросите прокомментировать.
Представьте, клиент оказался лапушкой и заполнил все, что вы попросили. Не спешите радоваться и бросаться выполнять задачу. С любой структурой ТЗ есть одна большая проблема.
В ТЗ клиент сам описывает предполагаемое решение. Оно не всегда бывает правильным, потому что клиент не обязан быть экспертом в вашей профессии. А вы обязаны.
И вот поэтому нам нужен…
…инструмент №2: понимание задачи
В фильмах про шпионов обязательно есть момент, когда герои перед важным делом говорят: «А теперь давайте сверим часы». Я предлагаю поступать точно так же при работе над любым проектом.
Если честно, идею про понимание задачи я украла из курса «Работа с клиентом». И, кажется, не только я — ощущение, что про это не писал только ленивый. Но при том месяц назад у меня с повестки ушли два ТЗ, потому что заказчик в процессе обсуждения понимал, что выполненная работа его задач не решит. Зато одно «да тут делов-то» выродилось аж в три крупные отдельные задачи.
Понимание задачи — не ощущение в голове, что все понятно. Это документ. Составлять его нужно потому, что настоящая задача часто не совпадает и в 90% случаев не ограничивается тем, что изначально описывает клиент в своем ТЗ.
Потому что ТЗ — это ответ на вопрос «Что делаем?», а настоящая задача — на вопрос «Зачем?».
Статьи, лендинги, паблики, что угодно — не самоцель, а инструменты, выбор которых зависит от задачи. Наша цель на этом этапе — выяснить настоящую задачу заказчика и предложить под нее подходящее решение. Иногда подходящее решение — посоветовать специалиста другого направления.
Это ТЗ: Переписать текст сайта и сделать его «продающим». (Заказчик сразу предлагает решение).
Это настоящая задача: Поднять конверсию посадочной страницы. (Если не зацикливаться на предложенном решении, можно увидеть, что задача решается разными способами. Например, контекстной рекламой).
Как выяснить задачу и написать понимание
Мне известен только один способ — провести интервью. Можно по скайпу или вживую, но никаких переписок. Эксперты часто думают так: «Ой, да это неважно», «А это и так все знают». Важно. Не знают. Поверьте, в личном разговоре вы соберете намного больше интересных подробностей.
После интервью нужно письменно изложить свое видение задачи и попросить клиента его согласовать. Как правило, на этом этапе заказчик вносит правки или уточнения — это хороший знак. Он говорит о том, что вы только что избежали бесполезной работы не в том направлении. Все правки и уточнения нужно добавить в понимание и еще раз согласовать.
Еще в понимании обязательно прописывается время, когда вы сможете приступить, сроки выполнения и стоимость, в которую вы оцениваете работу. В моей практике пока был только один случай, когда человек согласился на запрошенную цену без лишних вопросов, поэтому лучше сразу морально подготовиться обсуждать деньги.
Подытожу:
- Даже подробное ТЗ не гарантирует, что вы не сделаете что-то не то.
- Не мучайте клиента брифами, проведите интервью и подготовьте понимание задачи.
- Без ТЗ, но с согласованным пониманием задачи работать можно.
- ТЗ плюс понимание задачи = мощное комбо.
Дайте знать, если заметка была вам полезна!
