Что будешь делать при несогласованности между клиентами?

Стратегия управления несогласованностью требований клиентов

Как IT Project Manager с более чем 10-летним опытом, я рассматриваю несогласованность между клиентами (или между заказчиками и пользователями) как системную проблему коммуникации и процессов, а не просто как разовый конфликт. Моя стратегия включает несколько уровней действий.

1. Немедленные тактические действия (Огнетушитель)

• Документирование всех позиций. Первым шагом будет фиксация всех точек зрения в письменном виде, часто в виде сравнительной таблицы в Confluence или общего документа.

  | Требование | Клиент A (Бизнес) | Клиент B (Пользователи) | Расхождения |
  |------------|-------------------|-------------------------|-------------|
  | Отчёт X    | Ежедневный PDF на почту | Интерактивный дашборд в UI | Формат, частота, канал |
  

• Организация фасилитированной сессии. Созваниваю всех ключевых стейкхолдеров в одной комнате (виртуальной или реальной). Моя роль здесь — фасилитатор, а не судья. Я задаю вопросы, чтобы докопаться до корневых причин (5 Why), а не до симптомов.
• Фокус на бизнес-целях, а не на мнениях. Свожу дискуссию к общим целям проекта: "Как это требование помогает нам увеличить конверсию/сократить время обработки/повысить удовлетворённость?" Это переводит разговор из плоскости "я хочу" в плоскость "проекту нужно".

2. Процессуальные и коммуникационные меры (Профилактика)

Чтобы минимизировать такие ситуации, я выстраиваю процессы:

• Чётко определённый круг стейкхолдеров и RACI матрица. Ещё на старте проекта все знают, кто Accountable (единолично утверждает) и кто Consulted по каждому блоку требований.

  {
    "Процесс": "Утверждение ТЗ по модулю "Отчёты"",
    "Accountable": "Глава департамента продаж (Клиент А)",
    "Consulted": ["Руководители отделов (Клиент B)", "Архитектор"],
    "Informed": ["Команда разработки", "Техподдержка"]
  }
  

• Единый источник истины (Single Source of Truth). Все требования, решения и протоколы встреч хранятся в одном доступном месте (например, Jira + Confluence). Нельзя оспаривать то, что было согласовано и запротоколировано неделю назад.
• Регулярные синхронизации. Внедряю Steering Committee meetings (ежемесячно) для стратегических решений и Product Owner sync (еженедельно) для тактических вопросов. Это предотвращает накопление недопонимания.

3. Эскалация и принятие решений (Когда договориться не удаётся)

Если консенсус не достигнут, я действую по заранее согласованной схеме эскалации:

1. Презентация вариантов и последствий. Готовлю документ с анализом решений:

    *   **Вариант А:** Требования Клиента А. *Плюсы:* []. *Минусы/Риски:* []. *Влияние на сроки/бюджет:* [].
    *   **Вариант Б:** Требования Клиента Б. *Плюсы:* []. *Минусы/Риски:* []. *Влияние на сроки/бюджет:* [].
    *   **Компромиссный вариант В:** []. *Плюсы/Минусы:* [].

1. Эскалация на спонсора проекта или высшее руководство. Моя задача — не принять решение за них, а предоставить им всю информацию для взвешенного бизнес-решения. Я чётко формулирую вопрос: "Уважаемый спонсор, учитывая конфликт требований X и Y, и их влияние на срок выпуска (задержка 2 недели), просим вас утвердить один из представленных вариантов".
2. Фиксация и коммуникация решения. Как только решение принято, я обновляю бэклог, документацию и широко информирую команду и всех затронутых стейкхолдеров. Это точка невозврата для обсуждений.

Ключевой принцип: управление ожиданиями

На протяжении всего процесса я активно управляю ожиданиями. Я напоминаю сторонам, что любое изменение или задержка в согласовании требований напрямую влияет на сроки релиза. Часто это мотивирует к более конструктивному диалогу.

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