Приведи пример расхождения мнений с коллегами

Расхождение мнений с коллегами: реальный пример

Ситуация

Контекст: I-квартал текущего года, платформа для управления складом (WMS). Сервис ежедневно обрабатывает 100k операций, работает 2 года, используют 50+ компаний.

Проблема, которую нужно решить: Клиенты жалуются на медленность при экспорте данных. Экспорт 10k заказов занимает 45 секунд. Бизнес хочет ускорить до 5 секунд.

Мнение CTO (начальник разработки):

"Нам нужно полностью переписать backend на Go. Python медленный. Это единственное решение. Бюджет: 3 месяца, 2 разработчика."

Мнение Lead Developer (Python):

"Тебе не нужно переписывать. Проблема в неправильной индексации БД и N+1 queries. Можно оптимизировать за 2 недели. Бюджет: 100 часов на рефакторинг + тестирование."

Моё мнение (как аналитик):

"Обе позиции верны частично, но обе неполные. Нужно сначала выяснить, где реально узкое место."

Как я это решил

Шаг 1: Анализ и факты (2 дня)

Я провёл анализ:

• Запустил профилирование экспорта (Python profiler)
• Проанализировал query log в Postgres
• Снял метрики: CPU, memory, network

Что обнаружил:

45 секунд = 45000 ms
├─ SQL queries:    28000 ms (62%)  ← основной узкое место
├─ Serialization:   12000 ms (27%) ← JSON generation
├─ Network:         4000 ms (9%)   ← отправка клиенту
└─ Other:           1000 ms (2%)

Подробнее SQL:

Всего SQL запросов: 1001
├─ 1 query на загрузку заказов: 100ms  ← оптимально
├─ 1000 queries на загрузку items:     ← N+1 problem!
│   (по 20-30ms каждый)
│   Total: 22000 ms
└─ Batch update created_at: 500ms

ЗАКЛЮЧЕНИЕ: Lead Developer был прав в диагнозе (N+1 queries), но неправ в оценке сложности. Есть и проблема с JSON serialization.

Шаг 2: Обсуждение с командой (встреча 1 час)

Я предложил обсудить факты:

Я (аналитик): "Ребята, я нашёл основные проблемы. Давайте посмотрим на факты:"

1. N+1 queries (Lead был прав)
2. JSON serialization слишком медленная (CTO был прав, это production issue)
3. НО: переписывание на Go — это не фиксит JSON serialization
   (Go генерирует JSON не быстрее, это всё равно 12 секунд)

Сценарий 1: Оптимизация Python
- Исправить N+1 queries (join вместо 1000 отдельных запросов)
- Использовать streaming JSON (не грузить всё в память)
- Результат: 28s → 8s (70% improvement)
- Бюджет: 2 недели
- Риск: низкий

Сценарий 2: Переписать на Go
- 3 месяца, высокий risk (новый сервис, неизвестные баги)
- Может снизить до 3-4 секунд (теоретически)
- Но нужно переинтегрировать с остальной системой

Предложение: Сценарий 1 + частичное улучшение сериализации
Время: 3 недели
Результат: 45s → 6s
Бюджет: 150 часов

CTO: "Может быть, но я всё равно не верю, что Python можно оптимизировать так сильно."

Lead: "Go не будет быстрее. JSON serialization занимает время и на Go."

Шаг 3: Proof of Concept (5 дней)

Я предложил PoC:

"Давайте потратим 5 дней на PoC исправления N+1 на одном экспорте. Увидим результаты."

Все согласились.

Результат PoC:

До оптимизации:      45 000 ms
После fix N+1:       18 000 ms (-60%)
+ Streaming JSON:     6 500 ms (дополнительно -63%)
= Итого:             ~6 500 ms ✓

CTO: "О, интересно. Тогда давайте идти в production."

Lead: "Я говорил! Но я не ожидал, что streaming поможет так сильно."

Шаг 4: Планирование финального решения

Мы решили:

1. Исправить N+1 queries (2 недели)
2. Добавить streaming JSON (1 неделя)
3. Добавить compression (опционально) (3 дня)
4. Тестирование и оптимизация (1 неделя)

Общий бюджет: 3-4 недели вместо 3 месяцев Go переписи.

Почему это был конфликт и как я его разрешил

Сути конфликта:

• CTO: склонен к "большим архитектурным решениям", видит систему как целое
• Lead Dev: склонен к "local optimization", верит в incremental improvement
• Обе позиции были неполными без анализа узких мест

Мой подход (System Analyst'а роль):

1. Не сторонился вопроса

   • Много аналитиков избегают конфликтов
   • Я не избежал, но привёл факты

2. Отделил мнения от фактов

   • CTO мнение: "Python медленный" (частично верно, но неполно)
   • Факт: Python не проблема в 62% случаев (SQL медленный)

3. Предложил компромисс с доказательством

   • Не сказал: "Оба не правы"
   • Сказал: "Давайте PoC покажет"
   • PoC дал обоим то, что они хотели: уверенность в решении

4. Managed expectations на раннем этапе

   • CTO думал: "3 месяца, потом вся система будет быстра"
   • Я объяснил: "Go не решит JSON problem"
   • Это спасило от неправильного большого проекта

Что я выучил из этого

Для себя:

• Данные > мнения. Всегда профилируй перед оптимизацией
• Большие архитектурные решения часто маскируют local problems
• Senior разработчики часто верят в наобум, а не проверяют

Для команды:

• Эта ситуация стала case study для новых людей: "Как не ломать стол из-за гвоздя"
• Теперь все используют profiling перед тем, как предлагать переархитектуру

Другой подобный конфликт (краткий)

Ситуация: Дизайнер хочет полностью переделать UI ("устарело"). Разработчик против ("это 2 месяца работы").

Моё решение: Я провёл user research: спросил 20 клиентов про UI. Результат: UI okay, но есть 3 конкретных болевые точки.

Вместо полной переделки:

• Fixed 3 pain points (2 недели)
• Gradual design improvement (1 UI element per sprint)

Дизайнер доволен: видит, что его идеи внедряются. Разработчик доволен: нет большого bang.

Best practices для разрешения конфликтов

Как System Analyst'ы должны разрешать конфликты:

1. Слушайте обе стороны без осуждения

   • CTO: "Почему вы думаете, что Go лучше?"
   • Lead: "Почему вы уверены, что это N+1?"

2. Приводите факты

   • Profiler, metrics, data
   • Не эмоции

3. Ищите компромисс

   • Редко один полностью прав
   • Часто решение находится в середине

4. Предлагайте валидацию

   • PoC
   • A/B testing
   • Metrics

5. Документируйте решение

   • Почему выбрали этот путь
   • Какие альтернативы рассматривали
   • Что выучили

Вывод

Расхождение мнений в технических командах — это норма, а не исключение. Роль System Analyst'а — быть выше этих конфликтов и помочь команде найти лучшее решение через:

• Анализ фактов (не мнений)
• Управление ожиданиями (что может быть, а что нет)
• Proof of concepts (валидация перед большими решениями)
• Компромиссы (часто лучшее решение = комбинация идей)

Лучшая метрика успеха — когда обе стороны конфликта говорят в конце: "Да, это имело смысл. Спасибо, что заставил нас подумать." Это знак, что я правильно разрешил конфликт не подавлением, а рациональным анализом.