Тег «работа с клиентом»

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

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

Кратко

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

Подробно

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

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

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

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

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

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


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

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

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

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

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

Где фрилансеру найти клиентов, если «сарафанное радио» молчит? 

Вопрос от читателя моего платного блога…

Платные консультации по управлению, коммуникации, найму и не только ★

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

В первую очередь, я буду полезен в вопросах управления и построения процессов:

  • Управление проектами. Расскажу, как мы в студии ведём проекты, запускаем их в срок, не уходим в минус. Разберу вашу ситуацию, предложу решение и подскажу, как перестроить процесс, если ситуация повторится.
  • Управление командами. Укажу на слабые места в процессах и посоветую, как их усилить. Дам рекомендации и действующие практики, которые помогут выстроить эффективные процессы в команде.
  • Коммуникация и решение конфликтов. Покажу, как строить коммуникацию с заказчиками так, чтобы и защищать свои интересы и не давать себя в обиду. Помогу найти выход из конфликтной ситуации и объясню, почему вы туда попали и как действовать в подобных ситуациях в будущем.
  • Найм. Поделюсь опытом в найме дизайнеров, авторов и редакторов, оценке их работы и построении процессов внутри творческого коллектива.

Также помогу с прикладными задачами в дизайне, вёрстке и редактуре:

  • Дизайн и брендинг. Создание логотипов, разработка сайтов, лендингов и названий для бизнеса. Помогу понять, нужен ли вам сайт или айдентика, какие решения есть на рынке, которые не требуют продать почку.
  • Редактура и контент-маркетинг. Запуск корпоративного медиа, продвижение в социальных сетях, реклама. Нужен ли компании блог или медиа, с чего начать, сколько это примерно стоит.
  • Визуальное повествование. Расскажу, как донести пользу вашего продукта до клиентов простым языком в статьях, рассылках, презентациях, на сайтах и лендингах. Разберу ошибки в письмах, макетах, объявлениях и пр.

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

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

Результат. Предлагаю два варианта на выбор:

  1. Ссылка на Гугл-документ с планом действий и решениями, которые я озвучу на встрече.
  2. Запись встречи. Можно хранить у себя и пересматривать, но нельзя публиковать.

Цена и условия. Часовая консультация для частных лиц и ИП — стоит 15 000 25 000 ₽, для компаний — 30 000 50 000 ₽. Предоплата на счёт ИП или карту, без НДС.

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

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

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

Заказать консультацию →

Иногда люди не знают, что можно по-другому 

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

Еженедельные встречи с заказчиком — пульс проекта ★

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

Договариваться о каждой встрече отдельно

Подход даёт гибкость в планировании, но если в проекте больше двух человек, согласовывать день и время встречи становится нудно и утомительно. Однако это не самое страшное.

В начале проекта встречи проходят более-менее регулярно, но чем дольше идёт проект, тем реже встречи. Иногда между двумя встречами возникают перерывы в две-три недели, иногда — в месяцы. Я называю их «дырами». Чем больше «дыра», тем хуже взаимопонимание и коммуникация, тем меньше доверия в проекте.

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

Заказчик думает: «Раз они три недели молчали, значит, скорее всего что-то очень долго делали. Наверное, сейчас покажут мне крутые дизайны!»

Дизайнер в свою очередь думает: «Мы три недели рисовали макет, тут всё идеально. Сейчас его примут без правок!»

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

Встречаться раз в неделю в одно и то же время

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

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

Встречи каждую неделю в одно и то же время решают проблемы, присущие хаотичному планированию:

  • Снижается тревожность и беспокойство участников проекта. Клиент знает, над чем вы работаете или где возникли сложности и как вы с ними справляетесь. Исполнитель знает, что творится у клиента, учитывает контекст и корректирует решение и свои действия под этот контекст. Всё потому, что в коммуникации нет «дыр».
  • Повышается управляемость, снижается цена ошибки. Благодаря тому, что все в курсе, как идёт проект, растёт доверие между участниками проекта. Заказчик и исполнитель работают в тандеме, на благо проекта, вместе принимают решения и делят ответственность. Никто не ищет виноватых.
  • Не нужно согласовывать время для каждой встречи. Выбрали, создали в календаре повторяющуюся встречу и забыли. Это освобождает кучу времени на более полезные дела.

Еженедельные встречи позволяют делать проект поступательно, без стресса. И вы и клиент знаете, что в понедельник, в 15:00 будет встреча и вы принесёте макет, а клиент даст замечания. Даже если вы ничего принесёте, то обсудите, почему не получилось принести. Это будет честно и открыто, без утайки.

Вывод

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

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

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


Пост вдохновлён постом Лиды Поповой «Пациент скорее жив, чем мёртв»

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

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

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

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

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

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

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

Мизанплас

У меня есть негласное правило — превращай всё в систему. Это можно сравнить с тем, что шеф-повара называют мизанплас (фр. mise en place) — «укладка на место» или «всё на своих местах». Это состояние кухни, когда все ингредиенты, утварь и приборы, необходимые для приготовления блюда, лежат на своём месте. Шеф не думая протягивает руку и берет нужную посудину или нож. Так же должно быть и в проектах.

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

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

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

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

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

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

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

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

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

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

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

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