Как отстаивал свою точку зрения?

Как отстаивать свою точку зрения в команде

Это критически важный навык для senior разработчика. Ситуации возникают часто, и нужно находить баланс между принципиальностью и конструктивностью.

1. Реальный пример: спор о архитектуре

Ситуация: На code review я заметил, что коллега предложил хранить критические бизнес-данные в памяти (in-memory) без синхронизации с БД.

Что я сделал:

Шаг 1 — сначала понял его позицию

Мне: "Слушай, мне понравился твой подход к оптимизации производительности. 
Можешь пояснить, почему ты выбрал in-memory для хранения статуса платежей?"

Коллега: "Это даст нам 10x производительность. Синхронизация с БД займет 200ms."

Шаг 2 — подготовил аргументы

• Собрал примеры потери данных в real-world (Facebook 2010, Twitter 2012)
• Посчитал risk: вероятность потери данных × убыток = критично
• Предложил альтернативу: Redis с persistence + write-ahead log

Шаг 3 — донес свою точку зрения

Мне: "Я согласен, что нам нужна производительность. Но давай посчитаем риски:

1. Если падет процесс — потеряются тысячи платежей
2. Это Data Loss, а не Performance Optimization
3. Customer trust = больше, чем 10x performance

Предложу альтернативу:
- Redis с RDB snapshots (persistence)
- Write-Ahead Log в PostgreSQL
- Sync асинхронно в фоне

Это даст нам 3-4x производительность и сохранит данные."

Шаг 4 — нашли компромисс

• Коллега согласился с аргументом про потерю данных
• Мы реализовали Redis + WAL подход
• Результат: 300ms вместо 200ms, но с гарантией данных

2. Метод аргументации: FACT-based подход

Вместо:

❌ "Твой код плохой"
❌ "Мне кажется, это не работает"
❌ "Я не согласен"

Используй:

✅ "По результатам нагрузочного теста, этот подход даст N/s throughput"
✅ "В документации Postgres указано, что для этого случая лучше использовать..."
✅ "Я провел эксперимент: вариант A = O(n), вариант B = O(log n)"

3. Пример 2: спор о технологии

Ситуация: Тим лид хотел использовать NestJS для нового микросервиса. Я считал, что Express + самописный фреймворк будет проще.

Как я это обсудил:

// Критерии сравнения
const comparison = {
  'Learning Curve': {
    express: '3 дня',
    nestjs: '2 недели'
  },
  'Team Experience': {
    express: 'Everyone knows it',
    nestjs: '2 people used it once'
  },
  'Performance': {
    express: '~40k req/s',
    nestjs: '~35k req/s (overhead)'
  },
  'Time to MVP': {
    express: '1 week',
    nestjs: '2-3 weeks'
  },
  'Scalability': {
    express: 'Need custom solution',
    nestjs: 'Built-in DI, modules'
  },
  'Maintenance': {
    express: 'More code, less structure',
    nestjs: 'Less code, enforced structure'
  }
};

Мой аргумент:

Мне: "NestJS лучше для долгосрочной поддержки. Вот почему:

1. Time to MVP vs Maintenance — инвестируем 1-2 дополнительных недели
2. Результат — structured code, easier refactoring
3. Onboarding новых разработчиков — проще с явной структурой
4. Maintenance cost на год — сэкономим ~200 часов

Итого: +2 недели сейчас = -200 часов в будущем"

Итог: Tim lead согласился, результат был хорош.

4. Метод "Agree to Disagree"

Если я не могу убедить::

// Если позиция коллеги логична, но я не согласен
Мне: "Я вижу твою логику, и твой подход имеет смысл.
     Но я считаю, что есть риск X и Y.
     Давай сделаем так:
     
     1. Реализуем твой вариант
     2. Установим metrics для отслеживания
     3. Если результаты не соответствуют ожиданиям,
        пересмотрим через 2 недели"

Этот подход:

• Показывает уважение к его точке зрения
• Предлагает конкретный способ проверить гипотезы
• Не создает конфликт

5. Сложный пример: спор с PM

Ситуация: PM хотел добавить фичу в спринт, но это потребует 3 недели, а спринт = 2 недели.

Как я это донес:

Мне: "Я вижу, что эта фича приносит ценность для пользователей.
     Однако нам нужно быть честными про оценки.
     
     Вот что я провел:
     1. Task breakdown: 15 subtasks
     2. Оценка: 13 story points (3 недели)
     3. Текущая capacity: 8 story points в спринт
     
     Опции:
     A. Перенести на следующий спринт
     B. Отложить что-то другое
     C. Сделать MVP версию (5 points) + остальное позже
     
     Рекомендую C — MVP даст пользователям ценность быстро."

ПM выбрал вариант C. Это была good decision.

6. Когда я ошибался

Ситуация: Я настаивал на использовании Postgres вместо MongoDB. Но потом мы столкнулись с проблемой иерархических данных, и MongoDB был бы лучше.

Как я это признал:

Мне на следующий день: "Вчера я был не прав. MongoDB был бы лучшим 
вариантом для наших иерархических данных. Я не учел этот use case.

Мога мы:
1. Провести миграцию на MongoDB?
2. Или оптимизировать Postgres подход?

Второй вариант проще сейчас, но первый лучше долгосрочно."

Это показало, что я готов пересмотреть свою позицию если появляются новые факты.

7. Ключевые принципы аргументации

Говори о проблеме, а не о человеке:

❌ "Твой код неправильный"
✅ "Здесь есть race condition, потому что..."

Слушай больше, говори меньше:

Время говорения:слушания = 1:2 (не 2:1)

Используй данные:

✅ Benchmark, numbers, metrics
❌ "Мне кажется", "Я думаю"

Предложи решение:

❌ "Это не работает"
✅ "Это не работает. Вот 2 варианта как исправить..."

Будь готов измениться:

Если тебе показали новые факты и аргументы — измени позицию
Это признак хорошего специалиста, а не слабости

8. Красные флаги (когда нужно стоять твердо)

Никогда не идите на компромисс с:

1. Security — никогда не хардкодь пароли
2. Data integrity — никогда не пропускай validation
3. Tests — не снижай coverage для скорости
4. Scalability — не выбирай решение, которое не масштабируется

В этих случаях нужно быть более категоричным.

9. Иерархия аргументов

1. Data (самое сильное) — benchmark, test results
2. Logic — reasoning, cause-effect
3. Experience — это помогало раньше
4. Opinion (самое слабое) — мне кажется

Для сильных аргументов используй top of pyramid.

Итоговый совет

Отстаивай свою точку зрения, но будь готов:

• Слушать
• Признавать ошибки
• Менять мнение с новыми данными
• Работать с людьми, даже если они не согласны

Лучший аргумент — не словами, а результатами. Если твой подход показывает лучшие результаты, люди сами придут к тебе.