Как собирать требования, когда заказчик не знает, чего хочет
Практические техники элиситации требований для ситуаций, когда стейкхолдеры не могут сформулировать свои потребности.
Одна из самых распространённых ситуаций в работе бизнес-аналитика: заказчик говорит «нам нужна система», но не может объяснить, что именно она должна делать. Знакомо? Давайте разберём, как с этим работать.
Почему заказчик «не знает»
На самом деле заказчик знает — он просто не может это выразить на языке требований. Причины бывают разные:
- Проклятие знания — эксперт настолько погружён в предметную область, что считает многие вещи очевидными и не упоминает их
- Мышление решениями — заказчик приходит с готовым решением («нам нужна кнопка»), а не с проблемой («менеджеры тратят 40 минут на ручное формирование отчёта»)
- Страх ошибки — боязнь зафиксировать что-то «неправильное» и потом нести за это ответственность
- Коллективная неопределённость — разные стейкхолдеры хотят разного, но никто из них не знает позицию других
Задача аналитика — не ждать, пока заказчик «сам разберётся», а использовать техники, которые помогают извлечь знание.
Техники элиситации: что работает на практике
1. Начинайте с проблемы, а не с решения
Вместо вопроса «Что должна делать система?» задавайте вопросы о боли:
- «Что сейчас работает плохо и почему?»
- «На что уходит больше всего времени у вашей команды?»
- «Что вас раздражает в текущем процессе каждый день?»
- «Если бы можно было изменить одно — что бы это было?»
Такой разворот переключает заказчика с режима «придумать систему» в режим «описать реальность». А реальность он знает хорошо.
2. Наблюдение (Job Shadowing)
Проведите несколько часов рядом с конечным пользователем. Не в переговорной — за его рабочим местом. Наблюдайте и записывайте:
- Какие действия повторяются более одного раза в час
- Где происходят переключения между инструментами (Excel → 1С → почта → Excel — это сигнал)
- Когда пользователь выглядит раздражённым, смотрит в потолок или звонит коллеге с вопросом
- Что он делает «не по регламенту» — именно здесь чаще всего скрыты настоящие требования
Один день наблюдения даёт больше, чем три часа интервью.
3. Прототипирование на бумаге (Paper Prototyping)
Нарисуйте простейший интерфейс на бумаге, в Miro или Figma — буквально прямоугольники с подписями. Покажите заказчику и спросите:
- «Это то, что вы имеете в виду?»
- «Чего здесь не хватает?»
- «Что лишнее?»
Людям значительно проще критиковать готовое, чем придумывать с нуля. Даже «неправильный» прототип запускает нужный разговор: заказчик начинает объяснять, чем он отличается от того, что ему нужно.
4. Вопросы «А что если...»
Граничные случаи вскрывают неявные требования, которые кажутся заказчику «и так понятными»:
- «А что если клиент отменит заказ после подтверждения?»
- «А что если один менеджер одновременно ведёт 200 клиентов?»
- «А что если данные приходят с ошибками или дублями?»
- «А что если пользователь случайно удалил запись?»
- «А что если система недоступна три часа?»
На каждый такой вопрос либо есть ответ (и это требование), либо нет (и это риск, который нужно зафиксировать).
5. Пять «Почему» (5 Whys)
Техника из бережливого производства, которая отлично работает при сборе требований. Когда заказчик формулирует требование, спрашивайте «Почему?» пять раз подряд:
«Нам нужен отчёт по продажам по регионам» — Почему? — Чтобы руководство видело картину — Почему сейчас не видит? — Отчёт формируют вручную, раз в месяц — Почему раз в месяц? — Это занимает два дня работы аналитика — Почему два дня? — Данные в трёх разных системах, нет единого источника
Настоящее требование: не «отчёт», а «единый источник данных и автоматическая выгрузка». Это совсем другая задача.
6. Воркшопы с несколькими стейкхолдерами
Когда разные отделы хотят разного, индивидуальные интервью не дают полной картины. Организуйте совместный воркшоп на 2–3 часа:
- Модератор (аналитик) держит структуру и не даёт уйти в спор
- Каждый стейкхолдер записывает свои ожидания на стикерах
- Группа кластеризует ожидания и находит противоречия
- Противоречия фиксируются как открытые вопросы, не решаются на месте
Результат воркшопа: согласованный приоритизированный список требований, который видели все.
7. Анализ существующих артефактов
Иногда требования уже где-то есть — просто не в формате требований:
- Жалобы пользователей в службу поддержки: то, на что жалуются чаще всего, — это де-факто требования к улучшению
- Excel-таблицы и Access-базы, которые люди создали сами: это «теневые системы», показывающие, чего не хватает в основной
- Регламенты и инструкции: что написано в регламенте vs. как работают на самом деле — разрыв между ними и есть зона требований
- Отчётность и KPI: что руководство измеряет — то и нужно автоматизировать
Как структурировать собранное
После любой техники элиситации материал нужно структурировать. Я использую простую схему:
| Категория | Вопрос | Пример |
|---|---|---|
| Функциональные требования | Что система должна делать? | «Система должна автоматически уведомлять менеджера, если клиент не оплатил счёт в течение 5 дней» |
| Нефункциональные | Как система должна это делать? | «Уведомление должно приходить не позже чем через 5 минут после наступления условия» |
| Ограничения | Что система не может делать? | «Нельзя хранить персональные данные клиентов на зарубежных серверах» |
| Предположения | Что мы считаем истинным? | «Менеджеры проверяют почту каждые 2 часа» |
| Открытые вопросы | Что ещё нужно выяснить? | «Как обрабатываются частичные оплаты?» |
Антипаттерны: чего не делать
❌ Отправлять опросник вместо разговора. Заказчик заполнит его формально, пропустит нюансы или не заполнит вовсе. Опросник — инструмент уточнения, не сбора.
❌ Записывать всё дословно. Задача аналитика — не стенография, а интерпретация и структурирование. «Мне нужно, чтобы всё было быстро» — это не требование. «Время отклика страницы не более 2 секунд» — требование.
❌ Требовать точности с первой итерации. Первая версия требований всегда неполная. Это нормально. Ваша задача — сделать следующую итерацию лучше, а не добиться идеала за один сеанс.
❌ Фиксировать только то, что сказали. Люди часто не говорят о том, что кажется им очевидным. Задавайте уточняющие вопросы, проверяйте граничные случаи, не принимайте умолчания за согласие.
❌ Игнорировать конечных пользователей. Заказчик (спонсор проекта) и конечный пользователь — разные люди с разными интересами. Система, которая нравится руководителю, может быть неудобна для тех, кто работает с ней каждый день. Опрашивайте обоих.
Когда применять каждую технику
| Ситуация | Лучшая техника |
|---|---|
| Заказчик не может сформулировать задачу | Интервью с вопросами о проблемах, 5 Whys |
| Много стейкхолдеров с разными интересами | Воркшоп, карта стейкхолдеров |
| Сложный процесс, который трудно описать словами | Job Shadowing |
| Заказчик уверен, что знает решение | Прототипирование на бумаге |
| Нужно проверить полноту требований | Вопросы «А что если...» |
| Уже есть какая-то система или процесс | Анализ артефактов |
Итог
Хороший бизнес-аналитик — не тот, кто записывает то, что говорит заказчик. Это тот, кто помогает заказчику понять, чего он на самом деле хочет, — и переводит это на язык, понятный команде разработки.
Неумение формулировать требования — это не слабость заказчика. Это нормальная ситуация, с которой работает профессиональный аналитик. Чем богаче инструментарий техник элиситации — тем меньше итераций правок и тем выше вероятность, что система окажется именно такой, какой нужна бизнесу.
Техники элиситации подробно описаны в BABOK® Guide v3 (IIBA), глава 4: Elicitation and Collaboration. Для практического освоения рекомендую начать с интервью и Job Shadowing — они дают результат быстрее всего.