Главное Авторские колонки Вакансии Образование
Выбор редакции:
15 063 4 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Как решать конфликты с клиентами по методике Боуэра

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

Предисловие: эта статья подкреплена обоснованиями из НЛП-программирования. За дополнения спасибо НЛП-практику Валерии Пушковой.

Немного психологии и НЛП

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

Чтобы разорвать этот круг и выйти из конфликта, одной из сторон потребуется принять или отдать ответственность.

b_5800b6332c1eb.jpg

Методика Боуэр

Методика простая, но от этого не менее эффективная. Заключается она в строгой последовательности шагов:

  • Описание

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

  • Выражение

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

  • Предложение

Это ваш вариант решения проблемы, план действий. Что вы предлагаете, чтобы уладить ситуацию? Опишите детально и по пунктам.

  • Вознаграждение

Гарантируете ли вы успех, если все пойдет по плану из п.3? Какие выгоды получит от этого клиент? Этот пункт вызывает сложности, но с опытом вы научитесь его применять.

Примеры конфликтов с клиентами

Ситуация первая: клиент недоволен сроками

Классика жанра: после подписания договора изменилось ТЗ, а потом вы не рассчитали ресурсы – слишком много пришлось переделывать. Итог: дедлайн прошел, а воз и ныне там. Что делать и как построить общение с клиентом при таком раскладе?

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

Неверная реакция менеджера

Ответ из роли преследователя:

- Разве Вы не думали, что это повлечет за собой дополнительные трудозатраты, когда предлагали изменить ТЗ? Мы сделали, что могли.

Ответ из роли жертвы:

- Мы так старались успеть к сроку, но не смогли, потому что появились новые критические задачи, на которые нам пришлось перекинуть все ресурсы.

Ответ из роли спасителя:

- Мы передаем Ваш проект в аутсорсинговую компанию «N», уверены, они смогут Вам помочь.

b_5800b6e6ae349.jpg

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

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

Разрешаем конфликт с клиентом

Идем по схеме:

«Во время подписания договора мы ориентировались на определенный объем задач, который был изменен уже после запуска работ. Мы оценили доработки и исправления, но не так детально, как было нужно. Поэтому на текущем этапе мы не готовы перейти к демонстрации проекта – некоторые задачи не закончены (описание; чем объективнее, тем лучше).

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

Мы понимаем, что вы хотели запустить систему на этой неделе. От лица нашей команды приношу извинения за то, что не успели реализовать новые требования к проекту в заявленный срок (выражение; мы люди, нам жаль, мы тоже переживаем).

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

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

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

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

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

b_5800b6feb5eb0.jpg

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

Ситуация вторая: клиент недоволен оказанной услугой

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

Вопрос: как вести себя с недовольным клиентом?

Ответ:

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

Через пять минут мы развернем бэкапы и пользователи смогут работать в предыдущей версии. После этого мы оперативно устраним проблемы в новой (предложение). Таким образом, пользователям не придется ждать, а мы в свою очередь исправим ошибку в течение нескольких часов. А также устраним причины инцидента, чтобы такого больше не произошло (вознаграждение)».

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

Ситуация третья: клиент недоволен результатом работы

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

Вопрос: как объяснить клиенту, что в списке доработок очень трудоемкие задачи, а вы не работаете бесплатно?

На самом деле здесь будет долгая переписка. Вопрос дополнительной оплаты всегда скользкий. Но ваша задача – заложить правильный фундамент переговоров.

Ответ:

«Наша команда приняла проект в работу на основании ТЗ к договору. В нем были прописаны основные модули, а проработку деталей вы доверили нам, чтобы сэкономить время (описание).

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

Часть задач мы готовы реализовать бесплатно. Например, доработать дизайн, сделать некоторые разделы более развернутыми <и т.д. по списку менее трудоемких задач>. Но в доработках имеются также долгосрочные задачи - <которые нужно перечислить и обосновать трудоемкость>. Стоимость этих работ мы обсчитаем отдельно в течение недели (предложение).

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

***

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

Я работаю пиэмом вот уже пять лет. Все это время в любых спорных ситуациях использую методику Шарон и Гордона Боуэр. Развития конфликтов не происходило еще ни разу, поэтому будучи наставником, я обучаю всех младших менеджеров этой методике.

— Маша Третьякова, пиэм Tados

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Татьяна Гросюкова
Все отлично написано, автор молодец и понимает, о чем говорит. С моей стороны дополню: описанные в материале ситуации возникают в том случае, если не до конца продуман механизм взаимодействия как с клиентом, так и внутри компании. В ситуации, когда работа ведется по размытому ТЗ, логично возникновение спорной ситуации. Правильно и нужно знать пути решения конфликтов. Однако еще лучше на старте строить работу таким образом, чтобы пиэму не пришлось разгребать последствия.
Ответить
Tados
Разработка ПО для оборудования и сложных бизнес-процессов
Маша Третьякова
Спасибо, Татьяна)

>В ситуации, когда работа ведется по размытому ТЗ, логично возникновение спорной ситуации.

Согласна целиком и полностью. Но тут уже вопрос методологии разработки и поддержки проектов. По-чесноку, мы работаем по недо-agile. Когда-нибудь напишу об этом статью))

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

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

Плюсы такого подхода для нас важнее минусов:

1. Пространство для творчества и технологий (никаких спецификаций)
Так мы релизнули очередную версию ключевого проекта на Angular 2, когда он был еще в бете. Полет нормальный))

2. Глобальные задачи
От "нам надо увеличить выручку в N раз к концу XXX года" до "нужно обеспечить криптозащиту в таком-то модуле". Как это будет сделано - наша проблема.

3. Доверие Клиентов
Мы сравнительно редко сталкиваемся с классикой:
- Вы специалист, скажите, как надо.
- Вот так надо.
- Нет, сделайте по-другому.

Ну и, конечно, вы правы - при такой работе пиэм разгребает последствия. С другой стороны - пиэм занимается непосредственно развитием проекта. Лично я готова была в свое время продать за это душу))
Ответить
Михаил Великий
Вывели публикацию на главную страницу vc.ru.
Ответить
Tados
Разработка ПО для оборудования и сложных бизнес-процессов
Маша Третьякова
Спасибо, ребят!
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.