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