Что будешь делать если посчитаешь идею коллеги плохой?

Как я отношусь к критике чужих идей

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

Основные принципы

1. Сначала слушаю и понимаю

Перед тем как что-то оценивать, я полностью слушаю объяснение коллеги. Часто кажется, что идея плохая, потому что не хватает контекста. Я задаю уточняющие вопросы:

• Почему именно такой подход?
• Какие альтернативы рассматривались?
• Какие ограничения учитывались?

2. Выделяю положительное

В любой идее есть хорошие моменты. Я начинаю с признания того, что сделано правильно:

• "Мне нравится, как ты решил проблему X"
• "Это хороший путь для того, чтобы..."

Это создает позитивную атмосферу и показывает, что я не просто критикую.

3. Объясняю проблемы конкретно

Критика должна быть объективной и конкретной, не личной:

// ❌ Плохой способ:
"Это плохая идея"
"Это не сработает"

// ✅ Правильный способ:
"Если мы используем этот подход, возникнут проблемы с масштабируемостью,
потому что на 10,000 пользователей база данных будет обрабатывать 
X операций в секунду. Это превышает текущие лимиты PostgreSQL при такой схеме.

Пред рекомендую использовать кэширование через Redis или переделать запросы."

4. Предлагаю альтернативы

Если я вижу проблемы, я не просто говорю "это не работает", а предлагаю решения:

• Вариант 1: Использовать approach X (плюсы: Y, минусы: Z)
• Вариант 2: Использовать approach A (плюсы: B, минусы: C)
• Мой совет: Я бы выбрал вариант 1, потому что...

Практический пример

Коллега предлагает новую архитектуру микросервисов:

"Давайте каждый сервис будет иметь свою БД, полностью независимый stack"

Мой ответ:

"Спасибо за идею, мне нравится стремление к независимости сервисов. Это хорошо для разработки и развертывания.

Однако я вижу потенциальные проблемы:

1. Консистентность данных — когда нам нужны данные из двух сервисов одновременно, как мы гарантируем консистентность? Distributed transactions сложны и медленны.

2. Network latency — каждый запрос теперь может требовать нескольких network round-trip. Это замедлит систему.

3. Дублирование кода — много логики придется писать в каждом сервисе.

Предлагаю рассмотреть:

• Использовать event-driven архитектуру с message broker (RabbitMQ/Kafka) для синхронизации
• Иметь shared слой для общей логики, но разные БД
• Или создать BFF (Backend For Frontend) слой для агрегации данных

Любой из этих вариантов даст нам независимость, но с лучшей консистентностью. Какой нравится вам?"

Ключевые моменты

Я никогда не делаю:

• Не критикую человека, только идею
• Не говорю «это очевидно» или «любой знает, что..."
• Не решаю за человека, предлагаю обсудить
• Не оставляю диалог на отрицательной ноте

Я всегда делаю:

• Слушаю полностью
• Выделяю хорошее в идее
• Объясняю проблемы с примерами и цифрами
• Предлагаю альтернативы
• Пригашаю к дискуссии, не к спору

Случаи, когда я молчу

Стоит отметить, что не всегда нужно критиковать идею сразу:

• Ранний stage — если идея в стадии размышления, лучше дать подумать
• Not my domain — если это не моя ответственность, я спрашиваю перед критикой
• Предложение улучшения — если идея работает, но можно лучше, это может подождать code review

Критика должна быть конструктивной и направлена на улучшение, а не на демонстрацию власти или интеллекта. В хорошей команде критика — это знак уважения, а не враждебности.