Формирование бэклога продукта на основе требований

Код: 9-6

📌 Ситуация

У вас есть сырые требования от заказчика, стейкхолдеров или бизнес-аналитиков. Они неструктурированы, противоречивы или избыточны. Вам нужно превратить их в приоритизированный бэклог продукта, готовый для планирования спринтов и разработки. Без этого команда не понимает, с чего начинать, а заказчик не видит, что войдёт в первый релиз.

🤖 Промпт

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

🔒 Скопировать промпт могут только зарегистрированные пользователи.

или Зарегистрироваться

💡 Почему это работает

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

⚠️ Антипромпт

«Собери все требования заказчика в один список и расставь приоритеты.» Почему плохо: нет очистки дублей, нет структуры MoSCoW, нет рекомендаций по релизам. Результат — просто список задач без приоритетов.

📊 Характеристики

⏳ Время на подготовку: 20 мин
⚙️ Время выполнения: 25 мин
Сложность: ⭐⭐
Горизонт планирования: Проектный
Тип плана: Проектный план
Количество субъектов: 1
Жёсткость ограничений: Средняя
Необходимые данные: Сырые требования от заказчика или стейкхолдеров
Формат вывода: Таблица
Инструменты: Excel, Google Таблицы, Jira, Notion
Приоритет цели: Сбалансированность
Цикличность: Разовая задача
Фаза жизненного цикла: Планирование
Область знаний PMBoK: Содержание, Стейкхолдеры
Методология управления: Agile (Scrum)
🏷️ Теги: бэклогтребованияMoSCoWприоритизацияProduct Owner

📖 Пример использования

Входные данные: требования для CRM-системы: управление клиентами, отправка email-рассылок, отчёты по продажам, управление задачами, интеграция с телефонией, мобильное приложение. Результат: ИИ формирует бэклог из 34 элементов с приоритетами MoSCoW. Must Have (14 задач) — управление клиентами и отчёты; Should Have (10 задач) — рассылки и задачи; Could Have (6 задач) — интеграция с телефонией; Won't Have (4 задачи) — мобильное приложение в текущем релизе. Рекомендуемое разбиение на 3 релиза по 3–4 месяца каждый.
Scroll to Top