Как решались проблемы взаимоотношений в команде

Проблемы взаимоотношений в команде и как их решать

Основной навык, который отделяет junior от senior разработчика — умение работать в команде. За 10+ лет я сталкивался с разными конфликтами и выработал подход, который работает.

Типичные проблемы

Проблема 1: Код ревью как боевое поле

Сценарий: Ревьюер требует переписать половину PR потому, что "мне не нравится".

Как я решал:

• Установить правила: делим отзывы на MUST (нарушение стандартов), SHOULD (лучшие практики), NICE (стиль)
• Ревьюер должен объяснять ЧТО не так и ПОЧЕМУ
• Если расхождение во мнении — обсуждаем, не ругаемся
• Автор PR может возразить, если не согласен с SHOULD

Пример подхода:

// Комментарий ДОЛЖЕН быть таким:
// "MUST: Здесь есть SQL injection. Используй PreparedStatement.
// Причина: параметр name вставляется напрямую в query."

// А не так:
// "Фу, это же опасно! Переделай!"

Проблема 2: Один разработчик тормозит всех

Сценарий: Есть junior, который не может понять, как работает проект. Все раздражены.

Как я решал:

• Не ругаем в чате — беру за руку на созвоне
• Пишу простенький шпаргалку (README, диаграмма архитектуры)
• Назначаю ментора — senior, кто заинтересован в его развитии
• Даю понять, что это нормально и наша задача его поддержать
• Неспеша объясняю (опыт показал, что спешка ухудшает ситуацию)

Результат: junior обычно начинает приносить пользу за 2-3 недели.

Проблема 3: Разработчик игнорирует feedback

Сценарий: Предлагаешь улучшение, а он делает вид, что не видел комментарий.

Как я решал:

• Первый раз вежливо напоминаю (может, правда не заметил)
• Второй раз пишу в личку без агрессии: "Помню, ты был занят, но можно обсудить?"
• Третий раз — беру с lead разработчиком на созвон, разбираемся вместе
• Если и дальше — скалирую до тим лида

Важно: не превращать это в личную вражду. Часто человек просто не понимает, почему это важно.

Проблема 4: Конфликт между двумя разработчиками

Сценарий: Девелопер A говорит, что код Девелопера B ужасный. B защищается. Начинаются взаимные оскорбления в чате.

Как я решал:

• Сразу же убираю обсуждение из открытого чата в личку (не позорить)
• Спрашиваю обоих в отдельных разговорах: "Что произошло?"
• Выясняю суть: обычно это разное видение архитектуры, а не личная неприязнь
• Сажаю их вместе (zoom, в офис) — в текстовом чате конфликты хуже
• Направляю дискуссию: "Нам нужно выбрать ОДИН подход. Давайте оценим оба вариант."
• Обычно находим компромисс
• После решения все хорошо

Проблема 5: Разработчик в депрессии от сложного кода

Сценарий: Человек столкнулся с legacy кодом, который никто не понимает. Потерял веру в себя.

Как я решал:

• Говорю: "Этот код сложный для ВСЕХ. Даже автор бы не вспомнил, что он писал."
• Предлагаю переписать вместе (паир программирование)
• Разбиваем на микро-задачи, не на весь module сразу
• Хвалю за каждый маленький прогресс (не сложно же обычно)
• Через неделю человек вновь верит в себя

Как я выбираю тех, с кем хочу работать

1. Открытость к feedback — без этого никакой рост
2. Честность — лучше сказать "не знаю" чем соврать
3. Готовность помочь — senior должен поднимать junior
4. Отсутствие жёсткого эго — есть разные подходы, и это нормально
5. Инициатива — не только выполняет задачи, но и предлагает улучшения

Мой подход к конфликтам

Правило 1: Никогда не в публичном чате Если есть проблема — в личку или на созвон.

Правило 2: Используй "я" вместо "ты"

❌ "Ты написал говно"
✅ "Я вижу проблему с производительностью в этом блоке кода"

Правило 3: Фокусируйся на проблеме, не на личности

❌ "Ты невнимательный"
✅ "Здесь есть off-by-one ошибка, давайте обсудим как её избежать"

Правило 4: Ищи выигрыш для обоих Если есть конфликт подходов:

• Оценка вариант A: скорость, поддерживаемость, производительность
• Оценка вариант B: скорость, поддерживаемость, производительность
• Выбираем лучший или комбинируем

Правило 5: Признавай свои ошибки первым Если я неправильно понял чей-то PR или сделал критику без контекста — я первый извиняюсь. Это создаёт атмосферу, где ошибаться можно.

Что я говорю на собеседовании

"За 10 лет я понял, что разработка — это 20% техники и 80% умение работать с людьми. Я пережил конфликты, сложные личности, техдолг и крайние сроки. Научился разговаривать, слушать и искать компромисс.

В моей последней команде из 5 человек все остались друзьями и активно помогали друг другу — это показатель здоровой команды.

Для меня идеальная команда — это люди, которые:

• Критикуют конструктивно
• Готовы менять мнение, если логика убедительна
• Помогают новичкам
• Признают ошибки
• Смотрят на цель проекта, а не на эго"