Пытался ли объяснить коллегам, что они плохо работают?

Как я подходил к ситуациям, когда требовалось обсудить качество работы коллег

Да, за 10+ лет работы в backend-разработке на PHP такие ситуации возникали, и я выработал системный подход к ним. Ключевой принцип: критика должна быть конструктивной и направленной на решение проблем, а не на личности. Прямые обвинения ("вы плохо работаете") контрпродуктивны — они создают защитную реакцию, разрушают доверие и не улучшают результат.

Мой алгоритм действий в таких ситуациях

1. Анализ и объективизация проблемы. Прежде всего, я отделяю симптомы от причины. "Плохая работа" — это абстракция. Нужно найти конкретные инстансы: баги в прод, несоответствие требованиям, нарушение стандартов кода, срывы сроков из-за технического долга. Я собираю данные:

    *   Примеры кода с проблемами (нарушение **PSR**, отсутствие тестов, **SQL-инъекции**, **N+1 проблема** в запросах).
    *   Отслеживание повторяющихся инцидентов в трекере (Jira, Redmine).
    *   Метрики: увеличение времени отклика API, рост количества ошибок после релиза.

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

2. Обсуждение через призму кода и процессов, а не человека. Я использую технические аргументы и предлагаю альтернативы. Например, вместо "Твой код ужасен" я говорю:

    > "Я ревьюил пул-реквест #451 и обратил внимание на запрос в цикле. Это может вызвать проблему **N+1** и замедлить страницу заказов при росте данных. Давай посмотрим, как мы можем переписать это с использованием жадной загрузки (`with()` в Laravel или **DQL** JOIN в Symfony) или пакетной обработки."

    Привожу конкретный пример в коде:

```php
// Проблемный код
foreach ($users as $user) {
    $orders = $user->orders()->get(); // Запрос на каждой итерации
    // ...
}

// Предлагаемое решение
$usersWithOrders = User::with('orders')->get(); // Всего 2 запроса
foreach ($usersWithOrders as $user) {
    $orders = $user->orders; // Данные уже загружены
    // ...
}
```

4. Предложение помощи и ресурсов. Часто проблема — не в лени, а в недостатке знаний или давления сроков. Я предлагаю:

    *   Провести пару программирований.
    *   Ссылки на документацию (**PHP-FIG PSR**, **Laravel/Symfony best practices**).
    *   Внутренние гайдлайны команды по написанию тестов или проектированию API.

1. Эскалация через процессы. Если проблема систематическая и влияет на команду, я выступаю не как критик, а как инициатор улучшений:

    *   **Предлагаю ввести/ужесточить код-ревью.** Не как барьер, а как площадку для обучения.
    *   **Инициирую создание или обновление шаблонов (boilerplate)** для типовых задач.
    *   **Предлагаю провести tech talk или воркшоп** по проблемной теме (например, "Оптимизация запросов к БД в нашем проекте").

Важный пример из практики

Был случай, когда разработчик постоянно игнорировал обработку исключений в финансовых операциях. Вместо претензии я подготовил отчет по мониторингу (Sentry), который показывал, что 40% ошибок в продакшене связаны с одним типом исключения. На очередном планировании спринта я поднял вопрос: "Коллеги, посмотрите, этот тип ошибки стоит нам N часов на поддержку ежемесячно. Давайте выделим 4 часа в этом спринте, чтобы я и [имя разработчика] проанализировали все подобные места и внедрили единый Exception Handler. Это сэкономит время всем в будущем". Проблема была решена в рамках улучшения процесса, а не через обвинения.

Заключение

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