Что делаешь, если сроки на запуск фичи по оценке бизнеса и разработки расходятся?

Когда бизнес и разработка расходятся в сроках: как решить

Это одна из самых частых и сложных ситуаций для PM. Я расскажу как я это решаю.

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

Business говорит: "Нам нужно запустить интеграцию с Salesforce за 2 недели. Большой customer требует."

Tech lead говорит: "Это impossible. Минимум 5 недель. Нужно переделать архитектуру."

Это прямой конфликт. 2 vs. 5 недель. Что делать?

Шаг 1: Не угадываю, слушаю (день 1)

Встреча с business (CEO/Sales)

Я спрашиваю:

• "Почему 2 недели? Что случится если мы не успеем?"
• "Это hard deadline или можно договориться?"
• "Как важен этот customer? Какой revenue?"

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

• "Customer said 2 недели. Если не успеем они уйдут."
• "Это 5% от annual revenue. Важный но не critical."
• "Может быть договориться на 3 недели?"

Встреча с разработкой (Lead Engineer)

Я спрашиваю:

• "Почему 5 недель? Что составляет это время?"
• "Есть ли shortcut? Что если мы сделаем без переделки архитектуры?"
• "Что может вас ускорить? Больше resources? Простой MVP?"

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

• "2 недели на разработку. 2 недели на тесты. 1 неделя на integration. Это 5."
• "Если мы пожертвуем quality или features, может быть 3 недели."
• "Нужны 2 инженера вместо 1. А я не могу отвлечь второго."

Шаг 2: Ищу правду в середине (день 2)

Обычно solution это не полная уступка ни бизнесу ни разработке.

Вариант 1: Переговорить с customer

Я говорю sales: "Давайте позвоним customer и поговорим."

"У нас есть технический challenge. Вот что мы можем:

• MVP за 3 недели (основная функциональность)
• Full версия за 5 недель

Может ли вас устроить MVP версия для старта?"

Целый обычно согласится. Они хотят начать, не все features сразу.

Результат: 3 недели вместо 2 или 5.

Вариант 2: Reduce scope

Основные features Salesforce интеграции: sync contacts, sync deals, sync emails.

МВП может быть: только sync deals. На week 1-2 добавим остальное.

Это может сделать за 2 недели то что было бы 5 на full scope.

Вариант 3: Добавить resources

Если у компании есть budget - нанять контрактора, перенести task от другого инженера.

BUT: это не всегда работает. "Throwing bodies at problem" может сделать медленнее.

Вариант 4: Отложить другие приоритеты

Если это critical, может быть pause текущие проекты.

Техлид говорит: "Если я отвлекусь от Project X, то X задержится на 3 недели."

Business решает: это acceptable trade-off или нет?

Шаг 3: Мой процесс принятия решения

Вопрос 1: Насколько real deadline?

• Если customer абсолютно скажет "2 недели или мы уходим" → это real
• Если это "было бы nice иметь за 2 недели" → это soft deadline
• Soft deadline можно negotiate

Вопрос 2: Насколько реальна техническая оценка?

• Если инженер всегда accurate → trust their estimate
• Если часто overestimate → может быть можно faster
• Если underestimate → нужно учесть buffer

В моей praktici:

• Tech leads обычно accurate
• Juniors обычно underestimate
• Pessimistic engineers обычно overestimate на 20-30%

Вопрос 3: Какой risk?

• Если сделаем за 2 недели но будут bugs → это хуже чем delay
• Если сделаем за 5 недель и потеряем customer → это хуже чем bugs
• Есть ли middle ground?

Вопрос 4: Бизнес важность

• 5% revenue? → не worth quality sacrifice
• 30% revenue? → worth thinking hard
• 50%+ revenue? → do whatever needed

Шаг 4: Мой типичный ответ

Когда я презентирую решение всем:

"Вот ситуация:

• Customer требует 2 недели
• Техническая оценка 5 недель
• Это 3-недельный gap

Вариантов несколько:

Вариант A: MVP за 3 недели

• Sync deals (core feature)
• Без sync contacts и emails
• Customer может использовать и expand потом
• Risk: низкий
• Timeline: middle ground
• Recommendation: ДА

Вариант B: Full за 2 недели с low quality

• Быстро сделаем но будут bugs
• Потом fix bugs неделями
• Customer недовольный
• Risk: высокий
• Recommendation: НЕТ

Вариант C: Negotiate с customer

• Предложить MVP за 2 недели
• Или full за 5 недель
• Может быть они согласятся на 3 недели
• Risk: низкий
• Recommendation: ДА (попробовать)

Вариант D: Full за 5 недель

• Качественно
• Но customer может уйти
• Revenue loss: -5%
• Risk: medium
• Recommendation: только если customer не agreed

Мой выбор: Вариант A или C."

Что я НИКОГДА не делаю

Не обещаю что невозможно

Если инженер говорит 5 недель и я обещу 2 → это disaster.

• Команда demoralized
• Quality страдает
• Customer все равно недовольный
• Мы потеряли trust

Не давлю на инженеров

"Давайте просто try и see" это не management. Это setting people up for failure.

Вместо этого я спрашиваю: "Как мы может найти творческое решение?"

Не игнорирую бизнес concerns

Они real. Customer может действительно уйти.

Но решение это negotiate или reduce scope, не чудо.

Реальный story

В одном SaaS:

Big customer требовал Stripe integration за 2 недели.

Ingineer сказал: 4 недели.

Я:

1. Позвонил customer
2. "Мы любим вас. Stripe integration critical. Вот план:"
   • Week 1-2: Basic integration (charge customers)
   • Week 3-4: Advanced features (refunds, subscriptions)
3. Customer согласился
4. Инженер сделал за 2 недели то что было core
5. Week 3-4 добавили остальное

Все happy. Customer started платить, инженер не burnout, мы got full solution.

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

Когда сроки расходятся:

1. Слушай обе стороны - не предполагай кто right
2. Найди underlying truth - обычно проблема в assumptions
3. Reduce scope если нужно - MVP часто лучше full late
4. Negotiate если possible - customer часто гибче чем кажется
5. Communicate риск - если deadline unrealistic, скажи это
6. Есть backup plan - если 2 недели не работает, какой план B?

А самое главное: твоя работа это not choose sides.

Твоя работа это найти решение которое работает для бизнеса и team.

Лучшие PM это те кто находят третий вариант когда все видят только два.