Как выявлять требования

В прошлых статьях мы выяснили, какие бывают требования и кто в них заинтересован. Теперь нужно понять, откуда их брать. Выявление требований (elicitation) - это сбор информации об изменении из разных источников: у людей, из документов, из данных и из самой системы.

Кейс: как сегодня отменяют заказы

В магазине «Узелок» владелец хочет, чтобы покупатели сами отменяли заказы. Цель понятна: разгрузить поддержку. Но команда не знает, как отмена устроена сейчас.

Команда записала пять вопросов:

как поддержка принимает отмену сегодня;
до какого статуса склад может остановить сборку;
как оформляется возврат денег;
как часто заказы отменяют и на каком статусе;
как оператор меняет статус в админке.

Владелец знает цель, но не знает деталей склада. Поэтому одним разговором с владельцем здесь не обойтись. Для примера будем считать, что у «Узелка» есть выгрузка заказов со статусами и журнал обращений в поддержку.

Откуда брать сведения

Сведения о текущей работе и желаемом результате можно взять из пяти источников. Каждый показывает свою сторону.

Рисунок 1. Вопрос о текущей отмене заказа и пять источников, где искать ответ

Источник	Что даёт	Чего не даёт	Пример в кейсе
Интервью	Правила, причины, пожелания и исключения со слов людей	Того, что люди делают по привычке и не замечают	Оператор поддержки рассказывает, что делает при просьбе об отмене
Документы	Официальные правила, регламенты, договоры	Того, как правила работают на деле	Правила возврата и условия платёжного сервиса
Наблюдение	Реальный порядок действий, обходные приёмы, паузы	Причин и намерений	Звонок об отмене слушают рядом с оператором
Данные	Частоту, объём, распределение по статусам	Причин и смысла цифр	Выгрузка заказов: на каком статусе отменяют чаще всего
Существующая система	Что система умеет и запрещает сегодня	Того, что нужно изменить	Как оператор меняет статус заказа в админке

Каждый источник отвечает на свой вопрос. Ни один не закрывает все пять вопросов кейса сам.

Как выбрать источник под вопрос

Удобно начинать не с источника, а с вопроса и спрашивать, чего именно нам не хватает.

Если нужно узнать намерение или причину, идём к людям: интервью.
Если нужно узнать официальное правило, идём в документы.
Если нужно узнать, как работа делается на самом деле, смотрим и слушаем: наблюдение.
Если нужно узнать, как часто что-то происходит, берём данные.
Если нужно узнать, что система делает сегодня, открываем систему.

Типичная ошибка: опереться на один источник. Допустим, мы прочитали правила возврата и решили, что отмена возможна до отправки. А выгрузка заказов показывает, что склад на деле останавливает сборку только до статуса «Собирается». Расхождение между документом и практикой нужно выяснить с теми, кто работает с заказами, до того как оно попадёт в требования.

Рисунок 2. Правила возврата и выгрузка заказов расходятся, расхождение выясняют до записи требований

Как это делается по шагам

Выявление идёт по кругу: список вопросов, выбор источника, сбор, подтверждение и список остатка.

Рисунок 3. Пять шагов выявления требований, замкнутые в цикл

Назвать неизвестное. Записать вопросы, на которые пока нет ответа.
Выбрать источник для каждого вопроса.
Собрать сведения: провести интервью, прочитать документ, понаблюдать, посмотреть выгрузку.
Подтвердить. Записанное сверить с тем, у кого узнали, и с другими источниками.
Отметить остаток. Записать, что осталось неясным, и вернуться к шагу 1.

Подтверждение стоит отдельным шагом не случайно. Это проверка собранной информации на точность и согласованность с другими сведениями. Без него в требования попадают чужие предположения.

Короткий пример интервью

Вопрос задаём открыто, чтобы не подсказывать ответ.

Вопрос команды: «Что вы делаете, когда покупатель просит отменить заказ?»
Ответ поддержки: «Смотрю статус. Если заказ ещё не собран, пишу на склад и жду ответа. Деньги возвращаю только после подтверждения склада».
Что записываем: проверка статуса заказа, запрос на склад, ожидание подтверждения, возврат после подтверждения.
Что остаётся неясным: сколько склад обычно отвечает и что происходит, если ответа нет. Это идёт в список остатка.

Рисунок 4. Пример интервью с поддержкой: вопрос, ответ, записи и остаток

Как вести интервью и воркшопы целиком, разберём в статье 02-05, а логику самих вопросов в статье 02-04.

Где это встречается в работе

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

Итог

Выявление требований - это сбор информации из нескольких источников, а не один разговор.
Источников пять: интервью, документы, наблюдение, данные и существующая система.
Источник выбирают под вопрос: намерение, правило, практика, частота или поведение системы.
Собранное подтверждают у источника и сверяют с другими сведениями.
Нерешённое записывают как остаток и возвращаются к нему на следующем круге.

Что дальше

02-04 Уточняющие вопросы: как превратить расплывчатую задачу в список вопросов.
02-05 Интервью и воркшопы: как подготовить и провести разговор.
02-07 Как разобраться в существующей системе: как знакомиться с системой, которой мы не знаем.
08-03 Протокол встречи: как фиксировать итоги встреч и согласовывать их.