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

Когда разработчик хочет других технологий: как ответить

Это классический конфликт: инженер хочет usar новый язык/framework, вы как PM думаете что это добавляет сложность. Давайте разберем как это решать правильно.

Реальный сценарий

Разработчик говорит: "Я хочу переписать backend на Go вместо Python. Это faster и scalable."

Вы знаете что:

• Проект уже на Python
• Team лучше знает Python
• Нет urgent требований в production
• Это затянет delivery

Что вы говорите?

Неправильный ответ

Не говори: "Нет. Мы используем Python. Делай на Python."

Почему это плохо:

• Engineer чувствует себя не услышанным
• Может снизить его мотивацию
• Он может думать что вы не understand technical value
• Это не collaborative

Правильный подход

Шаг 1: Слушай его аргументацию

Вместо "no", спроси: "Почему ты хочешь Go? Какой benefit это даст?"

Он может сказать:

• "Go 10x faster чем Python"
• "Go лучше для concurrency"
• "Наш traffic растет, Python не справляется"
• "Я хочу learn Go для карьеры"

Это даст тебе information.

Шаг 2: Проверь facts

Не just верь что Go 10x faster. Спроси:

• "Есть ли benchmark data?"
• "Где именно bottleneck в Python коде?"
• "Является ли это production problem или potential problem?"

Обычно выясняется:

• Python достаточно fast для current traffic
• Bottleneck не в language а в database query
• Go может быть overkill

Шаг 3: Понимай trade-offs

Go faster но имеет costs:

Вопрос: Какой trade-off worth it?

Шаг 4: Define критерий для change

Вместо "нет" просто скажи: "Я понимаю desire за Go. Давайте define когда это makes sense."

Опции:

Вариант 1: Test first

"Давайте один small service напишемо на Go.

• Measure performance
• Measure development speed
• Если результаты good, расширяем
• Если не great, остаемся на Python"

Этот approach:

• Не commits всю codebase
• Дает empirical data
• Разработчик happy (может try Go)
• Risk managed

Вариант 2: When we have scaling pain

"Сейчас Python достаточно. Когда we hit 10x traffic и Python не справляется → переделаем на Go."

Этот approach:

• Может быть Go не будет нужна когда-то
• Дает time для team learn Go properly
• Не спешит decision

Вариант 3: Use Go for new services

"Мы остаемся на Python для существующего code. Новые services можем делать на Go."

Этот approach:

• Позволяет разработчику use new tech
• Не disturbs existing codebase
• Gradual transition
• Микросервис architecture benefits

Ключевые вопросы которые я спрашиваю

Вопрос 1: Is this technical decision или personal preference?

Есть разница:

• "Production is down, Python не справляется" = technical decision
• "Go is cool, я хочу learn" = personal preference

Оба valid но требуют разные ответы.

Вопрос 2: Есть ли production problem or potential problem?

• Production problem (system slow, timing out) = нужно act
• Potential problem (might be slow when we scale) = можем wait

Вопрос 3: Может ли мы optimize current stack first?

При antes переписывать в новый язык, может быть оптимизировать текущий:

• Database optimization
• Caching
• Code refactoring
• Это часто дешевле чем rewrite

Вопрос 4: Кто будет maintain это?

Если only one person knows Go:

• Большой risk для компании
• Если он уходит, code unmaintainable
• Нужна team которая может support

Реальный пример

В одной компании инженер хотел переписать все на Rust.

Я:

1. Слушал его arguments
2. Проверял data (no performance issue currently)
3. Спросил про trade-offs (hiring, learning curve, library ecosystem)
4. Предложил: "Давайте напишем один новый service на Rust. Посмотрим как идет."

Результат:

• Инженер очень happy что может попробовать Rust
• Написал one service за 2 недели
• Performance was good но Python было достаточно для use case
• Team learned Rust
• Остальное осталось на Python
• Everyone happy

Это win-win решение.

Что я бы сказал разработчику

"Я appreciate что ты думаешь о technology stack. Go - это great language.

Но я need to understand: это решает production problem или это preference?

Если production problem:

• Покажи мне данные/benchmarks
• Давайте обсудим timeline и resources
• Может быть optimize Python first

Если preference:

• Я understand desire to learn new tech
• Давайте find way where you can use Go
• Например new service или реплacement текущего
• Но нужно consider: hiring, maintenance, team knowledge

Мой recommendation: start small. One service на Go. Measure results. Then decide bigger changes.

Это way you get to try new tech без big risk для компании."

Этот answer:

• Respects engineer's opinion
• Shows you understand value
• Но делает decision data-driven
• Находит compromise

Когда я говорю ДА

Я say yes если:

1. There's real production problem

   • "Our API response time 10 seconds, нужно <1 second"
   • Технология может solve

2. We can afford risk

   • Team может learn new language
   • Есть resources для переписывания

3. Long-term benefit

   • Not just "learn new language"
   • Real performance/maintainability improvement

4. Plan is clear

   • Когда мигрируем
   • Как тестируем
   • Как rollback если problems

Когда я говорю НЕТ

Я say no если:

1. No real problem

   • Python works fine
   • Request is just "want to try"

2. Risk high, benefit low

   • Rewrite takes 3 months
   • Benefit is 10% speed (не critical)
   • Not worth it

3. Team knowledge gap

   • Nobody knows new language
   • Hiring difficult
   • Maintenance risk

Финальный совет

Лучший PM это не тот что says "нет" но тот что understand technology и находит creative solutions.

"Давайте test на new service" это better than "We always Python".

Этого way:

• Engineer happy (gets to learn)
• Company happy (tests technology)
• Risk managed (only one service)
• Data-driven decision

Everybody wins.