Multi-role estimation: оценка задач через симуляцию экспертной команды

ШАГ 1: Role-play оценка
Модель оценивает задачу от лица {роль_1}, {роль_2}, {роль_3}
→ Каждая роль: число + обоснование + ссылка на похожие задачи

ШАГ 2: Симуляция дискуссии (если оценки разошлись)
Модель генерирует обмен аргументами между ролями
→ Консенсусная оценка + итоговое обоснование

[Оба шага — в одном промпте или двух запросах подряд]

⚠️ Сильная зона метода: Оценка задач, где нужны разные экспертные перспективы (техническая сложность, UX, данные, инфраструктура). НЕ подходит для простых задач с одной перспективой ("Исправить опечатку в тексте").

Задача: Ты менеджер продукта в SaaS-стартапе. Команда просит оценить фичу "Экспорт отчётов в Excel с кастомными шаблонами". Нужно понять — 2 дня или 2 недели работы?

Промпт:

Ты — команда из трёх разработчиков: Frontend (React), Backend (Python/Django), QA. 
Оцените фичу "Экспорт отчётов в Excel с кастомными шаблонами" в story points (Fibonacci: 1, 2, 3, 5, 8, 13).

**Референс — прошлые задачи:**
- "Базовый экспорт в CSV" — 2 points
- "PDF-генерация с шаблонами" — 5 points 
- "Редактор таблиц в UI" — 8 points

**Формат:**
1. Frontend: [оценка] — [почему, какие сложности, на что похоже]
2. Backend: [оценка] — [почему, какие сложности, на что похоже] 
3. QA: [оценка] — [почему, какие сложности, на что похоже]

Если оценки разошлись — покажи короткую дискуссию (2-3 раунда аргументов), затем консенсус.

Результат:

Модель выдаст три оценки с обоснованиями (например: Frontend 3, Backend 5, QA 3). Поскольку оценки разошлись, модель покажет 2-3 раунда обмена аргументами: Backend защитит свою пятёрку ("нужна библиотека для XLSX + валидация шаблонов"), Frontend возразит ("UI уже есть, только кнопка + модалка"), QA добавит ("тест-кейсов немного, согласен с Frontend"). Финал — консенсусная оценка 3-5 points с итоговым списком сложностей, которые учли все роли.

LLM плохо держит в голове множество перспектив одновременно. Когда ты спрашиваешь "оцени задачу", модель выдаёт первую пришедшую в голову оценку — чаще всего с позиции самой очевидной сложности. Backend-нюансы могут выпасть, если задача выглядит простой с точки зрения UI. Или наоборот — завысит, если зациклится на одной технической сложности и не учтёт готовые решения.

LLM отлично симулирует дискуссии между ролями. Это сильная сторона: модель умеет генерировать аргументы от разных позиций, потому что в обучающих данных полно таких диалогов (code reviews, design discussions, tech debates). Каждая роль получает свой "профиль мышления" — frontend думает про UX, backend про данные, QA про тест-кейсы.

Техника использует эту силу через role-play промптинг. Вместо одного монолитного ответа ты явно просишь модель переключаться между ролями. Сначала она думает как frontend → выдаёт оценку. Потом переключается на backend → другая оценка. Затем симулирует их спор. Это заставляет модель пройти все углы зрения, а не застрять на первом пришедшем в голову.

Рычаги управления:

• Число ролей — 2-3 для простых задач (экономия токенов), 4-5 для сложных (больше перспектив)
• Прошлые примеры — добавь 3-5 референсных задач → модель калибрует оценку
• Раунды дискуссии — убери "2-3 раунда" → модель даст консенсус сразу (быстрее, но грубее)
• Формат вывода — убери "без объяснений" → видишь все аргументы (полезно для обучения команды)
• Имена ролей — вместо "Frontend" напиши "Лена (React-developer с 5 годами)" → острее выполнение роли

Ты — команда из {N} экспертов: {роль_1}, {роль_2}, ..., {роль_N}.
Оцените задачу "{описание_задачи}" в {единицы_измерения}.

**Референс — прошлые задачи:**
- "{задача_1}" — {оценка_1}
- "{задача_2}" — {оценка_2}
- "{задача_3}" — {оценка_3}

**Формат:**
1. {роль_1}: [оценка] — [почему, какие сложности, на что похоже]
2. {роль_2}: [оценка] — [почему, какие сложности, на что похоже]
...

Если оценки разошлись — покажи {N_раундов} раундов дискуссии, затем консенсус.

Плейсхолдеры:

• {N} — число ролей (обычно 2-4)
• {роль_1}, {роль_2} — Frontend, Backend, QA, DevOps, Data Engineer и т.д.
• {описание_задачи} — текст задачи
• {единицы_измерения} — story points (Fibonacci), часы, дни
• {задача_1-3} — 3-5 прошлых похожих задач с известными оценками
• {N_раундов} — обычно 2-3 (больше → точнее, но дороже в токенах)

🚀 Быстрый старт — вставь в чат:

Вот шаблон multi-role estimation. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит: какие роли нужны для твоего проекта, какие прошлые задачи использовать как референс, в каких единицах измерять. Она возьмёт паттерн role-play дискуссии из шаблона и адаптирует под твою задачу — ты получишь рабочий промпт без разбора в структуре вручную.

⚠️ Специфичность ролей: Техника работает хуже для задач, где все роли видят одинаковую сложность. Если и frontend, и backend, и QA скажут "это просто кнопка" — дискуссия бессмысленна, консенсус не добавит точности. Используй для кросс-функциональных задач (где каждая роль видит свои нюансы).

⚠️ Калибровка через примеры: Без прошлых референсных задач модель оценивает абстрактно, не зная контекста проекта. В исследовании fine-tuning на историческом датасете давал 83% улучшение точности. В обычном чате используй in-context learning — дай 3-5 прошлых задач с оценками, чтобы модель откалибровалась.

⚠️ Стоимость токенов: Каждая роль + дискуссия = много токенов. Для простых задач избыточно (дешевле спросить в лоб). Используй там, где цена ошибки высока: сроки поджимают, бюджет ограничен, команда спорит.

Команда проверила подход на двух фронтах: точность оценок и восприятие людьми.

Точность: Взяли 4 реальных проекта с Jira (4907 user stories с известными story points). Fine-tuned LLM (Llama-3.1-8B) на прошлых оценках проекта, затем тестировали на новых user stories. Сравнивали с тремя SOTA подходами (Deep-SE, GPT2SP, Fine-SE) по трём метрикам: средняя ошибка, относительная ошибка, процент попаданий в ±50%.

Результат удивил: В 3 из 4 проектов агент обогнал все SOTA (улучшение до 83% по ошибке). В проекте Usergrid достиг идеального PRED(50) = 1.0 (все оценки в пределах ±50%). Только в одном проекте (Talend) уступил Deep-SE — но всё равно превзошёл GPT2SP. Почему? Fine-tuning научил модель паттернам оценки конкретного проекта (какие задачи сложнее, какие проще), а не общим абстрактным знаниям.

Восприятие людьми: Собрали 12 разработчиков, дали им работать с агентами в реальной Planning Poker сессии (30 минут, оценка user stories для e-commerce проекта). Агенты играли роли frontend/backend специалистов — обосновывали оценки, ссылались на прошлые задачи, спорили с людьми.

Логика была проста: Если агенты правда полезны — люди это почувствуют в живой работе, не в бенчмарках. И вот инсайт: 83% участников сказали, что работать с агентами было естественно. 66% согласились, что агенты помогли быстрее достичь консенсуса. 58% отметили, что агенты закрыли knowledge gap между ролями (frontend не знал, что backend видит сложность в интеграции — агент это озвучил).

Что противоречило ожиданиям: Только треть участников готовы полностью заменить эксперта на AI. Но 75% доверяют оценкам агента и будут использовать в работе. Вывод: агенты воспринимаются как коллега, а не замена. Люди хотят AI на стороне команды, не вместо команды.

Контекст: Исследователи использовали этот промпт для fine-tuning LLM на датасете user stories. Читатель может взять его как отправную точку для своих задач.

[system]
You are an expert software development effort estimator. 
Given a software development issue summary, predict the effort in story points.

[user]
### Summary:
{{USER STORY}}

[assistant]
My estimated story point is: {{ESTIMATED POINT}}

Для multi-agent дискуссии (из реального промпта агента):

You are an agent that participates in a planning poker session 
with other agents and human players.

## Strategy
Your objective is to communicate via chat with other players to come up 
with the best estimation for the given user story. For better estimation, 
you should base your estimation on the past user stories and similar user stories.

In the first round, you can either make an estimation or ask questions to 
clarify the user story. For the following rounds, you should justify your 
estimation based on similar user stories and consider others' estimations.

## Past user stories
For reference, you can use the following past user stories to help you 
make your estimation:

{{PAST USER STORIES}}

## User story to be estimated
{{USER STORY}}

💡 Адаптация для оценки времени клиентских проектов:

Тот же принцип, но вместо story points — часы/дни для фриланс-задач.

Ты — команда: Дизайнер (Figma), Frontend (React), Копирайтер.
Оцените задачу "Лендинг для онлайн-курса по маркетингу (5 блоков, форма, анимации)" в часах.

**Референс:**
- "Простой лендинг без анимаций" — 16 часов
- "Корпоративный сайт (10 страниц)" — 40 часов
- "Лендинг с кастомными иллюстрациями" — 24 часа

**Формат:** [роль]: [оценка] — [почему]
Если разошлись — короткая дискуссия → консенсус.

🔧 Техника: Асинхронная дискуссия (для экономии токенов)

Вместо генерации всех ролей в одном запросе — делай последовательные запросы:

Запрос 1: "Ты Frontend. Оцени задачу X в story points, объясни почему."
Запрос 2: "Ты Backend. Вот оценка Frontend: [ответ]. Твоя оценка и аргументы."
Запрос 3: "Ты QA. Вот оценки Frontend/Backend: [ответы]. Твоя позиция?"
Запрос 4: "Проанализируй все три оценки. Найди консенсус."

Эффект: Каждый запрос короче → дешевле. Минус: нет реального спора между ролями (каждая видит только предыдущие, не реагирует на критику).

💡 Адаптация для риск-анализа бизнес-решений:

Комбинируй multi-role с методом "предмортем" (представь, что провалились — почему?).

Ты — команда: CFO, CMO, Product Manager.
Решение: "Запустить новую фичу без A/B теста, чтобы не терять momentum".

**Формат:**
1. CFO (риски): какие финансовые последствия, если провалимся?
2. CMO (риски): как это ударит по репутации?
3. PM (риски): какие технические проблемы не учли?

Затем: консенсус — стоит ли рисковать или сделать тест?

Эффект: Вместо оценки сложности — генерация разных угроз, которые каждая роль видит лучше. Консенсус = взвешенное решение.

An LLM-based multi-agent framework for agile effort estimation

https://figshare.com/s/bb33c350859802b071ea (платформа SEEAgent)

https://figshare.com/s/592bb84543653d80a515 (датасет eShope)

Авторы: Thanh-Long Bui, Hoa Khanh Dam (University of Wollongong), Rashina Hoda (Monash University)