Эстимейт для мобильных проектов — что это, методы оценки задач

Что такое эстимейт?

Эстимейт (от англ. estimate — оценка) — это прогнозирование количества времени или усилий, необходимых для выполнения задачи. В мобильной разработке эстимейты бывают в часах, днях, сторипоинтах или денежном выражении. Цель эстимейта — не точное предсказание, а снижение неопределённости для принятия решений.

Чем эстимейт отличается от обязательства

Эстимейт — это прогноз с погрешностью. Обязательство (commitment) — это обещание выполнить задачу к определённой дате. Разница критическая: эстимейт говорит «вероятно, 5 дней», обязательство — «сделаем за 5 дней». Менеджеры часто путают эти понятия, превращая эстимейт в дедлайн без права на ошибку.

Эстимейт как коммуникационный инструмент

Процесс эстимирования не менее важен, чем его результат. Когда команда обсуждает оценку задачи, выясняются скрытые требования, зависимости и риски. Даже если итоговая цифра неточная, обсуждение даёт понимание задачи всем участникам. Поэтому коллективные методы оценки (Planning Poker) эффективнее индивидуальных.

Методы эстимирования в разработке

Существует несколько методов эстимирования, каждый подходит для разных стадий проекта и уровней детализации. Выбор метода зависит от доступных данных и требуемой точности.

Planning Poker

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

T-Shirt sizing

T-Shirt sizing — грубая оценка по размеру футболки: XS, S, M, L, XL, XXL. Метод используется для быстрой оценки крупных задач (эпиков) на ранних стадиях, когда детали неизвестны. Позже каждая такая задача декомпозируется и оценивается в Planning Poker. T-Shirt sizing занимает 5-10 минут на задачу, но даёт только порядок величины.

Three-point estimation (PERT)

PERT использует три оценки: оптимистичную (O), пессимистичную (P) и наиболее вероятную (M). Итоговая оценка считается по формуле: (O + 4M + P) / 6. Метод учитывает неопределённость и даёт более реалистичный результат, чем единичная оценка. PERT особенно полезен для задач с высокими рисками или новыми технологиями.

Точность эстимейта: ожидания vs реальность

Точность эстимейта зависит от стадии проекта и количества известной информации. Чем раньше делается оценка, тем выше погрешность — это нормально и должно учитываться в планировании.

Cone of Uncertainty

Конус неопределённости (Cone of Uncertainty) — модель, описывающая, как снижается погрешность оценки по мере продвижения проекта. На этапе концепции погрешность составляет 400% (задача может занять от 1 до 4 месяцев). К моменту спринта — 20% (1-1.2 месяца). Осознание этой модели помогает не требовать точных оценок на ранних стадиях.

Факторы, влияющие на точность

• Сложность задачи — новая технология или знакомая? Неизвестное увеличивает погрешность в 2-3 раза.
• Размер задачи — мелкие задачи (до 2 дней) оцениваются точнее крупных. Декомпозиция улучшает точность.
• Опыт команды — команда, работавшая вместе 6+ месяцев, оценивает на 30-50% точнее новой.
• Исторические данные — наличие метрик velocity и циклометрии повышает точность прогнозов.

Relative vs Absolute estimation

Относительная оценка (в сторипоинтах) точнее абсолютной (в часах), потому что люди лучше сравнивают задачи, чем оценивают время. «Эта задача в два раза сложнее той» — более надёжное суждение, чем «эта задача займёт 8 часов». Относительные оценки не зависят от конкретного разработчика и сохраняют точность при смене исполнителя.

Как улучшить точность оценки: лучшие практики

Точность эстимейта можно повысить системным подходом, коллективным обсуждением и анализом прошлых ошибок. Есть несколько доказавших свою эффективность практик.

Декомпозиция до 1-2 дней

Любая задача, оценённая более чем в 2 дня, должна быть декомпозирована на подзадачи. Принцип: если задачу нельзя оценить точнее 50%, значит, она слишком крупная. Разбейте её на шаги, каждый из которых понятен и оцениваем. После декомпозиции суммарная оценка часто оказывается в 1.5-2 раза больше первоначальной.

Исторические данные и метрики

Ведите историю оценок и сравнивайте с фактическими затратами. Например: «задачи, оценённые в 3 сторипоинта, в среднем делаются за 4 дня, а не за 2». Используйте velocity команды для прогнозирования: если команда закрывает 20 сторипоинтов за спринт, не планируйте 30. Анализ точности прошлых оценок — лучший тренажёр для навыка эстимирования.

Якорение и калибровка

Якорение — психологический эффект, когда первая озвученная оценка влияет на всех участников. Чтобы избежать якорения, в Planning Poker все показывают карты одновременно, а не по очереди. Калибровка — регулярная сверка оценок с фактом: через 10-20 спринтов команда учится оценивать точнее за счёт обратной связи.

Учёт рисков в оценке

Каждая задача содержит скрытые риски: болезнь разработчика, проблема с API, изменение требований. Добавляйте в оценку risk-adjusted factor: для задач с высокими рисками — множитель 1.5-2, с низкими — 1.1-1.2. Прозрачно показывайте заказчику, какие риски учтены и как они влияют на сроки.

Типичные ошибки при эстимировании

Ошибки при эстимировании повторяются в большинстве команд, независимо от их зрелости. Знание этих ошибок — первый шаг к их исправлению.

Оптимистическая оценка

Самая распространённая ошибка — оценка по лучшему сценарию: «если всё пойдёт идеально, сделаем за 3 дня». В реальности ничто не идёт идеально: баги, вопросы по требованиям, зависимые задачи. Решение: оценивать по наиболее вероятному сценарию, а не по оптимистичному. Используйте PERT для учёта вариативности.

Оценка под давлением

Когда менеджер говорит «нужно до пятницы», разработчик подсознательно подгоняет оценку под этот дедлайн. Оценка под давлением всегда занижена и ведёт к срыву сроков. Решение: оценка должна предшествовать дедлайну, а не наоборот. Сначала команда оценивает, затем стороны договариваются о сроках.

Путаница между сложностью и временем

Сложность задачи (сколько думать) и время (сколько делать) — разные метрики. Задача может быть простой, но долгой (верстать 10 экранов). Или сложной, но быстрой (найти баг в легаси). В сторипоинтах обычно оценивается сложность, а время выводится из velocity команды.

Игнорирование контекстных переключений

Разработчик не работает 8 часов подряд над одной задачей: митинги, код-ревью, помощь коллегам, админка отнимают 30-50% рабочего времени. Контекстные переключения должны быть учтены в эстимейте: реально разработчик пишет код 3-4 часа в день.