Какие сроки озвучишь при получении 80 часов при Poker планировании?

Озвучивание сроков при Poker-оценке в 80 часов: реальный подход PM

Это очень практический вопрос. Когда разработчики оценивают задачу в 80 часов на Planning Poker, это требует от PM вовсе не дипломатичного "хорошо" и промежуточных вариантов, а стратегического анализа. Расскажу, как я это делаю.

Контекст: что означает 80 часов?

Типичная оценка на Poker:

• 5 точек Фибоначчи на Poker обычно = 80–120 часов eng work
• Это큰 задача, требующая реальной разработки
• Для одного разработчика это ~2 недели, для пары — ~1 неделя

Трёхшаговый процесс анализа

Шаг 1 — Почему так много?

Перед тем как озвучивать сроки, я спрашиваю разработку:

• Что именно требует столько времени?
• Это technical debt? Нужна переработка архитектуры?
• Или это просто много code to write?
• Есть ли unknowns, которые заложили буфер?

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

Пример распределения 80 часов:

- Architecture design & discussion: 16 часов (20%)
- Implementation: 40 часов (50%)
- Testing & bug fixes: 16 часов (20%)
- Integration & deployment: 8 часов (10%)

Видя это, я могу спросить: "Можем ли мы упростить дизайн? Можем ли мы сделать MVP без части фич?"

Шаг 2 — Критическая оценка: MVP vs Full version

Это ключевой момент. 80 часов часто означает "полная, production-ready версия". Но мне часто нужен MVP быстрее.

Вариант A — Полная фишка (80 часов):

• Все требования
• Хорошее покрытие тестами
• Полная интеграция
• Производительность оптимизирована
• Timeline: 2–3 недели

Вариант B — MVP (40–50 часов, 50% от оценки):

• Основная функциональность
• Базовые тесты
• Может быть медленнее, могут быть edge cases
• Достаточно для первых пользователей
• Timeline: 1–1.5 недели

Вариант C — Предварительный MVP (20–30 часов, 25% от оценки):

• Очень упрощённая версия
• Может быть просто для показа стейкхолдерам / доказания концепта
• Не production-ready
• Timeline: 3–5 дней

Я почти всегда выбираю Вариант B (50% оценки).

Как я озвучиваю сроки (без "да, 80 часов")

Вариант 1 — Для внутренней команды (обычно правда):

"В соответствии с Poker-оценкой, полная реализация потребует 80 часов. Это ~3 недели на одного разработчика. Но я предлагаю другой подход:

• Неделя 1: MVP версия (50 часов) — базовая функциональность готова
• Неделя 2: Полирование (30 часов) — баги, оптимизация, готово к релизу

Это позволит нам запустить фичу быстрее, собрать реальный пользовательский фидбэк и итерировать."

Вариант 2 — Для бизнеса / стейкхолдеров (более позитивно):

"Фишка будет готова через 2 недели в базовом виде, и через 3 недели полностью готова для масштабирования. Это позволит нам:

• Проверить market fit быстро
• Собрать пользовательский фидбэк
• Итерировать на основе реальных данных"

Вариант 3 — Для стратегического планирования (агрегированно):

"Эта инициатива займет 80 часов developer time. Если у нас есть 2 разработчика, это 2.5 дня параллельной работы. Если 1 разработчик, это 2 недели. Это входит в наш квартальный план следующим образом..." (показываю график)

Критическая ошибка: прямое озвучивание 80 часов

Если я просто скажу бизнесу "3 недели", я потеряю credibility по двум причинам:

1. Маркетинг / бизнес слышит только "три недели" и ждет полностью готовой фишки, а не MVP
2. Они не понимают, почему это так долго, и начинают давить: "А если быстрее?"

Мой реальный диалог с разработкой при 80 часах

Я: "Почему 80? Давайте разбираться."

Dev: "Нужно переделать database schema, миграции, change API, оновить фронтенд, покрыть тестами."

Я: "Хорошо. А если мы сделаем так: запустим MVP с текущей schema, без полной оптимизации, но работающее? Сколько часов?"

Dev: "Эм... может 45?"

Я: "Отлично. Тогда предлагаю: 45 часов на MVP (неделя), потом 35 часов на полирование (неделя). Это даёт нам 2 недели вместо 3, и мы раньше получим фидбэк."

Dev: "Да, это работает. Но нужно потом вернуться и отрефакторить..."

Я: "Понял. Запланируем 20 часов refactoring на следующий спринт. Договорились?"

Вот так я озвучиваю сроки: не как "80 часов = 3 недели готово", а как стратегический план с вехами.

Чеклист для озвучивания сроков при 80+ часах

• Понял ли я, почему ровно 80 часов? (спросил разработчика)
• Могу ли я предложить MVP (50% от оценки)?
• Есть ли в оценке technical debt, который можно отложить?
• Готов ли я разбить на спринты (weekly deliverables)?
• Объяснил ли я разницу между MVP и полной версией?
• Убедился ли я, что stakeholders понимают, что получат за X недель?
• Есть ли буфер для unknowns (обычно +20%)?
• Запланирована ли встреча с разработкой для детализации?

Итоговый ответ на вопрос

Если я получу 80 часов на Poker, я озвучу:

"Полная реализация требует 80 часов. Это 3 недели при 1 разработчике. Но я предлагаю:

1. MVP за 10–14 дней (базовая функциональность, готово к альфа)
2. Полная версия за 3 недели (production-ready, optimized)

Этот подход позволит нам выпустить в market быстрее, собрать фидбэк, итерировать. Альтернатива — ждать 3 недели и надеяться, что мы угадали все требования. Какой вариант предпочитаете?"

Вот так я озвучиваю. Не как "да, 80 часов = 3 недели готово", а как стратег, который понимает trade-offs и предлагает лучше для бизнеса.

Золотое правило: Никогда не озвучивай сроки как простую конвертацию часов в дни. Озвучивай как план с вехами, с объяснением trade-offs и альтернатив. Это покажет, что ты думаешь стратегически, а не просто переводишь числа.