Ответ
Решение конфликтов строится на принципах открытости, фокусе на проблеме, а не на личности, и совместном поиске оптимального решения для проекта.
Структурированный подход:
- Выявление и анализ: Даю высказаться всем сторонам, чтобы понять не только позиции, но и интересы и стоящие за ними опасения (например, спор об архитектуре может скрывать беспокойство о поддерживаемости кода или сроках).
- Фокусировка на цели: Напоминаю об общей цели проекта и команды. Предлагаю оценивать варианты по объективным критериям: производительность, поддерживаемость, сроки реализации, соответствие требованиям.
- Поиск решения:
- Технический диспут: Организую обсуждение с представлением аргументов "за" и "против", возможно, с написанием прототипов или spike-решений.
- Компромисс: Ищу вариант, который частично удовлетворяет интересы всех сторон.
- Эскалация: Если консенсус не достигнут, привлекаю тимлида или технического лида для принятия финального решения, которое команда обязуется поддержать.
Пример: Конфликт из-за выбора библиотеки для сети. Решением стало: 1) Сравнение по критериям (размер, активность поддержки, удобство API). 2) Создание двух простых тестовых модулей для оценки на практике. 3) Совместное голосование на основе собранных данных.
Важно: Поддерживать уважительную атмосферу, не допускать перехода на личности и рассматривать конфликт как возможность найти лучшее решение, а не как проблему.
Ответ 18+ 🔞
Да ты посмотри, какие у нас тут принципы благородные — открытость, фокус на проблеме, а не на личности, совместный поиск. Прямо как в каком-нибудь ебучем корпоративном букваре, блядь. Но если без этой сладкой хуйни, то суть в чём: чтобы не перегрызли друг другу глотки из-за того, какой хуйней писать — axios или fetch, или какую архитектуру выбрать — микросервисы или монолит, который потом разъёбывать три года.
Как я это обычно делаю, чтобы не было пиздеца:
-
Дать всем выговориться. Пусть каждый вывалит свою хуйню, но не просто «я за React», а «почему, сука, за React». Может, у человека там травма от Angular 1.x, или он боится, что на поддержку Vue мало специалистов. Нужно докопаться до реальной причины, а не до верхушки айсберга, которая торчит, как хуй из штанов.
-
Напомнить, ради чего всё это. Мы тут не для того, чтобы доказать, кто умнее, а чтобы фичу запилить, проект запустить, бабки заработать. Предлагаю смотреть на варианты через призму объективных критериев: что быстрее, что стабильнее, что легче поддерживать, что впишется в сроки, которые уже просрали.
-
Ищем выход, а не виноватых.
- Технический баттл — окей, пусть каждый приведёт аргументы, напишет кусок кода, докажет на практике. Иногда после пяти минут реального кодинга все споры заканчиваются, потому что становится ясно, что один вариант — просто пиздец какой кривой.
- Компромисс — ищем что-то среднее, чтобы все немного выиграли и немного посрали. Не идеально, но работает.
- Эскалация — если уж совсем упёрлись, как бараны в жопе мира, зовём тимлида или техлида. Пусть он, мудак, принимает решение, а потом вся команда его поддерживает, даже если внутри все орут «я же говорил, ёпта!».
Пример из жизни, чтобы не было абстрактной хуйни:
Спорили как суки за библиотеку для HTTP-запросов. Один орет «axios, там интерцепторы!», второй — «fetch, нативный, не тащи зависимость!».
Сделали так:
- Зафиксировали критерии: размер бандла, удобство API, возможность мокать в тестах.
- Каждый написал по маленькому модульчику на своём фаворите, чтобы ощутить, как это в реальности.
- Устроили голосование на основе цифр и ощущений. В итоге выбрали то, что оказалось адекватнее по сумме факторов, а не потому, что у кого-то громче крик.
Самое главное — не дать превратить спор в войну. Конфликт — это иногда даже полезно, если он вытаскивает на свет божий скрытые проблемы. Но если начинается переход на личности — сразу останавливаю, напоминаю, что мы все в одной лодке, и если её разъебать, то пойдём ко дну вместе, как дурачки.