Выключите свой снобизм: пять правил общения с клиентами

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

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

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

Выключите свой снобизм

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

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

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

Забудьте про терминологию

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

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

Структурируйте информацию

Если отправить клиенту 300-страничное техзадание, то он его не прочитает. А если и прочитает, то не поймет. В конце концов клиент подпишет ТЗ с мыслью «я доверяю этой команде, поставлю подпись не читая». Когда он увидит готовый продукт, то может с чем-то не согласиться и обвинит в этом вас. У него будет чувство, как будто ему подсунули договор с мелким шрифтом, а теперь выворачивают руки.

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

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

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

Скрин проекта в Voodoo

Показывайте промежуточные результаты

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

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

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

Не делайте доработки на скорую руку на финальном этапе

Это важное правило можно подать и по-другому — не делайте клиентам подарков. Подарки очень часто приводят к конфликтам. Звучит парадоксально, согласен. Проще объяснить на немного утрированном примере. Клиент просит добавить на сайт кнопку «обратный звонок».

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

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

Разработка — дело для педантов. Если нужно исправить деталь в проекте, эту задачу стоит зафиксировать и оценить по времени. Клиент должен быть предупрежден об изменении срока, дизайнер должен сделать макет и так далее по всему конвейеру.

Как окружить себя понимающими и отзывчивыми клиентами?

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