Какие ошибки можно допустить в описании пользовательских сценариев и как их исправить

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

Многие даже выбирают альтернативные подходы: придерживаются концепции Jobs-To-Be-Done или предпочитают говорить не о пользовательских сценариях, а о создаваемом функционале. Причина этого часто кроется в разочаровании от плохо составленных сценариев.

В этом деле одинаково важно знать, как писать хорошо и как писать НЕ НАДО.

Сегодня многие команды разработчиков внедряют в работу принципы Agile. Они строят процесс разработки вокруг пользователя, что логично — для кого вы создаёте приложение, если не для пользователей, верно?

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

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

Слишком длинный сценарий

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

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

Длинный сценарий может выглядеть так:

“Как пользователь, я хочу вернуться к статье позже, по пути домой. При этом я не хочу регистрироваться и искать место, где остановился”.

Как можно заметить, в этом сценарии пользователь преследует две цели  — не регистрироваться и не искать место, где закончил чтение. Вместо того чтобы пытаться втиснуть всё в один сценарий, сделайте несколько.

Вот как он мог бы выглядеть после разделения:

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

“Как пользователь, я хочу продолжить чтение с места, где остановился, без необходимости искать это место самому”.

Слишком детализированный сценарий

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

Вот пример сценария, который детализирован настолько, что в нём описываются подробности реализации:

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

О какой бизнес-ценности качественной реляционной БД может идти речь, если конечный пользователь не может её использовать? Кроме того, этот сценарий написан с точки зрения бизнеса, а не пользователя. Когда вы включаете в сценарий детали реализации, он перестаёт быть ориентированным на пользователя.

Бескомпромиссный сценарий

Пользовательские сценарии не предполагают точного, строгого описания функционала, а значит могут изменяться.

Вот пример бескомпромиссного сценария: “Как пользователю, мне нужна кнопка “Очистить всё” на панели уведомлений, чтобы я мог удалить старые уведомления”.

Понятно, что пользователь хочет иметь возможность удалять старые уведомления. Решить эту задачу можно кнопкой “Очистить всё”, но можно ведь и автоматически удалять уведомления после того, как они прочитаны.

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

Сценарий совпадает с критериями приемлемости

Я часто замечаю, что пользовательские сценарии — это те же критерии приемлемости, только написанные другими словами.

Вот как это выглядит:

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

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

Критерии приемлемости должны определять условия, при которых пользовательский сценарий считается завершённым. Они предполагают, что вы собираете отклики, помогаете своей команде планировать работу и направляете её. Это обогащает, уточняет сценарий и упрощает его тестирование. Что ещё более важно — у всей команды появляется единое понимание конечной цели разработки.

Вот примеры получше:

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

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

Пользователь в сценарии не определён

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

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

Если вам нужен пример, то все те, что я приводил выше, отлично показывают, как делать не надо. Не переживайте — я сделал так специально, чтобы сейчас иметь возможность всё объяснить ????

Каждый раз, начиная пользовательский сценарий с фраз “Как пользователь”, “Как посетитель”, “Как читатель”, вы вносите неясность. Чёткое определение персоны пользователя способно дать вашей команде необходимый контекст.

Мы с нашими разработчиками рекомендуем вместо использования слов “пользователь/посетитель/читатель” описывать персону. Это значит, что ваш пользовательский сценарий будет выглядеть примерно так:

“Как автор, я хочу получать уведомления, когда другие оставляют комментарии в Google Docs, чтобы мне не приходилось постоянно обновлять страницу”.

У сценария недостаточный контекст

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

Например: “Я контент-менеджер, и мне нужен текстовый редактор, чтобы править текст”.

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

Иногда более осмысленное решение не приходит и после перерыва. Это вполне может означать, что вам нужно плотнее пообщаться с пользователями и лучше понять их потребности. Совершенно бессмысленно пытаться выжать ответ из себя.

Заключение

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

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

---

Перевод статьи Vikash Koushik: Mistakes Your Team Might Be Making When Writing User Stories — and How to Fix Them