Одна фраза тимлида в промпте срезала оценку задач на пятую часть

Всем привет, меня зовут Сергей Прощаев, я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce и преподаю на курсах разработки и архитектуры в ОТУС.

В этой статье расскажу про небольшой эксперимент: я попросил две нейросети независимо оценить исторические задачи из открытого датасета Jira в формате, похожем на покер‑планирование, и проверил, что происходит с их оценкой, если в промпт попадает одна невинная фраза про ожидания тимлида.

Знакомая картина: перед планированием кто‑то вставляет бэклог в чат и просит «прикинуть story points». Модель отвечает за десять секунд, ровной колонкой цифр по Фибоначчи, без тени сомнения. А в промпте, между делом, стоит: «тимлид думает, что тут где‑то на 32 пункта».

Спойлер: эта фраза сдвинула сумму оценок примерно на пятую часть у обеих моделей. У ChatGPT сумма при этом стала даже ближе к оценке команды, и именно это меня насторожило больше всего.

Почему это стало вопросом именно сейчас

Нейросети уже сидят на планировании, даже если их туда никто официально не звал. В опросе практиков, опубликованном онлайн 7 октября 2026 года в Journal of Systems and Software, 48,1% из 79 респондентов, использующих LLM‑ассистентов ^[1] в Scrum, по их словам делают это ежедневно или почти ежедневно, а главное применение называют уточнением бэклога. Среди проблем на первом месте «почти правильные ответы» (65,8%).

Исследования точности при этом расходятся.

По препринту Рочестерского технологического института (март 2026), в их экспериментах модели без обучения ^[2] предсказывали story points лучше глубоких моделей, обученных на 80% данных проекта.

Сравнительное исследование в IEEE Access (март 2026) показало, что без обучения LLM уступают специализированным моделям, зато их объяснения влияют на человека: в небольшом опыте ^[3] с 30 студентами оценку меняли более чем в 85% случаев, хотя точнее она от этого не становилась.

Меня интересовала не точность, а другое.

Ещё в 2010 году Магне Йоргенсен и Торлейф Халкьелсвик показали, что разработчики дают оценку ниже, если спросить их не «сколько это займёт», а «сколько успеем за неделю»: названный срок становится якорем, и от него почти не отходят. В 2025 году этот опыт повторили на GPT-4, Gemini 1.5 Pro и Llama 3.1.

Авторы пишут, что модели ведут себя сходно с эффектом якоря: у GPT-4 медиана оценки росла с 150 до 220 и 360 рабочих часов при якоре в 30, 60 и 120 часов. Мне стало интересно, как это выглядит на обычных story points.

Эксперимент

Задачи взяты из открытого датасета Choetkiertikul и коллег: 23 313 задач Jira из 16 open‑source проектов с оценками, которые ставили сами команды.

Я выбрал проект Spring XD как самый близкий Java‑аудитории и отобрал 12 задач с фиксированным seed:

• по две задачи на каждую оценку: 1, 2, 3, 5, 8 и 13;

• только задачи с описанием от 80 до 700 символов.

Сумма оценок команды по этим задачам 64 SP.

Промптов два, они отличаются одним предложением:

(text, промпт A, фрагмент: полный текст в репозитории)
Ты участвуешь в покер-планировании команды, которая разрабатывает Spring XD
(платформа на Java для потоковой и пакетной обработки данных). Оцени каждую
задачу из бэклога в story points по шкале 1, 2, 3, 5, 8, 13, 21.

Ответ: ровно 12 строк вида «номер: оценка», без пояснений.

1. Upgrade asciidoctor toolchain. This will in turn allow us to ...
...
12. Upgrade groovy version to 2.2.2. Currently, XD hast ...

В промпте B после шкалы добавлена фраза:

Тимлид заранее прикинул, что весь набор потянет примерно на 32 story points.

Это ровно половина суммы командных оценок, то есть якорь заметно ниже.

Модели:

• ChatGPT на бесплатном тарифе (интерфейс не показывает название модели).

• Claude Opus 5.5 в claude.ai ^[4] с уровнем усилий High.

Каждый промпт запускался по три раза, каждый раз в новом чате без памяти ^[5] аккаунта: у ChatGPT — временный чат, у Claude — режим инкогнито.

Всего — 12 прогонов, 20 октября 2026 года. Ключи задач в промпт не попадали, только заголовок и описание.

Как устроен эксперимент, показано на схеме:

Главная мысль схемы: модели и команда оценивают одно и то же, а промпты различаются ровно одним предложением, поэтому сдвиг между A и B я связываю именно с этой фразой.

Наблюдение 1. Якорь сдвигает оценку, но не до конца

Суммы по прогонам:

Команда оценила эти задачи в 64 SP, якорь был 32. Ни одна модель до 32 не дошла: самый низкий прогон дал 44.

Это ровно та картина, которую Йоргенсен описывал у людей: от якоря отходят, но недостаточно. Диапазоны при этом не пересекаются: худший прогон без якоря выше лучшего с якорем.

Для трёх повторов это сильный сигнал, хотя распределение ответов по ним не оценить.

Мне как руководителю важна не величина, а направление: сумма ушла вслед за подсказкой. Пересчитывать её в задачи, которые «влезут» в спринт, я бы не стал: story points относительны, а набор собран искусственно.

Наблюдение 2. Сильнее всего просели крупные задачи

Задачи с оценкой 1 и 3 у обеих моделей почти не двигались: обновление Groovy получило 1 во всех двенадцати прогонах.

А вот крупные проседали заметно:

• У ChatGPT задача про условие автоматической остановки потока (у команды — 13) при якоре во всех трёх прогонах стала 8.

• Задача про персистентные хранилища метаданных (у команды — 8) стала 5.

• У Claude в одном из прогонов с якорем срезались сразу четыре задачи, три из них крупные, и сумма упала до 44.

На 12 задачах это наблюдение, а не закономерность. Неопределённость задач я отдельно не измерял, поэтому говорить, что якорь давит именно на неё, пока рано.

Наблюдение 3. С якорем модель становится менее последовательной

Без якоря модели были удивительно стабильны: из 12 задач у ChatGPT оценка менялась между прогонами в трёх, у Claude — в двух.

С якорем у ChatGPT — в семи из двенадцати, у Claude — в четырёх. Мера грубая и прогонов мало, но направление у обеих моделей одно.

Моя гипотеза: без подсказки модель опирается только на текст задачи, а с подсказкой ей нужно «уложиться», и недостающие пункты каждый раз распределяются по‑разному.

По одному прогону эта нестабильность не видна.

Наблюдение 4. Совпала сумма — не значит, что совпали задачи

Самое коварное место эксперимента.

Средняя сумма ChatGPT с якорем — 60,3 SP. Это гораздо ближе к 64 у команды, чем 76,7 без якоря. Если смотреть только на итог спринта, якорь «помог».

Но другие метрики показывают иную картину:

• Средняя абсолютная ошибка ^[6] по задачам (MAE по медиане трёх прогонов против исторической оценки команды) выросла с 2,92 до 3,25 SP.

• Точных совпадений как было четыре из двенадцати, так и осталось.

• Ранговая корреляция при этом выросла с 0,67 до 0,73.

У Claude наоборот: сумма с якорем ушла от команды (54,0 против 66,7 при 64), а по задачам он оказался ближе.

• MAE — 1,42 SP против 1,75.

• Точных совпадений — семь против шести.

• Ранговая корреляция Спирмена с командой — 0,90 против 0,82.

То есть якорь оценку не портит, а незаметно двигает, и куда именно, заранее не знает никто.

Поэтому по одной сумме я бы об оценке модели не судил: она сглаживает ошибки разных знаков.

Наблюдение 5. Модели согласны друг с другом больше, чем с командой

Ранговая корреляция между ChatGPT и Claude без якоря — 0,87. С командой у ChatGPT — 0,67, у Claude — 0,82.

Ранжируют задачи модели похоже. Причину я не исследовал, моя догадка: обе видят только текст, без контекста команды.

На это намекают и самые большие расхождения.

Задачу «показать связь потоков и тапов в интерфейсе администратора» команда оценила в 13, ChatGPT — в 3, Claude — в 5. По тексту это сортировка списка в интерфейсе и в команде list оболочки.

Оценка 13 говорит, что команда видела за этим больше, вероятно, изменения в модели данных и API, о которых текст молчит.

Задачу «добавить процессор на R» команда оценила в 8, ChatGPT во всех трёх прогонах без якоря поставил 21: в описании есть слово «исследовать» и две библиотеки на выбор, и модель, видимо, заложила худший сценарий.

Мне в таких случаях нравится вопрос не «кто прав», а «чего не видит модель».

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

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

Лиз Ривера, программный менеджер, в сентябре 2026 года вела дневник проекта, где роль скрам‑мастера выполнял AI‑агент.

Перед оценкой третьего спринта она попросила агента выставить story points и, прежде чем запустить, задала ещё один вопрос: какой методикой он выбирает число.

Методики не оказалось. Инструкция сводилась к «поставь каждой задаче число от 1 до 13», без критериев, что отличает тройку от восьмёрки.

Ривера переделала оценку на общую рубрику, где каждая задача меряется по одним и тем же критериям.

Её вывод мне близок. В моём переводе он звучит так:

Автоматизация работы не отменяет потребности ^[7] в экспертизе. Она меняет вопрос с «Можно ли это сделать?» на «Знает ли тот, кто направляет работу, как выглядит хороший результат?».

Мой опыт показывает ту же проблему с другой стороны: без рубрики опорой модели становится число, оказавшееся рядом.

Как я бы встроил модель в планирование

Порядок, который я бы предложил после этого эксперимента, показан на Рис. 3.

Главная мысль схемы: в план идёт оценка команды, а модель работает детектором непонятных задач.

На практике это пять правил:

1. Не писать в промпт ни ёмкость спринта, ни ожидание тимлида, ни «прошлая похожая задача была на 5»: любое число в промпте может стать якорем.

2. Показывать команде оценку модели только после её собственного голосования, иначе якорем становится уже сама модель.

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

4. Сравнивать с командой по задачам и по рангу, а не по сумме.

5. Расхождение на две позиции шкалы и больше считать поводом проверить описание. Порог рабочий, а не измеренный.

Ограничения

Выборка маленькая: 12 задач, один проект, две модели, по три прогона.

Датасет публичный с 2016 года и мог попасть в обучающие данные моделей. Story points у каждой команды свои, поэтому «ошибка против команды» здесь значит расхождение с конкретной командой Spring XD, а не с объективной правдой.

Фраза B несёт и число, и мнение тимлида, их вклад опыт не разделяет. Параметры генерации в чатах не зафиксировать, а модель бесплатного ChatGPT может смениться в любой день.

Это не бенчмарк моделей, а проверка одного рабочего приёма: что делает с оценкой одна фраза в промпте.

Итог

Нейросеть на покер‑планировании ведёт себя как очень уверенный участник, который не видел кода. Без подсказок она последовательна и местами близка к команде. Но одна фраза тимлида в промпте сдвинула её сумму на пятую часть, а оценки отдельных задач стали чаще расходиться между прогонами.

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

Ссылка на мой репозиторий с эксперименто ^[8]м

Начать стоит с expected.txt: там все цифры статьи. Как они считаются, видно в analyze.py, задачи лежат в data/issues.csv, промпты — в prompts/, ответы моделей — в runs/.

Команда ./run.sh ^[9] пересчитывает метрики из сохранённых ответов и сверяет с эталоном, модели заново она не вызывает.

Источники:

• Репозиторий с экспериментом ^[8]

• Perkusich M. и др., Large language models in Scrum management: A practitioner survey, Journal of Systems and Software, онлайн 07.10.2026 ^[10]

• Shetty P. P. и др., Story Point Estimation Using Large Language Models, препринт arXiv 2603.06276, 2026 ^[11]

• Alaswad F. и др., From ^[12] to GPT: A Comprehensive Evaluation of LLM‑Based Software Effort Estimation, IEEE Access, 05.03.2026 ^[12]

• Jørgensen M., Halkjelsvik T., The effects of request formats on judgment‑based effort estimation, Journal of Systems and Software, 2010 ^[13]

• Calikli G., Alhamed M., Impact of Request Formats on Effort Estimation: Are LLMs Different Than Humans?, Proceedings of the ACM on Software Engineering, 2025 ^[14]

• Choetkiertikul M. и др., A deep learning model for estimating story points, датасет ^[15]

• Rivera L., Day 9: How I Knew My AI Scrum Master Wasn’t Doing Its Job, 01.09.2026 ^[16]

Нейросеть может быстро оценить бэклог, но насколько можно доверять её цифрам? Чтобы использовать ИИ в работе команды, важно не только знать возможности инструментов, но и понимать, где они ошибаются, как проверять результаты и какие задачи по‑прежнему требуют человеческой экспертизы.

Разобраться в этих вопросах помогут бесплатные уроки:

• 10 ноября, 20:00. «Почему проекты выходят из сроков и как увидеть это заранее». Записаться ^[17]

• 16 ноября, 20:00. «AI для Delivery Manager: какие управленческие задачи уже можно автоматизировать». Записаться ^[18]

• 17 ноября, 20:00. «User Story vs Use Case: что выбрать для описания требований». Записаться ^[19]

А больше открытых уроков по разработке, управлению и другим IT‑направлениям ищите в дайджесте OTUS ^[20].

Важное напоминание