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

Как решить разногласие с инженером о том, что разработать

Этот вопрос проверяет мою способность к переговорам, уважению мнения других, и нахождению консенсуса. Это центральный skill PM.

Мой подход: Не победить спор, а найти best solution

Разногласие между PM и engineer это opportunity найти лучшее решение, потому что каждый имеет разные perspective.

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

Ситуация:

• Я (PM): хочу разработать Feature A (автоматическое архивирование)
• Engineer (Tech Lead): говорит, что сначала нужен рефакторинг БД

Мой интерес: быстро запустить Feature A Engineer интерес: качество и масштабируемость

Шаг 1: Не защищаю позицию, слушаю

Вместо (неправильно): "Нет, мы делаем Feature A. Рефакторинг может ждать."

Правильно: "Расскажи, почему ты думаешь, что рефакторинг нужен перед Feature A?"

Теч Лид объясняет: "Архитектура не масштабируется. Если мы разработаем Feature A сейчас, создадим техдолг, который потом проблемный. Лучше исправить foundation сейчас."

Я слушаю активно.

Это важно, потому что:

• Engineer видит technical risks
• Engineer имеет опыт в архитектуре
• Может быть прав

Шаг 2: Выясняю детали его аргумента

"Понимаю. Расскажи:

1. Какие конкретно проблемы возникнут?
2. На какой точке (при скольких пользователей)?
3. Сколько времени на рефакторинг?
4. Есть ли middle ground решение?"

Tech Lead: "При 50k пользователей БД будет медленна. Рефакторинг требует 6 недель. Или 4 недели если делать вместе с Feature A."

Шаг 3: Выясняю мой constraint

"3 клиента просят Feature A. Если не запустим в месяц, потеряю две сделки ($200k revenue)."

Теперь engineer знает business context.

Шаг 4: Ищем решение вместе

Вариант A: Feature A сейчас, рефакторинг потом

• Быстро, но техдолг

Вариант B: Рефакторинг + Feature A (4 недели)

• Правильно, но медленно

Вариант C: MVP Feature A, потом рефакторинг

• Быстро, меньше функций

Вариант D: Parallelized (рефакторинг и разработка одновременно)

• Две team работают параллельно
• Потом merge

Enginer: "Вариант D может работать!"

Шаг 5: Consensus decision

Решили на Вариант D (4 недели):

• Database team рефакторит (2 недели)
• Application team разрабатывает на sandbox (параллельно)
• Weekly syncs для coordination

Почему это работает:

• Engineer get его приоритет (правильная архитектура)
• Я get мой приоритет (быстро запустить)
• Компания get лучше решение

Почему мой подход работает

1. Я слушаю, не argue Знаю, что engineer часто right о technical issues.

2. Я объясняю business constraint Инженер нужно понять context.

3. Я ищу win-win Лучший outcome это когда обе стороны довольны.

4. Я ценю их expertise Инженер это не просто executor. Это expert в своем домене.

Когда я стану firm

Business-critical deadline: "Я понимаю твою точку. Но deadline критичен. Делаем Feature A сейчас. Рефакторинг в next sprint."

Enginer может быть недоволен, но поймёт.

Engineer требует идеальность: "Я ценю quality. Но не можем ждать 6 месяцев. Делаем 80% решение сейчас, iterate потом."

Я know engineer wrong: Редко. Но если требует переписать всё в новый язык без reason: "Спасибо за идею. Но это overkill. Давайте profile код, найдём bottleneck."

Как maintain relationship после disagree

Если я настоял и провалилась:

1. "Ты был прав. Это моя ошибка."
2. Fix это (установить приоритет на рефакторинг)
3. "Спасибо, что ты был настойчив. Буду лучше слушать."

Так engineer знает, что его мнение valued.

Общее правило: Respect engineers

Инженеры видят:

• Technical risks
• Feasibility issues
• Долгосрочные implications

Их input это важно.

Как я бы это ответил в interview

"Когда у меня disagreement с engineer:

1. Слушаю его аргумент полностью. Не assume я right.

2. Выясняю constraint: technology, timeline, risks.

3. Объясняю свой constraint: business pressure, customer need.

4. Ищем совместное решение: может быть есть option для обоих.

5. Если не найдём, escalate: не override unilaterally.

6. Respect final decision, даже если не то что я хотел.

В своем опыте, я disagreed с tech lead о Feature A vs рефакторинг. Вместо argue, я listened. Мы нашли parallelized approach (рефакторинг + feature вместе). Happy engineer, happy me, happy company.

Это best outcome."