keepsimple
dark
en | ru

#8. Пользовательские истории

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

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

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

Пользовательская История. Составление

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

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

Итак, предположим, что мы с вами – команда. Я новенький Владелец Продукта, а вы – опытный Бизнес Аналитик, с которым я советуюсь.

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

В один прекрасный день Я получаю запрос от нашего клиента:

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

Дедлайны ужасные. Это возмутительно и все такое, но что поделать, жизнь – боль.

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

3...2...1...

Окей, теперь у нас есть набросок дизайна, где издатели могут включить функцию ограничения доступа по странам, и вводить страны, которым разрешен вход. Я подхожу к вам и прошу высказать мнение. Вы с недоумением смотрите на мой набросок и спрашиваете «А почему не добавить возможность блокировки отдельно взятых стран? Ведь если речь идет об ограничении доступа, тогда же очевидно, что издатели гораздо чаще будут ограничивать доступ для нескольких стран, нежели открывать доступ для нескольких сотен – это же тупо!». Да, действительно, видимо я слишком долго думал о том как я люблю Грецию. Я беру еще немного времени на размышления, и добавляю в набросок возможность блокировки.

Возвращаюсь к вам, показываю обновленную версию, и объясняю, что теперь, издатель сможет выбирать один из двух пунктов – Allow, для разрешения, либо Deny – для блокировки, и что одновременно может быть активен только один из списков. Вы снова грустно смотрите на меня, и задаете вопрос «А мы действительно можем гарантировать, что никто из указанных стран не будет иметь доступ?», на что я отвечаю «Ну, как..мы используем IP адрес для ограничения доступа. Если пользователь использует VPN, или какие-нибудь технологии смены IP-адреса, тогда, очевидно, доступ он получить сможет», на что вы задаете весьма резонный вопрос «А может быть мы в рамках этой же функции, объясним это издателю, чтобы у него в будущем не возникало претензий, что кто-то таки смог добраться и прочесть их журнал, хоть он и уверен, что этот кто-то находится в списке заблокированных стран?».

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

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

И возвращаюсь к вам. Я подробно рассказываю, к каким я там выводам пришел и какую еще умную работу совершил, на что вы хвалите меня словами «Молодец, все правильно» и идете в сторону двери, попутно добавляя «Я бы, возможно, добавил описание к каждому из пунктов – Allow и Deny, чтобы в корне исключить вероятность какой-либо путаницы кем-либо, ты же понимаешь, у нашего клиента миллионы пользователей по всему миру, а люди разные..».

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

Итак, у меня есть дизайн и я знаю, что максимум, что может измениться – это цвет, тогда как по функционалу я вроде бы представляю, как все должно работать. Я сажусь за свое рабочее место, запускаю наш корпоративный инструмент управления проектом (Trello, JIRA, Asana, Basecamp, что угодно), и в колонке Бэклог Продукта, в сааамом низу, создаю новую Историю.

!!! Далее я буду писать историю так, как если бы писал ее на самом деле (Правда на русском я еще никогда историй не писал ☺))). Отдельные комментарии я буду начинать и заканчивать двумя косыми чертами «//»

Назовем Историю «Ограничение доступа по странам» и перейдем к контенту.

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

//как вариант, можно сразу же показать местоположение иконки отдельным изображением:

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

«я бы хотел видеть иконку глобуса (1), при....» с прикрепленным изображением:

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

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

Я хочу видеть кнопки «Разрешить» и «Запретить», с вопросительными знаками рядом с ними, при наведении на которых должны появиться соответствующие подсказки:

(Для «Разрешить»): Публикация будет доступна только для указанных стран

(Для «Запретить»): Публикация не будет доступна для указанных стран

Кнопка «Разрешить» должна быть активирована по-умолчанию.

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

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

Я хочу иметь возможность добавлять неограниченное кол-во стран в любой из списков, и удалять их из списка по клику на «Х» в названии страны, либо через клавишу Backspace при выбранном поле ввода.

Если я выбрал кнопку «Разрешить» и ввел названия стран, я хочу, чтобы система разрешила доступ к моему журналу только для тех пользователей, чей IP-адрес принадлежит к стране/странам указанным в списке разрешенных.

Если я выбрал кнопку «Запретить» и ввел названия стран, я хочу, чтобы система запретила доступ к моему журналу для тех пользователей, чей IP—адрес принадлежит к стране/странам указанным в списке запрещенных.

Я хочу, чтобы списки стран, которые я составил, были сохранены под кнопками так, чтобы при переключении между кнопками «Разрешить/Запретить» списки не стирались, и я мог продолжать их редактировать.

Под полем ввода я хочу видеть две подсказки системы:

  • *Для определения страны мы используем IP-адрес посетителя.
  • Пользователи по-прежнему могут получить доступ к этой публикации, если они получили его из страны, где публикация была доступна, либо специальным предложением по почте.

Как только я ввел нужные страны, я хочу иметь возможность сохранить настройки через кнопку «Сохранить настройки», либо, если я передумал, закрыть окно нажав на кнопку «Отменить».

Все.

Теперь, когда дизайнер утром придет на работу, он может прикрепить дизайн-файлы к нашей Истории, и она будет готова к разработке. Мы вроде-бы быстро закончили нашу Историю, и радостно побежали домой, спать. С утра, во время планирования работ на день, команда, в соответствии с пожеланием нашего клиента, в особом порядке возьмется за разработку этой истории, и вроде бы все хорошо, но здесь нужно небольшое лирическое отступление, чтобы понять, все ли в порядке с нашей Историей?

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

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

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

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

Вот такая вот, казалось бы, небольшая История стала большой проблемой из-за невнимательности Владельца Продукта.

Собственно, я показал (в некоторых местах, утрированно) процесс составления Истории, чтобы мы с вами лучше поняли следующие правила:

  • Правильный формат истории – это тот, который согласован с Командой. Это может быть повествование от первого лица, это может быть формат «текст – картинка», это может быть что-угодно, и единственно верным здесь является то, что устраивает всю команду, которая собирается с историей работать;
  • Правильная детализация истории - это та, которая согласована с Командой. По мере того, как команда все дольше и дольше работает над проектом, уровень детализации Истории снижается, потому-что множество вещей становится очевидным, однако, если команда новая, либо если в ней появился новенький, детализация вновь должна повышаться, чтобы избежать разночтений;
  • Правильный размер истории – это тот, который дает достаточно информации всем участникам команды, работающим с историей, чтобы не иметь неясных вопросов;

Пользовательская История. Состав

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

Для этого, у Владельца Продукта есть целый ряд инструментов, которые он смело может использовать в Истории (согласовав с Командой, конечно же):

  • Скриншоты
  • Скриншоты с заметками (типа тех, которые были выше в этой статье)
  • Скринкасты (видео)
  • Эскизы, Макеты, Дизайн файлы
  • Презентационные файлы (редко)

И вообще все что угодно.

У Владельца Продукта не должно быть какого-то «единственного стиля» составления Историй, так как в этом случае он будет недостаточно гибким. Если команде нужны скриншоты – PO их делает. Если команде нужны видео, или эскизы набросанные на стикерах – PO их составляет.

Нельзя брезговать ничем, даже таким:

Владельцу Продукта на заметку:

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

В завершение этой статьи, я хочу показать как вышеуказанная «История» была составлена мной в формате PRD (Product Requirements Documentation) в Joomag:

Теперь мы знаем, как выглядят и как составляются Истории, столь необходимые для имплементации проекта.

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