Были ли ситуации когда взгляды не совпадали со взглядами руководства

Конфликты с руководством

Да, такие ситуации были несколько раз. Это нормально, когда разные люди видят проблемы под разными углами. Важно как это разрешать.

Случай 1: Переход с PHP на Node.js

Ситуация: Я работал в стартапе на PHP-based архитектуре. После 3-х лет система сильно заросла техническим долгом: медленная, сложно добавлять новые фичи, девелопмент зависал.

Я предложил переписать на Node.js + PostgreSQL. CTO сказал: "У нас нет времени на это. Нам нужны новые фичи прямо сейчас."

Мой подход:

1. Не спорил с эмоциями — я понимал его позицию. Бизнес нужны фичи, не архитектура.

2. Подготовил данные:

   • Провел анализ: каждая новая фича занимает в 3 раза больше времени из-за хрупкости кода
   • Посчитал: за год потеряли эквивалент 4 месяцев разработки на рефакторинг
   • Показал: с новой архитектурой разработка будет быстрее

3. Предложил компромисс:

   • Не переписываем всё сразу
   • Новые фичи пишем на Node.js
   • Старое постепенно миррируем
   • За 6 месяцев переходим полностью

4. Доказал концепт:

   • Вместе с одним разработчиком написал один модуль на Node.js
   • Он был готов в 2 раза быстрее чем на PHP
   • Код был проще и чище

Результат: CTO согласился. Через полгода вся система на Node.js, разработка ускорилась, техдолг упал.

Случай 2: Testing strategy

Ситуация: Я настаивал на 80%+ code coverage и TDD подходе. Manager считал это потерей времени: "Вместо тестов пиши фичи!"

Мой подход:

1. Понял его позицию — в стартапе каждый день важен. Я не был прав в том, что тесты важнее фич.

2. Показал реальный сценарий:

   • Мы написали feature без тестов (быстро)
   • Потом потратили 3 дня на поиск баг в production
   • Потом потратили день на fix после каждого обновления (было 2 update за месяц)
   • Всего потеряли 5 дней

   Если бы были тесты:

   • +2 дня на тесты при разработке
   • -1 день на обновления (тесты ловят ошибки)
   • Итого экономия 2 дня

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

   • Критичный код (payments, auth): 100% coverage
   • Бизнес логика: 70%+
   • UI код: не требуется
   • Постепенно повышаем планку

4. Показал инструменты:

   • Jest с хорошей инфраструктурой пишется быстро
   • Можно тестировать параллельно с разработкой

Результат: Договорились на 80% для core модулей. Потом он сам увидел что баги уменьшились, и уже не возражал.

Случай 3: Микросервисы vs Монолит

Ситуация: CTO хотел сразу разделить монолит на 10 микросервисов. Я говорил что это оverkill для нашего размера компании.

Проблема моей позиции: Я был прав по технике, но слишком категоричен. Я сказал: "Это bad idea" и остановился. Не объяснил почему.

Мой подход (в следующий раз):

1. Нарисовал сценарий:

   Микросервисы добавляют:
   - Complexity: изучать N сервисов вместо 1
   - DevOps: нужен K8s, monitoring, logging для каждого
   - Network overhead: 100ms между сервисами
   
   Нашего размера (5 разработчиков, $100К MRR):
   - Монолит: 1 простой deploy, 200ms response
   - Микросервисы: 5 deploys, 400ms response, 2 DevOps инженера
   

2. Предложил roadmap:

   • Сейчас: монолит с чистой архитектурой (можем рефакторить)
   • 6 месяцев: если растем 3x → подумаем о разделении
   • 1 год: если нужна масштабируемость → тогда микросервисы

3. Показал примеры:

   • Airbnb, Uber, Netflix — начали с монолита
   • Разделили когда действительно потребовалось

Результат: Согласился на план. Спустя год, когда действительно нужна была масштабируемость, мы разделили на 3 сервиса (не 10), с конкретными причинами.

Мой подход в конфликтах взглядов

Что я делаю:

1. Слушаю первым, говорю вторым

   • Почему руководитель так считает?
   • Какие ограничения он видит?
   • Может в нём есть важная информация (про бизнес, про клиента)

2. Думаю о бизнес целях

   • Не о технике, а о impact
   • Не "это хорошая архитектура", а "это даст нам 20% скорость разработки"

3. Приносю данные

   • Анализ, метрики, примеры
   • Не мнение, а факты

4. Предлагаю компромисс

   • Постепенный переход
   • Эксперименты
   • Вариант который подходит обеим сторонам

5. Соглашаюсь когда проигрываю

   • Потом доказываю результатом, если был прав
   • Или признаю что ошибался

Когда я не согласен

Есть моменты, когда я ставлю ногу в землю:

1. Безопасность — если решение запихивает потенциальный взлом, я не согласен
2. Compliance — если нарушает закон
3. Крайняя неправильность — если это 100% приведет к отказу системы

Но это случается редко. И даже здесь я сначала объясняю, а не просто отказываю.

Вывод

Конфликты взглядов между разработчиком и руководством — это нормально. Главное:

• Слушай
• Приноси данные
• Предлагай компромисс
• Гибкость в методе, твёрдость в целях
• Не зацикливайся на технологии, фокусируйся на результате