Как оценивал сроки разработки на проекте?

Оценка сроков разработки на проекте

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

Ключевые принципы моего подхода

Разделение ответственности Я понимаю, что оценивают разработчики, а я помогаю структурировать и координировать. Никогда не диктую сроки сверху. Вместо этого:

1. Детализирую требования до уровня, когда разработчик может дать точную оценку
2. Даю на оценку не целый модуль, а отдельные задачи (stories)
3. Убеждаюсь, что команда понимает все зависимости и риски

Методология оценки

Story Points вместо часов/дней Использую относительную оценку через Story Points. Это работает лучше, потому что:

• Разработчики оценивают сложность, не давление
• Проще учесть неопределённость
• Можно рассчитать velocity команды и прогнозировать спринты

Процесс оценки на практике:

1. Planning Poker на refinement

   • Каждый разработчик оценивает независимо (1, 2, 3, 5, 8, 13 или 21 поинт)
   • Если оценки отличаются сильно (например, 3 и 13), обсуждаем различия
   • Автор требования объясняет, что было упущено
   • Переоцениваем

2. Базовая историе для калибровки

   • Выбираем простую задачу как «1 поинт» (например, исправление опечатки)
   • Все остальные задачи оцениваются относительно неё

3. Правило трёх

   • Если задача больше 13 поинтов, дробим её на меньшие
   • Большие задачи содержат слишком много неопределённости

Учёт рисков и буферов

Буфер при оценке (правило Hofstadter) Люди систематически недооценивают сложные задачи. Поэтому:

• Простые задачи (1-3 поинта) — берусь без буфера
• Средние (5-8 поинтов) — добавляю 20-30% буфера к итоговому сроку
• Сложные (13+ поинтов) — это признак, что надо дробить задачи

Анализ рисков перед оценкой Перед спринтом проходим:

• Есть ли неизученные технологии?
• Зависимости от внешних систем (API, третьи сервисы)?
• Блокеры: дизайн не готов, нет данных от бизнеса?
• Требуется ли code review с высокой планкой качества?

Если есть риски — увеличиваю буфер или переносю в следующий спринт.

Velocity и прогнозирование

Отслеживание velocity После каждого спринта смотрю, сколько поинтов команда реально сделала:

Спринт 1: 34 поинта (13 + 8 + 5 + 5 + 3)
Спринт 2: 39 поинтов
Спринт 3: 33 поинта (была отпуск)
Средний velocity: ~35 поинтов в спринт

Это позволяет предсказать: если у нас 200 поинтов на фичу, это примерно 6-7 спринтов.

Стабилизация velocity В начале проекта velocity нестабильна (новая команда, новые процессы). Обычно требуется 3-4 спринта, чтобы stabilize. Я планирую это, выставляя более консервативные сроки в начале.

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

Принцип честности

• Если видим, что 2 недели не хватит на всё — говорим 3 недели
• Лучше обещать меньше и сделать больше, чем обещать больше и не доделать
• Показываю данные velocity и историю, на которой основываю прогноз

Сценарное планирование (MVP vs Full)

• Приоритизирую фичи: must-have, should-have, nice-to-have
• Даю три сценария: оптимистичный, реалистичный, пессимистичный
• Бизнес выбирает, что входит в MVP, что в следующий релиз

Пример коммуникации: "У нас есть 40 поинтов требований. Velocity команды — 35 поинтов в спринт. Реалистичный сценарий — 5-6 недель. Если уберём nice-to-have (8 поинтов), то 4 недели. Риск: если появятся заблокеры от интеграций, это может добавить неделю."

Адаптация к реальности

Мониторинг прогресса Каждый день на standup:

• Что сделано вчера?
• Что планируем сегодня?
• Есть ли заблокеры?

Если видю, что не укладываемся, то не ускоряю разработчиков (это ломает quality), а:

1. Переговариваю с бизнесом о приоритетах
2. Уменьшаю scope, откладываю non-critical фичи
3. Добавляю ресурсы (если есть такой бюджет)

Постмортем после спринта На retro обсуждаем:

• Почему недооценили эту задачу?
• Что нового узнали о процессе?
• Как настроить оценки на следующий раз?

Инструменты и метрики

Использую:

• Jira для tracking story points и velocity graphs
• Excel для долгосрочного планирования и сценарного анализа
• Burndown charts для визуализации прогресса спринта
• Risk matrix для анализа неопределённостей

Результаты

Благодаря этому подходу:

• Мой 80% оценок укладываются в ± 10% от фактического времени
• Команда чувствует, что их оценки уважают
• Бизнес может планировать с уверенностью
• Снижается стресс и переработки благодаря реалистичным сроком