Практика

3.10 Контекстные сценарии взаимодействия

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

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

У нас есть основной персонаж Иван и два дополнительных персонажа: Люся и Евгений. Создадим контекстные сценарии взаимодействия Ивана с биллинговой системой. После чего расширим их за счет шаблонов использования системы дополнительными персонажами, учитывая, что они имеют меньшее значение при вынесения решений по проектированию.

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

Контекстные сценарии использования

  1. Иван становится клиентом компании «Сибирские Сети». При заключении договора в офисе компании (или сдаче приемке монтажных работ у Ивана дома) сотрудники провайдера сообщают ему о существовании биллинговой системы и ее преимуществах.
  2. При подключении Иван вносит свой первый платеж на свой счет в биллинговой системе. Если его подключение попадает под действие какой-либо промо-акции, он не вносит деньги на счет и пользуется определенный период времени услугами провайдера бесплатно.
  3. Провайдер выдает Ивану некий ключ доступа к системе. Иван может поделиться этим ключем со своей семьей или друзьями напрямую или опосредованно, разрешая им доступ к системе.
  4. Находясь дома, Иван знакомится с системой, получая от нее контекстную полезную помощь для новичков. В процессе знакомства система осуществляет собственную настройку для работы с Иваном самым удобным и предпочтительным для него образом.
  5. Система предлагает настроить автоматическое списание средств с любого стороннего счета Ивана за услуги провайдера. Иван указывает параметры своей зарплатной карты. Евгений разрешает системе доступ к своему интернет-кошельку в платежных системах Яндекс.Деньги и WebMoney. Люся ничего не указывает, поскольку предпочитает платить наличными.
  6. Проходит определенный период использования услуг и наступает момент, когда баланс счета Ивана начинает приближается к нулю.
  7. Первым делом система пытается самостоятельно сделать платеж, пытаясь списать средства с банковской карты Ивана. Эту операцию она совершает заблаговременно, рассчитывая, что для конца оплаченного периода остается не менее 3 дней.
  8. Списываемая сумма зависит от тарифного плана и равна ежемесячному платежу. Платеж проходит успешно, и система оповещает Ивана о переводе денег.
  9. У Евгения эта операция не завершается успехом, поскольку ни на одном из его электронных кошельков, проверенных системой последовательно, не оказывается достаточной суммы денег для списания. Система оповещает Евгения о невозможности совершить автоматический платеж и ожидает от него дальнейших действий.
  10. Евгений очень занят делами и не успевает вовремя внести деньги на счет в биллинговой системе, в следствии чего интернет у него отключается. Заметив отсутствие связи поздно вечером, Евгений решает совершить обещанный платеж, чтобы внести требуемую сумму на следующий день. Он заходит на страницу биллинговой системы и совершает обещанный платеж.
  11. На следующий день Евгений пополняет свой счет в одном из интернет-кошельков, снова заходит на страницу биллинговой системы и гасит задолженность. Система принимает платеж и сообщает экранным сообщением, что все прошло успешно.
  12. Когда баланс Люси подходит к критической границе, она получает уведомление о том, что скоро интернет может быть отключен. При этом она также сообщает ей, что мультикасса, через которую Люся привыкла вносить деньги, временно не работает.
  13. Люся обращается к системе за информацией о текущем состоянии счета и за помощью в поиске альтернативных путей оплаты. Система предлагает Люсе другую ближайшую мультикассу, которая точно работает. Люся узнает адрес и совершает внесение средств при помощи предложенной точки отплаты. Сразу же после проведения платежа система уведомляет Люсю, что ее он совершен успешно.
  14. Однажды летом Иван решает поехать в отпуск на целый месяц. Он обращается к биллинговой системе и указывает срок своего отсутствия. В указанный период система переходит в режим ожидания и не производит списание средств, а доступ к услугам провайдера блокируется.
  15. Иван возвращается немного раньше, чем планировал. Он вновь обращается к системе и переводит ее в нормальный режим функционирования.

***

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

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

Реклама
Стандартный

  1. 5. Нет возможности автоматически списывать деньги со сторонних счетов (Яндекс.деньги, Visa, MasterCard не позволяет)
    9. сказка)
    11. Кто он? Евгений, Иван, как-то не последовательно
    12. было бы прикольно посылать ссылку на 2гис, где будет отмечено место подключения и все точки где можно пополнить, чтобы легко понять куда идти платить ближе
    14. если 0 — блокировка автоматом, плюс в ручную можно заблокировать.

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

    2. Кончились бабки.
    Иван —
    Евгений —
    Люси —

    p.s. чот вспомнил про единую карту http://www.youtube.com/watch?v=AFyxfkQ72eI&feature=channel_video_title

    • 5. Разве это не возможно или не станет возможным уже в ближайшем будущем?
      11. Поправил.
      12. Люся получает рекомендацию по карте в следующем пункте (13).
      14. Смысл в том, что он может остановить работу системы, если уезжает в отпуск, а на счету есть еще достаточно денег и их не хочется терять просто так.

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

      Вопросы и варианты подключения не столь важны. Разделить сценарии на группы — была такая мысль. Но мне показалось, что это излишне 🙂

      Единая карта — добро при правильной реализации.

    • Полноценных программных интерфейсов может и нет.

      Но вот смотри, уже сейчас человек может указать параметры карты Visa и оплатить услуги в интернет-магазине или на сайте тех же Сибирских Сетей.

      Почему же нельзя попросить у человека его данные и за него при помощи этих данных проводить платежи, м?!

      А наличие простых API уже не за горами. Ведь это выгодно в первую очередь бизнесу.

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

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

    Светлое будущее всегда не за горами)

  3. Егор спасибо.

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

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

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

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

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

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

  4. Уведомление: 3.11 Функциональные требования и информационная архитектура « PEREDELKA

  5. Уведомление: 3.12 Дополнительные сценарии « PEREDELKA

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s