Как будешь оценивать сроки?

Оценка Сроков в Product Management

Оценка сроков — один из самых критических и одновременно сложных навыков PM. Неправильная оценка приводит к срывам deadline, потере доверия и стрессу в команде.

Почему оценка сроков сложна

От PM часто требуют:

• "Когда выпустим эту фичу?" (и ответ нужен сейчас)
• Обещать сроки инвесторам и клиентам
• Планировать roadmap на квартал/год

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

• Сложность задач часто неясна до начала работы
• Появляются неожиданные блокеры
• Другие приоритеты могут сдвинуть сроки
• Качество vs скорость — всегда компромисс

Методы оценки сроков

Метод 1: Три-точечная оценка (Three-Point Estimation)

Вместо одной цифры даешь три:

Оптимистичный сценарий (Best case)

• Всё идет как по маслу
• Нет неожиданных блокеров
• Пример: 2 дня

Вероятный сценарий (Most likely)

• Реалистичный случай
• Учитываем типичные проблемы
• Пример: 4 дня

Пессимистичный сценарий (Worst case)

• Всё может пойти не так
• Неожиданные проблемы с интеграцией
• Пример: 8 дней

Формула PERT (Program Evaluation and Review Technique): Expected Time = (Optimistic + 4 × Most Likely + Pessimistic) / 6

Пример: (2 + 4×4 + 8) / 6 = 4.33 дня

Преимущества:

• Более реалистична, чем одна оценка
• Видна разброс сценариев
• Даёт буфер для непредвиденного

Метод 2: Story Points (Agile подход)

Мы не оцениваем в часах/днях, а в относительной сложности:

Шкала: 1, 2, 3, 5, 8, 13, 21

1 point: "Это тривиально, может сделать стажер"

• Изменить текст на кнопке
• Добавить новый color в Figma

3 points: "Типичная задача, может быть несколько ньюансов"

• Создать новый UI компонент
• Добавить поле в форму

8 points: "Сложная задача, много переменных"

• Интегрировать новый payment gateway
• Переделать архитектуру кэширования

13+ points: "Очень сложная, нужно разбить на подзадачи"

• Полная переделка системы
• Если оценка 13+, это значит, что задача слишком большая

Связь с днями:

• Обычно в среднем: 1 point = 1-2 часа, 3 points = 1-2 дня, 5 points = 2-3 дня, 8 points = 3-5 дней
• Но это варьируется от команды к команде

Преимущества:

• Не создаёт ложную точность (6 дней звучит точно, но это фейк)
• Фокусируется на сложности, не на личных скоростях
• Легче делать Planning Poker (команда голосует)

Метод 3: Исторические данные (Velocity)

Мы смотрим, сколько points команда сделала в прошлые спринты:

Пример:

• Спринт 1: 45 points
• Спринт 2: 48 points
• Спринт 3: 42 points
• Средняя velocity: 45 points в спринт

Планирование на квартал:

• Если в квартале 13 спринтов × 45 points = ~585 points
• Если backlog содержит 650 points, то квартала не хватит

Преимущества:

• Основано на реальных данных, не на гадании
• Видны тренды (velocity растет или падает)
• Командная метрика, не индивидуальная

Недостатки:

• Требует истории (как минимум 3-4 спринта)
• Velocity может меняться (новые люди, другие задачи)

Метод 4: Bottom-Up оценка

Делим большую фичу на маленькие задачи и оцениваем каждую:

Пример: Feature "Интеграция с Stripe"

1. Подготовка Stripe account — 1 point
2. API интеграция базовая — 5 points
3. Обработка платежей — 3 points
4. Обработка ошибок и refunds — 5 points
5. E2E тесты — 3 points
6. Documentation — 2 points

Итого: 19 points (~4-5 дней)

Преимущества:

• Детальная оценка
• Видны все компоненты работы
• Легче переделегировать подзадачи

Недостатки:

• Требует много времени на разбор
• Может быть детализирована (analysis paralysis)

Что делать когда оценки неправильны

Ситуация 1: Оценка была слишком оптимистична

Нельзя:

• Рубить углы и снижать качество
• Пилить ночами (бурнаут)
• Скрывать проблему

Нужно:

1. Как можно раньше сказать PM

   • "Мы открыли, что задача сложнее, чем думали"
   • Не в день дедлайна, а через день-два

2. Переоценить realistically

   • "Вместо 5 дней нам нужно 8"
   • С обоснованием

3. Предложить варианты:

   • Extend deadline на 3 дня
   • Убрать некоторые фичи (MVP вместо full)
   • Добавить людей (если это поможет)

Ситуация 2: Работа завершилась быстрее, чем ожидалось

Плюсы:

• Команда выглядит быстрой
• Можно взять дополнительные задачи

Но будьте осторожны:

• Может быть недостаточное тестирование -技техдолг может остаться
• Следующие спринты станут медленнее

Что делать:

1. Проверить качество дважды
2. Провести полное тестирование
3. Закрыть техдолг из оставшегося времени
4. Обновить оценки на будущее (может быть, мы недооценивали)

Рекомендации по оценке

1. Добавьте буфер

Никогда не обещайте точное количество дней. Добавьте буфер:

• Оценка: 5 days
• Обещание: 7 дней (40% буфер для незапланированного)
• Инвестор услышит 7, но если финишим за 5-6, это хорошие новости

2. Разделяйте работу на спринты

Не обещайте сделать всё в один sprint. Лучше:

• Sprint 1: MVP версия (2 недели)
• Sprint 2: Доп фичи и оптимизация (2 недели)
• Sprint 3: Polish и баги (1 неделя)

Тогда каждый спринт более реалистичный.

3. Регулярно калибруйте

Каждый квартал смотрите на accuracy оценок:

• Насколько часто мы выходили за сроки?
• На сколько дней в среднем?
• Почему?

Это информация для улучшения следующих оценок.

4. Учитывайте контекст

Одна и та же задача может быть разной сложности в разном контексте:

• Новая кодовая база = сложнее
• Новая технология = сложнее
• Плохо задокументированный код = сложнее
• Выходной сезон (праздники) = сложнее

5. Kommunizируй прозрачно

Если оценка неопределённа, скажите это:

Плохо: "Это будет готово за 3 дня" Хорошо: "Это может быть готово за 2-5 дней. Самый вероятный сценарий — 3-4 дня. Первые 2 дня критичны для понимания arquitectury."

Мой Personal подход

1. Спрашиваю инженеров, не ставлю оценки сам

   • Инженеры знают свой код лучше всех

2. Использую story points + исторические данные

   • Story points для вычисления, velocity для планирования

3. Всегда добавляю буфер

   • 20-30% для неожиданного
   • Обещаю консервативнее, чем реальная оценка

4. Регулярно обновляю backlog приоритизацию

   • Если обнаружили, что задача 13 points, разбиваем на две

5. Бесимся с длинными задачами

   • Если что-то больше 13 points, это красный флаг
   • Нужно разбить или переделать подход

Вывод

Правильная оценка сроков:

• Базируется на методе (three-point, story points, velocity)
• Основана на реальных данных, не на гадании
• Включает буфер для неожиданного
• Обновляется когда появляется новая информация
• Коммуницируется прозрачно стейкхолдерам

Золотое правило: лучше обещать консервативнее и выполнить быстрее, чем обещать амбициозно и срывать deadline. Доверие важнее скорости.