Что будешь делать если разработчики говорят что нужно 4 года на реализацию фичи?

Ответ

Если инженер говорит что нужно 4 года — это не значит что нужно 4 года. Это означает что нужно лучше понять что они хотят сделать и помочь переосмыслить проблему. Мой подход это трёхэтапный процесс.

Этап 1: Понять почему 4 года (встреча с инженерами)

Я бы созвал встречу с Lead инженером и сказал:

Я услышал что нам нужно 4 года. Это много. Мне нужно понять почему. Давайте разберёмся что блокирует нас.

Ключевые вопросы:

• Это 4 года потому что архитектура не готова к этой фиче?
• Или это 4 года потому что много других приоритетов?
• Какие части самые сложные? Что из этого critical, а что можно отложить?

Часто 4 года разбивается на:

• 6 месяцев: переработка архитектуры (prerequisite)
• 1 год: разработка основной фичи
• 1 год: интеграция с остальными системами
• 1.5 года: оптимизация и поддержка

Пример из моего опыта:

На маркетплейсе инженеры говорили что нужно 2 года на полностью новую систему рейтингов. Когда я расспросил подробнее:

• 3 месяца: переделать БД schema
• 6 месяцев: новый алгоритм рейтинга
• 3 месяца: интеграция с фронтом
• 2 месяца: тестирование
• 4 месяца: миграция старых данных

Итого: около 18 месяцев, не 2 года. И это была пессимистичная оценка.

Этап 2: Переосмыслить проблему (с инженерами и дизайнером)

Когда я понял что блокирует разработку, я спрашиваю:

Есть ли более простой способ решить эту проблему?

Часто ответ нет потому что:

1. Инженеры думают о fully polished решении
2. Они не знают что PM готов принять MVP версию

Пример из финтеха:

Инженеры говорили 18 месяцев на систему personalised recommendations. Я спросил:

Что если мы не делаем personalised recommendations? Что если мы просто показываем рекомендации которые работают для 80% пользователей?

Ответ инженера: О... тогда это 2 недели. Но это не будет personalised.

Я ответил: Правильно. Сначала сделаем базовую версию за 2 недели. Потом если людям понравится, мы добавим personalization.

Этап 3: Разработать стратегию пошагово

Подход MVP + Iteration:

Вместо того чтобы ждать 4 года, я бы разделил проект на части:

Квартал 1: MVP (3 месяца)

• Самая простая версия фичи
• Решает 80% use case'ов
• Всё остальное откладываем
• Результат: можем показать пользователям

Квартал 2: Beta & Feedback (3 месяца)

• Даём MVP 1000 бета-пользователям
• Собираем feedback
• Улучшаем на основе feedback

Квартал 3: Soft Launch (3 месяца)

• Запускаем на 10% пользователей
• Мониторим баги и performance
• Масштабируем медленно

Квартал 4: Оптимизация (3 месяца)

• Добавляем фичи которые просили пользователи
• Улучшаем performance
• Полный запуск

Результат: вместо ожидания 4 лет, мы имеем работающую фичу через 12 месяцев.

Пример: Реальный случай из моего опыта

Ситуация:

На финтех платформе нужна была система синхронизации портфеля с другими брокерами (то есть юзер может подключить счёт с другого брокера и видеть всё в одном месте).

Инженеры оценили: 3 года. Нужно интегрироваться с 50+ брокерами, каждый имеет свой API, там разные стандарты данных.

Моё решение:

Встреча с инженерами. Я спросил:

Какие брокеры самые популярные? Сколько юзеров хочет интегрироваться с ними?

Результат:

• 80% запросов — это Top 5 брокеров
• 20% запросов — это остальные 45 брокеров

Я предложил:

Давайте сначала интегрируемся с Top 5. Это сколько времени?

Инженеры подумали: Может быть... 4-5 месяцев

Что мы сделали:

• Месяц 1: интеграция с 2 самыми популярными брокерами
• Месяц 2: интеграция с 3 остальными
• Месяц 3: тестирование, баги, оптимизация
• Месяц 4: soft launch (5% пользователей)
• Месяц 5: full launch

Результат:

• 95% users получили то что хотели в течение 5 месяцев
• Когда мы запустили, пользователи просили интеграцию с ещё 10 брокерами (не с остальными 40)
• Мы добавили их за следующие 3 месяца

Если бы мы ждали полной интеграции со всеми 50, мы бы потратили 3 года и скорее всего добавили бы фичи которые никому не нужны.

Мой переговорный подход

На встречу я бы сказал это:

Ребята, 4 года — это слишком долго. Рынок быстро меняется, и за 4 года наши конкуренты уйдут далеко.

Давайте подумаем иначе. Какая самая минимальная версия этой фичи решает 80% проблем пользователей? Сколько времени на это?

Если это 6 месяцев вместо 4 лет, давайте попробуем MVP. Если пользователи её полюбят, мы улучшаем дальше. Если нет, мы выучили что-то важное и не потратили 4 года.

Ключ: Я не говорю нет инженерам. Я говорю давайте разделим на части и начнём с самой важной части.

Если инженеры всё равно настаивают на 4 годах

Если после всех обсуждений инженеры говорят что даже MVP нужен 1-2 года, это говорит о более глубокой проблеме:

• Архитектура системы ломана
• Нужна переработка основ перед любой новой фичей

В этом случае я бы:

1. Обсудил с CTO что архитектура требует рефакторинга
2. Переоценил приоритеты: может быть вместо новой фичи, мы должны инвестировать в переработку архитектуры
3. Планировал на несколько кварталов вперёд:
   • Q1-Q2: рефакторинг архитектуры
   • Q3+: новые фичи

Ключевой урок

4 года почти никогда не означает что нужно 4 года. Это означает:

• Инженеры думают о полностью perfect решении
• Архитектура плохая и нужна переработка
• Нет ясности о том какая часть фичи действительно нужна

Моя работа как PM — помочь инженерам переосмыслить проблему и найти компромиссы, которые позволяют выпустить что-то за 6-12 месяцев вместо 4 лет.