Что делаешь, если заказчик обращается с неосуществимой идеей?

Ответ

Неосуществимая идея от заказчика — это не reject. Это opportunity для переговоров. Мой подход это понять почему они хотят это, а потом предложить achievable solution которая решает underlying problem.

Пример: Заказчик хочет всё перестроить за неделю

Сценарий:

Заказчик (CEO/PM) приходит и говорит: У нас есть идея. Нам нужно полностью переделать архитектуру приложения за одну неделю. Конкуренты растут быстро.

Моя первая реакция (внутренняя):

Это impossible. Если мы переделаем архитектуру в неделю, всё сломается. Но я не говорю нет. Я спрашиваю.

Шаг 1: Понять underlying problem

Вместо того чтобы сразу говорить нет, я спрашиваю:

• Помню что ты сказал что нам нужно быстро. Какая конкретная проблема тебя беспокоит? Что именно нам нужно улучшить?
• Почему неделя? Что случится если мы возьмём 2 недели? 3 недели?
• Какие части архитектуры самые critical? Может быть нам нужно только переделать parts, не всё?

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

CEO говорил: Нам нужна новая архитектура потому что платформа медленная.

Я спросил: Медленная в каких местах? Когда пользователь проверяет портфель? Когда делает заказ?

Ответ: Когда делает заказ. Это takes 5 секунд.

Я спросил: А сейчас это 5 секунд? Но это же acceptable для e-commerce. Конкуренты быстрее?

Ответ: Конкуренты делают это за 2 секунды.

Вывод: Проблема не в архитектуре нужна новая. Проблема в checkout too slow. Это другое.

Шаг 2: Переформулировать проблему

После того как понял что really нужно, я переформулирую:

Вместо: Переделать архитектуру за неделю

В: Улучшить speed checkout с 5 секунд на 2 секунды

Это разные проблемы! Первое impossible. Второе возможно.

Шаг 3: Предложить achievable solution

Я бы сказал:

OK, я слышу что checkout медленный. Давайте посмотрим как это fix. У нас есть 3 опции:

Опция 1: Quick optimization (неделя)

• Кэширование результатов
• Оптимизация queries
• Результат: checkout с 5 секунд на 3.5 секунд

Плюсы: быстро, не рискует Минусы: не достигаем целевой 2 секунды

Опция 2: Moderate refactoring (2-3 недели)

• Переделать parts of architecture (не всё, только checkout flow)
• Добавить async processing
• Результат: checkout с 5 секунд на 2 секунд (достигаем goal!)

Плюсы: достигаем goal Минусы: дольше, нужно testing

Опция 3: Full rewrite (месяцы)

• Полностью новая архитектура
• Новая database, новые services
• Результат: всё super fast

Плюсы: future-proof, super fast Минусы: очень долго, очень risky, много bugs в процессе

Я рекомендую Опция 2. Это balance между speed и quality.

Шаг 4: Get alignment on trade-offs

Заказчик часто хочет всё и сразу. Нужно явно говорить о trade-offs:

Я бы сказал:

Если мы хотим неделю (Опция 1), мы улучшим на 30% и это всё. Это acceptable для вас?

Если мы хотим улучшить на 60% (достичь goal из 2 секунд), нам нужно 2-3 недели.

Если мы хотим всё перестроить, это месяцы и риск очень высокий.

Что для тебя более важно: скорость или качество решения?

Пример из реальной жизни

Ситуация:

Founder финтех приложения говорил: Нам нужна система personalised recommendations за неделю. Наши конкуренты имеют это.

Мой анализ:

• Founder хочет competitive feature
• Но он think что recommendations это просто 1 фича
• На самом деле это complex: data pipeline, ML model, testing, etc.
• Неделю это impossible

Мой разговор с founder:

Я понимаю что конкуренты имеют recommendations. Это правда важно. Но давайте разберёмся что это значит.

Вариант 1: Простые recommendations (основано на popular items)

• Complexity: low
• Time: 2-3 дня
• Результат: не personalised, но что-то есть

Вариант 2: Personalised recommendations (основано на user behavior)

• Complexity: medium
• Time: 2-3 недели
• Результат: хороший, competitive

Вариант 3: ML-powered recommendations (machine learning model)

• Complexity: high
• Time: месяц+
• Результат: super good, но требует data и expertise

Я рекомендую: Вариант 1 в неделю, потом upgrade к Варианту 2 если будет positive feedback.

Результат:

Founder согласился. Мы сделали Вариант 1 за неделю. Люди использовали. Потом мы улучшили к Варианту 2.

Ошибки которые я делал в прошлом

Ошибка 1: Сразу говорить нет

Плохо: Это impossible Лучше: Давайте разберёмся что on the table

Ошибка 2: Не понимать underlying problem

Плохо: просто отклонить идею Лучше: спросить почему они хотят это, потом переформулировать

Ошибка 3: Не предлагать альтернативы

Плохо: Нельзя Лучше: Можно но вот варианты и trade-offs

Ошибка 4: Не быть confident

Плохо: звучать как может быть... Лучше: Вот что я рекомендую (с данными)

Best practices для saying no to impossible ideas

1. Listen first, judge later

• Не спешите отклонять
• Слушайте полностью

2. Ask questions, not statements

• Вместо: Это невозможно
• Спросите: Как ты думаешь это будет work? Что может пойти неправильно?

3. Show trade-offs

• Люди хотят одного но не думают о consequences
• Покажи: Если мы делаем X за Y time, значит мы жертвуем Z

4. Propose alternatives

• Не просто скажи что нельзя
• Предложи что можно

5. Use data

• Вот историческая data из похожих проектов
• Это заняло нам X месяцев в прошлом, и это была simpler

6. Get alignment

• Убедись что заказчик понимает trade-offs
• OK, ты выбираешь speed over quality, правильно?

Заключение

Неосуществимая идея — это не конец разговора. Это начало. Моя работа как PM это:

1. Понять что на самом деле нужно (может быть underlying problem другой)
2. Переформулировать в achievable terms
3. Предложить варианты с trade-offs
4. Согласовать на чём мы стоим

Это требует diplomaticity и communication skills. Но результат это что заказчик happy, team happy, и мы deliver хорошее решение.