Конфликт с клиентом

Время чтения - 7 мин.

Дата публикации 21.05.2024 (обновлено 15.10.2026)

Почему стоит дочитать этот материал

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

Что вы получите от прочтения:

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

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

Введение

Речь пойдёт о реальной ситуации, которая произошла на одном из наших проектов. Я опишу своё видение и отношение к подобным ситуациям.

Суть конфликта

Заказчик недоволен, что были падения сайта. Это негативно влияет на продвижение, то есть снижает эффективность мер по поисковой оптимизации и другим методам привлечения трафика. Также это сказывается на репутации сайта в глазах пользователей. Всё это так.

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

Как было бы в идеальном мире

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

Что в реальности выходит

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

Негативные последствия для заказчика и для подрядчика

На фриланс-площадках можно найти множество заявок на доработку проекта. Думаю, в большинстве таких случаев был конфликт и выход исполнителей из проекта. И дальше начинается долгая и сложная история поиска подходящего человека или команды. А поддержка стороннего проекта, реализованного совсем другими людьми, другой компанией, — дело непростое и гораздо более затратное, нежели когда эти задачи выполняют люди, которые знают каждый уголок в проекте.
Если в итоге не удаётся найти подходящего специалиста (а попыток внедрения разных людей может быть множество), проект просто перестаёт развиваться. А при критичных проблемах — а они рано или поздно всегда возникают с ростом проекта — проект просто загибается.

Как заказчик может уменьшить критичность этой проблемы:

всегда расставаться с исполнителями полюбовно.

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

владеть артефактами по проекту.

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

знать своего исполнителя.

Предсказывать, как он может повести себя в случае проблем или наезда, и с учётом этого корректировать управление проектом. Самый опасный тип исполнителя — «я обиделся и заблокировал все контакты». И в этом случае заказчик внезапно остаётся со своим проектом один на один.

растить в штате своего разработчика.

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

Для подрядчика неприятные последствия могут быть следующие:

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

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

судебные претензии — они могут быть в любом случае, но особенно опасны в случае неисполнения пунктов договора;
чёрный пиар — заказчик может распространять свой негативный опыт использования ваших услуг. С другой стороны, просто посмотрите, сколько негатива есть об АМО, Битрикс24, 1С. А это лидеры рынка по своим типам программ и сервисов.

Как быть?

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

Что должен понять исполнитель:

на заказчика давят его клиенты и пользователи. В случае простоя сайта куча негатива выливается на него — который он потом выливает на вас;
заказчик не всегда так же глубоко понимает технические проблемы. В его представлении всё кажется простым («ведь у Озона как-то это работает»). Это невероятно раздражает, когда заказчик начинает учить тебя техническим моментам, особенно когда он путает понятия DNS и хостинг или не знает, что такое URL. Здесь нужно просто помнить: заказчик не знает и не понимает всех деталей, но при этом имеет конкретную цель — вот на ней и нужно сосредоточиться;
решайте проблемы, а не сетуйте. «К сожалению, данные были потеряны» — страшная фраза для любого владельца продукта. Никому не нужно ваше сожаление: старайтесь решать проблему, а не причитать.

Что должен понять заказчик:

функциональный сайт — это довольно сложная система. В ней миллион нюансов, о которых вы, скорее всего, не знаете. Исходите из того, что сложность любой задачи на сайте выше, чем вам кажется (очень часто разработчики слышат от заказчика «Да там дело на 5 минут…»);
нужно ответственно относиться к изменениям состава участников проекта. Если вы меняете основного разработчика, а достойной замены сразу нет — проект под очень большим риском;
ориентир на решение бизнес-задач, а не на полемику. Полемика только ухудшит ситуацию на проекте. Если исполнитель не справляется с бизнес-задачей, нужно совместно с ним выработать план, как решить эти задачи с привлечением внешних ресурсов.

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

программист — это программист, а не всё, что связано с ИТ (дизайн, администрирование, devops, бизнес-аналитика, продвижение, веб-аналитика и так далее).

Заключение

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

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

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