Сбор требований

Сбор требований (Requirements Elicitation) – это процесс выявления, обнаружения и извлечения требований из различных источников: заказчиков, пользователей, документов, существующих систем.

Почему сбор требований – это сложно

Проблемы сбора требований:

1. Заказчик не знает, чего хочет. Он видит проблему, но не знает решения. Или думает, что знает, но ошибается.

2. Заказчик не говорит всего. Что-то кажется ему очевидным, и он забывает сказать. А для вас это не очевидно.

3. Разные люди хотят разного. Бухгалтеру нужна детализация, директору – общие цифры, менеджеру – скорость. А система одна.

4. Требования меняются. Пока вы собирали, бизнес изменился, закон вышел новый, конкурент сделал фичу.

5. Языковой барьер. Бизнес говорит на одном языке, IT – на другом. “Давайте сделаем облако” – для бизнеса это про доступ отовсюду, для IT – про конкретную технологию.

Источники требований

Прежде чем собирать, нужно понять, где искать. У требований есть несколько источников.

Заинтересованные лица (Stakeholders)

Люди, у которых есть интерес к системе.

• Заказчик (спонсор) – тот, кто платит деньги. Говорит о целях и бюджете.
• Пользователи – те, кто будет работать в системе. Говорят о задачах и проблемах.
• Руководители – те, кто управляет пользователями. Говорят о процессах и отчетах.
• Администраторы – те, кто будет поддерживать систему. Говорят о надежности и удобстве эксплуатации.
• Интеграционные смежники – те, с чьими системами нужно будет дружить/интегрироваться.

Документы и артефакты

• Бизнес-стратегия – куда компания движется.
• Нормативные документы – законы, стандарты, регламенты.
• Описание текущих процессов – как работают сейчас.
• Документация существующих систем – что уже есть.

Существующие системы

• Текущая система – что уже работает, что в ней плохо.
• Системы конкурентов – как у них, что можно подсмотреть.

Аналитика и данные

• Логи и метрики – что реально делают пользователи.
• Обращения в поддержку – что чаще всего болит.
• Опросы и исследования – что говорят пользователи.

Техники сбора требований

Интервью (Interview)

Самый распространенный способ. Вы садитесь с человеком и разговариваете один на один.

Виды интервью:

• Структурированное – жесткий список вопросов, как анкета.
• Неструктурированное – свободная беседа, вы плывете по течению.
• Полуструктурированное – есть список тем, но порядок свободный. Золотая середина.

Советы по интервью:

• Готовьте вопросы заранее.
• Спрашивайте не только “что”, но и “почему” и “зачем”.
• Просите примеры: “Расскажите ситуацию, когда это происходит”.
• Не перебивайте, дайте выговориться.
• Переспрашивайте и уточняйте: “Правильно ли я понял, что…”.
• Записывайте (по началу рекомендую использовать OBS и записывать все встречи для дальнейшего анализа).

Примеры вопросов:

• “Расскажите, как вы сейчас выполняете эту задачу?”
• “Что вам нравится в текущем процессе?”
• “Что вас бесит, раздражает, хочется изменить?”
• “Бывают ли нештатные ситуации? Как вы с ними справляетесь?”
• “Представьте, что у вас есть волшебная палочка. Что бы вы изменили?”

Анкетирование и опросы

Когда нужно опросить много людей, интервью не проведешь – времени не хватит. Тогда рассылают анкеты.

Плюсы: можно охватить много людей. Минусы: низкий возврат, поверхностные ответы, нельзя уточнить.

Советы:

• Делайте вопросы четкими и понятными.
• Используйте закрытые вопросы (выбор вариантов) для статистики.
• Оставляйте открытые поля для комментариев.
• Не делайте слишком длинные анкеты – люди бросят заполнять.

Наблюдение (Observation)

Вы приходите и смотрите, как люди работают. Это очень мощный инструмент, потому что люди часто делают не так, как говорят.

Варианты:

• Пассивное наблюдение – вы просто сидите в углу и смотрите, не вмешиваясь.
• Активное наблюдение – вы задаете вопросы по ходу: “А почему вы сейчас сделали так?”.
• Включенное наблюдение – вы сами пробуете выполнять работу (если это возможно).

Что дает наблюдение:

• Видите реальные действия, а не рассказы о них.
• Замечаете то, что люди сами не замечают (“автоматизмы”).
• Видите обходные пути (workarounds), которые люди придумали, чтобы компенсировать недостатки системы.

Анализ документов (Document Analysis)

Вы изучаете все бумажные и электронные документы, которые есть в компании.

• Инструкции и регламенты.
• Отчеты и формы.
• Должностные инструкции.
• Документацию существующих систем.

Что дает: понимание формальных правил и процессов, которые люди могут не соблюдать, но они есть.

Мозговой штурм (Brainstorming)

Собираете группу людей и генерируете идеи. Важно: на этапе генерации никакой критики, любые идеи записываются. Потом уже отсеиваете.

Хорош для: поиска новых решений, сбора пожеланий, расширения границ.

Воркшопы (Workshops)

Это структурированные встречи с группой заинтересованных лиц. Ведущий (фасилитатор) проводит группу через серию упражнений.

Примеры упражнений:

• Event Storming – на стене стикерами моделируются события в системе.
• User Story Mapping – строим карту пользовательских историй.
• Прототипирование на бумаге – рисуем экраны вместе с пользователями.

Плюсы: быстро, вовлекает всех, рождает общее понимание. Минусы: сложно организовать, требует опытного ведущего.

Прототипирование (Prototyping)

Вы показываете пользователям “черновик” будущей системы - картинки, кликабельный макет, простую версию. Они смотрят и говорят: “нет, это не то, кнопка должна быть слева”.

Плюсы: требования становятся наглядными, ошибки видны рано. Минусы: пользователи могут подумать, что это уже готовая система, и удивляться, почему долго делают.

Анализ обратной связи (Feedback Analysis)

Если система уже существует, изучайте:

• Запросы в техподдержку.
• Жалобы и предложения пользователей.
• Логи и метрики использования.
• Отзывы на форумах.

Это готовый источник требований на улучшение.

Проблемы и сложности при сборе требований

Проблема 1: “Я не знаю, чего хочу”

Заказчик честно признается, что не знает. Или знает, но смутно.

Что делать: помогайте наводящими вопросами, показывайте аналоги, рисуйте прототипы. Иногда люди понимают, чего хотят, только когда видят, чего НЕ хотят.

Проблема 2: Противоречия

Одни говорят “делаем быстро”, другие – “делаем надежно”. И то, и другое правильно, но требует компромисса.

Что делать: фиксировать противоречия, показывать их, помогать договариваться о приоритетах.

Проблема 3: Невысказанные предположения

Заказчик не говорит, потому что ему кажется, что “это и так понятно”.

Что делать: переспрашивать, уточнять, проверять. Лучше 10 раз показаться занудой, чем сделать неправильно.

Проблема 4: Влиятельные люди

Есть “серые кардиналы”, которые не присутствуют на встречах, но могут заблокировать проект.

Что делать: выявить всех заинтересованных лиц в начале, поговорить со всеми.

Проблема 5: Изменчивость

Сегодня хотят одно, завтра – другое.

Что делать: фиксировать версии, документировать изменения, синхронизироваться по приоритетам.

Процесс сбора требований: Как это выглядит на практике

Давайте представим типовой процесс работы аналитика на этапе сбора.

Шаг 1. Идентификация заинтересованных лиц

Кто все эти люди? Составляем список: заказчик, пользователи, руководители, смежники, администраторы. Со всеми нужно поговорить.

Шаг 2. Планирование сбора

Кого, когда, каким методом опрашиваем. Готовим вопросы, договариваемся о встречах.

Шаг 3. Проведение интервью и воркшопов

Разговариваем, задаем вопросы, записываем, уточняем. Используем доски (Miro, Holst), стикеры, прототипы.

Шаг 4. Анализ и структурирование

Собираем все записи, ищем противоречия, группируем по темам, отделяем важное от второстепенного.

Шаг 5. Валидация

Показываем заинтересованным лицам: “Правильно ли я понял?”. Часто на этом этапе выясняется, что поняли не так или не всё.

Шаг 6. Формализация

Записываем требования в нужном формате: User Stories, Use Cases, спецификация – в зависимости от методологии.