Колонки

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

Колонки
Стас Гольденшлюгер
Стас Гольденшлюгер

Сооснователь Alef Development

Полина Константинова

Клиент профессионалом не является и являться не должен. В этом убежден Стас Гольденшлюгер, сооснователь IT-студии Alef Development. В колонке он объяснил свою позицию и рассказал, какие ошибки допускают компании при работе с клиентами и почему нужно забыть профессиональную терминологию во время общения с ними.

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

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

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

Подписывайтесь на канал Rusbase в «Яндекс.Дзен», чтобы ничего не пропустить

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

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

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

Фото: Unsplash

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

Разработчик даже не стеснялся закатывать глаза.

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

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

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

Если вы говорите про браузер, то перечислите Firefox, Opera и Chrome. Если объясняете клиенту про базу данных, то проведите аналогию с экселевской табличкой.

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

 

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

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

Фото: Unsplash

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

Ему нужно сделать только одно действие — нажать галочку, если все устраивает, или крестик, если требуются доработки.

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

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

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

 

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

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

Если в процессе работы выяснится, что в ТЗ что-то было неверно записано и требуется внести изменения, лучше об этом узнать как можно раньше.

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

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

 

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

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

«Работы на пять минут, почему бы не сделать ему такой подарок», — думает менеджер и соглашается.

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

Фото: Unsplash

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

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

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

 

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

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

Материалы по теме:

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Актуальные материалы —
в Telegram-канале @Rusbase

ПРОГРАММЫ И КУРСЫ

18 — 20 ноября 2019

INTR: Основы Hadoop

18 ноября 2019 — 18 января 2020

Основы работы с цифровыми правами