Эту страницу открывают, когда разные участники проекта дают несовместимые требования: бизнес хочет одно, пользователи другое, безопасность третье, а команда говорит, что часть пожеланий вообще конфликтует технически или организационно.
Противоречивые требования нельзя просто аккуратно переписать в один документ. Их нужно управленчески разбирать, иначе конфликт переедет в реализацию, приемку и отношения между участниками.
В какой ситуации открывать
Сюда приходят, когда:
- два стейкхолдера хотят разного поведения системы;
- удобство пользователя конфликтует с контролем и безопасностью;
- сроки и объём не позволяют удовлетворить все ожидания сразу;
- команда видит технический конфликт там, где бизнес видит «просто сделайте оба варианта».
Как выглядит проблема
Противоречие может быть:
- между требованиями разных групп;
- между требованием и ограничением;
- между скоростью и качеством;
- между локальной выгодой одной стороны и общей логикой проекта.
Почему это происходит
Обычно причины такие:
- разные группы преследуют разные цели;
- нет ясных критериев успеха;
- не определены реальные приоритеты;
- скрытые интересы и ограничения не были выявлены вовремя;
- карта ролей и право финального решения размыты.
Что делать пошагово
1. Явно зафиксируйте, в чём именно конфликт требований. 2. Разведите позиции по сторонам и критериям. 3. Выясните, кто принимает итоговое решение. 4. Подготовьте варианты компромисса с последствиями. 5. Переведите спор из плоскости мнений в плоскость цены решений. 6. Зафиксируйте принятое решение и обновите рабочие артефакты.
Что говорить и как коммуницировать
Полезные формулировки:
- сейчас у нас не одно требование, а конфликт двух требований;
- нам нужно выбрать, какой критерий в этом контексте приоритетнее;
- нельзя одновременно сохранить все параметры без изменения срока, объёма или качества.
Здесь особенно важны деэскалация напряжения, объяснение компромиссов и работа с конфликтом приоритетов.
Какие артефакты и формализации нужны
- фиксация конфликта требований;
- карта сторон и их критериев;
- оценка последствий вариантов решения;
- обновлённая версия требований после решения;
- при необходимости stakeholder map или RACI.
Когда эскалировать
Эскалация нужна, если:
- конфликт не может быть решён на рабочем уровне;
- требования отражают разные бизнес-интересы;
- нужен политический или стратегический выбор;
- конфликт влияет на критичные сроки, стоимость или репутационный риск.
Как не допустить повторения
- заранее собирать критерии успеха;
- раньше выявлять скрытые вводные;
- держать актуальной карту ролей и decision makers;
- не прятать противоречия в гладкий текст спецификации.
Какой навык здесь проседает
Чаще всего здесь проседает связка из участников и ролей, критериев успеха и переговорных навыков PM.