Тег «понимание задачи»

Сними шелуху

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

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

Сравните эти фразы:

— Нам нужно заняться маркетингом!
— У нас третий месяц падают продажи. Раньше рассылка давала результат, а теперь перестала. Есть гипотеза, что…

— Мы сейчас делаем маркетинговое исследование! Это очень важно!
— Мы изучаем, как люди ведут себя в наших магазинах, что покупают на кассе, а что берут с доставкой. Исследование поможет нам понять…

— А давайте подключим к проекту маркетолога, чтобы он тоже давал замечания дизайнеру?!
— Предлагаем перед дизайном обсудить основные смыслы со специалистами, которые отвечают за настройку рекламы. Это поможет нам сформировать у людей цельный образ…

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

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

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

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

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

Мантра счастья, радости и просветления

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

Мантра скучная, но безотказная. В ней всего четыре шага:

  1. Выгрузить своё понимание задачи и возможные решения из головы. Написать текстом, что именно я планирую делать, по шагам: какие страницы будут рисовать, какие тексты писать, что будет делать эта кнопка, какие сценарии будут.
  2. Составить список «кроличьих нор». Так называются моменты, которые я упустил, и вопросы, на которые у меня нет ответа. Они сами всплывают в голове, пока я пишу план действий. Важно их сразу записать.
  3. Задать проверочные вопросы. Иногда кажется, что всё понятно. Тогда я задаю себе наводящие вопросы. Чего я не знаю? Что я не понимаю в этом решении? На что у меня нет ответов? Всегда находится два-три нюанса, о которых я не подумал.
  4. Отправить понимание задачи заказчику. Заказчиком может быть кто угодно: дизайнер, автор, разработчик, внешний клиент. Вне зависимости от статуса и должности я передаю ему свои мысли с просьбой: «Посмотри, всё ли верно я понимаю? Ничего ли я не упустил? Возможно, что-то из этого не подходит». Что-нибудь обязательно не подойдёт.

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

Пользуйтесь. А я пока кофе попью.

Зачем и почему 

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

Как понять, какой продукт решит проблему заказчика? 

Читательница Юлия прислала вопрос: «Как понять какой инфопродукт решит проблему заказчика? Например: клиент набирает людей, чтобы летом собирать клубнику в Финляндии. Я взяла у него интервью, знаю цели и проблемы. Как мне понять теперь что ему нужно: сайт, лонгрид, статья, подкаст?»…

Что мы не делаем ★

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

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

Не сделать лишнего помогает такой приём — добавить в понимание задачи пункт «Что мы не делаем». Не просто обсудить с клиентом, мол, да-да, вот эту интеграцию с ЦРМ пока делать не будем, а прям записать в документ в отдельный пункт с деталями. Многим это кажется странным, мол, я-то точно не забуду. Забудете.

Люди всё забывают и очень быстро.

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

Вот план действий на случай, если клиент пришёл с задачей, которую вы отложили:

  1. Не бросать текущие задачи и не бежать сломя голову чего-то там делать, рисовать и писать.
  2. Пойти посмотреть, что вы писали в понимании задачи и о чём договорились.
  3. Вернуться к клиенту с ответом: «Да, Иван Иваныч, понимаем, но мы с вами решили пока это не делать. Можем взять в следующий спринт, цикл, вынести в отдельный проект, когда закончим текущий».

Конечно, всё это будет работать, только если вы прикрепляете и подписываете понимание задачи к договору в качестве приложения. Без договора клиент может нагнуть вас как хочет: требовать любую работу, менять условия и в принципе вам не платить.

История про бронекофе 

Меня упрекают, что вот я постоянно говорю про понимание задачи. Окей, зайду с другой стороны. Вот вам лайфстайл-история не про понимание задачи…

Понятное дело, разумеется и конечно

Однажды в кафе я наблюдая наблюдал примерно такой диалог:

Заказчик: А вы оптимизируете тексты под СЕО перед публикацией?
Исполнитель: Ну, разумеется.

Заказчик: Нам ещё мобильная версия нужна, знаете…
Исполнитель: Понятное дело.

Исполнитель: Планируете ли вы отдавать тексты на вычитку корректору?
Заказчик: Конечно, а вы как думаете?

Хуечно, блять. Терпеть не могу, когда на встрече кто-то отвечает так, будто ему лень объяснять свой подход и рабочий процесс. И наоборот, когда в ответ на уточняющий вопрос прилетает «а вы как думаете?»

Пиздец, нельзя так общаться с людьми. Если вам задают банальный вопрос, никогда не обламывайтесь ответить развёрнуто. Даже если для этого придётся просто повторить то, что сказал собеседник. В этом и суть коммуникации — подтвердить, что а) вы слышали, что сказал человек, б) вы поняли, что он имел ввиду.

Ретрансляция — охуенный приём, без которого невозможна нормальная коммуникация. Когда кто-то обламывается его использовать, он подрывает компетентность другой стороны и уместность самого вопроса. Это почти как сказать человеку: «Ты чё тупой?» Вместо этого лучше ответить детально и по делу:

Заказчик: А вы оптимизируете тексты под СЕО перед публикацией?
Исполнитель: Да, мы анализируем запросы через Яндекс Вордстат и потом пишем тексты с этими запросами.

Заказчик: Нам ещё мобильная версия нужна, знаете…
Исполнитель: Да, понимаем, сейчас 50% трафика — мобильные устройства. Мы продумываем мобильную версию на этапе визуальной концепции, а потом готовим макеты в пяти разрешениях, чтобы сайт выглядел хорошо на любом устройстве.

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

Клиент не знает, как вы работаете. Возможно, в его жизни были только исполнители-мудаки, и потому он теперь переживает и всё уточняет. Исполнитель, в свою очередь, ничего не знает про бизнес заказчика и его возможности и ожидания от результата. Уточняющие вопросы помогают убедиться, что вы понимаете друг друга.

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

Как понять, какой инфопродукт решит проблему заказчика?

Читательница моей рассылки Юлия Упорова прислала вопрос:

Как понять какой инфопродукт решит проблему заказчика? Например: клиент набирает людей, чтобы летом собирать клубнику в Финляндии. Я взяла у него интервью, знаю цели и проблемы. Как мне понять теперь что ему нужно: сайт, лонгрид, статья, подкаст?

С её согласия публикую его здесь вместе с ответом.

Сейчас в описанной вами ситуации не хватает информации о том, как задачу формирует сам клиент. Какую задачу он, в итоге, хочет решить? Я осмелюсь предположить, что цель клиента — привлечь людей на сбор клубники. Он им за это что-то заплатит, а потом продаст клубнику с наценкой, на чём и заработает. Это может быть не совсем так, но детали здесь не сильно важны.

Если всё так, то чтобы найти наилучшее решение, я бы следовал примерно такому плану:

  1. Составить понимание задачи. Как сформулировал задачу сам клиент? Почему он её так сформулировал? А что на самом деле он хочет получить, какую проблему хочет решить: привлечение клиентов, привлечение людей для сбора клубники или что-то ещё?
  2. Определить, что будет результатом проекта. Как клиент будет оценивать результат? По какой метрике? Сколько людей ему нужно найти, чтобы считать, что вы справились с задачей?
  3. Определить ЦА. Кто эти люди, кто обычно едет в Финляндию собирать клубнику? Где они живут, чем занимаются, как наладить с ними контакт? Почему клиент считает, что именно эти люди поедут собирать клубнику? В чём их мотивация?
  4. Изучить поведение и привычки ЦА. Как эти люди потребляют информацию: радио, ТВ, интернет? В каком виде они её потребляют: аудио, видео, мемы, текст? Что они читают и смотрят? На каких площадках? Какой язык коммуникации для них уместен?
  5. Выбрать решение. Это может быть не только рассылка, текст или лендинг, но и реклама на ТВ, реклама в подъездах, реклама на радио или в дачных автобусах и т. д. Решение определяется множеством факторов и особенностей контекста, в котором существует бизнес клиента.

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

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

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

Объяснил, отдал и забыл

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

У меня есть простой принцип, который помогает не волноваться и делегировать всё, что только можно. Принцип звучит так: сделай всё, чтобы задача была сделана хорошо, отдай её и забудь. Можно сократить его до «объяснил, отдал и забыл», что тоже верно.

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

Только так можно проверить, умеет человек работать или нет. Именно так я проверяю всех ребят, которые приходят в студию: я просто даю им небольшую боевую задачу. Справятся — будем жить. Не справятся — значит ещё не время нам работать вместе.

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

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

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

В такие моменты у неопытных исполнителей: менеджеров, дизайнеров, редакторов — случается стресс и замыкание. Они бегут к своему ноутбуку и начинают создавать видимость работы: пишут текст, рисуют дизайн, пишут клиенту коммерческое. Мол, потом разберёмся, что там нужно. Главное же, что я работаю, решаю задачу! И вроде как не придраться: дизайнер ведь и правда чего-то там рисовал, редактор что-то писал, а менеджер вёл какие-то переговоры с заказчиком и что-то ему отправлял.

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

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

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