Какой конфликт решал?

Отличный вопрос. Конфликты в проектной работе — это неотъемлемая часть процесса, и их решение является ключевой компетенцией менеджера проектов. Я поделюсь с вами конкретным кейсом, который хорошо иллюстрирует как техническую, так и человеческую сторону управления конфликтами.

Контекст и предыстория конфликта

Проект: Разработка нового мобильного приложения для крупного финтех-банка. Ситуация: На этапе интеграции бэкенд-сервисов (разрабатываемых внутренней командой) и фронтенд-приложения (разрабатываемого внешним подрядчиком) возник острый конфликт.

Стороны конфликта:

• Команда бэкенда (Internal): Техлид и два senior-разработчика. Их цель — создать масштабируемый, надежный и безопасный API, следуя внутренним стандартам банка.
• Команда фронтенда (External Vendor): Менеджер подрядчика и его разработчики. Их цель — максимально быстро выполнить контрактные обязательства по видимой части приложения (UI/UX), чтобы получить промежуточные платежи.

Суть конфликта: Бэкенд-команда настаивала на использовании GraphQL для API, аргументируя это гибкостью для будущих функций и снижением нагрузки на сеть. Фронтенд-команда требовала классический REST API, так как их разработчики были с ним знакомы, а на изучение и реализацию работы с GraphQL по контракту времени не было. Конфликт быстро перешел в фазу взаимных обвинений в «непрофессионализме» и «срыве сроков». Ежедневные стендапы превратились в поле боя, продуктивность упала.

Мои действия по разрешению конфликта (ШАГИ)

Как менеджер проекта, я не стал принимать чью-либо сторону немедленно. Вместо этого я инициировал структурированный процесс разрешения:

1. Индивидуальные встречи (Separate Listening): Я провел отдельные закрытые встречи с техлидом бэкенда и менеджером подрядчика. Цель — понять не только технические аргументы, но и скрытые интересы и опасения.

    *   Выяснилось, что бэкенд опасается, что «кривой» REST с кучей запросов «поломает» их сервисы после релиза.
    *   Подрядчик боялся финансовых санкций за срыв сроков и роста трудозатрат.

1. Совместная рабочая сессия с фокусом на данные (Data-Driven Workshop): Я организовал встречу с ключевыми разработчиками с обеих сторон, но заблаговременно поставил четкую задачу. Каждая сторона должна была подготовить аргументы, подкрепленные данными:

    *   **Бэкенд:** Оценка нагрузки на сервер (RPS — requests per second) для двух сценариев, примеры сложных данных для будущих фич.
    *   **Фронтенд:** Оценка увеличения времени на реализацию с GraphQL, риски и сроки обучения.

# Пример того, как мы структурировали сравнение (упрощенно)
options = {
    "graphql": {
        "backend_effort": "medium",
        "frontend_effort": "high (learning curve)",
        "performance": "high (batch requests)",
        "flexibility": "high",
        "risk": "medium (new tech for frontend)"
    },
    "rest": {
        "backend_effort": "low",
        "frontend_effort": "low",
        "performance": "medium (multiple requests)",
        "flexibility": "low",
        "risk": "high (possible future refactoring)"
    }
}

1. Поиск компромисса и гибридного решения: На основе данных стало ясно, что идеального решения нет. Я предложил рассмотреть гибридный подход: основное API делать на REST (для скорости выхода на рынок MVP), но для двух самых сложных и «прожорливых» с точки зрения данных экранов — реализовать пилотные endpoint'ы на GraphQL. Это позволило:

    *   Подрядчику уложиться в сроки по большей части контракта.
    *   Внутренней команде отработать и доказать эффективность нового стека на реальной задаче.
    *   Запланировать постепенный переход на GraphQL в пост-релизных итерациях.

1. Формализация и коммуникация: Решение было зафиксировано в виде:

    *   Обновления **технического задания (ТЗ)**.
    *   Изменения в **плане проекта** (расширили сроки на две недели для пилота и обучения).
    *   Письма-согласования со спонсором проекта, где я четко обозначил риски каждого варианта и выгоду от выбранного гибридного пути.

Результат и выводы

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

• Технический результат: MVP был выпущен вовремя. GraphQL в пилотных экранах показал на 40% меньше сетевых запросов, что убедило всех в его ценности для второго релиза.
• Командный результат: Взаимное уважение между командами выросло. Они увидели, что их слышат, а решения принимаются на основе анализа, а не силы голоса.
• Управленческий вывод: Я укрепил процесс принятия важных архитектурных решений. Теперь в устав проекта был добавлен обязательный этап — Architecture Decision Record (ADR), где подобные дилеммы документируются на ранней стадии.

Ключевой урок: Самый опасный конфликт — не тот, что на поверхности (REST vs GraphQL), а тот, что под ней (страх срыва сроков vs страх будущей нестабильности). Задача PM — создать безопасную среду для диалога, перевести эмоции в объективные критерии и вести команду к решению, которое служит интересам проекта, а не амбициям отдельных групп.