Сбор требований
Процесс выявления, анализа и документирования потребностей стейкхолдеров.
Методы сбора требований
1. Интервью
Когда использовать:
- Нужно глубокое понимание
- Работа с ключевыми стейкхолдерами
- Конфиденциальная информация
Типы:
- Структурированное — заранее подготовленные вопросы
- Полуструктурированное — основные вопросы + импровизация
- Неструктурированное — свободная беседа
Подготовка:
- Изучить предметную область
- Подготовить вопросы
- Согласовать время (30-60 минут)
- Подготовить инструменты записи
Вопросы:
Открытые (предпочтительно):
- "Расскажите о вашем рабочем дне"
- "Какие проблемы вы сейчас испытываете?"
- "Как вы представляете идеальное решение?"
Закрытые (для уточнения):
- "Сколько пользователей будет в системе?"
- "Нужна ли интеграция с 1С?"
Техники:
- 5 Why — спрашиваем "почему?" 5 раз, чтобы найти корневую причину
- Активное слушание — перефразируем, уточняем
- Молчание — даем собеседнику время подумать
После интервью:
- Расшифровать записи в течение 24 часов
- Выделить ключевые требования
- Отправить summary на согласование
2. Воркшопы (Workshops)
Когда использовать:
- Нужно собрать разные точки зрения
- Выработать консенсус
- Быстро собрать много информации
Подготовка:
- Определить цель воркшопа
- Пригласить правильных людей (5-12 человек)
- Забронировать переговорку с доской
- Подготовить материалы (стикеры, маркеры)
- Разослать повестку заранее
Структура (2-3 часа):
- Введение (10 мин) — цель, правила, повестка
- Разогрев (10 мин) — icebreaker
- Основная часть (90-120 мин) — работа по повестке
- Подведение итогов (20 мин) — summary, next steps
Техники:
- Brainstorming — генерация идей без критики
- Affinity Mapping — группировка идей по темам
- Dot Voting — голосование точками за приоритеты
- User Story Mapping — визуализация пользовательского пути
Роль фасилитатора:
- Держать фокус на цели
- Управлять временем
- Вовлекать тихих участников
- Гасить конфликты
- Фиксировать результаты
3. Наблюдение (Shadowing)
Когда использовать:
- Нужно понять реальный процесс работы
- Пользователи не могут объяснить что делают
- Есть разрыв между тем что говорят и делают
Процесс:
- Договориться с пользователем
- Наблюдать за работой 2-4 часа
- Задавать уточняющие вопросы
- Фиксировать действия, проблемы, workarounds
Что фиксировать:
- Последовательность действий
- Используемые инструменты
- Время на каждую операцию
- Проблемы и ошибки
- Обходные пути (workarounds)
- Эмоции пользователя
Пример:
10:00 - Открывает Excel с отчетом
10:05 - Копирует данные в другой файл (вручную!)
10:15 - Форматирует таблицу
10:20 - Отправляет по email
Проблема: Нет автоматизации, много ручной работы
4. Анкетирование (Surveys)
Когда использовать:
- Много респондентов
- Нужна количественная информация
- Ограниченный бюджет
Типы вопросов:
- Закрытые — выбор из вариантов
- Шкала Likert — от 1 до 5
- Открытые — свободный ответ (минимум)
Правила:
- Не больше 10-15 вопросов
- Простые формулировки
- Один вопрос = одна тема
- Избегать leading questions
Инструменты:
- Google Forms
- Typeform
- SurveyMonkey
- Microsoft Forms
5. Анализ документов
Что анализировать:
- Существующая документация
- Регламенты и инструкции
- Отчеты и аналитика
- Логи системы
- Обращения в поддержку
Цель:
- Понять текущее состояние (As-Is)
- Выявить проблемы
- Найти требования
6. Прототипирование
Когда использовать:
- Сложно объяснить словами
- Нужна обратная связь по UI/UX
- Высокая неопределенность
Типы:
- Low-fidelity — бумажные наброски, wireframes
- High-fidelity — интерактивные прототипы в Figma
Процесс:
- Создать прототип
- Показать пользователям
- Собрать обратную связь
- Итерировать
Типы требований
Функциональные
Что система должна делать.
Примеры:
- Пользователь может зарегистрироваться через email
- Система отправляет уведомление при новом заказе
- Менеджер может экспортировать отчет в Excel
Нефункциональные
Производительность
- Страница загружается за < 2 секунд
- Система обрабатывает 1000 запросов в секунду
- Время отклика API < 200ms
Безопасность
- Пароли хранятся в зашифрованном виде
- Двухфакторная аутентификация
- Логирование всех действий администратора
Масштабируемость
- Поддержка до 100,000 пользователей
- Горизонтальное масштабирование
Доступность (Availability)
- Uptime 99.9%
- RTO (Recovery Time Objective) < 1 час
- RPO (Recovery Point Objective) < 15 минут
Usability
- Новый пользователь может оформить заказ за < 5 минут
- Не более 3 кликов до любой функции
- Поддержка мобильных устройств
Совместимость
- Работает в Chrome, Firefox, Safari (последние 2 версии)
- Интеграция с 1С через REST API
- Импорт данных из Excel
Приоритизация требований
MoSCoW
- Must have — критично, без этого не запускаем
- Should have — важно, но можно отложить
- Could have — желательно, если останется время
- Won't have — точно не в этом релизе
Матрица Эйзенхауэра
| Срочно | Не срочно | |
|---|---|---|
| Важно | Делаем первым | Планируем |
| Не важно | Делегируем | Удаляем |
RICE Score
Формула: (Reach × Impact × Confidence) / Effort
- Reach — сколько пользователей затронет (в месяц)
- Impact — насколько сильно (0.25 / 0.5 / 1 / 2 / 3)
- Confidence — уверенность в оценках (0-100%)
- Effort — трудозатраты (person-months)
Пример:
Фича: Фильтр товаров по цене
Reach: 5000 пользователей/месяц
Impact: 1 (средний)
Confidence: 80%
Effort: 0.5 person-months
RICE = (5000 × 1 × 0.8) / 0.5 = 8000
Kano Model
Классификация требований по влиянию на удовлетворенность:
- Basic — ожидаемые (их отсутствие раздражает)
- Performance — чем больше, тем лучше
- Excitement — wow-эффект, неожиданные
Документирование требований
Техническое задание (ТЗ)
Структура:
- Введение
- Цели и задачи
- Границы проекта
- Термины и определения
- Описание бизнес-процессов
- Функциональные требования
- Нефункциональные требования
- Ограничения
- Интеграции
- Приложения (диаграммы, mockups)
User Stories
Для Agile проектов (см. отдельную статью).
Use Cases
Детальные сценарии взаимодействия (см. отдельную статью).
Валидация требований
Критерии качества
Требование должно быть:
- Однозначным — одна интерпретация
- Полным — вся необходимая информация
- Согласованным — не противоречит другим
- Проверяемым — можно протестировать
- Трассируемым — связано с бизнес-целями
- Реализуемым — технически возможно
Техники валидации
Peer Review
Коллеги проверяют требования.
Walkthrough
Проходим по требованиям с командой.
Inspection
Формальная проверка по чек-листу.
Прототипирование
Создаем прототип и проверяем с пользователями.
Управление изменениями
Change Request Process
-
Запрос на изменение
- Кто инициирует
- Описание изменения
- Обоснование
-
Анализ влияния
- Затронутые компоненты
- Оценка трудозатрат
- Риски
-
Принятие решения
- Одобрить / Отклонить / Отложить
- Приоритет
-
Реализация
- Обновление документации
- Разработка
- Тестирование
-
Закрытие
- Верификация
- Обновление трассировки
Частые ошибки
1. Не задаем "почему?"
❌ Принимаем требование как есть ✅ Выясняем бизнес-цель, ищем альтернативы
2. Собираем требования только от одного человека
❌ Получаем однобокую картину ✅ Опрашиваем разные роли
3. Пишем решение вместо требования
❌ "Нужна кнопка 'Экспорт в Excel'" ✅ "Нужно анализировать данные в Excel"
4. Слишком детально на ранних этапах
❌ Описываем цвет кнопок в ТЗ ✅ Детализируем постепенно
5. Не проверяем понимание
❌ "Все понятно?" — "Да" ✅ "Расскажите своими словами что мы обсудили"
Чек-лист сбора требований
- Определены все стейкхолдеры
- Проведены интервью с ключевыми ролями
- Изучена существующая документация
- Проанализированы текущие процессы (As-Is)
- Определены бизнес-цели
- Собраны функциональные требования
- Собраны нефункциональные требования
- Требования приоритизированы
- Требования задокументированы
- Проведена валидация с заказчиком
- Получено формальное одобрение
Инструменты
- Jira / Confluence — документирование и трекинг
- Miro / Mural — воркшопы, визуализация
- Figma — прототипирование
- Notion — структурирование знаний
- Google Docs — совместное редактирование
- Loom — видео-демонстрации
Полезные ресурсы
- Книга "Software Requirements" — Karl Wiegers
- Книга "Mastering the Requirements Process" — Suzanne Robertson
- BABOK Guide — свод знаний бизнес-анализа