«Нужна кнопка выгрузки» кажется понятным заданием. Но какую информацию человек собирается выгрузить, кому передать и что сделать дальше? Если не задать эти вопросы, можно получить работающую кнопку и неудобный процесс. В Гуси-Лебеди мы предлагаем начинать обсуждение отдельной функции с пользовательской истории: кто решает задачу, чего хочет добиться и зачем ему это нужно.
User story, или пользовательская история, кратко описывает желаемый результат с точки зрения человека, который будет пользоваться продуктом. Она задаёт тему для обсуждения команды. Детали поведения, ограничения и условия проверки добавляют после уточнения задачи. Само предложение ещё не доказывает, что потребность существует: для этого нужны наблюдения, обращения, интервью или другие основания.
Ниже разберём условный пример с обработкой обращений: от просьбы о новой функции до критериев приёмки. Это учебный пример, а не описание выполненного проекта или обещание результата.
Как находить потребность за запросом на функцию
Начните с ситуации, а не с элемента интерфейса. Когда менеджер просит выгрузку, выясните, что происходит до неё и после. Возможно, он каждый день вручную ищет обращения, на которые ещё никто не ответил. Возможно, он составляет отчёт руководителю. Это разные задачи, хотя просьба о кнопке звучит одинаково.
Спросите, какие данные человек использует сейчас, что мешает закончить работу и какой результат ему нужен. Ответ «хочу экономить время» стоит уточнить: на каком действии теряется время? Ответ «нужен удобный интерфейс» тоже не объясняет, что должно измениться. Полезнее увидеть нынешний процесс или разобрать конкретное обращение, чем сразу выбирать цвет кнопки.
В нашем примере остановимся на одной потребности: менеджеру нужно находить доступные ему обращения без зарегистрированного ответа, чтобы выбрать их для обработки. Мы пока не решаем, нужен ли отдельный экран, фильтр или выгрузка. Сначала согласуем, что именно считается необработанным обращением.
Отделяйте подтверждённые наблюдения от предположений. Если проблема возникла в интервью или обращении сотрудника, сохраните источник и контекст без лишних персональных данных. Если функцию предложила сама команда, обозначьте гипотезу и проверку, которая поможет принять решение. User story помогает описать потребность, но не подтверждает её одним своим существованием.
Где заканчивается история и начинается сценарий
User story отвечает на вопросы «кто, что хочет получить и зачем». Use case подробнее описывает взаимодействие с системой: исходные условия, шаги, альтернативы и исключения. Для фильтра обращений история фиксирует цель менеджера. Сценарий уточняет, как он включает фильтр, что видит при отсутствии данных и как возвращается к полному списку.
Оба описания могут понадобиться одной функции. При сложной логике не пытайтесь уместить все ветки в одно предложение. А общие правила доступа, интеграций и работы сайта связывайте с техническим заданием на разработку, чтобы разные истории не задавали противоречащие друг другу условия.
Как записывать историю понятным языком
У распространённого шаблона три части: «Как [роль], я хочу [результат или действие], чтобы [польза]». В руководстве Atlassian эту структуру связывают с пользователем, его потребностью и целью. Заполнение скобок помогает начать разговор, но не гарантирует хорошую историю. Если в конце написано «чтобы было удобнее», команда всё ещё может по-разному понимать задачу.
Для нашего примера формулировка такая: «Как менеджер по обращениям, я хочу видеть доступные мне обращения без ответа, чтобы выбрать их для обработки». Роль задаёт контекст, желание описывает результат, а последняя часть объясняет следующий шаг человека. Это не обещание роста продаж и не доказательство экономии времени.
| Слабая формулировка | Что стоит уточнить |
|---|---|
| Как пользователь, я хочу хороший личный кабинет | Какая роль и какое действие требуют изменения |
| Как менеджер, я хочу красную кнопку | Какую задачу должен решать элемент интерфейса |
| Как руководитель, я хочу все отчёты | Какие решения принимаются по отчёту и какие данные нужны |
Названия кнопок и экранов не запрещены. Они просто не должны подменять объяснение потребности. Если способ реализации уже задан согласованным ограничением, запишите его рядом с историей и объясните основание. Команда сможет отличить обязательное условие от первого предложенного варианта.
Проверка INVEST без формальной галочки
INVEST объединяет шесть признаков: Independent, Negotiable, Valuable, Estimable, Small, Testable. В практической проверке это означает: историю можно разумно отделить от других работ; способ реализации можно обсуждать; польза понятна; команда способна оценить объём; размер подходит для выбранного этапа; результат проверяем.
Не объявляйте историю независимой, если ей нужен ещё не созданный источник данных. Зафиксируйте зависимость. Возможность оценить работу и уже полученная оценка также различаются: если разработчики не понимают, как определяется ответ на обращение, сначала нужна проработка правила. И не считайте небольшой историю «переделать весь кабинет» только потому, что она записана коротко.
Большую потребность разделяйте по завершённым действиям пользователя. Например, поиск обращений без ответа и получение отчёта о работе отдела можно обсуждать отдельно. При этом «сделать таблицу базы данных» остаётся технической задачей реализации, а не самостоятельным пользовательским результатом. Связанные задачи нужны, но им не обязательно придавать вид user story.
Как добавлять критерии приёмки
История объясняет, зачем нужна функция. Критерии приёмки определяют, по каким наблюдаемым признакам команда и заказчик примут конкретный результат. «Менеджеру удобно работать» нельзя однозначно проверить. «В списке видны обращения, у которых нет зарегистрированного ответа» уже позволяет обсуждать проверку, но требует уточнить, где и как регистрируется ответ.
Для нашего условного примера сначала договоримся о правилах: менеджер видит только доступные ему обращения, а отвеченным считается обращение с зарегистрированным исходящим ответом. Это выбранные условия примера. В вашем процессе роль, доступ и понятие ответа могут быть другими.
Теперь можно записать сценарий: дано менеджер с доступом к двум обращениям, одно с ответом и одно без него; когда он включает фильтр «Без ответа»; тогда список содержит только второе обращение. Форма «дано, когда, тогда» помогает отделить исходные условия, действие и ожидаемый результат. Она полезна, но не обязательна для каждого критерия.
Проверьте и ситуации, в которых обычный путь не срабатывает:
- Если подходящих обращений нет, список показывает пустое состояние и позволяет снять фильтр.
- Обращение вне прав доступа менеджера не появляется в результатах.
- После зарегистрированного ответа и обновления списка обращение перестаёт попадать в выборку.
- Если данные не удалось получить, интерфейс сообщает об ошибке и предлагает повторить запрос, а не показывает ошибку как отсутствие обращений.
Это разные проверки, поэтому не стоит прятать их в одну фразу «фильтр работает корректно». Перед разработкой обсудите, где нужны дополнительные решения: например, когда список обновляется и что происходит при смене ответственного. Не назначайте произвольную скорость или срок хранения данных лишь ради измеримого числа. Значения должны следовать из требований проекта и быть согласованы.
Критерии конкретной истории также не заменяют общие правила качества команды. Проверка прав доступа, ревью изменений и необходимые проверки безопасности могут входить в Definition of Done. Успешный сценарий одной функции ещё не подтверждает соблюдение всех этих правил.
Как передавать историю в работу и проверять результат
Перед передачей соберите в одной карточке историю, контекст, согласованные критерии и ссылки на необходимые материалы. Отдельно отметьте открытые вопросы. Команда должна понимать, что уже решено, а что ещё требует обсуждения. Назначение исполнителя не устраняет неизвестную логику.
Автором первой формулировки может быть заказчик, аналитик или участник продуктовой команды. Затем историю обсуждают с теми, кто будет реализовывать и проверять изменение. Пользователь объясняет рабочую ситуацию, разработчик помогает выявить зависимости, проверяющий превращает ожидания в воспроизводимые сценарии. Состав участников зависит от проекта, а не от обязательного ритуала.
В нашем примере полезно заранее подготовить тестовые обращения: доступное без ответа, доступное с ответом и недоступное этому менеджеру. Тогда проверка опирается на известные условия. Если использовать случайные рабочие данные, будет трудно отличить ошибку фильтра от неожиданного статуса обращения.
При приёмке пройдите согласованные сценарии и сохраните результат проверки. Выполненный критерий функции и подтверждённая польза для работы пользователя также требуют разных оснований. Фильтр может правильно выбирать обращения, но менеджер всё ещё может не пользоваться им. После выпуска нужно выяснить, подходит ли решение реальному процессу, а не выводить это из отсутствия ошибок.
Изменившиеся требования не прячьте в переписке. Обновите карточку, обсудите влияние на объём и повторите затронутые проверки. В разработке и сопровождении сайта такой подход помогает связывать отдельные изменения с понятной задачей и условиями приёмки.
Хорошую историю узнают не по обязательному числу строк. По ней понятно, чью работу меняют, какой результат нужен и как проверить договорённость. Если эти ответы пока отсутствуют, следующий шаг команды состоит в уточнении задачи, а не в украшении формулировки.