Выключите свой снобизм: пять правил общения с клиентами
Клиент профессионалом не является и являться не должен. В этом убежден Стас Гольденшлюгер, сооснователь IT-студии Alef Development. В колонке он объяснил свою позицию и рассказал, какие ошибки допускают компании при работе с клиентами и почему нужно забыть профессиональную терминологию во время общения с ними.
Среди маркетологов или программистов обсуждение невменяемых заказчиков при встрече с коллегами по рынку стало чуть ли не частью этикета. Да, в жизни любой студии или агентства иногда возникают сложные клиенты. Я склонен думать, что эта сложность появляется, если в процессе работы у клиента было какое-то непонимание. Сделать так, чтобы непониманий не было, — задача исполнителя.
Более того, клиент не обязан знать, что он хочет. Он может передумать, путаться в терминологии, хотеть нелогичных вещей, не понимая их нелогичности. Дело в том, что профессионалом в этой коммуникации должен быть только исполнитель. Клиент профессионалом не является и являться не должен. И задача исполнителя — упростить обсуждение до такого уровня, чтобы человек, не обладающий специальными знаниями, мог принимать взвешенные решения.
Выключите свой снобизм
Да, вы можете классно разбираться в проектировании баз данных и говорить о них часами, а собеседник в это время будет себя чувствовать запутанным и беспомощным.
Фото: Unsplash
У нас был совместный проект с другой IT-командой: мы отвечали за разработку мобильного приложения, они делали сервер. Обсуждения вели в общих чатах и на живых встречах. Другая команда периодически пыталась поставить клиента на место: показать, что тот задает банальные вопросы, на которые каждый должен знать ответ.
Разработчик даже не стеснялся закатывать глаза.
В итоге они потеряли клиента, которому не понравилась их заносчивость, а мы делали и приложение, и сервер.
Забудьте про терминологию
Никакой инкапсуляции, полиморфизма, наследования, конверсии, баз данных и прокси. Клиенту может быть неловко вас переспрашивать, если он что-то недопонял, поэтому лучше показывать, чем рассказывать, и к каждому слову приводить пример или аналогию.
Если вы говорите про браузер, то перечислите Firefox, Opera и Chrome. Если объясняете клиенту про базу данных, то проведите аналогию с экселевской табличкой.
Я готов поспорить, что программистов из первого примера оставила без проекта не только их заносчивость, но и слово «консистентность». Они употребляли его в разговоре, чтобы показать свой профессионализм. Не надо напускать туман на клиента, ему приятно, когда все понятно.
Структурируйте информацию
Если отправить клиенту 300-страничное техзадание, то он его не прочитает. А если и прочитает, то не поймет. В конце концов клиент подпишет ТЗ с мыслью «я доверяю этой команде, поставлю подпись не читая». Когда он увидит готовый продукт, то может с чем-то не согласиться и обвинит в этом вас. У него будет чувство, как будто ему подсунули договор с мелким шрифтом, а теперь выворачивают руки.
Фото: Unsplash
Техзадание должно быть разбито на небольшие части с обилием иллюстраций и минимумом терминов. Мы реализовали этот принцип в своей внутренней разработке Voodoo: там клиент по очереди утверждает ТЗ, схему и дизайн каждой страницы сайта или экрана мобильного приложения.
Ему нужно сделать только одно действие — нажать галочку, если все устраивает, или крестик, если требуются доработки.
Когда человек фокусируется на маленьком объеме информации, его решения становятся более взвешенными — уменьшается риск недопониманий между заказчиком и исполнителем.
До введения Voodoo сдача проектов занимала в три раза больше времени, потому что клиент хуже представлял себе конечный результат и имел к нему больше вопросов и корректив.
Скрин проекта в Voodoo
Показывайте промежуточные результаты
Присылайте клиенту предварительные версии или видеозаписи работы программы, таким образом в день сдачи на него не обрушится слишком много информации.
Если в процессе работы выяснится, что в ТЗ что-то было неверно записано и требуется внести изменения, лучше об этом узнать как можно раньше.
Аналогия: вы заказали портрет у художника. На работу уйдет три месяца. Если он будет показывать вам наброски, то ко дню финальной приемки вы будете представлять примерный результат. Если же художник запрется в комнате и будет рисовать тайно, то портрет вас удивит: на нем вы можете оказаться голым, верхом на белом медведе и с мечом в руке.
Промежуточные демонстрации помогают избежать ситуаций, где заказчик и исполнитель по-разному видят конечную цель.
Не делайте доработки на скорую руку на финальном этапе
Это важное правило можно подать и по-другому — не делайте клиентам подарков. Подарки очень часто приводят к конфликтам. Звучит парадоксально, согласен. Проще объяснить на немного утрированном примере. Клиент просит добавить на сайт кнопку «обратный звонок».
«Работы на пять минут, почему бы не сделать ему такой подарок», — думает менеджер и соглашается.
Программисты делают кнопку, затем клиент просит ее немного передвинуть в сторону, потому что ее не было на дизайне, и мы не знаем, куда ее лучше поставить. Верстальщик ее двигает. Но поскольку это подарок и его делают без всяких формальностей — сайт забывают перетестировать, и эта кнопка ломает верстку на айфонах.
Фото: Unsplash
На данный момент клиент уже недоволен многократным передвижением кнопки, а теперь он еще увидел баг. К тому же пока мы занимались этой кнопкой, прошло два дня, и клиент вспомнил, что день сдачи проекта был позавчера.
Конечно, ему уже неважно, что эта кнопка делается бесплатно. Зато он может смело утверждать, что вы все делаете с пятого раза, неаккуратно и срываете сроки. Вот такой подарок вышел.
Разработка — дело для педантов. Если нужно исправить деталь в проекте, эту задачу стоит зафиксировать и оценить по времени. Клиент должен быть предупрежден об изменении срока, дизайнер должен сделать макет и так далее по всему конвейеру.
Как окружить себя понимающими и отзывчивыми клиентами?
- Выключите снобизм и примите как факт неосведомленность клиента об основах программирования.
- Говорите простыми словами и приводите примеры.
- Не перегружайте информацией, а выдавайте ее структурированно и по делу.
- Показывайте промежуточные результаты.
- Педантично проводите даже самые маленькие пожелания клиента по всем стадиям разработки.