Что будешь делать если коллега выбрал неэффективный способ решения задачи?

Что делать если коллега выбрал неэффективный способ решения задачи

Это один из самых важных навыков в работе PM — управление конфликтами и влияние без полномочий. Я не начальник разработчика, но должен помочь ему сделать лучше. Вот мой подход.

Принципы моего подхода

1. Никогда не в лоб критиковать

• ❌ ПЛОХО: "Это неправильный подход, делай вот так"
• ✅ ХОРОШО: "Я вижу что ты выбрал это решение. Можешь объяснить почему? У меня есть вопрос..."

2. Предполагать добрые намерения Мой коллега выбрал это решение по причине:

• Может он знает что-то что я не знаю
• Может это лучше всего при текущих constraint'ах
• Может он учитывал факторы которые мне неведомы

3. Быть фасилитатором, не диктатором Моя роль — помочь команде найти ЛУЧШЕ решение, а не навязать своё.

Шаг за шагом процесс

Шаг 1: Понимание (не суждение)

Первое что я делаю — спрашиваю, не критикую:

Примечание: разработчик выбрал решение которое кажется мне неэффективным.

Я говорю:
"Привет [имя], я видел что ты выбрал подход с [решение X]. 
Можешь объяснить почему ты выбрал это? Мне интересно услышать твоё обоснование."

Почему это важно?

• Может быть я ошибаюсь и его решение лучше
• Я даю ему возможность защитить свой выбор
• Я показываю уважение к его мнению

Шаг 2: Слушаю активно

Когда он объясняет, я действительно слушаю:

• Не перебиваю
• Не оспариваю во время
• Задаю уточняющие вопросы
• Пытаюсь понять его логику

Он: "Я выбрал подход с монолитной архитектурой потому что..."
Я: "Интересно. А как это влияет на время deploy'а?"
Он: "Ну, он медленнее, но мы можем..."
Я: "Понял. А что насчёт масштабирования?"

Шаг 3: Объяснение моих concerns (не критика)

Теперь я поднимаю свои concerns, но в формате вопросов, а не утверждений:

✅ ХОРОШО:
"Я понимаю твоё обоснование. У меня есть concern по поводу [X].
Если мы используем это решение, как мы справимся с [проблемой]?"

❌ ПЛОХО:
"Это решение не сработает потому что..."

Шаг 4: Предложение альтернатив

Если я действительно верю что есть лучше решение, предлагаю его:

"Я вижу плюсы в твоём подходе. Но я думаю что есть альтернатива которая может быть лучше. 
Можем ли мы вместе рассмотреть подход [Y]?"

Далее я объясняю:

• Почему я думаю что это лучше
• Какие плюсы это имеет
• Какие минусы (я честен)
• Как это compares с текущим подходом

┌─────────────────┬────────────────┬────────────────┐
│ Критерий        │ Текущий подход │ Альтернатива   │
├─────────────────┼────────────────┼────────────────┤
│ Скорость разра- │ 2 недели       │ 3 недели       │
│ ботки           │                │                │
│ Maintenance     │ Высокий        │ Низкий         │
│ Масштабирование │ Сложно         │ Легко          │
│ Время deploy    │ 30 мин         │ 5 мин          │
└─────────────────┴────────────────┴────────────────┘

Основное преимущество: Long-term maintenance намного проще.
Маин disadvantage: Нужно на 1 неделю больше на разработку.

Шаг 5: Совместное решение

Не я решаю, ОН решает (или вместе):

"Что ты думаешь? Может быть нам стоит подумать о [альтернативе]?"

Опции:
А) Он согласен и меняет подход
Б) Он возражает и объясняет почему его подход лучше
В) Мы находим компромисс

Когда коллега категорически против

Если он не согласен, у меня есть опции:

Опция 1: Я ошибался

"Окей, я понимаю твою точку зрения. Может быть я был неправ.
Давай попробуем твой подход и посмотрим что получится."

Опция 2: Компромисс

"Я вижу что мы не согласны. Может быть есть middle ground?
Что если мы..."

Опция 3: Эскалация к техлидеру/менеджеру

Только если это ОЧЕНЬ важно:

"Я думаю это важная решение которое влияет на продукт. 
Может быть нам нужно обсудить это с техлидом и убедиться что все согласны?"

НО! Эскалация — это последний вариант. Это портит отношения.

Конкретный пример

Ситуация: Разработчик выбрал использовать no-SQL базу когда нужна relyability и transactional integrity.

МОЙ ПОДХОД:

1. ПОНИМАНИЕ
Я: "Я вижу что ты выбрал MongoDB вместо PostgreSQL. 
Можешь объяснить почему?"
Он: "Потому что это faster и проще масштабировать. У нас будет миллионы records."

2. СЛУШАЮ
Я: "Хорошо, я понимаю concern по поводу масштабирования. 
А как ты планируешь справляться с consistency?"
Он: "Ну, мы можем делать application-level validation."

3. ВЫСКАЗЫВАЮ CONCERN
Я: "Я понимаю. У меня есть concern: application-level validation может привести к bugs 
еесли несколько processes пишут в БД одновременно. 
Как мы это решим?"

4. ПРЕДЛАГАЮ АЛЬТЕРНАТИВУ
Я: "Может быть PostgreSQL с правильной индексацией лучше?
Он имеет ACID транзакции что гарантирует consistency. 
И benchmarks показывают что он может справиться с миллионами записей."

5. ОБСУЖДАЕМ
Он: "Но это медленнее при записи."
Я: "Может быть. Но какой метрика важнее для нас — write speed или data reliability?"
Он: "Хм, reliability скорее."
Я: "Тогда может быть стоит попробовать PostgreSQL?"

6. ОН РЕШАЕТ
Он: "Окей, я попробую PostgreSQL и посмотрю как она справляется."
Я: "Отлично. И если окажется что она слишком медленная, мы всегда можем поменять."

Когда он явно ошибается (очевидная ошибка)

Если он собирается сделать что-то очень плохое (типа захардкодить password):

Я: "Стоп, нужно обсудить. Это может быть security risk.
Что если мы будем использовать environment variables вместо hardcoding?"

Важно: Я говорю fast и ясно, но не rudely.

Ошибки которых нужно избежать

❌ Быть слишком критичным

• "Это неправильно" (вместо "Может быть есть другой способ?")
• Это убивает мотивацию

❌ Давить авторитетом

• "Я PM, слушайся" (если ты не его менеджер, это не работает)
• Он будет делать назло

❌ Не слушать его feedback

• Если он说 что-то разумное, нужно это признать
• Else он не будет слушать тебя в следующий раз

❌ Эскалировать сразу

• Это последний вариант
• Сначала попробовать разговор

❌ Быть слишком мягким

• Если это действительно плохая идея, нужно сказать
• Но как? Смотрите выше 👆

Когда я сам ошибался и коллега указал

Это очень важно — я ДОЛЖЕН быть открыт к критике:

Коллега: "Я думаю этот approach не лучший потому что..."

Я (правильный ответ):
"Спасибо что указал. Я не подумал об этом. Может быть ты прав.
Давай обсудим твой вариант."

Я (неправильный ответ):
"Нет, я уже всё обдумал."

Если я всегда прав, никто мне не будет доверять и не будет предлагать хорошие идеи.

Долгосрочная стратегия

Чтобы минимизировать такие конфликты:

1. Беру разработчика в обсуждение на ранней стадии

   • Не даю ему готовое решение
   • Думаем вместе

2. Создаю культуру где OK обсуждать подходы

   • Регулярные архитектурные обсуждения
   • Design reviews
   • Где люди могут предложить идеи

3. Слушаю его ideas и признаю когда он прав

   • Это создаёт trust
   • Он будет слушать меня когда я имею concern

4. Нанимаю smart people

   • Если разработчик достаточно smart, он будет находить хорошие решения
   • Моя задача не контролировать, а помогать

Резюме

Ключ — это influence without authority. Я должен:

1. Понять почему он выбрал это решение
2. Слушать его обоснование
3. Уважать его мнение
4. Предложить альтернативы если вижу лучше
5. Дать ему решить (или найти компромисс)
6. Признать если я был неправ

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