Ответ
Конструктивное разрешение разногласий — ключевой навык для здоровой команды. Мой подход основан на аргументации, данных и поиске консенсуса.
1. Фокусировка на цели, а не на позициях Вместо спора "чей подход лучше" переводим дискуссию в плоскость: "Какая из предложенных архитектур лучше решает конкретные бизнес-задачи и соответствует нашим ограничениям (сроки, поддержка, производительность)?"
2. Использование объективных критериев Предлагаю оценивать варианты по заранее согласованным метрикам:
- Поддерживаемость: Насколько легко будет читать и изменять код новичку?
- Производительность: Есть ли объективные замеры (профилирование в Instruments)?
- Масштабируемость: Как решение поведет себя при росте кодовой базы?
- Риски: Зависимость от новых/нестабильных технологий?
3. Практические инструменты для принятия решений
- Proof of Concept (PoC): Если спор принципиальный, предлагаю быстро реализовать прототипы обоих подходов для сравнения «в бою». Это снимает большинство споров.
- Архитектурные записи (ADR): Документируем принятое решение, его контекст и последствия. Это создает shared understanding и справочник для будущих дискуссий.
Пример из опыта:
Спор: Внедрять SwiftUI в существующий UIKit-проект сразу или постепенно? Разные мнения: Часть команды — за быстрый переход, другие — за осторожный. Решение через PoC и критерии:
- Сделали PoC для одного экрана в SwiftUI, интегрировав его в UIKit-навигацию.
- Оценили по критериям: Время разработки (быстрее), Стабильность (есть баги в
List), Поддержка (iOS 13+).- Приняли компромиссное решение: Новые, относительно простые экраны — на SwiftUI. Сложные и ключевые — пока оставляем на UIKit. Параллельно обучаем команду.
4. Культура уважения и готовности изменить мнение Важно создать среду, где можно не соглашаться, но где окончательное решение, подкрепленное аргументами, поддерживается всеми. Если мои аргументы оказываются слабее, я готов поддержать решение коллеги.