requirements-elicitation

name	requirements-elicitation
description	Подготовка плана сбора требований (elicitation plan) по методологии Вигерса. Используй когда пользователь просит: - спланировать сбор требований - подготовить elicitation plan - определить, кого интервьюировать и как - выбрать техники сбора требований под проект - оценить риски и пробелы в текущем понимании требований

Навык: План сбора требований (Requirements Elicitation Plan)

Цель

Создай план сбора требований — короткий документ, который отвечает на четыре вопроса:

1. Кого опрашивать? (стейкхолдеры, представители, эксперты).
2. Что именно нужно узнать? (пробелы в текущем понимании).
3. Как собирать? (техники: интервью, опрос, наблюдение, прототип, анализ артефактов).
4. Когда и в каком порядке? (расписание, зависимости).

План — это рабочий артефакт для аналитика, не корпоративный документ. Краткость важнее полноты.

Обязательные действия

1. Изучи контекст проекта. Если есть Vision and Scope — прочитай. Если нет — задай 3-5 уточняющих вопросов о бизнес-цели, типе проекта (веб / мобильное / интеграция / ML), составе команды.
2. Выяви пробелы. Сравни текущие документы с типичной структурой требований Вигерса (бизнес-цели, стейкхолдеры, use cases, бизнес-правила, нефункциональные). Перечисли, что отсутствует или не подтверждено.
3. Подбери техники под пробелы. Не все техники подходят всем проектам — см. матрицу ниже.
4. Сформулируй план по структуре ниже.
5. Проверь по чеклисту качества.

Структура плана elicitation

# План сбора требований: [Название проекта]

**Аналитик:** [имя]
**Дата:** [YYYY-MM-DD]
**Срок завершения elicitation:** [дата]

## 1. Контекст
- Тип проекта: [веб / мобильное / интеграция / ML / B2B SaaS / ...]
- Бизнес-цель (одна фраза): [...]
- Текущий статус документации: [что уже есть]

## 2. Пробелы (что нужно узнать)
| ID | Пробел | Приоритет | Кому адресован |
|----|--------|-----------|----------------|
| G-1 | [например: Не подтверждены метрики успеха BO-1] | Высокий | Спонсор |
| G-2 | [...] | Средний | Технический архитектор |

## 3. Стейкхолдеры (кого опрашивать)
| Стейкхолдер | Роль | Источники | Доступность |
|-------------|------|-----------|-------------|
| ... | ... | интервью / опрос / документы | высокая / средняя / низкая |

## 4. Техники
| Техника | Зачем выбрана | Кому применима |
|---------|---------------|----------------|
| 1:1 интервью | Глубинное выяснение мотивации | Спонсор, ключевые пользователи |
| Опрос (survey) | Массовая валидация гипотез | >20 пользователей |
| Наблюдение / shadowing | Молчаливые требования | Операторы, поддержка |
| Анализ артефактов | Существующие отчёты, баги, тикеты | Историческое знание |
| Прототипирование | Пользователь не может сформулировать | UI / UX-зависимые проекты |
| Workshop / brainstorm | Конфликт интересов между группами | Кросс-функциональные решения |

## 5. Расписание
| Неделя | Активности |
|--------|-----------|
| Нед. 1 | Спонсор + 2 ключевых пользователя (1:1, по 60 мин) |
| Нед. 2 | Опрос (рассылка), shadowing 2 операторов |
| Нед. 3 | Workshop с продуктовой и инженерной командами |
| Нед. 4 | Сводка пробелов, добор недостающего, валидация |

## 6. Риски и митигация
- R-1: Спонсор недоступен → попросить делегата с правом решений
- R-2: Малая выборка опроса (<30%) → подкрепить интервью

## 7. Артефакты на выходе
- [ ] Stakeholder profiles (skill: stakeholder-profile)
- [ ] Use cases по приоритетным сценариям (skill: use-case)
- [ ] Vision & Scope (skill: vision-and-scope) — если ещё не утверждена
- [ ] Перечень бизнес-правил
- [ ] Перечень нефункциональных требований

Матрица «техника → когда применять»

• Интервью — когда мотивация / контекст не очевидны. Дороже всего, но самый информативный.
• Опрос — когда базовые гипотезы есть, нужна валидация на масштабе.
• Наблюдение — когда «как делают на самом деле» отличается от «как должны делать».
• Анализ артефактов — когда есть тикеты / отчёты / переписка, накопившие неявные требования.
• Прототип — когда пользователь говорит «не знаю, пока не увижу».
• Workshop — когда нужен консенсус между группами с разными интересами.

Чеклист качества плана

• Каждый пробел (G-N) имеет приоритет и адресата
• Каждый стейкхолдер имеет хотя бы одну технику
• Расписание помещается в реалистичный срок (не «всё за 1 неделю»)
• Риски сформулированы конкретно, с митигацией
• Список артефактов на выходе совпадает с пробелами

Частые ошибки

❌ План без пробелов — «опросим всех о всём». Без gap-анализа elicitation размыт. ❌ Только интервью — недёшево и не масштабируется. Сочетай техники. ❌ Пропуск анализа артефактов — старые тикеты часто содержат уже найденные неявные требования. ❌ Один стейкхолдер на роль — критично иметь несколько источников для тройной проверки.