Какие техники выявления требований существуют?
Что проверяют
Не список из учебника, а умение выбрать технику под ситуацию: кто стейкхолдеры, сколько их, насколько задача новая. Следом спрашивают, какую технику вы бы взяли для конкретного проекта и что делаете, когда стейкхолдеры противоречат друг другу.
Как отвечать
Опирайтесь на BABOK, там техники выявления описаны отдельно. Называйте их сразу с назначением:
- интервью: основной инструмент, лучше полуструктурированное, с подготовленными вопросами и свободной частью. Дорого по времени, но даёт глубину и контекст;
- анкетирование: когда респондентов десятки и сотни, например сотрудники филиалов. Даёт статистику, но не объясняет «почему»;
- наблюдение (job shadowing): сидите рядом с пользователем и смотрите, как он работает. Вскрывает обходные пути и неявные шаги, о которых на интервью не скажут;
- анализ документов и систем: регламенты, договоры, текущая база, API старой системы. Хороший старт перед интервью, но документация часто отстаёт от практики;
- воркшопы (фасилитированные сессии, JAD): собираете ключевых участников и договариваетесь сразу. Экономит недели на согласованиях;
- мозговой штурм: для новых продуктов, где требования ещё предстоит придумать;
- прототипирование: макет в Figma или кликабельный прототип. Пользователь реагирует на картинку лучше, чем на текст;
- фокус-группы, анализ интерфейсов и конкурентов: когда нужно понять рынок или стыки с соседними системами.
Главное в ответе: комбинация. Типичная цепочка на проекте автоматизации: анализ документов, интервью с владельцем процесса, наблюдение за исполнителями, воркшоп для согласования, прототип для проверки понимания. Приведите свой пример с проекта.
Где спотыкаются
Путают выявление с документированием. Use case, BPMN и user story это способы зафиксировать требования, а не добыть их.
Называют интервью единственным инструментом. Пользователи описывают процесс так, как он записан в регламенте, а не как они реально работают, поэтому без наблюдения часть требований теряется.
Не говорят о подтверждении. Выявленное нужно проверить и согласовать с заказчиком, иначе вы собрали мнение, а не требование.