УправлениеПереговоры

Разреши себе быть глупым

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

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

Задавать глупые вопросы мне помогает установка: будь самым глупым на этой встрече.

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

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

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

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

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

Что делать, если в проекте затык: советы для дизайнеров, авторов и руководителей 

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

Легко, там работы на денёк! ★

Одно из правил, которого я придерживаюсь в проектах и переговорах: не говорить о чём-либо «это легко» и не оценивать чью-либо работу этим словом. Ни свою, ни чужую. Особенно, если я никогда не делал то, о чём говорю.

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

Легко — это контракт с клиентом, что вы соглашаетесь выдать безупречный результат в короткий срок и без права на ошибку. Хуже только работать без договора или по бартеру. Именно поэтому «легко» так убийственно для проекта. Оно создаёт завышенные ожидания и не учитывает, что что-нибудь обязательно пойдёт не так. А что-нибудь всегда идёт не так.

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

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

Не спешите давать оценки. Возьмите время оценить задачу, учитывая все детали и контекст. Особенно, если работу будете делать не вы, а кто-то другой. И уж точно не говорите о своей работе: «Ой, легкотня!» Каждый раз, когда я думал так, случалось ровно наоборот.

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

Ошибка на старте. Наврать клиенту про опыт ★

Читаю рассылку одного агентства и вижу такой совет:

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

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

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

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

Это если в общем. Теперь по фактам. Вот как я советую поступать, если нет опыта.

Совет № 1. Снизить ожидания от результата

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

— А вы раньше писали статьи о коммерческой недвижимости?
— Пётр Алексеевич, знаете, нет, я прежде не писал на эту тему. Я понимаю, что, возможно, вам нужен автор с опытом в этой сфере. Но если у нас будет эксперт по теме, то вот как бы я решал вашу задачу… Можем для начала написать первую статью и посмотрим, как пойдёт. Если будет не очень, то расстанемся.
— Эксперты у нас есть. Давайте пробовать.

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

Совет № 2. Опыт и цена никак не связаны

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

Цена — это про договорённости с самим собой и заказчиком, а не про опыт, часы, знаки или что-то там ещё. Если мне комфортно сделать работу за Х денег и заказчика это устраивает, то я её делаю. А если нет, то не делаю. Всё просто.

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


Что это такое?

Серия бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Вот оглавление:

  1. Отправить клиента заполнять бриф
  2. Как пропадать правильно
  3. Не сообщать о проблемах
  4. Наврать клиенту про опыт — вы здесь

Ошибка на старте. Не сообщать о проблемах ★

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

Ниже инструкция о том, как не быть мудаком и пропадать правильно.

Кратко

Как только вы поняли, что у вас проблема, сообщите о ней руководителю или заказчику. Предупредите, что у вас что-то идёт не по плану, и нужен новый. Хорошо, если вы не просто придёте со словами «у меня проблема, помогите», но ещё и предложите решение и возьмёте на себя ответственность. Иначе пользы от вашего предупреждения мало.

Подробно

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

  1. Не сообщают никому о ситуации.
  2. Пропадают с радаром и не выходят на связь.
  3. Не отвечают на сообщения и звонки.
  4. Появляются в день дедлайна с оправданиями.

Чаще всего они мямлят что-то вроде:
— У меня заболела бабушка, прорвало трубу, я заболел…
— Мне казалось, что я успею…
— Я не хотел тебя тревожить по мелочам…

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

Вот как следует поступать, если у вас проблема, вы заболели, буксуете с задачей или ещё по какой-то причине не успеваете сдать работу в срок:

  1. Сообщить о проблеме. Расскажите коллеге, руководителю или клиенту о проблеме в тот же момент, как она возникла. Не надо ждать завтра или пока всё разрешится само собой. Дайте знать, что есть ситуация, которая может навредить проекту, если ничего с ней не делать.
  2. Описать ситуацию и предложить решение. Если работаете в команде — делегировать задачу кому-то, кто может подменить вас на время жопы. Такая опция есть не всегда, поэтому скорее всего придётся проявить смекалочку и найти решение самому.
  3. Сформировать ожидания. Сообщите клиенту и остальным коллегам, сколько времени вас не будет, как с вами связаться и к кому обратиться, пока вас нет. Большая часть проектной работы с заказчиком или в команде — это управление. Не обязательно самим проектом или людьми, а, в первую очередь, собой, своим процессом, задачами и ожиданиями других людей.
  4. Отвечать на сообщения и звонки. Гасятся только мудаки. Ну и все эти отмазки про «не было связи» звучат смешно в 2023 году, когда связь есть уже в любой деревне.
  5. Решить проблему. Без спешки и с чистой совестью перед командой и клиентом. Помните: спешка ебёт горячку.

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


Что это такое?

Серия бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Вот оглавление:

  1. Отправить клиента заполнять бриф
  2. Как пропадать правильно
  3. Не сообщать о проблемах — вы здесь
  4. Наврать клиенту про опыт

Ошибка на старте. Как пропадать правильно ★

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

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

  • Не сообщают никому о ситуации.
  • Пропадают с радаром и не выходят на связь.
  • Не отвечают на сообщения и звонки.
  • Появляются в день дедлайна с оправданиями.

Чаще всего они мямлят что-то вроде:

— У меня заболела бабушка, прорвало трубу, я заболел…

— Мне казалось, что я успею…

— Я не хотел тебя тревожить по мелочам…

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

Как следует поступать, если у вас проблема: вы заболели, буксуете с задачей или ещё по какой-то причине не успеваете сдать работу в срок.

1. Сообщить о проблеме. Расскажите коллеге, руководителю или клиенту о проблеме в тот же момент, как она возникла. Не надо ждать завтра или пока всё разрешится само собой. Дайте знать, что есть ситуация, которая может навредить проекту, если ничего с ней не делать.

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

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

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

5. Решить проблему. Без спешки и с чистой совестью перед командой и клиентом. Помните: спешка ебёт горячку.

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


Что это такое?

Серия бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Вот оглавление:

  1. Отправить клиента заполнять бриф
  2. Как пропадать правильно — вы здесь
  3. Не сообщать о проблемах
  4. Наврать клиенту про опыт

Презентация дизайна: ошибка, из-за которой ваш дизайн не принимают. Часть I 

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

Презентация дизайна: как работать с замечаниями. Часть II 

Презентация дизайна: ошибка, из-за которой ваш дизайн не принимают. Часть I…

Не правки, а замечания и вопросы

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

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

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

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

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

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

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

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

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

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

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

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