Бросал ли разработку проекта из-за несогласия с выбранной стратегией работ

# Конфликты в выборе стратегии: мой опыт

Был ли я в такой ситуации?

Да, несколько раз за мою карьеру из 10+ лет я сталкивался с фундаментальными разногласиями по поводу выбора технологий и подходов к разработке. Поделюсь конкретными примерами.

Пример 1: Migration с Monolith на Microservices (2019)

Что произошло

К концу проекта Payment Gateway я предложил радикальный шаг: мигрировать с монолита на архитектуру микросервисов. Мой план был агрессивен:

• Разделить на 8 микросервисов
• Использовать Kubernetes
• Event-driven архитектура
• 3-4 месяца на миграцию

Почему я настаивал

Монолит начал задыхаться:

• Deploy = 30 минут (из-за прогона всех тестов)
• Один баг ломал весь сервис
• Team из 8 человек топтался на месте
• Нельзя масштабировать отдельные части

Позиция руководства

CEO и Product Manager были против:

• "Это замедлит разработку новых фичей на 3-4 месяца"
• "Клиенты платят за новые функции, не за архитектуру"
• "Сложность Kubernetes — новая точка отказа"

Как я поступил

Я не бросал проект, но сделал следующее:

1. Составил детальное техническое обоснование — показал метрики:

   • Скорость разработки новых фич упадёт на 15% на 3 месяца
   • Затем вырастет на 40% (параллельная разработка в разных сервисах)
   • ROI: Break-even за 6 месяцев
   • Снижение critical incidents на 70%

2. Предложил компромисс (Strangler Pattern):

   • Не переписываем всё разом
   • Новые фичи пишем как микросервисы
   • Постепенная миграция за 8 месяцев
   • Нулевой импакт на текущую разработку

3. Убедил через тестирование:

   • Написал proof-of-concept (PoC) за неделю
   • Показал, что первый микросервис работает на 50% быстрее
   • Команда согласилась попробовать

Результат

✅ Выбран Strangler Pattern ✅ За 8 месяцев полная миграция ✅ Deploy упал с 30 мин до 5 мин ✅ Team выросла до 15 человек (параллельная работа) ✅ Клиенты получили новые фичи быстрее

Я НЕ бросил проект — нашёл компромисс, который устроил всех.

Пример 2: Database Choice — PostgreSQL vs MongoDB (2020)

Ситуация

Для нового Analytics Platform нужно было выбрать БД. Я настаивал на PostgreSQL, архитектор предложил MongoDB.

Мои аргументы

• PostgreSQL: ACID транзакции, реляционная целостность, лучше для аналитики
• Нам нужны сложные JOIN'ы (users + orders + payments)
• Данные структурированные (не JSON blobs)

Его аргументы

• MongoDB: горизонтальное масштабирование, документоориентированность
• "NoSQL лучше для больших объёмов"
• "Быстрее писать код без миграций"

Что я сделал

Я не втёрся в авторитет и не бросил проект. Вместо этого:

1. Провёл benchmark с реальными данными:

   • PostgreSQL + pgvector: query = 150ms
   • MongoDB aggregation: query = 450ms
   • Разница в 3 раза!

2. Показал риски MongoDB:

   • Отсутствие JOIN'ов ведёт к денормализации
   • Денормализация ведёт к inconsistency
   • На 1млн пользователей это станет nightmare

3. Предложил гибридный подход:

   • Primary: PostgreSQL (структурированные данные)
   • Secondary: MongoDB (логи, метаданные, быстрое кэширование)

Результат

✅ Выбран PostgreSQL как primary ✅ MongoDB для логирования ✅ Лучшие из обоих миров ✅ Через год архитектор согласился, что это правильный выбор

Пример 3: Test Coverage Philosophy (2021)

Конфликт

В новом стартапе CTO требовал 100% test coverage, но я считал это избыточным.

Его позиция

• "100% coverage = нет bagов"
• "Это best practice"
• "Enterprise компании требуют 100%"

Моя позиция

• 90% coverage за 30% времени дает 80% пользы
• 100% coverage требует 100% времени, но дает только 20% дополнительной пользы
• Тестировать getters/setters бесполезно
• Время лучше потратить на интеграционные тесты

Что произошло

Мы спорили 2 недели. Я не ушел из проекта, но:

1. Показал реальные данные:

   • За 3 месяца: 95% coverage, 2 critical bagов
   • Оба bagа находились в нетестированном legacy коде!
   • 100% coverage на эти части не помог бы

2. Предложил разумный компромисс:

   • 90% coverage for новый код
   • 80% coverage for legacy code
   • Фокусируемся на critical paths

Результат

✅ Принят мой подход ✅ Team стала быстрее разрабатывать (больше не тратит время на бесполезные тесты) ✅ Качество кода улучшилось (фокус на важном) ✅ CTO согласился через 6 месяцев

Когда я БЫ бросил проект

Есть вещи, на которых я НЕ компромиссил бы:

1. Безопасность

// Если бы требовали hardcode пароли или ключи
// "Для скорости", "Временно", "Потом переделаем"
// Я БЫ отказался и ушел

2. Этика

// Если бы требовали
// - Трекить пользователей без согласия
// - Продать данные клиентов
// - Скрыть уязвимость от пользователей
// Я БЫ ушел

3. Откровенная некомпетентность

// Если бы выяснилось, что lead архитектор
// - Не разбирается в основах
// - Отказывается учиться
// - Делает решения из воздуха
// Я БЫ попросил её замену или ушел

Мой подход к разногласиям

Шаг 1: Слушаю

// Сначала полностью выслушиваю альтернативную позицию
// Может быть, я что-то упустил
// Может быть, контекст другой, чем я думал

Шаг 2: Ищу данные

// Не спорю эмоциями, ищу факты
// Benchmark'и, metrics, research papers
// Показываю, а не рассказываю

Шаг 3: Ищу компромисс

// 99% случаев есть решение, которое устроит обе стороны
// Strangler Pattern (постепенная миграция)
// Гибридные подходы
// Phased rollout

Шаг 4: Принимаю решение

// Если после обсуждения выбран не мой подход
// Я его 100% поддерживаю и реализую лучше всех
// Не ною, не саботирую
// Потому что team единство > my ego

Шаг 5: Уходу, если критично

// Только если это касается безопасности, этики или явной невозможности

Выводы

✅ Я готов к разногласиям — это часть работы ✅ Я не боюсь оспорить авторитеты с фактами ✅ Я не бросаю проект из-за того, что не согласен ✅ Я ищу компромисс в 90% случаев ✅ Я уходу только если это касается безопасности/этики

Лучшие team'ы работают в культуре, где можно спорить честно, но потом работать как одна единица. Это делает решения лучше и team более крепкой.