Чью сторону должен принимать PM при противостоянии тестировщиков и разработчиков

Позиция Project Manager в конфликте тестировщиков и разработчиков

За 10+ лет управления проектами я убедился, что Project Manager (PM) не должен автоматически принимать сторону ни тестировщиков (QA), ни разработчиков (Dev). Его роль — быть нейтральным арбитром и адвокатом проекта, а не отдельных ролей или личностей. Принимая чью-либо сторону, PM рискует потерять доверие команды, усилить конфронтацию и сместить фокус с общей цели (качественного продукта) на межличностное противостояние.

Конфликт между QA и Dev, как правило, коренится не в личной неприязни, а в различии KPI, процессов и ментальных моделей:

• Разработчики ориентированы на скорость создания функциональности, инновации, удовлетворение технических требований.
• Тестировщики сфокусированы на качестве, поиске дефектов, минимизации рисков, защите интересов пользователя. Эти цели объективно создают напряжение, но они же взаимодополняющи для успеха проекта.

Алгоритм действий PM в ситуации противостояния

1. Диагностика корневой причины конфликта. Нужно быстро выяснить, является ли спор техническим, процессным или межличностным. Я использую простой опросный сценарий в ходе отдельных встреч с лидами направлений.

# Пример наводящих вопросов для анализа (не для прямого озвучивания):
1. В чём суть разногласия? (Факт, а не эмоция)
2. Как это влияет на выполнение спринта/релиза? (Оценка воздействия)
3. Какой процесс или его отсутствие привёл к ситуации? (Поиск системной причины)
4. Что, по вашему мнению, будет справедливым решением? (Понимание ожиданий)

1. Фасилитация совместного решения. PM должен организовать и модерировать сессию, где стороны вместе ищут решение. Классический метод — перевести проблему из плоскости «мы против них» в плоскость «проблема против нас всех».

    > **Пример:** Вместо «Dev снова залили сырой код, а QA их тормозят, не пропуская в релиз», проблема формулируется так: «Мы, команда, рискуем сорвать срок релиза из-за высокого количества критических багов в сборке. Как нам совместно это исправить и предотвратить в будущем?»

1. Фокус на данные, а не на мнения. Нужно основывать обсуждение на метриках, а не на эмоциях.

    *   Количество reopened багов и их тип.
    *   Статистика по времени прохождения CI/CD пайплайна.
    *   Процент автоматизированных тестов.
    *   История изменений требований (scope creep).

1. Оптимизация процессов. Часто конфликт — симптом проблем в процессе.

    *   **Внедрение или уточнение Definition of Done (DoD).** Чёткие, согласованные всеми критерии готовности задачи снимают 50% споров.
    *   **Ревью процессов — скрам-митинги, ретроспективы.** Обсуждение на ретро, почему баги «утекают» или почему фиксы задерживаются.
    *   **Настройка CI/CD.** Автоматизация прогона тестов и статического анализа кода (например, через **SonarQube** или **ESLint**) делает обратную связь объективной и безличной.

# Пример Definition of Done (DoD) как инструмента предотвращения конфликтов:
task_do_d:
  - Код написан и соответствует стандартам.
  - Код проверен в peer review (минимум одним разработчиком).
  - Все модульные/интеграционные тесты написаны и проходят.
  - Код успешно собирается в основной ветке (CI pipeline green).
  - Ручное тестирование QA выполнено, критические/блокирующие баги исправлены.
  - Документация (если требуется) обновлена.

1. Эскалация по необходимости. Если конфликт зашёл в тупик или имеет стратегический характер (например, принципиально разные взгляды на архитектуру, влияющую на тестируемость), PM должен эскалировать вопрос к техническому лиду (Tech Lead), Architect или Head of Delivery. При этом эскалация — не перекладывание ответственности, а предоставление руководству полной картины: проблема, анализ, предложения команды, риски.

Чьи интересы представляет PM в итоге?

PM представляет интересы проекта, продукта и бизнеса. Его конечная цель — доставка качественного продукта в срок и в рамках бюджета. Он должен:

• Защищать процесс, который уравновешивает скорость и качество.
• Создавать среду для конструктивного диалога.
• Быть щитом для команды от внешнего хаоса, чтобы специалисты могли делать свою работу.

Золотое правило: Если PM чувствует, что вынужден постоянно принимать чью-то сторону («защищать» QA от Dev или наоборот), это красный флаг. Значит, в процессах или команде есть системный сбой, который нужно исправить, а не латать ежедневными интервенциями. Сильная команда — не та, где нет споров, а та, где спор ведётся вокруг решений, а не вокруг амбиций, и разрешается на основе данных и общего соглашения.