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

Стратегия разрешения конфликта на почве воспринимаемой некомпетентности

Ситуация, когда один разработчик считает другого некомпетентным, — это критический межличностный конфликт, который напрямую угрожает продуктивности команды, качеству кода и психологической безопасности. Мои действия будут направлены на немедленное сдерживание негатива, объективное расследование и системное решение, а не на поиск виноватых.

Немедленные действия: Локализация и деэскалация

1. Индивидуальные беседы (отдельно с каждым разработчиком):

    *   **С инициатором жалобы:** Цель — перевести эмоциональную оценку («некомпетентен») на язык конкретных фактов и наблюдаемого поведения. Задаю вопросы:
        > «Расскажи, пожалуйста, на каких конкретных задачах или ситуациях основано твое мнение?»
        > «Можешь привести пример кода, решения архитектурной задачи или коммуникации, который вызвал беспокойство?»
        > «Как это повлияло на твою работу или сроки задачи?»
    *   **С разработчиком, на которого поступила жалоба:** Цель — понять его точку зрения на те же ситуации, не озвучивая прямо обвинение в «некомпетентности». Обсуждаю те же задачи или модули в контексте сложностей и вызовов.
        > «Как ты оцениваешь сложность последней задачи по модулю X? С какими вызовами столкнулся?»
        > «Как проходит взаимодействие с коллегой Y по этому вопросу?»

1. Анализ артефактов работы: Независимо от субъективных мнений, анализирую реальные выходы:

    *   **Историю коммитов и код-ревью** по спорным задачам. Ищу паттерны: частые реверты, критические замечания в ревью, низкое качество merge request.

```bash
# Пример: изучаю историю вклада разработчика за последний спринт
git log --author="ИмяРазработчика" --since="2 weeks ago" --oneline
```

    *   **Процесс и результаты код-ревью.** Были ли замечания проигнорированы? Возникали ли длительные споры без конструктивного исхода?
    *   **Метрики качества** (если они есть): количество инцидентов в production, связанных с его кодом, покрытие тестами, техник-долг.

Основная фаза: Фасилитация и поиск решения

1. Совместная встреча (фасилитация): После сбора фактов организую встречу с обоими разработчиками. Моя роль — фасилитатор, а не судья.

    *   **Устанавливаю правила:** Обсуждаем факты и последствия, а не личные качества. Используем «Я-высказывания».
    *   **Представляю объективные данные** (например, конкретный кусок кода из ревью) как отправную точку для обсуждения.

```python
# Пример: выношу на обсуждение не абстрактную "плохую архитектуру", а конкретный метод
# Исходный вариант (может вызывать вопросы)
def process_data(data):
    # Длинная функция, смешивающая логику, парсинг и валидацию
    result = []
    for item in data:
        # ... 30 строк логики ...
    return result

# Предлагаю обсудить возможные улучшения: разделение ответственности (SRP)
```

    *   **Фокусирую разговор на процессе:** «Как нам улучшить наш процесс код-ревью, чтобы подобные вопросы решались на раннем этапе?» или «Нужно ли уточнить Definition of Done для таких задач?».

1. Определение корневой причины: На основе бесед и анализа выявляю реальную проблему. Она редко бывает именно в «некомпетентности». Чаще это:

    *   **Разрыв в экспертизе:** Младший/средний разработчик против старшего. Решение: менторинг, четкое распределение задач по уровню, парное программирование.
    *   **Коммуникационный сбой:** Разные ожидания от дизайна, интерфейса или критериев завершенности. Решение: уточнение AC (Acceptance Criteria), предварительные дизайн-ревью.
    *   **Процессуальные пробелы:** Отсутствие четких стандартов кода, шаблонов или эталонов. Решение: создание/актуализация гайдлайнов, проведение внутренних воркшопов.
    *   **Личностный конфликт или bias.** Решение: перевод внимания на общие цели команды, возможно, изменение схемы взаимодействия.

Системные действия и завершение

1. Внедрение корректирующих мер: Действия зависят от корневой причины.

    *   **Для разработчика, чьи навыки требуют роста:** Составляю **индивидуальный план развития (PDP)** с конкретными целями (например, «улучшить понимание паттерна Observer», «освоить инструменты профилирования»), назначаю ментора, корректирую нагрузку.
    *   **Для команды:** Инициирую создание **чек-листа для код-ревью**, провожу ретроспективу на тему «Эффективная обратная связь», внедряю практику **архитектурных kata** для выравнивания понимания.

1. Мониторинг и поддержка: Назначаю регулярные короткие встречи с обоими разработчиками на ближайшие 2-3 спринта, чтобы отслеживать атмосферу и эффективность принятых мер. Отслеживаю метрики команды (скорость, качество) на предмет положительной динамики.

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