Когда-то я тоже столкнулась с историей, которая многих ставит в тупик.

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

Знакомый сценарий? Дальше — классика. Проект повис, нервы на пределе, а крайних ищут среди исполнителей.

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

Что действительно важно
📌 Фиксировать любые договорённости письменно. Устные обещания без подтверждения — это просто слова.
📌 Чётко понимать зоны ответственности. Аналитик отвечает за описание и анализ. Менеджер — за коммуникацию и сроки. Когда эти роли смешиваются, проект начинает штормить.
📌 Следить за собственными ресурсами. Если вас втягивают в чужой внутренний конфликт — это повод остановиться и подумать о тактике защиты.
📌 Помнить, что вы не обязаны знать бизнес-процессы заказчика лучше него самого. Ваша задача — задавать правильные вопросы и структурировать ответы, а не додумывать логику за сотрудников заказчика. Попытка «угадать» или доработать процесс по своему усмотрению почти всегда приводит к ошибкам и претензиям.

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

Зоны ответственности
🔹 Аналитик — собирает данные, фиксирует противоречия, подсвечивает риски и возможные варианты.
🔹 Менеджер — принимает решение по срокам и бюджету, а также выносит вопрос на уровень заказчика.
🔹 Заказчик — выбирает приоритет бизнес-процесса и утверждает итоговый вариант.

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

Несколько вредных советов, которые лучше не применять
❌ «Промолчи и сделай как считаешь нужным, потом разберутся». Разбираться будут с вами.
❌ «Эскалируй громко и публично, чтобы все испугались». Это сделает вас токсичным, а не принципиальным.
❌ «Напиши большое письмо с эмоциями и деталями». Его не дочитают, а вывод будет один: вы нервозны.
❌ «Подожди, может само рассосётся». В таких историях сами рассасываются только бюджет и репутация.

А как бы вы поступили на месте аналитика или менеджера?

Как бы вы выстроили диалог с заказчиком? Или, может быть, у вас есть свой способ не дать внутреннему конфликту клиента разрушить проект?
Делитесь в комментариях — соберём коллективный опыт 👇

#управлениепроектами #конфликтывпроектах #работасзаказчиком #управлениерисками