| name | requirements-elicitation |
| description | Подготовка плана сбора требований (elicitation plan) по методологии Вигерса.
Используй когда пользователь просит:
- спланировать сбор требований
- подготовить elicitation plan
- определить, кого интервьюировать и как
- выбрать техники сбора требований под проект
- оценить риски и пробелы в текущем понимании требований
|
Навык: План сбора требований (Requirements Elicitation Plan)
Цель
Создай план сбора требований — короткий документ, который отвечает на четыре вопроса:
- Кого опрашивать? (стейкхолдеры, представители, эксперты).
- Что именно нужно узнать? (пробелы в текущем понимании).
- Как собирать? (техники: интервью, опрос, наблюдение, прототип, анализ артефактов).
- Когда и в каком порядке? (расписание, зависимости).
План — это рабочий артефакт для аналитика, не корпоративный документ. Краткость важнее полноты.
Обязательные действия
- Изучи контекст проекта. Если есть Vision and Scope — прочитай. Если нет — задай 3-5 уточняющих вопросов о бизнес-цели, типе проекта (веб / мобильное / интеграция / ML), составе команды.
- Выяви пробелы. Сравни текущие документы с типичной структурой требований Вигерса (бизнес-цели, стейкхолдеры, use cases, бизнес-правила, нефункциональные). Перечисли, что отсутствует или не подтверждено.
- Подбери техники под пробелы. Не все техники подходят всем проектам — см. матрицу ниже.
- Сформулируй план по структуре ниже.
- Проверь по чеклисту качества.
Структура плана 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 — когда нужен консенсус между группами с разными интересами.
Чеклист качества плана
Частые ошибки
❌ План без пробелов — «опросим всех о всём». Без gap-анализа elicitation размыт.
❌ Только интервью — недёшево и не масштабируется. Сочетай техники.
❌ Пропуск анализа артефактов — старые тикеты часто содержат уже найденные неявные требования.
❌ Один стейкхолдер на роль — критично иметь несколько источников для тройной проверки.
