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

Что делать, если нужно сделать продукт быстрее, чем могут разработчики

Это классическая PM-дилемма: бизнес требует результат быстро, но техническая реальность другая. Моя философия: мы не ускоряем разработчиков, мы умнее выбираем что делать. Вот мой подход.

1. Сначала уточняю, действительно ли это deadline-driven

Вопросы, которые я задаю:

• Почему нам нужно это сделать именно к этой дате?
• Что случится, если мы задержимся на неделю? На месяц?
• Это мягкий deadline (nice-to-have) или жёсткий (деньги уходят, контракт теряется)?

Часто оказывается, что deadline искусственный или подвижный. Я разговаривал с бизнесом и выяснял: "Нам нужно это для квартального обновления, но это можно выпустить во второй неделе апреля вместо первой". Это даёт команде 1 неделю буфера.

2. Скоп-контроль: выбираю MVP

Это главное оружие PM в сжатых сроках. Я не режу качество, я режу функционал.

Метод Кано-анализа — классификация фич:

Пример: нужно выпустить payment feature за 2 недели.

Полный scope: платёж кредитной карте + PayPal + Apple Pay + стлилось + аналитика + email receipt + fraud detection

MVP на 2 недели: платёж кредитной карте + базовая аналитика + один email уведомление

Это 90% ценности для 40% времени.

3. Разговор с инженерами: что действительно feasible?

Я не говорю: "Надо сделать быстрее, давайте."

Я говорю: "Вот наш MVP scope. Сколько нам нужно времени на это? Какие corners мы можем cut?"

Инженеры дают мне честный timeline и варианты оптимизации:

• "Без unit тестов это быстрее" → я говорю "нет, нужны тесты хотя бы для критических path"
• "Можем использовать external library вместо наработок" → "да, берём"
• "Нужна рефакторизация перед этой фичей" → я оцениваю стоимость vs benefit
• "Это требует миграции БД" → я рассчитываю, на сколько это задержит релиз

4. Технические shortcuts (осознанно)

Иногда я соглашаюсь с техническими shortcuts, но всегда с планом их исправить.

Примеры shortcuts с планом:

1. Hardcoded данные вместо API

   • MVP: hardcode 10 default вариантов
   • После релиза: сделаем админ-панель
   • Risk: low (нужно просто обновить код)

2. Manual обработка вместо автоматизации

   • MVP: пользователь заполняет форму, мы вручную обрабатываем в админке
   • После релиза: автоматизируем
   • Risk: low (масштабируется до 1000 заявок)

3. Простая версия вместо оптимизированной

   • MVP: query без индексов, но данные < 100K записей
   • После релиза: добавим индексы
   • Risk: medium (только если уверены, что не будет 1M records)

4. Меньше браузеров в тестировании

   • MVP: полное тестирование на Chrome, базовое на Safari
   • После релиза: все браузеры
   • Risk: low (большинство users на Chrome)

Что я НИКОГДА не режу:

• Безопасность (auth, валидация, защита от инъекций)
• Стабильность (обработка ошибок, graceful fallbacks)
• Производительность на critical path (если это платёж, не может быть медленным)
• Data integrity (потеря данных — это смерть продукта)

5. Параллелизм: что можно делать одновременно?

Я анализирую dependencies и удаляю их:

• "Design и frontend могут работать параллельно" → даю дизайнеру примерную мокстру
• "Backend и frontend на разные endpoints" → договаривается о контрактах, работают параллельно
• "Testing может начаться раньше" → давайте staging version тестировщикам, пока frontend ещё пилится

Пример gantt (что я рисую командой):

День 1-2:  [Design] [Backend setup]
День 3-6:  [Design] [Frontend on mocks] [Backend impl]
День 7-8:              [Frontend интеграция] [QA]
День 9:                             [Deploy]

Вместо последовательного: Design → Frontend → Backend → QA → Deploy

6. Внешние ресурсы

Когда я их ищу:

• Нет budget на hiring → беру contractor на специфическую фичу (обычно рентабельно)
• Нужна специализированная работа → нанимаю freelancer (например, иллюстратор для assets)
• Есть готовый продукт который решает нашу проблему → покупаем license вместо разработки

Пример: нужно выпустить payment за 2 недели. Нанимаю contractor-бэкендера на неделю (+$3K), основной инженер фокусируется на frontend + integration. Экономим 1 неделю.

7. Управление рисками сжатого цикла

Я документирую trade-offs:

MVP Scope для Payment Feature

✅ Включено:
- Платёж кредиткой
- Базовая аналитика
- Email receipt

❌ Исключено (v1.1):
- PayPal интеграция
- Apple Pay
- Fraud detection
- Advanced analytics
- Refunds через UI

Risks & Mitigations:
- Risk: Нет PayPal → теряем 20% пользователей
  Mitigation: Запустим v1.1 на неделю 2 апреля
  
- Risk: Нет refunds → support перегружен
  Mitigation: Refunds делаю вручную в админке 1 неделю

- Risk: Баги в платёжной системе
  Mitigation: Полное smoke-тестирование, мониторинг 24/7 первую неделю

8. Коммуникация с бизнесом

Я не скрываю compromises, я их обсуждаю:

"Если хотим выпустить платёжную систему за 2 недели:

• Выпустим с поддержкой только кредиток, не PayPal
• Возвраты будут через админку первую неделю
• Это даст нам 90% функционала для 80% пользователей
• На следующей неделе добавим остальное

Альтернатива: ждём 4 недель и выпускаем 100% фич. Выбор за вами."

Обычно бизнес выбирает быстро, потому что понимает trade-offs.

9. После релиза: план погашения техдолга

Я создаю backlog для исправления shortcuts:

• Week 1 после релиза: критические баги + моніторинг
• Week 2-3: рефакторизация hardcoded части → админ-панель
• Week 4: автоматизация manual процессов
• Week 5-6: добавление вторичных фич (PayPal, Apple Pay)

Это не факультативно. Технический долг нужно погашать, или он сжирает скорость разработки.

10. Реальный пример из практики

Ситуация: надо выпустить invite system за 10 дней. Полный scope = 3 недели.

Мой подход:

1. Переговорил с бизнесом: "Какой минимум нужен?" → поняли, что нужны только email invites, не SMS
2. Переговорил с инженерами: "Без рефакторизации базы сколько?" → 1 неделя
3. Нашли shortcuts: hardcode email templates (позже настроится в админке)
4. Распараллелили: дизайнер рисует UI, backend работает на fixtures, frontend интегрируется после
5. Запустили за 9 дней
6. На неделе 2 добавили SMS invites (планировалось заранее)

Результат: 90% функционала в срок, без паники, без burnout команды.

Ключевые выводы

Мой основной принцип: мы не ускоряем разработчиков, мы умнее выбираем что делать.

Инструменты PM:

1. MVP scope — режу функции, не качество
2. Параллелизм — удаляю dependencies
3. Осознанные shortcuts — с планом исправления
4. Внешние ресурсы — контрактор на спайк-задачи
5. Коммуникация — бизнес знает trade-offs
6. Техдолг план — деньги на исправления заложены

Этот подход позволяет выпускать быстро, но не сломав команду и архитектуру.