AI для оценки сложности и трудозатрат: от требований к стори-поинтам через LLM

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

Идея звучит провокационно, но это не замена планинг-покеру. Это черновик оценки, который аналитик получает за минуту вместо часа. Дальше — верификация и калибровка. Давайте разберём, как это работает на практике.

Что LLM может и не может в оценке

Языковая модель не написала ни строчки продакшен-кода. У неё нет контекста вашей кодовой базы, она не знает, что UserService — это 4000 строк спагетти, а PaymentGateway трогать страшно даже тимлиду. Но модель отлично справляется с тем, что составляет 70% оценки на раннем этапе: анализ формулировки требования.

Что LLM делает хорошо:

• Находит неявные сложности в тексте: «интегрироваться с внешним API» — это не одна задача, а цепочка из аутентификации, обработки ошибок, ретраев и мониторинга
• Выделяет зависимости: помнит, что «добавить фильтрацию в отчёт» требует изменения и на фронте, и на бэке
• Работает с типовыми паттернами: CRUD, форма с валидацией, экспорт в Excel — для них оценка предсказуема
• Не устаёт на двадцатой User Story и не завышает оценку из страха

Что LLM делает плохо:

• Не знает технический долг вашего проекта
• Не учитывает человеческий фактор: Вася делает эту фичу за день, Петя — за три
• Слепа к скрытым архитектурным решениям, которые не описаны в требовании, но известны команде

Вывод: LLM — не оракул. Это первичный фильтр, который отсеивает очевидное и подсвечивает спорное. Спорное всё равно пойдёт на planning poker, но очевидное — нет.

Как LLM оценивает трудозатраты: конвейер оценки

Процесс оценки через LLM — это не «кинул User Story, получил цифру». Это четырёхэтапный конвейер:

graph TB
  US["User Story<br/>входные данные"]
  CTX["Контекст<br/>история спринтов<br/>командная velocity<br/>исторические оценки"]
  LLM["LLM-анализ<br/>декомпозиция и<br/>оценка сложности"]
  FACTORS["Анализ факторов<br/>неопределённость<br/>зависимости<br/>техническая сложность<br/>объём работ"]
  SP["Стори-поинты<br/>+ обоснование"]
  COMPARE["Сравнение с<br/>экспертной оценкой"]
  CALIBRATE["Калибровка<br/>модели"]
  DONE["Оценка принята"]

  US --> LLM
  CTX --> LLM
  LLM --> FACTORS
  FACTORS --> SP
  SP --> COMPARE
  COMPARE -->|"расхождение > 30%"| CALIBRATE
  CALIBRATE -.-> LLM
  COMPARE -->|"в пределах допуска"| DONE

  style US fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style CTX fill:#7b68ee,stroke:#5a4db2,color:#fff
  style LLM fill:#f0a500,stroke:#c88400,color:#fff
  style FACTORS fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style SP fill:#50c878,stroke:#3a9a5c,color:#fff
  style COMPARE fill:#7b68ee,stroke:#5a4db2,color:#fff
  style CALIBRATE fill:#f0a500,stroke:#c88400,color:#fff
  style DONE fill:#50c878,stroke:#3a9a5c,color:#fff

Левая часть схемы — входные данные. User Story (синий) — формулировка задачи. Контекст (фиолетовый) — история предыдущих спринтов, velocity команды и референсные оценки похожих задач. Без контекста модель оценивает «в вакууме» и ошибается сильнее.

Центральный блок — LLM-анализ (жёлтый). Модель декомпозирует User Story на подзадачи, а затем прогоняет каждую через четыре фактора (синий): неопределённость формулировки, явные и неявные зависимости, техническая сложность, объём работ. На выходе — стори-поинты с обоснованием (зелёный).

Правая часть — верификация. Оценка LLM сравнивается с экспертной. Если расхождение больше 30% — запускается калибровка промпта (жёлтый, пунктирная обратная связь). Если в пределах допуска — оценка принята.

Примечательно, что петля калибровки — это не разовая акция. Первые 3–5 спринтов вы будете регулярно уходить в неё, пока модель не «поймёт» стиль вашей команды.

Факторы, которые анализирует LLM

Хороший промпт просит модель оценить не «задачу вообще», а разложить её по четырём осям. Это даёт не только цифру, но и обоснование — чтобы аналитик не принимал оценку слепо:

Каждый фактор оценивается по шкале 1–5, а итоговые стори-поинты — это не среднее арифметическое, а взвешенная сумма с повышающим коэффициентом за неопределённость (потому что «непонятно что делать» — это всегда дороже, чем «много работы, но понятно какой»).

Практические промпты

Промпт для оценки одной User Story

1
Ты — системный аналитик. Оцени трудоёмкость User Story в стори-поинтах
2
по шкале Фибоначчи (1, 2, 3, 5, 8, 13, 21).
3

4
Контекст команды:
5
- Velocity: 25 стори-поинтов за спринт (2 недели)
6
- 1 SP ≈ простая задача: поправить текст на форме
7
- 5 SP ≈ средняя задача: новый CRUD-эндпоинт с валидацией
8
- 13 SP ≈ крупная задача: интеграция с внешним платёжным шлюзом
9

10
User Story:
11
"Как администратор, я хочу экспортировать список заказов за выбранный
12
период в Excel, чтобы передавать данные в бухгалтерию."
13

14
Для оценки проанализируй:
15
1. Неопределённость (1–5): насколько чётко сформулировано требование?
16
2. Зависимости (1–5): сколько компонентов затронуто?
17
3. Техническая сложность (1–5): CRUD или сложная логика?
18
4. Объём работ (1–5): сколько кода и конфигурации?
19

20
Выдай: стори-поинты + обоснование по каждому фактору.

Результат, который вы получите — не просто «5 SP». Это «5 SP, потому что неопределённость 2 (формат экспорта не уточнён, но Excel — типовой), зависимости 3 (бэк + фронт + очередь на случай больших файлов), техническая сложность 2 (библиотека для Excel), объём 3».

Промпт для пакетной оценки бэклога

Когда у вас 20+ User Story, гонять каждую по отдельности — долго. Вот промпт для пакетной оценки:

1
Оцени каждую User Story из списка ниже в стори-поинтах по шкале Фибоначчи.
2
Для каждой задачи дай: SP + краткое обоснование (одно предложение).
3

4
Контекст команды: velocity 25 SP за спринт.
5

6
User Stories:
7
1. [US-001] Как пользователь, я хочу сбросить пароль через email...
8
2. [US-002] Как администратор, я хочу видеть дашборд с метриками...
9
...
10

11
Формат ответа — markdown-таблица:
12
| ID | SP | Обоснование |

Важный нюанс: не просите модель оценивать 50 задач за один промпт. Качество деградирует после 10–15 позиций — модель начинает «забывать» контекст первых задач и оценка становится случайной. Разбивайте бэклог на пачки по 10–12 штук.

Сравнение: LLM vs экспертная оценка

Ниже — результаты реального эксперимента на 15 User Story среднего проекта. Оценку давали: (а) LLM без контекста, (б) LLM с историей спринтов, (в) команда на planning poker:

Тенденция: без контекста LLM усредняет оценки — завышает простые задачи и занижает сложные. С контекстом (история спринтов, velocity, референсные оценки) точность резко растёт. Примечательно, что на типовых задачах вроде CRUD и простых форм LLM с контекстом попадает в точку почти всегда.

Дашборд метрик (US-04) — показательный промах. Требование звучало как «показать 4 графика», модель оценила в 8 SP. Но команда знала, что данные лежат в трёх разных БД и их нужно агрегировать в реальном времени — вышло 13 SP. Это как раз та скрытая сложность, которую LLM не видит.

Калибровка модели под команду

LLM не «волшебная палочка» — она настраиваемый инструмент. Первые оценки будут мимо, и это нормально. Калибровка — итеративный процесс. Вот что реально работает:

1. Референсная таблица в промпте. Включите в системный промпт 3–5 примеров: «User Story X — мы оценили в 2 SP, потому что…». Это якоря, от которых модель отталкивается. Без якорей LLM опирается на свои представления о сложности, а они редко совпадают с вашими.

2. Постмортем расхождений. После каждого спринта берите 2–3 задачи, где оценка LLM разошлась с командной, и анализируйте причину. Типичные паттерны:

• LLM завысила → формулировка User Story была размытой, модель перестраховалась
• LLM занизила → скрытая сложность, не описанная в требовании, но известная команде
• LLM попала → задача типовая, без сюрпризов

3. Уточнение критериев неопределённости. Научите модель распознавать «размытые» формулировки, которые именно ваша команда считает рискованными. Например, слово «интеграция» — для одной команды это всегда +3 SP к любой оценке. Пропишите это в промпте явно.

4. Метрика качества. Заведите простой трекинг: «процент задач, где оценка LLM попала в диапазон ±1 SP от командной». Через 3–4 спринта калибровки этот показатель выходит на 60–70%. Это не 100%, но для первичной оценки — отличный результат.

Важно: расчёт не на то, чтобы модель заменила planning poker. Расчёт на то, чтобы на planning poker приходили задачи, которые действительно нужно обсуждать — а не 20 очевидных CRUD-ов.

Где это оправдано, а где нет

AI-оценка — не универсальный инструмент. Вот матрица применимости:

Хорошая эвристика: если User Story прозрачна настолько, что джуниор понимает, что делать — LLM оценит точно. Если сеньор говорит «надо подумать» — LLM не поможет. Идите на planning poker.

А как же человеческий фактор?

Можно автоматизировать анализ требований, но нельзя автоматизировать командную динамику. На planning poker люди не только цифры называют — они проговаривают риски, синхронизируют понимание задачи, выявляют скрытые конфликты. LLM этого не делает.

Более того, есть риск «эффекта якоря»: когда команда видит оценку LLM до обсуждения, она бессознательно подстраивается под неё (даже если оценка неверна). Чтобы этого избежать — давайте оценку LLM после planning poker, как второй источник для сверки. А не до.

Так вы получаете лучшее из двух миров: команда обсуждает задачу без внешнего давления, а потом сверяется с LLM — вдруг модель увидела зависимость, которую люди пропустили? На практике такое случается в 15–20% случаев. Что немаловажно — именно эти 15–20% экономят дорогие сюрпризы в середине спринта.

Заключение

AI для оценки трудозатрат — не про «заменить планинг-покер роботом». Это про то, чтобы сместить фокус аналитика с механики оценки на содержание. Пусть LLM считает типовые CRUD’ы — а вы держите в голове общую картину продукта, архитектурные риски и человеческий фактор. То, в чём модель всё ещё слаба.

Начать можно уже завтра: возьмите три User Story из бэклога, дайте их LLM с контекстом команды и сравните с собственной оценкой. Если расхождение систематическое — калибруйте промпт. Если случайное — модель уже работает на уровне шума, и это повод задуматься о качестве самих требований. Возможно, дело не в AI, а в том, что User Story размыты настолько, что даже человек не может оценить — и это отдельная тема для разговора. Про то, как писать User Story так, чтобы их можно было оценивать (не только LLM, но и команде), — в посте про User Story и Use Case.

P.S. Если после прочтения вы подумали «ага, сейчас скормлю бэклог ChatGPT и пойду пить кофе» — перечитайте раздел про человеческий фактор. Модель оценивает текст. Оценивает ли она реальность — решать вам.