Распространенные ошибки в общении с клиентом: как не расстроить клиента

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

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

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

Не ошибитесь в базовом общении с клиентами

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

Если старый друг гостит у вас дома, и вы соглашаетесь отведать местные деликатесы «на старом месте» в полдень, через несколько недель, вы бы просто появились там? Не могли бы вы оставаться на связи в то же время, позвонить, чтобы подтвердить несколько дней? Или, может быть, вы предположили бы, что они слишком заняты, и не хотели бы беспокоить их без уважительной причины? Вы ожидаете, что они дадут вам знать, когда они прибудут?

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

В какой-то момент вы наверняка сталкивались с подобными ситуациями и в профессиональном общении, даже с давними партнерами и коллегами. Некоторые проекты выполняются с минимальным общением, например, говоря «обычно, в полдень, увидимся там», чтобы подтвердить легкий обед. Даже если что-то случится, другая сторона обязательно даст вам знать, и вы согласитесь перенести свидание.

Однако в мире разработки программного обеспечения все не так просто и линейно.

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

Хотя иногда это должно вызывать неловкость, поговорить с клиентом не помешает, даже если у вас нет ничего необычного, о чем нужно сообщить! У вас есть сомнения по поводу одного крошечного пункта пользовательской истории? Если вы считаете, что это важно, дайте им знать. Вы немного опаздываете и не уверены, сможете ли вы уложиться в предполагаемую дату, о которой договорились? Срочно звоните клиенту! Лучше бы они узнали об этом сразу.

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

Плохая коммуникация с клиентами порождает нереалистичные ожидания

Итак, в начале я упомянул, что у клиента наверняка есть много ожиданий от проекта, верно? Верно. Период.

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

Вот короткая параллель: вы купили планшет онлайн, и вам пообещали доставку в течение 10 дней. На 8-й день магазин сообщает вам о проблеме и задерживает доставку на неделю. Чтобы компенсировать вам неудобства, продавец обещает предоставить вам магазинный кредит в размере 75 долларов.

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

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

"Какой? Буквально вчера ты сказал мне, что я получу лучшую сделку! Это не честно! Я уже сказал детям…»

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

Как разработчикам, особенно фрилансерам, избежать подобных ситуаций в общении с клиентами?

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

• Слушайте клиента.

• Проанализируйте их проблему.

• Проанализируйте предложенное решение.

• Убедитесь, что это в рамках бюджета/графика.

• Наконец, продолжайте и представьте свое предложение.

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

Не думайте, что вы знаете, что нужно клиенту

Перефразируя Мэри Шмих, Леди и джентльмены класса 17: Слушайте клиента. Если бы я мог предложить вам только один совет на будущее, я бы слушал клиента.

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

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

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

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

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

Непонимание того, о чем просит клиент

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

Какой???

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

Во-вторых, не каждый является очень опытным писателем; они пытаются сказать А, но в итоге описывают Б.

Итак, прочитав все, что вам прислали, как вы будете уверены, что то, что вы читаете, действительно то, что они имели в виду? Ну, вы все переварите, сделаете пометки, все проанализируете и… созовете собрание . (Понимаете? Все дело в общении!) На встрече вы расскажете о проблеме, и своими словами расскажете, что вы поняли. На этом этапе вы, вероятно, сможете выявить любые недоразумения.

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

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

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

Почему нельзя делать все, о чем просит клиент, не подумав

Хорошо, теперь, когда вы знаете, что вы должны выслушать клиента и подтвердить то, что вы поняли, вы можете просто пойти дальше и сделать все, о чем вас просили, верно?

Неправильно!

Теперь настал момент, когда вы, наконец, можете использовать весь свой опыт и спросить себя: решит ли то, о чем вас попросил клиент, его проблему? То, что они спросили у вас, действительно то, что им нужно?

Вы были бы удивлены, увидев, сколько раз ответ «нет».

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

Если вы и клиент разумны, то вы либо продолжите свое решение, либо проведете сеанс мозгового штурма, чтобы придумать лучшее решение (на случай, если ваша идея по какой-то причине не будет приемлема для клиента).

Прототип — не пишите объемную документацию

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

Итак, я согласен с тем, что каким-то образом (на более высоком или более низком уровне) мы должны документировать то, что мы собираемся разработать. Но передача нескольких страниц текста без каких-либо визуальных элементов не принесет вам много пользы. Клиенту это надоест читать, он перестанет обращать внимание и, вероятно, не сможет понять, что вы имеете в виду под этими сложными бизнес-правилами, или интерпретирует совсем не то, что вы себе представляли.

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

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

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

Хватит тратить время на убеждение клиента в своей правоте

Я почти уверен, что каждый разработчик сталкивался со следующей ситуацией: в начале проекта клиент говорит: «Мне нужно, чтобы фон программы был желтым. Это уже согласовано с советом». Затем, когда программное обеспечение доставлено, они говорят: «О, но цвет фона не может быть желтым. Я говорил тебе, что он должен быть зеленым! Теперь, как вы должны справиться с этим?

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

Всегда хорошо иметь хороший опыт общения с клиентом, просто чтобы убедиться, что вы находитесь на одной волне, и оставить письменный след. В большинстве случаев, если это что-то простое, вы можете просто написать клиенту по электронной почте, сказав: «Как мы договорились на той встрече, фон системы будет желтым». И если в будущем клиент передумает, вы можете утверждать, что сделали это из-за той встречи, упомянутой в электронном письме, но если это изменение действительно необходимо, вы можете выполнить его на дополнительные x часов. (а иногда и дополнительные x долларов).

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

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

Знайте, когда укладываться в сроки

И последнее, но не менее важное: одна из самых больших ошибок, которую вы можете совершить, — это дать клиенту крайний срок для завершения проекта. И они будут умолять вас сделать эту ошибку!

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

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

Ничто из этого на самом деле не является ошибкой разработчика и может серьезно повлиять на сроки проекта. Но если вы, желая угодить клиенту, пообещали, что доставите все к какому-то сроку, а в итоге, по всем правильным причинам, этого не сделаете, я могу гарантировать одно: клиент будет, по крайней мере, немного , расстроенный. Если вы фрилансер, вы должны эффективно управлять своим временем, как объясняется в этой статье блога Toptal Engineering. Не забывайте, что управление взаимоотношениями с клиентами — это и ваша работа.

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

Кроме того, я настоятельно рекомендую (особенно если вы уже дали оценку) всегда сообщать клиенту, когда что-то занимает больше времени, чем ожидалось, чтобы он мог действовать, чтобы помочь вам!