Конфликт с клиентом
Введение
Речь пойдет о реальной ситуации, которая произошла на одном из наших проектов. Я распишу свое видение и отношение к подобным ситуациям.
Суть конфликта
Заказчик недоволен, что были падения сайта. Это негативно влияет на продвижение, т.е. снижает эффективность мер по поисковой оптимизации и другим методам привлечения трафика на сайт. Также это сказывается на репутации сайта в глазах пользователей. Все это так.
Далее следуют гневные сообщения о нашей никчемности, криворукости и т.д. Здравый смысл подсказывает не вступать в полемику или оправдания, но эмоции иногда перевешивают и начинается перепалка. Толку от такой перепалки 0, т.к. каждая сторона еще больше укрепляется в своей позиции.
Как было бы в идеальном мире
Во-первых, без эмоций с обоих сторон. У каждой стороны есть бизнес-задачи и нужно отталкиваться от них.Во-вторых, конструктивные предложения. Нет смысла обвинять друг друга, это просто ухудшит отношения без какого-либо продвижения по бизнес-задачам.Третье - совместно выработать организационные решения, уменьшить вероятность проблем и снизить критичность, если проблема все же вновь возникла.
Что в реальности выходит
Перепалка, взаимные обвинения, накал эмоций, угрозы, попытки уколоть оппонента, потеря времени и нервов. Всегда кажется, что ты прав, что правда за тобой, что другая сторона намеренно делает что-то плохо или имеет дурные намерения.
Негативные последствия для заказчика и для подрядчика
Можно много найти на фриланс площадках заявок на доработку проекта. Думаю, в большинстве таких случаев был конфликт, выход из проекта исполнителей. И дальше начинается долгая и сложная история поиска подходящего человека или команды. А поддержка стороннего проекта, реализованного совсем другими людьми, другой компанией - дело это непростое и гораздо более затратное, нежели когда эти задачи делают люди, которые знают каждый уголок в проекте. Если в итоге не удается найти подходящего человека (может быть множество попыток внедрения разных людей), то проект просто перестает развиваться. А при критичных проблемах (а они рано или поздно всегда возникают с ростом проекта), проект просто загибается.
Как можно для заказчика уменьшить критичность этой проблемы:
- всегда полюбовно расставаться с исполнителями
Если вы оставляете за собой кучу сожженных мостов (обижаете исполнителей), то повышаются абсолютно ненужные риски (вредительство, кража информации и прочие нехорошие вещи). Это сильно неадекватно со стороны исполнителя, но такие гавнюки бывают (и лучше их распознавать на ранней стадии проекта)
- владеть артефактами по проекту
Документация, движок сайта, бекапы базы, все доступы, связанные с сайтом. До создания платформы нам не раз обращались люди по доработке сайта, но они не знали даже на чем написан сайт, не было никакой документации и не было конечно связи с исполнителем.
- знать своего исполнителя
Предсказывать, как он себя может повести в случае проблем или наезда, и с учетом этого корректировать свой менеджмент проект. Самый опасный тип исполнителя - это "я обиделся и заблокировал все контакты". И в этом случае заказчик внезапно остается со своим проектом 1 на 1.
- растить в штате своего разработчика
Это снижает риск внезапной потери основного разработчика. Сначала он может не делать какую-то основную работу, но он будет постепенно вникать в проект. В какой-то момент он сможет полностью взять поддержку проекта на себя.
Для подрядчика неприятные последствия могут быть следующие:
- потеря клиента и разрушение отношений с ним - на мой взгляд, это самый критичный момент для исполнителя
В разработке отношения могут длиться годами. У нас есть клиент, с которым мы работаем более 10 лет по разным проектам. Потеря долгоиграющего клиента - это действительно серьезная потеря.
- судебные претензии - они могут быть в любом случае, но особенно они опасны в случае неисполнения пунктов договора
- черный пиар - заказчик может распространять свой негативный опыт по использованию ваших услуг. С другой стороны - просто посмотрите сколько негатива есть на АМО, Битрикс24, 1С негативных отзывов. А это лидеры рынка по своим типам программ/сервисов.
Как быть?
Мой опыт мне подсказывает, надо как-то договариваться и совместно вырабатывать решение с ориентиром на проработку проблемы. Не выяснять отношения, ругаться, переходить на угрозы. Здесь движение должно быть как со стороны заказчика, так и со стороны исполнителя.
Что должен понять исполнитель:
- на заказчика давят его клиенты, пользователи. В случае простоя сайта куча негатива выливается на него (который он потом выливает на вас).
- заказчик не всегда так же глубоко понимает технические проблемы. В его видении это кажется простым ("ведь у Озона как-то это работает"). Это невероятно бесит, когда заказчик начинает тебя учить техническим моментам (особенно когда он путает понятия DNS, хостинг или не знает, что такое URL). Здесь нужно просто об этом помнить: заказчик не знает и не понимает всех деталей, но при этом имеет конкретную цель - вот на ней и нужно сосредоточиться.
- решайте проблемы, а не нойте. "К сожалению данные были потеряны" - страшная фраза для любого владельца продукта. Никому не нужно ваше сожаление, старайтесь решать проблему, а не причитайте.
Что должен понять заказчик:
- функциональный сайт - это довольно сложная штука. В ней миллион нюансов, о которых вы скорее всего не знаете. Исходите из того, что сложность любой штуки на сайте выше, чем вам кажется (очень часто разработчики слышат от заказчика "Да там дело на 5 минут...").
- нужно ответственно относиться к изменениям состава членов проекта. Если вы меняете основного разработчика, и у вас нет достойной замены сразу - проект очень под большим риском.
- ориентир на решение бизнес-задач, а не на полемику. Полемика только ухудшит ситуацию на проекте. Если исполнитель не справляется с бизнес-задачей, нужно выработать совместно с исполнителем план, как можно решить эти задачи с привлечением внешних ресурсов.
В большинстве случаев именно заказчик является более зависимой частью пазла (если конечно это не крупный бизнес). Разрушить доверие, взаимодействие и атмосферу на проекте очень легко - просто написать 1-2 гневных письма с обвинениями и переходом на личности.
- программист - это программист, а не все, что связано с ИТ (дизайн, администрирование, devops, бизнес-аналитика, продвижение, веб-аналитика и т.д.).
Заключение
Когда возникают серьезные проблемы, для снижения стресса я использую простой прием - читаю военные мемуары или что-то подобное. При сравнении масштабов проблем понимаешь, что твои неприятности не такие уж и большие и всегда можно их порешать. Это снижает эмоциональный накал и проще воспринимать ситуацию в правильном свете.
Эмоции - плохой помощник в деле разрешения проблем коммуникации. Нужно сосредоточиться на решении бизнес-задач. И не создавать дополнительных рисков, которые могут разрушить проект.
P.S. Нам удалось найти общий язык, взаимопонимание с клиентом. Но в целом это звоночек - где-то мы недорабатываем, что-то неверно доносим до клиента в плане ожиданий, где-то можно более точно действовать. В любом случае подобные ситуации - возможный драйвер для улучшения и роста.
Источник: