Ну вот, смотри, Саша Реушкин. Ты все ждал, когда это произойдет. Именно в этот момент мы переходим от исследований и анализа первичных данных к непосредственному проектированию и можем немного пофантазировать.
У нас уже есть персонажи, и есть их цели. Это дает нам картину их мира, и их потребностей. Потребности должны превратиться в требования к разрабатываемой системе при помощи идеальных сценариев взаимодействия персонажей. Причем, эти сценарии должны быть контекстными, т.е. учитывающими разнообразие окружения и условий работы.
У нас есть основной персонаж и два дополнительных персонажа: и . Создадим контекстные сценарии взаимодействия Ивана с биллинговой системой. После чего расширим их за счет шаблонов использования системы дополнительными персонажами, учитывая, что они имеют меньшее значение при вынесения решений по проектированию.
В результате небольшого мозгового штурма в несколько итераций получаем синтезированные, но унифицированные сценарии, в которых к тому же учтены приоритеты между персонажами.
Контекстные сценарии использования
- Иван становится клиентом компании «Сибирские Сети». При заключении договора в офисе компании (или сдаче приемке монтажных работ у Ивана дома) сотрудники провайдера сообщают ему о существовании биллинговой системы и ее преимуществах.
- При подключении Иван вносит свой первый платеж на свой счет в биллинговой системе. Если его подключение попадает под действие какой-либо промо-акции, он не вносит деньги на счет и пользуется определенный период времени услугами провайдера бесплатно.
- Провайдер выдает Ивану некий ключ доступа к системе. Иван может поделиться этим ключем со своей семьей или друзьями напрямую или опосредованно, разрешая им доступ к системе.
- Находясь дома, Иван знакомится с системой, получая от нее контекстную полезную помощь для новичков. В процессе знакомства система осуществляет собственную настройку для работы с Иваном самым удобным и предпочтительным для него образом.
- Система предлагает настроить автоматическое списание средств с любого стороннего счета Ивана за услуги провайдера. Иван указывает параметры своей зарплатной карты. Евгений разрешает системе доступ к своему интернет-кошельку в платежных системах Яндекс.Деньги и WebMoney. Люся ничего не указывает, поскольку предпочитает платить наличными.
- Проходит определенный период использования услуг и наступает момент, когда баланс счета Ивана начинает приближается к нулю.
- Первым делом система пытается самостоятельно сделать платеж, пытаясь списать средства с банковской карты Ивана. Эту операцию она совершает заблаговременно, рассчитывая, что для конца оплаченного периода остается не менее 3 дней.
- Списываемая сумма зависит от тарифного плана и равна ежемесячному платежу. Платеж проходит успешно, и система оповещает Ивана о переводе денег.
- У Евгения эта операция не завершается успехом, поскольку ни на одном из его электронных кошельков, проверенных системой последовательно, не оказывается достаточной суммы денег для списания. Система оповещает Евгения о невозможности совершить автоматический платеж и ожидает от него дальнейших действий.
- Евгений очень занят делами и не успевает вовремя внести деньги на счет в биллинговой системе, в следствии чего интернет у него отключается. Заметив отсутствие связи поздно вечером, Евгений решает совершить обещанный платеж, чтобы внести требуемую сумму на следующий день. Он заходит на страницу биллинговой системы и совершает обещанный платеж.
- На следующий день Евгений пополняет свой счет в одном из интернет-кошельков, снова заходит на страницу биллинговой системы и гасит задолженность. Система принимает платеж и сообщает экранным сообщением, что все прошло успешно.
- Когда баланс Люси подходит к критической границе, она получает уведомление о том, что скоро интернет может быть отключен. При этом она также сообщает ей, что мультикасса, через которую Люся привыкла вносить деньги, временно не работает.
- Люся обращается к системе за информацией о текущем состоянии счета и за помощью в поиске альтернативных путей оплаты. Система предлагает Люсе другую ближайшую мультикассу, которая точно работает. Люся узнает адрес и совершает внесение средств при помощи предложенной точки отплаты. Сразу же после проведения платежа система уведомляет Люсю, что ее он совершен успешно.
- Однажды летом Иван решает поехать в отпуск на целый месяц. Он обращается к биллинговой системе и указывает срок своего отсутствия. В указанный период система переходит в режим ожидания и не производит списание средств, а доступ к услугам провайдера блокируется.
- Иван возвращается немного раньше, чем планировал. Он вновь обращается к системе и переводит ее в нормальный режим функционирования.
Для каждой ситуации существуют свои правила участия в них и способы понимания действий партнера.
Сценарии – это стандартные последовательности действий в тех или иных привычных ситуациях. Большинство социальных действий, в которые мы вовлечены, имеют форму запланированных последовательностей, в которых все отрегулировано и предсказуемо – как в сценарии фильма. Вне зависимости от того, кто именно вовлечен в данную ситуацию, последовательность действий, которые всем следует совершать, и то, в какой момент это следует делать, хорошо известна. Например, сценарий социальной ситуации «на приеме у врача» предполагает жалобы больного, расспросы со стороны врача, процедуры, выполняемые медсестрой, выписывание врачом рецептов и устные рекомендации больному о действиях, способствующих выздоровлению. Сценарий ситуации «случайная встреча с приятелем» также предполагает определенную последовательность действий: удивление, расспросы, обсуждение нескольких тем, представляющих общий интерес, передача приветов, прощание.
Итак, сценарии как бы фиксируют модели опыта и потому выступают своеобразными гидами для поведения человека в разнообразных ситуациях. Если ситуация знакома, знание сценария помогает автоматически совершать последовательные действия. Если ситуация незнакома – отсутствие сценария затрудняет адекватное поведение. В межличностном взаимодействии знание типичных сценариев способствует взаимопониманию между участниками, и напротив, отсутствие таких сходных сценариев может привести к конфликту.
Взаимодействие является тем фундаментальным процессом, который скрепляет партнеров в диадную общность. Основные механизмы, обеспечивающие формирование межличностного пространства взаимодействия, – взаимопонимание, координация и согласование.
Основная функция взаимопонимания – формирование общего смыслового поля участников взаимодействия, позволяющего объединить интересы сторон, выработать сходное видение задач в данной конкретной ситуации. Для этого участники взаимодействия должны быть достаточно осведомлены друг о друге – о социальном статусе, ролевых позициях, групповой принадлежности, привычках, взглядах на мир, об отношении к тем или иным жизненным событиям. Способами достижения такого знания выступают уточнения, переспросы, повторы, перефразирования, обсуждения и споры по различным жизненным проблемам.
Координация – поиск таких средств общения, которые в наилучшей степени соответствуют намерениям и возможностям партнеров. Результатом координации является совместимость в действиях, согласованность в операциях.
Согласование – механизм взаимодействия, касающийся в основном мотивационно-потребностной стороны общения. Его результатом является относительное согласие в целях, смыслах, намерениях, что задает основной тон межличностным отношениям, определяет их эмоциональную окраску.
28. Социальный ритуал. Функции социальных ритуалов.
Социальный ритуал - исторически сложившаяся форма неинстинктивного, предсказуемого, социально санкционированного, упорядоченного символического поведения, в котором способ и порядок исполнения действий строго канонизированы и не поддаются рациональному объяснению в терминах средств и целей.
Именно посредством регулярных, повторяющихся, четко обозначенных, имеющих
устойчивую последовательность действий люди создают саму возможность совместного коллективного существования, прогнозируемости социальных событий, а следовательно, задают условия для социального выживания и безопасности.
Практически все исследователи выделяют следующие функции социальных ритуалов:
коммуникативная функция ;
функция мировоззренческая (формирование системы культурных символов);
функция социализации (социальное воспитание, трансляция опыта, социальных и трудовых навыков от поколения к поколению);
функция социального контроля ;
функция укрепления сплоченности группы ;
функция регулирования психической стабильности , создания уверенности в трудных и
кризисных ситуациях (в период кризиса следование ритуалам может снимать ощущение тревоги и неблагополучия, тем самым вызывая у людей положительные эмоции).
Приветствую всех, кому интересна тема юзабилити. Напомню, в своей предыдущей статье () я размышляла о том, какое поведение программ создает отрицательное впечатление у пользователей. Сегодня мы поговорим о том, как создавать системы, которые казались бы пользователю вежливыми и дружелюбными и вызывали бы желание использовать их в дальнейшем.
В этой статье мы перейдем к более конкретным темам и обсудим, во-первых, понятие «Проектирование взаимодействия», во-вторых, такие инструменты как пользовательские сценарии (user scenarios) и карты сценариев (scenario maps). Мы не будем спускаться еще на уровень ниже и говорить о таких вещах, как ментальные модели, метафоры и аффорданс, главным образом потому, что эти знания в меньшей степени касаются аналитиков. Но, тем не менее, для тех, кому хочется знать немного больше, могу посоветовать почитать Джефа Раскина и Инди Янг .
Проектирование взаимодействия
Итак, начнем с определения. Которое, вообще говоря, звучит достаточно туманно:
«Проектирование взаимодействия (Interaction Design, IxD) - область знаний, направленная на проектирование поведения продуктов и систем, с которыми пользователем осуществляется взаимодействие». Wikipedia
Трудно назвать это определение исчерпывающим и понятным. Так что попробуем разобраться, используя знания:
а) о смежных областях:
б) о результатах деятельности проектировщиков взаимодействия.
Для лучшего понимания места проектирования взаимодействия в контексте UX можно посмотреть на следующую диаграмму, из которой видны связи с такими областями знаний как информационная архитектура, проектирование интерфейса, юзабилити-инженерия, эргономика, человеко-компьютерное взаимодействие, промышленный дизайн и, в конечном итоге, проектирование опыта взаимодействия:
Несомненно, диаграмму рисовал кто-то, занимающий должность проектировщика взаимодействия:) (это видно по огромной области, уделенной под эту деятельность). Можно найти похожие диаграммы, центр которых будет точно также же занят, к примеру, информационной архитектурой. Правда, как обычно, где-то посередине: с одной стороны, разные компетенции очень часто пересекаются, и потому их «рвут на части», причисляя ту или иную деятельность к компетенциям то проектировщиков взаимодействия, то информационных архитекторов, то юзабилити-инженеров. С другой – в зависимости от специфики проекта действительно порой приходится уделять больше внимания той или иной составляющей. Для себя я определила проектирование взаимодействия как «сердце» UX. В основном потому, что все остальные области (информационная архитектура, визуальный дизайн, юзабилити инженерия) направлены на решение довольно узких задач (организация информации и проектирование навигации, подбор цветовых схем, шрифтов и других элементов дизайна, обеспечение эффективности, продуктивности и удовлетворенности пользователей), и, пожалуй, концентрируясь только на этих областях, спроектировать систему нельзя. А проектирование взаимодействия вполне способно покрыть весь процесс.
Лучше понять, что же такое проектирование взаимодействия, можно, взглянув на возможные артефакты этой деятельности (я умышленно описываю только самые близкие аналитикам варианты, разумеется, полный список намного больше):
- варианты использования;
- персоны и пользовательские сценарии;
- диаграммы деятельности;
- макеты, а особенно – прототипы систем.
Так как практически каждый первый аналитик очень хорошо представляет, что такое варианты использования, на них мы останавливаться не будем. А рассмотрим мы вместо этого такой артефакт как пользовательские сценарии.
Пользовательские сценарии
Одним из мощнейших инструментов проектирования взаимодействия являются пользовательские сценарии . Я начала использовать этот инструмент относительно недавно, ранее отдавая предпочтение описанию в виде Use Case-ов (Варианты использования или Прецеденты использования). Однако на текущий момент сценарии зарекомендовали себя исключительно положительно. Во-первых, в процессе разработки сценариев остается гораздо больше пространства для воображения и условий для придумывания уникальных решений и мощных фич (что только плюс, если вы не просто документируете будущую систему, а и пытаетесь учесть / улучшить опыт взаимодействия). Сам процесс построен так, что стимулирует творческую деятельность. Во-вторых, это не обезличенные сценарии, а взаимодействия, привязанные к реальным персонам. Персоны, напомню, иллюстрируют собой живых людей, с их мотивами, целями, задачами, опытом, эмоциями (см. ). А значит, процесс взаимодействия в результате получится естественным, а не искусственным и чуждым пользователю алгоритмом. Ну и в-третьих, как показала практика использования сценариев, этот инструмент вносит тот самый fun в процесс.
Тем, кто не проникся таким инструментом, как персоны, настоятельно советую посмотреть презентацию Санжара Кеттебекова «Новое лицо персоны. Аналитика поведения для дизайна», в которой рассказывается, как именно при помощи персон команда Санжара добилась повышения прибыли сайта Los Angeles Times (http://latimes.com/) вдвое.
Вот как выглядит профиль персоны (пример на английском с реального проекта; имена, пароли и явки изменены):
Сценарий – это в буквальном смысле сценарий, в котором в роли актеров выступают ваши персоны. В условиях ограниченного времени можно использовать только персоны (без сценариев), правда, в этом случае будет довольно трудно удерживать в памяти их особенности в каждый момент времени. Поэтому если время позволяет и есть желание попробовать что-то новое, стоит представить взаимодействие пользователя с вашей системой в виде сценария.
Для описания сценариев я использую следующий шаблон (его можно скачать по ссылке «шаблон описания сценариев»):
<Название сценария>
<Цели>
В этом разделе нужно определить, с одной стороны, чего пытается достичь пользователь, а с другой – как задачи пользователей вписываются в цели организации. Если вы провели всю предварительную работу (например, создали Vision & Scope документ и персоны), эти цели у вас уже где-то задокументированы. Остается только включить их сюда. Это позволяет заодно проконтролировать, что никакие цели не остались «за бортом» и вы учли интересы всех сторон (фактически – еще один вариант трассировки требований).
<Процесс>
Это самый главный раздел сценария. Здесь обычно по шагам расписывается, каким образом пользователь будет достигать своих целей. Если вы хотя бы раз описывали Use Case-ы, с описанием сценария у вас едва ли возникнут трудности. Если нет, то вам понадобится всего лишь чуть больше практики. Главное отличие в том, что в сценариях допустимы «лирические отступления»: любые детали о контексте использования системы, о мыслях и эмоциях пользователя, приветствуются.
<Входы и выходы>
В этом разделе описывается, какие материалы и какая информация нужна пользователю для того, чтобы успешно использовать интерфейс. Например, для приглашения своих друзей в какую-то систему пользователю может понадобиться список их электронных адресов (которые едва ли он помнит наизусть). Значит, можно подумать о том, как помочь ему с этим.
<Опыт>
Какие похожие вещи делал пользователь в прошлом? Как раньше организация обходилась без этого решения?
Как ни крути, большинство систем, которые мы создаем – не уникальны. Если бы было не так, в сети не нашлось бы двух сайтов, имеющих нечто общее. Если вы создаете платежную систему, подумайте, с какими платежными системами пользователь уже умеет работать. Если это мобильное приложение – вы уже в некотором роде ограничены предыдущим опытом пользователя: можно, конечно, придумать уникальные жесты, которых никто еще не встречал. Однако в этом случае обучаемость заметно снизится, что, в свою очередь, отрицательно скажется на юзабилити.
<Ограничения>
Какие физические, временные или финансовые ограничения проявят себя во время работы пользователя?
Зная о таких ограничениях, можно определить метрики, по которым в дальнейшем мы будем судить об успешности нашего решения. Например, если мы знаем, что у пользователя есть только 5 минут перед тем, как ему нужно будет убежать на совещание, мы можем проверить, реально ли выполнить задачу за 5 минут. Или другой пример, мы знаем, что нас персонаж будет в большинстве случаев использовать систему (мобильное приложение на смарт-фоне) в московском метро в часы пик. В таком случае мы знаем, что пользователь будет стеснен в движениях (ага, пассажиры вокруг) и ограничен в жестах (т.к. будет держать свой смарт-фон и пользоваться им одной рукой). Так давайте учтем и тоже проверим это.
<Физическое окружение>
Где находится пользователь? Что у него на столе? Как у пользователя обстоят дела с доступом к необходимой информации (например, пользовательским мануалам)? Что написано на стикерах, прикрепленных к его монитору?
<Используемые инструменты>
Что из железа и софта использует пользователь в своей работе? Эту информацию, как и многое другое, можно получить при изучении данных веб-аналитики.
<Отношения>
Каковы связи между этим пользователем и другими людьми, на которых влияет система? Задумайтесь о социальных последствиях вашего решения.
Созданный сценарий в результате выглядит примерно следующим образом:
После того, как такие сценарии составлены, проводится нечто вроде мозгового штурма. Шаги сценария выписываются на отдельные стикеры, затем каждый шаг обсуждается командой. В процессе обсуждения выясняется следующее:
1) Какие вопросы , в том числе – технические, вызывает шаг?
Сценарий, как легко догадаться, основное понятие сценарной теории Э. Берна, получает у него множество определений.
Сценарий - постепенно развертывающийся жизненный план, который формируется еще в раннем детстве в основном под влиянием родителей, а позже дорабатывается ребенком под иными внешними влияниями. Каждый сценарий базируется на ограниченном количестве тем, большинство которых можно найти в греческой драме и мифологии. Сценарию всегда противостоит подлинная личность, живущая в реальном мире.
Берн предлагает даже формулу сценария: РРВ - Пр - Сл - ВП - Итог, то есть Раннее Родительское Влияние - Программа - склонность Следовать программе - Важнейшие Поступки (брак, воспитание детей, развод и др.) - Итог (предполагаемые сцена собственной смерти и надпись на могильной плите).
Американский психолог вовсе не хочет сказать, что вся наша жизнь строго детерминирована родительской программой или сценарием. Сценарная теория утверждает, что в определенные критические моменты человек следует сценарным указаниям; в остальное же время он идет туда, куда его влечет, и делает то, что диктует его воображение.
В зависимости от степени влияния программы, Берн обозначает три типа судьбы: сценарный, насильственный и независимый. А также, соответственно, три типа личности:
1) руководимая сценарием;
2) одержимая сценарием (как правило, роковым, с трагическим итогом);
3) о полностью «несценарном» типе личности говорить не приходится, да формирование такой личности и не является целью, к которой нужно стремиться. Поведение же будет не сценарным, если результат его можно изменить и сложилось оно не под влиянием родителей.
Критерий степени влияния родительской программы на судьбу человека не единственный в типологии личности, насколько в теории Берна можно вычленить типологию. Само качество этого явления становится вторым критерием и дает два основных типа : Принцев/Принцесс (Победителей) и Лягушек (Неудачников).
Победитель - человек, преуспевающий (с его точки зрения) в том деле, которое он намерен сделать. Неудачник - тот, кто не в состоянии осуществить намеченное.
Неудачник, как правило, жертва прошлой активности Сумасшедшего Ребенка его воспитателя. Победитель - продукт «хорошего сценария», благожелательные предписания которого носят адаптивный, а не запрещающий характер, сценария, снабженного многими «разрешениями».
Чем больше у человека разрешений (от родителей), тем меньше он связан сценарием. Эти разрешения не надо путать со вседозволенностью. Важнейшими среди них Берн называет разрешения быть красивым, любить, изменяться, успешно справляться со своими задачами.
По Берну, наиболее важные решения, определяющие отношение к жизни, принимаются в первые два-три года, а большая часть сценариев усваивается до шести лет. Основными детерминантами сценариев индивида являются Детские состояния Я его родителей, которые внедряются в сознание ребенка посредством запретов. В то время как некоторые запреты выражаются достаточно четко, например «Нельзя плакать на глазах у всех» или «Нельзя бить тех, кто меньше тебя», другие могут лишь подразумеваться. Например, ребенку, которого распекают за откровенные проявления чувств, вполне может быть внушено «не чувствуй». Сценарии, в свою очередь, усиливают влияние внушенных запретов. Таким образом круг замыкается. Выбранный сценарий жизни должен, разумеется, соответствовать жизненной позиции.
Вторым по значению источником сценариев являются сообщения, исходящие от Родительских состояний Я родителей или воспитателей. Эти сообщения, называемые также предписаниями (контрзапретами) или директивами (драйверами), также ограничивают свободу роста и развития личности. Можно привести перечень наиболее распространенных директив: «будь совершенным», «будь сильным», «торопись», «упорно пытайся» и «радуй других». Эти сообщения в социальном отношении приемлемы, но по сути деструктивны, поскольку подразумевают, что дети хороши, только если следуют родительским указаниям. Но коль скоро никто не совершенен и не обладает абсолютной силой, быстротой, способностью добиваться успеха или радовать родителей, директивы способствуют формированию жизненных сценариев неудачников.
По Берну, сценарий проявляется в движениях, жестах, позах, манерах человека. Берн считал, что важную роль в создании жизненных сценариев играют и запомнившиеся с детства фантазии и сказки. Характер сценария зависит и от культурной среды, из которой происходит данный человек.
На первой стадии своего развития малыш вообще имеет дело с «магическими» людьми. Даже герои телерекламы излучают на него волшебный свет. Родители же являются ребенку гигантскими фигурами, вроде мифологических титанов, что позволяет Берну говорить о сценарии как о родительском «колдовстве» или «заклятии».
Магическое детское восприятие и обеспечивает трепетную чувствительность ребенка к программе. Оно вообще является основой существования человечества, если под этим подразумевать преемственность культурной традиции.
Третий критерий в типологии Э. Берна - иллюзорная установка в отношении судьбы, определяемая сценарием. По этому основанию люди делятся на две категории:
1) ждущих Санта Клауса (и собирающих поэтому подарки судьбы);
2) ждущих Смерти с косой (как избавительницу от постоянных ударов судьбы).
Первая иллюзия предпочтительней, но утрата обеих бывает чрезвычайно болезненной.
Четвертый критерий - социальные установки личности. Он связан с разделением людей на Принцев и Лягушек. Тип социальной установки, диктуемый сценарием, Берн называет позицией-местоимением и связывает также с установкой личности в отношении судьбы.
Первое, что люди чувствуют друг в друге, - это их позиции. В западных странах, считает Берн, одежда свидетельствует о позиции своего хозяина значительно ярче, чем о его социальном положении. Люди со сходными установками, как правило, стремятся вступить в контакт друг с другом.
Обозначив Принца (Победителя) знаком «+», а Лягушку (Неудачника) знаком «-», Бёрн выводит формулы четырех базовых позиций:
1) Я«+» Ты«+» (ориентация на успешный итог сценария);
2) Я«+» Ты«-» (установка превосходства);
3) Я«-» Ты«+» (депрессивная установка);
4) Я«-» Ты«-» (безнадежность, предполагающая самоубийство, психиатрическую лечебницу и т. п. в итоге сценария).
Путем включения в формулу местоимения «они» и прилагательных-антонимов количество позиций может быть увеличено «до количества людей в мире», как заявляет создатель типологии, обозначая тем самым известную ее условность (свойственную и всякой типологии).
Э. Берна интересует не строгость классификации, а возможность «внесения поправок» в сценарий, в частности, возможность достижения устойчивого изменения социальной установки. Что же касается частых и непродолжительных перемен позиций, то они - признак нестабильной, тревожной психики, возможно, признак «сценарного сбоя».
Направить изменения в нужную сторону терапевту помогает анализ «сценарного аппарата», т.е. анализ элементов неудачного сценария.
Антисценарий - заложенный в ходе программирования способ освобождения от сценария. Он может быть ориентирован на событие (определять продолжительность сценарного диктата до рождения третьего ребенка, допустим) или на время («после 70 лет можно забыть о чувстве долга и делать, что хочется»).
Дети стремятся быть такими, какими им хочется, не проявляя при этом непослушания. Хитрость воспитывают и поощряют сами родители: это часть родительского программирования. Иногда результатом может стать выработка антисценария, в связи с чем ребенок сам меняет смысл сценария на противоположный, оставаясь в то же время послушным изначальным сценарным указаниям.
Как видим, следование антисценарию все же не есть освобождение от родительской программы. Даже «бунт» может предполагаться сценарием, а действительно независимые попытки эмансипации привести не к замене программы, а всего лишь к глубокой депрессии как следствию «проваленного» (невыполненного, но и ничем не замещенного) сценария.
Определяя задачи сценарного анализа, Берн ставит основную его цель: помочь любому обратившемуся за консультацией человеку стать свободным в осуществлении своих намерений, пересилить родительское программирование и страх перед наказанием за непослушание (речь идет, разумеется, о «плохой» программе).
На пути к истокам сценария своего клиента аналитик не должен пренебрегать мелочами. Большой удачей можно считать обнаружение самой формулы родительского «заклятья», самого «заклинания». Ведь, как правило, оно складывается из повседневных указаний, которым родители и не думали придавать столь «судьбоносного», как нынче стали говорить, значения.
По мнению Берна, социализация малыша пойдет совсем разными путями в зависимости от того, что говорили ему родители во время приема гостей: «Не открывай рот, пока тебя не спрашивают!» или «Представься гостям и расскажи им стишок!» (смысл: «не высовывайся!» или «покажи, на что ты способен!»).
На сценарий может оказать также влияние то, что человек узнает об обстоятельствах собственного зачатия и рождения, имя, которым его нарекли, и фамилия, доставшаяся от предков как благословение или проклятие.
Истоки многих жизненных сценариев можно проследить, вглядываясь в события жизни прародителей, считает Берн. Семейные предания наравне с национальной и всемирной мифологией определяют характер социализации индивида. Если К.Г. Юнг усматривал в этом архетипическую природу, близкую генетической программе, то Э. Берн видит исключительно социальное влияние.
Во-первых, что такое сценарий использования? Сценарий использования – это связный рассказ о поведении системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Кто-то или что-то может быть пользователем системы, это может быть какая-то информационная система или устройство. И этот кто-то или что-то называется Действующим лицом (ДЛ). А сам сценарий использования представляет собой последовательность шагов, которые описывают действия ДЛ и реакцию системы на них.
Например, сценарий регистрации на каком-нибудь сайте может выглядеть вот так:
Но въедливый читатель может справедливо возразить, что в разработку такой сценарий отдавать нельзя. И он будет прав! Мы ведь сейчас посмотрели на систему с высоты, наверно, 5-этажного дома, когда общее поведение уже понятно, но детальных требований ещё нет. Поэтому сценарий использования должен быть, как минимум, дополнен альтернативными потоками выполнения (то что представлено выше, называется основной поток и описывает действия системы, когда все идет как надо). Альтернативные потоки – это потоки, в которых описывается реакция системы на ошибочные действия пользователя или исключительные ситуации, либо же случаи альтернативных действий пользователя, если он захотел, например, зарегистрироваться с помощью аккаунта в социальной сети. Также документ со сценарием использования можно дополнить деталями пользовательского интерфейса, правилами валидации данных, различными бизнес-правилами и сообщениями об ошибках. А вот нефункциональные требования обычно описываются в отдельном документе, так как они обычно применимы ко всей системе целиком, а не к конкретным СИ.
Если же подняться ещё выше и посмотреть на систему с большей «высоты», то она будет выглядеть как набор услуг, предоставляемых системой пользователю (сценарии использования также можно рассматривать как высокоуровневые требования к системе). Тут мы приходим к тому, что неплохо бы было визуализировать эти требования, и для этого отлично подходит соответствующая диаграмма UML: диаграмма сценариев использования. Кусочек диаграммы показан ниже. Она состоит из действующих лиц, сценариев использования и различных связей между ними.
Для разработчиков и тестировщиков она, на первый взгляд, несет ещё меньше пользы, чем сами сценарии использования. Но ведь и предназначена она для другого!
Диаграмма СИ рисуется обычно аналитиком в самом начале проекта для того, чтобы широкими мазками охватить весь планируемый функционал проекта и согласовать его с заказчиком. И после этого каждый СИ уже детализируется с помощью шагов и детальных требований. СИ помогают смотреть на систему с точки зрения предоставляемых системой услуг и не закапываться в частности.
Я обычно использую диаграмму СИ для решения следующих задач:
- Оценка трудоемкости проекта;
- Планирование графика работ;
- Выявление пропущенных требований;
- «Оглавление» для проектных документов.
Оценка трудоемкости проекта
Как показывает опыт и практика, оценка получается тем точнее, чем детальнее выделен список предстоящих работ. Ведь действительно, задачу «написать статью» оценить гораздо сложнее, чем задачу «найти 5 картинок для иллюстраций». Так вот, сценарии использования являются первой итерацией разбивки системы на отдельные элементы. Более того, эти элементы обладают хорошей связностью (в данном случае – функциональная) и могут быть оценены отдельно друг от друга. Если этого недостаточно, то уже каждый СИ можно декомпозировать на основной/альтернативные потоки или даже задачи, которые необходимо выполнить программисту для реализации отдельного сценария.Здесь довольно часто также проявляется возможность повторного использования ранее созданных артефактов. Например, если для системы требуется функционал регистрации пользователей, то плюс/минус он будет работать одинаково во многих системах, что при оценке сразу же снижает степень неопределенности.
Даже существует специальный способ оценки, основанный на СИ – Use Case Points . В этом случае выделяются действующие лица и сценарии, у них по определенным правилам определяется сложность, задаются некоторые поправочные коэффициенты, учитывающие профессионализм команды и сложность предметной области, и на выходе появляется готовая оценка. То есть, к оценке, в идеале, даже не надо привлекать разработчиков и тестировщиков.
Планирование графика работ
В проектах с фиксированном бюджетом обычно явно выделяются последовательные стадии проектирования, разработки и тестирования (как в водопадной модели). Но в реальности тестирование уже частично начинается даже до завершения стадии проектирования, так как тестировщики подключатся к ревью разработанных требований и начинают писать тест-дизайн. И если для аналитика и, скажем, архитектора, составить график работ не составляет большого труда, так как активности этих ролей начинаются вместе со стартом проекта, то определить, когда и на какую задачу стоит подключать тестировщиков с разработчиками, уже становится сложнее. Действительно, ведь входными данными для них являются подготовленные и согласованные документы с требованиями. И для решения этой проблемы опять хорошо подходят СИ. Так как каждый сценарий содержит в себе завершенное описание какого-то процесса, то их проще согласовывать с заказчиками и, соответственно, можно довольно точно установить в план-графике ключевые точки согласования документов требований. А уже от этих точек планировать работу остальной команды.Выявление пропущенных требований
Не удивительно, что когда заказчик каким-то образом озвучивает требования к будущей системе, то он в своем описании сконцентрирован именно на полезном функционале и никак не упоминает, например, функции настройки системы или функции управления учетными записями пользователей, хотя без них система не будет полноценно работать. Очень часто после получения таких требований команда начинает выполнять оценку. У меня на практике были случаи, когда команда сразу бросалась в бой и оценивала то, что описал заказчик, оставляя за бортом неозвученные, но, тем не менее, обязательные функции системы.Также бывает и другая ситуация, когда в описании системы присутствуют требования о том, что в процессе работы пользователи должны создавать какие-то сущности. В подавляющем большинстве случаев, к таким сущностям применимы все CRUD (Create, Read (или также встречается расшифровка Retrieve), Update, Delete) операции, про которые тоже иногда забывают. В чем же здесь польза модели СИ? А как раз в графическом представлении требований. Когда глаз охватывает всю картинку, то гораздо проще заметить недостающие элементы, чем когда требования сформулированы обычным текстом.
Очень часто заказчик просит вместе с системой передавать комплект проектной документации. У себя в компании мы пишем проектную документацию в виде сценариев использования. Если же заказчик требует документы по ГОСТу, то все равно сперва пишутся сценарии использования, а затем уже на их основе формируются ГОСТовские документы.
У нас используется, как минимум, два подхода к документированию: когда каждый СИ описывается в отдельном документе, и когда в одном документе описываются сразу несколько СИ, относящихся к одной подсистеме. Часто тот или иной подход определяется, исходя из принятого процесса или привычек заказчика.
Выше уже было сказано, что первая версия списка сценариев использования уже формируется на этапе оценки и планирования графика работ. В дальнейшем этот список может дополняться и корректироваться, но уже с определенной степенью точности можно договариваться с заказчиком о том, какие именно документы будет предоставлять проектная команда.