Оценка трудоёмкости требований — это перевод «хотелок бизнеса» в измеримую работу команды, где можно получить прогноз сроков на 1–8 недель вперёд уже через 1–2 недели практики, но ключевой риск — оценивать “по ощущениям” и потом объяснять, почему релиз уехал в отпуск без вас.

Почему это вообще боль (и почему BA крайний)

Боитесь потратить месяцы на идеальные требования, а потом услышать от разработки: «Ну… это же на 2 спринта минимум»? Нормально. У бизнеса время — деньги, у разработки время — тоже деньги, просто в другой валюте: человеко-дни, story points, WIP и «у нас техдолг горит».

В моей практике провалы оценок почти всегда не из-за «плохих программистов», а из-за плохого перевода. Требование звучит как «сделайте как в Тинькофф», а внутри прячутся 15 экранов, 3 интеграции, миграция данных и один “маленький” edge case, который убивает весь happy path. И угадайте, кто потом выслушивает монолог про сроки.

Как BA оценивать трудоёмкость, не играя в шамана

1) Перевод в «единицы работы»: что именно вы просите сделать

Тезис: разработка оценивает не «идею», а набор конкретных изменений в системе. Чем точнее вы разложили хотелку, тем меньше магии в оценке.

Что делать: дробите требование до уровня, где каждый пункт можно реализовать и протестировать. Не «улучшить личный кабинет», а «показать баннер при условии X», «добавить поле Y в форме», «отправить событие Z в аналитику».

Практический вывод: если вы можете написать список задач так, чтобы QA понял, что проверять — вы уже близко к оценке.

Подводный камень: дробить по UI-экранам. Экран — это витрина. Реальная стоимость часто в данных, правах, интеграциях и миграциях.

• UI: новые/изменённые экраны, состояния, валидации.
• Backend: бизнес-логика, правила, расчёты, ограничения.
• Данные: таблицы/поля, миграции, качество данных.
• Интеграции: внешние API, очереди, события, ретраи.
• Нефункционалка: безопасность, производительность, аудит, логирование.

2) 5 факторов, которые «раздувают» оценку (и ими надо управлять)

Тезис: трудоёмкость растёт не линейно. Два «маленьких» требования могут быть дороже одного «большого», если одно из них лезет в опасные зоны.

Практический вывод: когда вы приносите на оценку не «описание фичи», а список рисков и вопросов — команда начинает говорить с вами на одном языке. И да, оценки становятся спокойнее.

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

3) Нормальный процесс оценки: Pre-estimate → Estimate → Commit

Тезис: разработка не обязана выдавать точность до часа по сырому требованию. Правильный процесс снижает стоимость ошибки.

1. Pre-estimate (черновая): на уровне идеи. Диапазон «маленькое/среднее/большое», чтобы отсечь фантазии.
2. Estimate (рабочая): после декомпозиции, определения интерфейсов и критериев готовности. Тут появляются story points/человеко-дни.
3. Commit (обязательство): только после уточнения зависимостей, доступности людей, WIP и готовности входных данных.

Практический вывод: BA должен уметь честно сказать бизнесу: «Сейчас есть только pre-estimate, точнее будет после spike/декомпозиции». Это не слабость, это управление риском.

Подводный камень: обещать сроки до того, как команда сказала “commit”. Потом будет классика: «Вы же обещали к пятнице».

4) «Definition of Ready» — ваш антидот против вечной переоценки

Тезис: если задача не готова — оценка превращается в гадание. DoR делает вход контролируемым.

• Есть цель и измеримый эффект (что меняется для пользователя/процесса).
• Есть границы: что входит/не входит в scope.
• Описаны сценарии: happy path + 3–5 ключевых ошибок/исключений.
• Ясны данные: источники, форматы, качество, миграции.
• Есть критерии приёмки, которые QA может превратить в тест-кейсы.
• Выявлены зависимости (команды, сервисы, контракты).

Практический вывод: DoR экономит не только время разработки, но и вашу репутацию — потому что “переоценили” на деле часто означает “оценивали не то”.

5) Как говорить с разработкой: фразы, которые работают

Тезис: тон разговора влияет на оценку почти так же сильно, как требования. Если вы спрашиваете «почему так долго», вы получите оборону. Если вы спрашиваете «где риск», вы получите сотрудничество.

Экспертный вердикт и инструмент: мини-методика BA для оценки трудоёмкости

Если вы хотите говорить с разработкой на одном языке, вам не нужен “талант оценщика”. Вам нужен ритуал, который повторяется из задачи в задачу и режет неопределённость до того, как она съест сроки.

Чек-лист: 7 вопросов перед оценкой

1. Какой результат должен увидеть пользователь/бизнес в конце?
2. Где граница scope: что точно не делаем в этой итерации?
3. Какие исключения критичны (ошибки, пустые данные, таймауты, повторы)?
4. Какие данные нужны и насколько они чистые?
5. Есть ли интеграции и кто владелец внешнего сервиса?
6. Какие нефункциональные требования обязательны (аудит, права, перформанс)?
7. Что является главным риском и нужен ли spike?

Мини-таблица «размер задачи» для предварительной калибровки

Частые вопросы