Как будешь реагировать если заказчик недоволен решением?

Мой подход к работе с недовольством заказчика

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

Пошаговый алгоритм действий

1. Немедленное активное слушание и фиксация.

    *   Я организую встречу (или личный разговор, если ситуация эмоционально заряжена) с ключевыми представителями заказчика. Моя цель — не переубедить, а **понять корень недовольства**. Я задаю уточняющие вопросы по модели «5 почему»: «Почему это решение не решает вашу задачу?», «Какую конкретную бизнес-цель оно блокирует?».
    *   Все претензии я фиксирую письменно в реальном времени, например, в виде протокола или комментария в задаче. Это исключает разночтения в будущем.

```markdown
<!-- Пример фиксации в системе (Jira, Confluence) -->
## Инцидент: Недовольство интерфейсом модуля отчетности
**Дата:** 2023-10-26
**Источник:** Заказчик (Иван Петров, Head of Sales)
**Суть претензии:** "Сформированный отчет не позволяет мгновенно увидеть ключевой KPI - конверсию по этапам. Приходится скачивать и считать вручную."
**Уточняющие вопросы и ответы:**
- Q: Какой именно показатель должен быть на первой странице?
- A: Динамика конверсии из "лида" в "договор" за выбранный период в виде графика.
- Q: Кто основные потребители этого отчета?
- A: Менеджеры по продажам и я на ежедневной планерке.
**Первоначальная гипотеза:** Требуется не новый отчет, а доработка дашборда в существующем интерфейсе.
```

2. Анализ и разделение проблемы.

    *   Я структурирую полученную информацию, разделяя **субъективные ожидания** («хотели бы видеть более современный дизайн») и **объективные требования** («система не выполняет обязательное требование ТЗ п.4.12»).
    *   Далее происходит совместный с техническим лидом и аналитиком анализ: является ли это сбоем, недопониманием спецификации или изменением исходных требований. Я сверяю претензию с документацией (**Vision Document**, **User Stories**, **ТЗ**).

1. Прозрачная коммуникация и предложение решений.

    *   Я никогда не оставляю заказчика в неведении. В заранее согласованные сроки (обычно в течение 1-2 рабочих дней) я предоставляю развернутый ответ, который включает:
        *   Констатацию понимания проблемы (повторяю ее своими словами).
        *   Результаты анализа: что пошло не так? Ошибка в реализации, пробел в анализе или эволюция потребностей?
        *   **2-3 варианта решения** с четким описанием последствий по срокам, бюджету и содержанию проекта.
        *   Рекомендацию команды и запрос на решение от заказчика.

1. Действие и контроль.

    *   После согласования пути решения, я формализую его как изменение (**Change Request**) или задачу на доработку (**bug fix**), вношу коррективы в план проекта и ставлю задачу команде.
    *   Я лично контролирую исполнение и организую демонстрацию результата заказчику в сжатые сроки, чтобы закрыть цикл обратной связи и восстановить доверие.

Ключевые принципы, которые лежат в основе этого подхода

• Проактивность вместо реактивности. Я выстраиваю процесс так, чтобы получать обратную связь постоянно (через регулярные демо, промежуточные поставки), минимизируя риск «сюрприза» на поздних стадиях.
• Фокус на интересы, а не на позиции. Вместо спора о том, «чье решение лучше», мы с заказчиком исследуем, какую бизнес-проблему нужно решить. Часто оказывается, что есть более эффективный путь, чем изначально предполагали обе стороны.
• Ответственность и отсутствие поиска виноватых. Даже если недовольство вызвано неясным ТЗ со стороны заказчика, моя ответственность как PM — выявить эти риски и устранить неопределенности на ранних этапах. Я выступаю проводником между миром бизнеса и разработки.

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