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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тексты и подсказки в интерфейсе — это обычная редакторская задача 

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

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

Читать дальше

Самое сложное ★ 

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

Раньше я не понимал, почему люди не могут начать. А меня все просили, ну напиши пост, как справиться с писательским блоком. Мол, хочу вот важные темы осветить, но никак не могу сесть и начать. Я говорил что-то вроде: «Ну, просто садись и пиши, рано или поздно напишешь». Так вот забудьте мой совет — это полная хуйня.

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

Представим, что вы хотите написать статью про налоги для ИП. У вас же нет задачи написать, что «налоги — это плохо», а есть задача раскрыть тему, показать разные нюансы налогообложения для ИП. Желательно так, чтобы предприниматели пришли, прочитали и поняли, что им делать, чтобы не нарваться на штраф и не потерять лишние деньги.

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

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

О продающих текстах в последний раз ★ 

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

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

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

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

Если клиент или руководитель просит вас написать продающий волшебный текст с огоньком, спросите его: «А что это значит? Что вы имеете ввиду под продающим текстом? А в чём будет заключаться „огонёк“? Какой результат он по-вашему даст? Как люди узнают о вашем тексте?» И тут небольшой совет: так нужно поступать с любым текстом.

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

— Коль, чё-то текст не очень продающий…
— Ща я туда огоньку добавлю и причастных оборотов сверху накину!

Под диктовку ★ 

Делать что-то под диктовку, значит — деградировать. Например, вносить правки от главреда или двигать пиксели по указке арт-директора. Это полный пиздец. Даже если эта работа будет сделана, в 99% случаев получится плохо. Потому что сотрудник, которому не доверяют, выполнит задачу максимально наотъебись.

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

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

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