group-telegram.com/ba_and_sa/2232
Last Update:
Салют! Сегодня продолжаем мой «мини курс» для системных аналитиков!
В прошлый раз рассмотрели:
1. Введение в системный анализ
Сегодня у нас:
#курс | @ba_and_sa
____________
Для закрепления:
Сбор требований — это основа успеха любого проекта. Ошибки на этом этапе могут привести к переделкам, срыву сроков и недовольству заказчика.
Перед встречей с заказчиком:
- Изучите контекст. Узнайте, чем занимается компания, какие у нее бизнес-цели, кто конкуренты. Почитайте документацию, если она есть (например, ТЗ прошлых проектов)
- Определите стейкхолдеров. Кто принимает решения? Кто будет пользоваться системой? Не упустите ни одну группу: менеджеры, конечные пользователи, технические специалисты
- Сформулируйте гипотезы. Запишите свои предположения о потребностях заказчика — это поможет задавать точные вопросы.
📋 Техники сбора требований
Используйте комбинацию методов:
- Интервью.
Задавайте открытые вопросы: «Расскажите, как сейчас проходит процесс X», избегайте наводящих вопросов: «Вам же нужна автоматизация, верно?»
- Воркшопы. Совместное обсуждение с использованием доски (физической или цифровой) помогает визуализировать требования.
- Наблюдение. Посмотрите, как пользователи работают в текущей системе — это выявит неочевидные проблемы.
- Прототипы. Эскизы интерфейсов или схемы процессов помогут заказчику конкретизировать пожелания.
- Составьте чек-лист вопросов, но будьте готовы отклониться от него. Примеры:
▫️ «Что вас не устраивает в текущем процессе?»
▫️ «Какие ограничения (бюджет, сроки, технологии) важно учесть?»
- Используйте технику «5 почему». Если заказчик говорит: «Нам нужна кнопка здесь», спросите: «Почему это важно?», пока не докопаетесь до корневой потребности.
- Записывайте всё. Используйте диктофон (с разрешения!) или конспектируйте ключевые тезисы.
📑 Документирование требований
- Структурируйте информацию. Разделяйте требования на:
- Функциональные (что система должна делать).
- Нефункциональные (производительность, безопасность, удобство).
- Ограничения (сроки, бюджет, законодательство).
- Используйте шаблоны. Например, User Stories (*«Как [роль], я хочу [действие], чтобы [цель]»*) или Use Case-диаграммы.
- Проверяйте требования на SMART: Конкретные, Измеримые, Достижимые, Релевантные, Ограниченные по времени.
- Не додумывайте за заказчика. Если что-то непонятно — переспрашивайте.
- Не игнорируйте конфликтующие требования. Если мнения стейкхолдеров расходятся, зафиксируйте это и обсудите приоритеты.
- Не используйте технический жаргон. Говорите на языке заказчика.
- Не спешите. Лучше потратить время на уточнение, чем переделывать готовый функционал.
- Проведите ревью. Убедитесь, что требования:
- Полные (охватывают все сценарии).
- Непротиворечивые.
- Тестируемые (можно проверить результат).
- Утвердите документ. Подпись заказчика формализует договоренности и снижает риски.
____
Советы из личного опыта
- Всегда спрашивайте: «Что будет, если этого НЕ сделать?» — это помогает отсечь «хотелки» от критически важных требований.
- Добавляйте примеры из реальной жизни в документацию («Для заказа клиент заполняет форму, как на Рис. 1»).
- Используйте инструменты: Jira, Confluence, Miro, Draw.io — они упрощают визуализацию и совместную работу.
Финальный лайфхак: Требования меняются. Заложите в процесс регулярные встречи для актуализации документации и будьте готовы к итерациям.
Источник: @ba_and_sa
