Как оценить задачу которую ты никогда не делал?

Как оценить неизвестную задачу

Это очень частая ситуация в разработке. За 10+ лет я выработал системный подход к оценке задач, которые на первый взгляд кажутся неопределёнными.

Шаг 1: Разобрать задачу на компоненты

Никогда не оценивай задачу целиком, если она большая. Разбей её на мелкие, понятные части:

Задача: "Реализовать автентификацию через Google"

Компоненты:
1. Интеграция Google Sign-In SDK
2. Обработка Google токена на клиенте
3. API endpoint для верификации токена
4. Сохранение пользователя в БД
5. Тестирование всего процесса
6. Документирование

Шаг 2: Задать уточняющие вопросы

Не гуляй в тумане — задай конкретные вопросы:

• Требования: Какой минимальный scope? Какой максимальный?
• Зависимости: Какие еще компоненты уже готовы?
• Подобные задачи: Были ли в проекте похожие фичи? Какая была оценка?
• Риски: Какие известные подводные камни?
• Дизайн: Есть ли макеты в Figma? Готов ли backend?

Шаг 3: Используй метод "Planning Poker"

Если ты работаешь в команде:

1. Каждый разработчик индивидуально оценивает (1, 2, 3, 5, 8, 13, 21...)
2. Если оценки совпадают — берём эту оценку
3. Если расходятся — обсуждаем 5-минутный диалог
4. Переоцениваем

Этот метод отлично работает именно для неизвестных задач!

Шаг 4: Аналогия с известными задачами

Найди в истории проекта похожую задачу и используй её как baseline:

Новая задача: "Интеграция с API платежей Stripe"

Похожая прошлая задача: "Интеграция с API доставки DPD" = 8 points

Рассуждение:
- DPD тоже требовал обработку ошибок → +0
- Но Stripe имеет более сложную аутентификацию → +3
- Stripe имеет больше SDK поддержки → -2
→ Итого: 8 + 3 - 2 = 9 points (округлим до 8 или 13)

Шаг 5: Добавь буфер на неизвестность

Если ты не знаешь что-то наверняка, добавь 50% к оценке:

База оценка: 5 points
Неизвестность высокая → 5 * 1.5 = 7.5 → округляем до 8 points

Шаг 6: Оцени скрытые задачи

Частые части, которые часто забывают:

• Code Review → +1 point
• Тестирование → +1-2 points
• Документирование → +0.5 point
• Исправление feedback'ов → +1 point

// Пример полной оценки
// Feature: "Реализовать экран профиля пользователя"

// Базовая функциональность: 5 points
// + Tests (unit + widget): 2 points
// + Edge cases (null safety, offline): 1 point
// + Code review + fixes: 1 point
// + Документирование: 1 point
// = 10 points total

Шаг 7: Пересчитай в рабочие часы (если нужно)

В компаниях часто просят оценку в часах, а не points. Используй Fibonacci velocity:

Велосити команды = 40 points / 2 недели = 20 points/неделя
Средний разработчик выполняет 4 points/день (при 8-часовом дне)

Задача оценена в 8 points → 8/4 = 2 дня → 16 часов

Практический пример: неизвестная задача

Задача: "Добавить поддержку dark mode в приложение"

Мой анализ:

1. Разбить на части:

   • Реализовать переключение темы (BLoC/Provider) → 3 points
   • Переделать все цвета на использование темы → 5 points
   • Тесты для всех экранов → 3 points
   • Исправление feedback'ов → 2 points

2. Вопросы: Нужна ли автосмена по системе? (да, добавляет 2 points)

3. Итого: 3 + 5 + 3 + 2 + 2 = 15 points

Что НЕ нужно делать

• ❌ Гадать без информации — лучше сказать "не знаю"
• ❌ Завышать оценку из страха — это портит планирование
• ❌ Завышать оценку чтобы "выглядеть продуктивнее" — контрпродуктивно
• ❌ Забывать про тесты, documentation и code review
• ❌ Забывать про communication overhead

Совет от опыта

Лучше сказать на планировании: "Я не уверен, даю оценку 13 points с риском" — чем потом убегать по задаче неделю. Хороший PO оценит честность и поможет уточнить требования. Оценка задач — это наука, а не магия.