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

Как двигать проект вперёд и не страдать 

Ситуация в проекте с клиентом прямо сейчас:

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

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

Какие тут можно сделать выводы:

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

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

Нет комментариев 1 мес

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

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

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

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

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

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

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

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

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

Нет комментариев 3 мес

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

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

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

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

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

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

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

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

Нет комментариев 5 мес

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше материалов в платном блоге на Бусти за 250 ₽/мес →

Нет комментариев 6 мес

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

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

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

Кратко

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

Подробно

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

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

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

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

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

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

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

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

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

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

Больше материалов в платном блоге на Бусти за 250 ₽/мес →

Нет комментариев 6 мес

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

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

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

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

Нет комментариев 8 мес

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

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

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

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

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

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

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

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

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

Нет комментариев 8 мес

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

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

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

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

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

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

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

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

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

Нет комментариев 8 мес

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

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

Кратко

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

Подробно

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

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

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

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

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

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

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

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

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

Больше материалов в платном блоге на Бусти за 250 ₽/мес →

Нет комментариев 9 мес

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

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

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

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

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

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

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

Нет комментариев 2022