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

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

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

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

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

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

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

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

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

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

Не знаешь, что делать — не делай ничего

Свежий пример из редакторской практики:

Автор присылает на провереку пост, где есть перечень из четырёх пунктов. Три пункта — хорошие, с примерами и фактурой, а четвёртый — дохлый, на одну строчку. Рядом с остальными пунктами перечня он выглядит неуверенно, неполноценно.

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

Снова пишу комментарий. Автор начинает двигать слова, но это не помогает. Так продолжается какое-то время, пока я не задаю вопрос: «А какую проблему ты пытаешься этим решить?» Оказалось, автор был уверен, что должен перебрать как можно больше решений. Это частое заблуждение.

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

Вот несколько примеров:

  1. В списке появился куцый пункт, и вы не знаете, что туда дописать — уберите этот пункт. Это лучше, чем оставить прежний список с дохлым пунктом.
  2. В макете есть экран с плохой компоновкой, запуск уже через неделю, и вы понимаете, что со всеми согласованиями разработчики не успеют выкатить эти изменения в срок. Передоговоритесь с клиентом о том, чтобы запустить сайт без этого экрана. Это лучше, чем отложить пуск.
  3. Вы сели писать письмо другу, но слова не складываются в текст. Значит, сегодня явно не тот день, чтобы страдать над белым листом. Отложите письмо, займись другими делами. Это лучше, чем отправлять вымученное письмо.

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

Ошибка на старте. Отправить клиента заполнять бриф ★

Начинаю серию бесплатных постов про ошибки на старте проекта. Планирую около 5−6 постов, но может и больше. Тут уж как пойдёт. Первый — про брифы и техзадания.

Кратко

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

Подробно

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

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

Другая проблема в том, что в 99% случаев брифы не помогают сделать проект хорошо. Клиенты заполняют их наотъебись, упуская важные детали. И они не со зла: у них нет времени на ещё одну анкету, и они в самом деле не знают, что важно для проекта, а что нет. Потому и пришли к исполнителю, чтобы тот помог разобраться, взял часть ответственности и помог.

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

Некоторые клиенты могут использовать техзадания в качестве аргумента в переговорах о стоимости. Мол, вот это нам обещали сделать за пять рублей в студии «Пурпурный карась», давайте и вы так же. Я в такие моменты отвечаю: «Так, а зачем покупать у меня? Идите туда и делайте за пять рублей там. У меня это стоит вот столько».

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


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

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

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

Мы планируем нашу проектную загрузку… 

Иногда клиенты пропадают. Ничего с этим не поделать, хотя очень хочется…

Нихуя непонятно

Лучший момент на встрече, когда клиент говорит, что ему нихуя непонятно. Если вы слышите такое, это хороший знак, и вот почему:

  1. Клиент с вами честен и прям. Он вам доверяет и знает, что вы спокойно воспримете даже такой ответ. Клиент, который вам не доверяет, никогда так не скажет, да ещё и матом.
  2. Клиент только что сообщил «У нас проблема». Вам осталось лишь её определить и устранить.
  3. Клиент только что сообщил: «Вы не попали в цель». Это может означать, что решение слишком сложное или что клиент ожидал увидеть что-то другое.

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

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

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

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

О заботливом редакторе и клиенте-красавчике 

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

Мы не сможем так сделать ★

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

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

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

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

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

Чрезмерная осторожность

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

  • Кажется, что мы сорвали дедлайн.
  • Вероятно, вам стоит начать с развития соцсетей, а не сайта.
  • Сейчас как будто бы реклама не работает.

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

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

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

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

  • Мы сорвали дедлайн. Вот что мы можем сделать…
  • Начинать нужно с раскрутки группы в ВК, а не сайта, потому что…
  • Реклама не дала ожидаемого результата. Предлагаем…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заткнись и слушай

Лучший совет, который можно дать начинающему автору, дизайнеру и любому другому исполнителю перед встречей с заказчиком: «Заткнись и слушай».

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

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

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

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

Фиксируй важные мысли, уточняй детали, объясняй риски, аргументируй. Но не дави. Это простое знание поможет избежать неоправданных конфликтов и напряжения. И только так формируется настоящее доверие.