Были ли конфликты с заказчиком?

Конфликты с заказчиком: как я их разрешал

Да, конфликты с заказчиком случались неоднократно. Это нормальная часть работы BA. Главное — уметь видеть корень проблемы и разрешать конфликт конструктивно.

Кейс 1: Расхождение в понимании требований

Ситуация

Заказчик одного проекта заявил, что разработчики не выполнили его просьбу. Он просил «сделать систему быстрее», а команда ничего не изменила. Возник конфликт: заказчик считал, что команда его не слушает, команда считала, что требование неясно.

Как я решил

1. Встал на сторону заказчика — не защищал команду, а слушал, что именно его не устраивает
2. Задавал уточняющие вопросы:
   • Где именно система медленная? (На странице товаров? При загрузке изображений?)
   • Что означает «быстрее»? (Сейчас 3 секунды, нужно 1 секунду?)
   • Какие метрики вы измеряли?
3. Провел анализ:
   • Измерил текущую скорость загрузки каждой страницы
   • Выявил, что самая медленная функция — загрузка большого CSV файла
   • Рассчитал, сколько это стоит в часах разработки
4. Создал компромисс:
   • Предложил приоритизировать загрузку по страницам (сначала таблица, потом дополнительные данные)
   • Это решило проблему заказчика, не требуя глобального переписывания
5. Документировал решение:
   • Отправил письмо заказчику: "Вот что было медленно, вот что мы сделали, вот метрики"
   • Заказчик получил четкую информацию, что его голос услышан

Результат: Конфликт разрешился. Более того, заказчик начал правильнее формулировать требования, потому что понял, что я помогу ему найти реальную проблему.

Кейс 2: Расширение scope без согласования бюджета

Ситуация

На середине проекта заказчик попросил добавить "маленькую функцию" — экспорт в Excel. Он считал, что это займет «несколько часов» и не понимал, почему команда говорит, что это 5 дней работы.

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

Как я решил

1. Показал детализацию работы:
   • Создал не сложную задачу, а развернул её на подзадачи:

     - Дизайн интерфейса экспорта (4 часа)
     - Реализация логики извлечения данных из БД (8 часов)
     - Форматирование Excel (их требования к внешнему виду оказались сложнее, чем казалось) (16 часов)
     - Тестирование на разных версиях Excel (8 часов)
     - Обработка ошибок (4 часа)

• Total: 40 часов = 5 дней для одного разработчика

1. Объяснил, почему это стоит дорого:

   • Показал примеры того, как мелкие детали тратят время ("Вы же хотите, чтобы формулы работали в старых версиях Excel 2010?")
   • Привел примеры из других проектов

2. Предложил альтернативы:

   • Вариант 1: Выделить ещё 5 дней разработки (стоимость X)
   • Вариант 2: Упростить функцию (только базовый экспорт, без красивого форматирования) — займет 2 дня
   • Вариант 3: Отложить на следующий этап и перепланировать спринт

3. Принял решение вместе с заказчиком:

   • Он выбрал Вариант 2 (упрощенный экспорт)
   • Это был компромисс: мы дали функцию быстро, заказчик получил базовый функционал
   • На будущее заказчик понял, что даже маленькие функции нужно оценивать

Результат: Конфликт разрешился, потому что я дал заказчику выбор с полной информацией. Он принял решение самостоятельно.

Кейс 3: Расхождение в видении решения

Ситуация

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

Как я решил

1. Не спорил, а слушал, почему ему кажется это хорошим решением
2. Предложил провести workshop:
   • Нарисовал его вариант и показал, что произойдет при масштабировании
   • Предложил свой вариант с преимуществами и недостатками
   • Пригласил разработчика, чтобы технические детали объяснял он
3. Нашел компромисс:
   • Заказчик согласился, но с условием, что мы реализуем первый этап его путем (чтобы он видел результат быстро), а потом отрефакторим
   • Это было честно: быстрый результат + правильная архитектура

Результат: Заказчик остался доволен, потому что получил что хотел в краткосрочной перспективе, и понял необходимость рефакторинга в долгосрочной.

Ключевые принципы, которые я применяю при конфликтах

1. Эмпатия, а не защита

Заказчик всегда прав в том, что чувствует (раздражение, неудовлетворение), но может быть неправ в диагнозе проблемы.

"Я понимаю, что вас раздражает медленная загрузка" (эмпатия) → "Давайте найдем, что именно медленно" (диагноз).

2. Данные вместо эмоций

Если есть конфликт, я собираю данные:

• Метрики производительности
• Оценки времени на разработку
• Примеры из аналогичных проектов

Данные объективны и снимают эмоциональное напряжение.

3. Предложение альтернатив

Я редко говорю "нет, это невозможно". Вместо этого: "Мы можем сделать это тремя способами. Вот плюсы и минусы каждого. Выбирайте."

Это дает заказчику контроль и ощущение причастности к решению.

4. Прозрачность в коммуникации

Я всегда объясняю ограничения, почему что-то стоит именно столько, почему это займет столько времени.

Заказчик может не согласиться, но он будет знать, на что жаловаться.

5. Документирование соглашений

После разрешения конфликта я отправляю письмо: "Мы согласились сделать вот это, в этот срок, по этой цене, с этими результатами".

Это предотвращает споры в будущем.

Вывод

Конфликты с заказчиком — это не провал, а возможность.

✓ Если конфликт разрешить правильно — заказчик начинает вас больше ценить ✓ Конфликты выявляют реальные проблемы (часто не те, что казались на первый взгляд) ✓ Правильно разрешенный конфликт укрепляет отношение доверия

Лучший BA — это не тот, у кого нет конфликтов, а тот, кто умеет их разрешать профессионально и конструктивно.