Не собираем пожелания, а вытаскиваем реальную работу пользователя

Когда использовать

Этот материал нужен, когда запрос уже звучит как готовое решение, но за ним еще не видна реальная работа:

• “добавьте поле”;
• “нужен новый отчет”;
• “сделайте интеграцию”;
• “автоматизируйте согласование”;
• “покажите статус”;
• “перенесите процесс в систему”.

Такие формулировки могут быть правильными. Но если начать с пожелания, команда легко пропустит настоящую проблему, скрытых участников, дорогие исключения и критерий полезного результата.

Задача аналитика и тимлида на старте - не собрать полный список хотелок. Задача

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

Главная проверка

Перед постановкой задачи спросите:

Что человек пытается сделать в реальной работе,
и что сегодня делает этот результат трудным, дорогим или рискованным?

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

1. Отделить запрос от работы

Запрос - это то, что человек просит. Работа - это то, что он пытается сделать.

После такого перевода обсуждение меняется. Команда спорит не о том, какое поле добавить, а о том, какая работа должна стать проще и как проверить результат.

2. Найти рабочий контекст

Хорошие требования появляются из контекста, а не из изолированного интервью.

Минимальный набор вопросов:

• кто выполняет работу;
• когда она начинается;
• что человек знает в этот момент;
• где он берет данные;
• что делает руками;
• кто ждет результат;
• что происходит, если он ошибается или задерживается;
• какое решение он принимает после результата.

Важно спрашивать не только “что вам нужно”, но и “что вы делаете до и после”. Иначе задача может оптимизировать один экран, но оставить весь рабочий процесс таким же дорогим.

3. Достать ограничение

За пожеланием почти всегда есть ограничение:

• не хватает времени;
• данные приходят поздно;
• система не показывает причину;
• внешний сервис отвечает нестабильно;
• другой отдел не видит контекст;
• оператор боится принять решение без подтверждения;
• поддержка не может объяснить пользователю, что происходит.

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

Слабый вопрос:

Какой отчет вам нужен?

Лучше:

Какое решение вы не можете принять без отчета?
Что вы делаете сейчас, когда отчета нет?
Что будет плохим результатом, если решение задержится?

4. Назвать скрытых участников

Пользователь редко работает один. В сценарии могут участвовать:

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

Если участника не назвать в начале, он появится позже: на приемке, в production, в ручной поддержке или в споре о том, кто должен был увидеть исключение.

Для каждого участника стоит спросить:

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

5. Проверить обходные пути

Обходной путь показывает настоящую цену проблемы.

Спросите:

• как задачу решают сейчас;
• где используют таблицы, чаты, ручные проверки или копирование данных;
• кто помогает, когда система не справляется;
• сколько шагов нужно пройти;
• где чаще всего ошибаются;
• что уже перестали делать, потому что слишком дорого.

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

6. Сформулировать problem statement

После discovery полезно записать не решение, а короткое описание проблемы.

Шаблон:

Кто:
Какую работу выполняет:
Что мешает сейчас:
К чему это приводит:
Какой результат должен стать возможным:
Что не решаем в первой версии:

Пример:

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

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

7. Выбрать следующий шаг

Не каждое discovery должно заканчиваться разработкой.

Возможные исходы:

Сильный результат discovery - это не длинный список требований. Это ясный следующий шаг и понимание, почему именно он сейчас полезен.

Шаблон discovery-разбора

Запрос:
Что человек просит.

Работа:
Что человек пытается сделать на самом деле.

Контекст:
Когда начинается работа:
Что уже известно:
Где берутся данные:
Кто ждет результат:

Ограничение:
Что мешает сейчас:
Какая ошибка или задержка дорога:

Участники:
Кто выполняет:
Кто принимает решение:
Кто поддерживает исключения:
Какие системы участвуют:

Текущий обходной путь:
Как решают сейчас:
Где ручной труд:
Где чаще всего ошибка:

Первый полезный результат:
Что должно стать возможным:
Что не входит в первую версию:
Как поймем, что стало лучше:

Следующий шаг:
Карта системы / цена проблемы / readiness / spike / решение / не делать.

Антипаттерны

Стоит остановиться, если:

• требования начинаются со списка полей без работы пользователя;
• пользователь говорит решение, а команда не спрашивает контекст;
• в задаче нет скрытых участников и исключений;
• обходной путь не разобран;
• полезный результат описан как “сделать экран”;
• все пожелания попадают в backlog без выбора;
• спор о приоритете идет без понимания цены проблемы;
• discovery заканчивается словами “в целом понятно”, но без следующего шага.

Хорошее discovery не делает задачу большой. Оно делает реальную работу видимой, чтобы команда не строила аккуратную функцию вокруг неверно понятого запроса.