Бизнес сценарий что это

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

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

NOTE

Материал находится в процессе корректировки!

Содержание

26.1. Введение

26.2. Полезность бизнес-сценариев

26.3. Создание бизнес-сценария

26.3.1. Полный процесс

26.3.2. Сбор

26.3.3. Анализ

26.3.4. Обзор

26.4. Содержание бизнес-сценария

26.5. Вклады в бизнес-сценарии

26.6. Бизнес-сценарии и TOGAF ADM

26.7. Рекомендации по разработке бизнес-сценариев

26.7.1. Общие рекомендации

26.7.2. Вопросы, требующие ответов для каждой области

26.8. Рекомендации по документированию бизнес-сценария

26.8.1. Текстовая документация

26.8.2. Модели бизнес-сценариев

26.9. Рекомендации для целей и стремлений

26.9.1. Важность целей

26.9.2. Важность SMART(умных) стремлений (Objectives)

26.9.3. Категории целей (Goals) и стремлений (Objectives)

26.10. Резюме

26.1. Введение

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

Бизнес-сценарии – это важная техника, которая может использоваться на
различных стадиях работы над Корпоративной Архитектурой, преимущественно в фазах
Архитектурное Видение и Бизнес-Архитектура, а также, если требуется, и в других
фазах чтобы определить характеристики архитектуры исходя непосредственно из высокоуровневых требований бизнеса.
Эти техники используются, чтобы помочь выявить и понять потребности бизнеса и, таким образом, получить из
них бизнес-требования на которые наравлена разработка архитектуры.

Бизнес-сценарий описывает:

  • Бизнес-процесс, приложение или набор приложений, которые допускаются
    архитектурой

  • Бизнес-среду и технологии

  • Людей и вычислительные компоненты (называемые «акторами»),
    которые являются участниками сценария (выполняют его)

  • Желаемый результат надлежащего исполнения

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

Хороший бизнес-сценарий также отвечает характеристикам «SMART». Он:

  • Конкретный (Specific), определяющий потребности, которые должны
    быть реализованы в бизнесе

  • Измеримый (Measurable), определяющий ясные показатели успеха

  • Достижимый (Actionable):

    • Ясно сегментирует проблему

    • Обеспечивает фундамент для определения элементов и планирования
      решения

  • Реалистичный (Realistic), в котором проблема может быть решена в
    границах физической реализуемости, времени и финансовых ограниченний

  • Ограниченный во времени (Time-bound), который ясно
    формулирует когда истекает возможность для реализации решения

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

26.2. Полезность бизнес-сценариев

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

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

  • Неясна важность решения бизнес-проблемы.

  • Неясна значимость потенциальных решений.

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

Дополнительная полезность бизнес-сценариев лежит в области связи с
поставщиками. Многие архитектуры в настоящее время реализуются с
максимальным использованием готовых программных решений, имеющихся в
продаже (COTS), часто от разных продавцов, ведущих свою деятельность на открытом рынке.
Использование бизнес-сценариев от клиента может быть важным подспорьем
IT-поставщикам в поставке соответствующих потребностям решений. Продавцы должны
гарантировать, что компоненты их решения добавляют ценность к открытым
решениям и являются рыночными. Бизнес-сценарии обеспечивают язык, с
помощью которого продавцы могут связывать проблемы клиента и технические
решения. Помимо создания очевидно необходимого «что и почему», они
позволяют продавцам решать проблемы оптимально, используя открытые
стандарты и усиливая навыки друг друга.

26.3. Создание бизнес-сценария

26.3.1. Полный процесс

Создание бизнес-сценария включает следующие действия, как
проиллюстрировано на рисунке 26-1:

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

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

  3. Идентификация и документирование стремлений (желаемых результатов
    успешного решения проблем); достижение «SMART»

  4. Идентификация субъектов-людей (участников) и их места в
    бизнес-модели

  5. Идентификация субъектов-компьютеризированных систем (вычислительных элементов) и их
    места в технологической модели

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

  7. Проверка соответствия цели и уточнение (только в случае
    необходимости)

Рисунок 26‑1. Создание бизнес-сценария

Обычно, бизнес-сценарий разрабатывается итеративно в фазах
сбора, анализа и фиксации информации в сценарии.

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

Три фазы разработки бизнес-сценария представлены на рисунке 26-2 и
описаны подробно ниже.

Рисунок 26‑2. Фазы разработки бизнес-сценария

26.3.2. Сбор

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

В этой фазе могут использоваться множество техник, такие, как
исследование информации, качественный анализ, количественный анализ,
опросы, запросы информации и т.д. До любых очных семинаров (см. ниже)
должно быть собрано и предварительно обработано «офлайн» как можно
большее количество информации. Например, запрос на предоставление информации может
включать запрос имеющихся стратегических и операционных планов. Такие
документы обычно предоставляют хорошие возможности проникновения в суть,
но информация, которую они содержат, требует существенной
предварительной обработки. Информация может использоваться для генерации
предварительного рабочего документа бизнес-сценария до семинара, если
возможно. Это увеличит понимание и уверенность архитектора и ценность
семинара для всех его участников.

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

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

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

26.3.3. Анализ

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

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

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

  • Заинтересованные лица

  • Субъекты-люди

  • Субъекты-компьютеризированные системы

  • Проблемы

  • Стремления

Таким образом, бизнес-процесс становится центральным узлом, имеющим
большое значение, так как в большинстве случаев целью является улучшение
бизнес-процесса.

26.3.4. Обзор

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

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

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

26.4. Содержание бизнес-сценария

Документация бизнес-сценария должна содержать все важные подробности о
сценарии. Она должна фиксировать последовательности критических шагов и
взаимодействий между субъектами в зависимости от ситуации. Она должна
декларировать всю необходимую информацию обо всех субъектах, в
частности: ответственности субъектов; ключевые предварительные условия,
которые должны быть обеспечены до выполнения системных функциональных
возможностей; технические требования к сервисам для обеспечения
приемлемого качества.

Есть два основных типа информационного наполнения: графика (модели) и
текстовое описание.

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

  • Текстовое описание бизнес-сценария фиксирует детали в текстовой форме.
    Типичное содержание бизнес-сценария представлено ниже.

СОДЕРЖАНИЕ
ПРЕДИСЛОВИЕ
ОСНОВНЫЕ ПОЛОЖЕНИЯ ДЛЯ РУКОВОДСТВА
ДОРОЖНАЯ КАРТА ДОКУМЕНТА
БИЗНЕС-СЦЕНАРИЙ
ОБЗОР БИЗНЕС-СЦЕНАРИЯ
ПРЕДПОСЫЛКИ СЦЕНАРИЯ
НАЗНАЧЕНИЕ СЦЕНАРИЯ
ОПРЕДЕЛЕНИЯ/ОПИСАНИЯ ИСПОЛЬЗУЕМЫХ ТЕРМИНОВ
ПРЕДСТАВЛЕНИЯ СРЕДЫ И ПРОЦЕССОВ
ДЕЛОВАЯ СРЕДА
Клиентура
ОПИСАНИЯ ПРОЦЕССОВ
Процесс «a»
и т.д.
ТЕХНИЧЕСКАЯ СРЕДА
Техническая среда «a»
и т.д.
АКТОРЫ, ИХ РОЛИ И ОТВЕТСТВЕННОСТИ
АКТОРЫ-КОМПЬЮТЕРИЗОВАННЫЕ СИСТЕМЫ И ИХ РОЛИ
СВЯЗЬ КОМПОНЕНТОВ И ПРОЦЕССОВ
АКТОРЫ-ЛЮДИ И ИХ РОЛИ
СВЯЗЬ ЛЮДЕЙ И ПРОЦЕССОВ
АНАЛИЗ ИНФОРМАЦИОННОГО ПОТОКА
ПРИНЦИПЫ И ОГРАНИЧЕНИЯ
Принципы IT
Ограничения
ТРЕБОВАНИЯ
АНАЛИЗ БИЗНЕС-СЦЕНАРИЯ
СВОДКА ПРОБЛЕМ
Проблемы (Issues)
Стремления (Objectives)
РЕЗЮМЕ
ПРИЛОЖЕНИЯ
ПРИЛОЖЕНИЕ A: БИЗНЕС-СЦЕНАРИИ – ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ
ПРИЛОЖЕНИЕ B-n: ЗАМЕТКИ C СЕМИНАРА ПО БИЗНЕС-СЦЕНАРИЮ

26.5. Вклады в бизнес-сценарий

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

Как правило, вовлеченность руководства от бизнеса является самой активной на
ранних стадиях, когда исследуются и фиксируются бизнес-проблемы, а
вовлеченность архитектора увеличивается в более поздних стадиях, когда
описываются архитектурные решения. Точно так же, если поставщики
вовлечены в процесс создания бизнес-сценария, вовлеченность стороны
клиента (управление бизнесом плюс корпоративные архитекторы) является
самой большой в ранних стадиях, в то время как участие поставщиков
возрастает в более поздних стадиях, когда исследуется и фиксируется роль
определенных технических решений. Эти утверждения проиллюстрированы на
рисунке 26-3.

Рисунок 26‑3. Относительные вклады в бизнес-сценарий

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

26.6. Бизнес-сценарии и TOGAF ADM

Наиболее заметно бизнес-сценарии фигурируют в начальной фазе Метода
Разработки Архитектуры (Architecture Development Method / ADM), фазе Архитектурного Видения, когда они
используются для определения соответствующих бизнес-требований и
выстраивании согласованности с руководством от бизнеса и другими заинтересованными
сторонами.

Однако, бизнес-требования используются во всех фазах цикла ADM, как это
показано на рисунке 26-4.

Рисунок 26‑4. Значимость требований во всех фазах ADM

Поскольку бизнес-требования важны во всех фазах цикла ADM, у техники
бизнес-сценариев есть важная роль в TOGAF ADM: гарантировать, что
бизнес-требования укомплектованы и корректны.

26.7. Рекомендации по разработке бизнес-сценариев

26.7.1. Общие рекомендации

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

  • Выделите время, понаблюдайте и запишите как они работают сегодня

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

  • Выясните критические бизнес-правила у специалистов по проблемной
    области

  • Сосредоточьтесь на том, какие потребности должны быть реализованы и
    как это должно быть достигнуто

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

26.7.2. Вопросы, требующие ответов для каждой области

Семинары и встречи по сбору информации о бизнес-сценарии (см. п. 26.3.2.
Сбор) призваны структурировать ее в соответствующих представлениях.
Естественно, не может существовать стандартного, пригодного для всех
ситуаций набора вопросов, ответы на которые заведомо удовлетворят
потребности разработчика сценария. Ниже представлены ряд рекомендаций,
которые могут помочь консультантам бизнес-сценария в формулировании
вопросов.

Идентификация, документирование и ранжирование проблем

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

Если проблема слишком специфична или задает вопрос «как»:

  • Поднимите красный флаг

  • Задайте вопрос: «Почему Вы должны следовать этим путем?»

Если проблема слишком неопределенна или неприменима на практике:

  • Поднимите красный флаг

  • Задайте вопрос: «Что Вы получите или будете в состоянии
    делать, если эта проблема будет решена?»

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

  • Где Вы испытываете эту специфическую проблему? В каком
    бизнес-процессе?

  • Когда Вы сталкиваетесь с этой проблемой? В начала процесса, в
    середине или в конце?

Задайте вопросы, которые помогают идентифицировать затраты на решение проблемы:

  • Вы оценивали затраты, связанные с этой проблемой? Если оценивали,
    каковы они?

  • Имеет ли проблема скрытые затраты? Если да, каковы они?

  • Покрывают ли затраты на решение этой проблемы какие-то другие затраты? Если да,
    что и сколько?

  • Связаны ли проблема с низким качеством или неэффективностью в организации?

Идентификация бизнес- и технологической среды

Вопросы, касающиеся бизнес-среды:

  • Какие ключевые процессы страдают от проблем? Какие главные шаги
    должны быть предприняты?

  • Расположение/масштаб внутренних департаментов бизнеса?

  • Расположение/масштаб внешних бизнес-партнеров?

  • Какие определенные бизнес-правила и регулирующие положения имеют
    отношение к ситуации?

Вопросы, касающиеся текущей технологической среды:

  • Какие технологические компоненты уже предусмотрены для разрешения
    этой проблемы?

  • Есть ли какие-либо технологические ограничения?

  • Применяются ли какие-либо технологические принципы?

Идентификация и документирование стремлений

В достаточной ли мере каждое утверждение »что» поддерживается разъяснением
»почему»? Если нет, попросите измеримое объяснение в следующих
областях:

  • Возврат от инвестиций

  • Масштабируемость

  • Потребности в производительности

  • Соответствие стандартам

  • Простые в использовании метрики

Идентификация акторов-людей и их места в бизнес-модели

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

  • Пользователь компьютера с компьютером

  • Пользователь телефона с телефоном

  • Расчетчик зарплаты с системой расчета зарплаты

  • Подписчик интернета с веб-браузером

Актор представляет роль, которую играет пользователь; пользователь –
это кто-то играющий роль при использовании системы (например, Джон
(пользователь) является диспетчером (актор)). Каждый актор использует
систему по-разному (иначе, они должны быть тем же самым актором).
Спросите о людях, которые будут включены в процессы, с различных точек
зрения, таких как:

  • Разработчик

  • Ремонтник

  • Оператор

  • Администратор

  • Пользователь

Идентификация компьютерных акторов и их места в технологической модели

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

Документирование ролей, ответственностей, метрик успеха, необходимых сценариев

При определении роли, задайте такие вопросы:

  • Какие основные задачи актора?

  • Должен ли актор читать/писать/изменить информацию?

  • Должен ли актор сообщать системе о внешних изменениях?

  • Хочет ли актор быть информированным о неожиданных изменениях?

Проверка пригодности для назначения и совершенствование в случае необходимости

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

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

26.8. Рекомендации по документированию бизнес-сценария

26.8.1. Текстовая документация

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

В приложениях:

  • Подробно зафиксируйте все важные данные о бизнес-сценарии:

    • Описание и объяснение ситуации

    • Все измерения

    • Все роли акторов и вложенные измерения

    • Все необходимые сервисы

  • Зафиксируйте критические шаги между акторами, которые разрешают
    ситуацию, и упорядочите взаимодействия

  • Представьте релевантную информацию обо всех акторах:

    • Разделение ответственности среди акторов

    • Список предусловий, которые должны быть выполнены до надлежащего
      функционирования системы

    • Технические требования для сервиса должны иметь приемлемое
      качество

В основной части бизнес-сценария:

  • Обобщите все соответствующие данные, детально представленные в
    приложениях

26.8.2. Модели бизнес-сценариев

  • Нужно помнить цель использования модели:

    • Зафиксировать представления бизнеса и технологии в графической
      форме

    • Помочь в понимании

    • Дать отправную точку для подтверждения требования

    • Связать акторов и взаимодействия

  • Диаграммы должны быть ясными и чёткими:

    • Нельзя помещать слишком много на одну диаграмму

    • Более простые диаграммы проще понять

  • Число диаграмм для простой навигации:

    • Поддерживайте каталог диаграмм, чтобы избежать дублирования

26.9. Рекомендации для целей и стремлений

26.9.1. Важность целей

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

Каждая организация ведет себя по-разному в этом отношении. Некоторые
рассматривают IT как движущую силу для развития предприятия. Другие,
видят IT только в роли поддержки, просто автоматизирующим
бизнес-процессы, которые уже существуют. Существенно то, что
архитектурные стремления должны быть очень тесно связаны с
бизнес-целями и стремлениями организации.

26.9.2. Важность SMART (умных) стремлений

Мало того, что цели должны быть заявлены в общих чертах. К ним должны
быть присоединены определенные меры, чтобы сделать их SMART, как показано выше.

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

Перечисленные ниже цели были адаптированы относительно предыдущих версий
TOGAF. Они сгруппированы в категории целей, каждая со списком возможных
целей. Каждая из этих целей должна быть определена как SMART с
наборами мер и метрик для задачи. Однако, так как каждая фактическая
работа будет специфичной для конкретного проекта архитектуры, невозможно
обеспечить список универсальных «SMART» стремлений, которые будут
касаться любого проекта.

Вместо этого, мы представляем здесь некоторый пример стремлений SMART.

Пример создания «SMART» стремлений

Под общей целью, озаглавленной «Повысить производительность
пользователей» есть стремление обеспечить «Непротиворечивый
пользовательский интерфейс», и это стремление описано следующим
образом:

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

Чтобы сделать это стремление «SMART», мы должны ответить на вопросы,
является ли это стремление определенным, измеримым, понятным,
реалистичным и ограниченным во времени, и затем переформулировать
стремление, если потребуется.

Далее зафиксирован анализ этих критериев для заданного стремления:

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

  • Измеримое: Как указано выше, стремление является измеримым, но
    могло бы быть более конкретным. Второе предложение может быть
    исправлено, например: «Это приведет к увеличению
    пользовательской эффективности на 10 % и уменьшению пользовательских
    ошибок ввода заказов на 20 %, что, в свою очередь, приведет к
    снижению затрат на ввод и корректировки на 5 %.»

  • Понятное: Стремление действительно кажется понятным. Ясно, что
    должна быть предоставлена последовательность пользовательских экранов,
    и это требование может быть обработано тем, кто отвечает
    за поставку пользовательского интерфейса на устройства.

  • Реалистичное: Стремление обеспечить «непротиворечивый
    пользовательский интерфейс гарантирует, что все доступные для
    пользователя функции и сервисы будут появляться и вести себя
    схожим и предсказуемым образом независимо от приложения или сайта»
    не может быть реалистичным. Появление у сотрудников мобильных устройств
    может поставить вопрос о расширении области действия формулировки стремления на эти
    устройства и об обвинении разработчиков основного направления в
    незаконном отсутствии соответствующего решения, а также в препятствовании
    использованию новых технологий. Формулировку стремления можно еще
    раз уточнить: «непротиворечивый пользовательский интерфейс через
    устройства пользовательского ввода, которые обеспечивают
    подобные функциональные возможности и гарантируют…» и т.д.

  • Ограниченное во времени: Стремление, как оно сформулировано, не
    ограничено во времени. Чтобы оно стало ограниченным во времени, в
    стремлении можно указать: «К концу 3-го квартала обеспечить
    непротиворечивый…».

Итоговое SMART стремление больше походит на следующее (помните, что
это всего-лишь пример):

«К концу 3-го квартала обеспечить непротиворечивый пользовательский
интерфейс через устройства пользовательского ввода, обеспечивающие
подобные функциональные возможности, который гарантирует всем
пользователям, использующим эти устройства, что все доступные для
пользователя функции и сервисы будут появляться и вести себя подобным,
предсказуемым образом независимо от приложения или сайта. Это приведет к
увеличению пользовательской эффективности на 10 % и уменьшению
пользовательских ошибок ввода заказов на 20 %, что, в свою очередь,
приведет к снижению затрат на ввод на 5 %.»

26.9.3. Категории целей и стремлений

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

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

Цель: Улучшить производительность бизнес-процесса

Улучшение бизнес-процесса может быть достигнуто через реализацию
следующих стремлений:

  • Увеличенная производительность процесса

  • Непротиворечивое качество результата

  • Предсказуемые производственные издержки

  • Увеличенное повторное использование существующих процессов

  • Сокращенное время передающей бизнес-информации от одного процесса до
    другого процесса

Цель: Уменьшить затраты

Улучшение затрат может быть достигнуто через реализацию следующих
стремлений:

  • Более низкие уровни избыточности и дублирования активов всюду по
    предприятию

  • Уменьшенная зависимость от внешних поставщиков услуг IT по
    интеграции и настройке

  • Более низкие затраты на обслуживание

Цель: Улучшить бизнес-операции

  • Улучшение бизнес-операций может быть достигнуто через реализацию
    следующих стремлений:

  • Увеличенный бюджет, доступный для новых бизнес-функций

  • Уменьшенные затраты на ведение бизнеса

  • Уменьшенное время выхода на рынок для продуктов или услуг

  • Улучшенное качество услуг клиентам

  • Улучшенное качество бизнес-информации

Цель: Улучшить эффективность управления

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

  • Увеличенная гибкость бизнеса

  • Более короткое время на принятие решений

  • Более высокое качество решений

Цель: Снизить риски

Снижение рисков может быть достигнуто через реализацию следующих
стремлений:

  • Простота реализации новых процессов

  • Уменьшенные ошибки ввода в бизнес-процессы через сложные и
    неисправные системы

  • Уменьшенная реальная угроза безопасности (включая опасности,
    вызывающие потерю жизни)

Цель: Улучшить эффективность организации IT

Улучшение эффективности IT-организации может быть достигнуто через
реализацию следующих стремлений:

  • Увеличенный выпуск новых проектов

  • Уменьшенное время для выпуска новых проектов

  • Уменьшенные затраты на выпуск новых проектов

  • Уменьшенное время прерывания обслуживания при выпуске новых проектов

  • Общая разработка: приложения, характерные для нескольких сфер
    бизнеса, будут разработаны или приобретены однажды и многократно
    использованы, а не разработаны отдельно каждой сферой бизнеса.

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

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

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

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

Цель: Увеличить производительность пользователей

Увеличение производительности пользователей может быть достигнуто через
реализацию следующих стремлений:

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

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

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

Цель: Улучшить мобильность и масштабируемость

Улучшение мобильности и масштабируемости приложений может быть
достигнуто через реализацию следующих стремлений:

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

  • Масштабируемость: приложения, которые соответствуют модели, будут
    конфигурируемы, обеспечивая работу на полном спектре требуемых
    платформ.

Цель: Улучшить функциональную совместимость

Улучшение функциональной совместимости может быть достигнуто через
реализацию следующих стремлений:

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

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

Цель: Увеличить независимость от поставщика

Увеличение независимости от поставщика может быть достигнуто через
реализацию следующих стремлений:

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

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

Цель: Сократить затраты жизненного цикла

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

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

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

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

  • Сокращенные затраты на обучение: общие системы и непротиворечивые
    человеческо-машинные интерфейсы (Human Computer Interfaces –
    HCI) обеспечивают сокращение затрат на обучение.

Цель: Улучшить защищенность

Защищенность информации в организации может быть улучшена через
реализацию следующих стремлений:

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

  • Непротиворечивая защита пользовательских интерфейсов: стандартный
    пользовательский интерфейс со средствами защиты приведет к сокращению
    времени обучения при переходе от одной системы к другой.

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

  • 25%-ое сокращение запросов в службу поддержки, касающихся вопросов
    безопасности.

  • 20%-ое сокращение «ложных положительных сигналов», обнаруженных в
    сети (ложный положительный сигнал является событием, которое
    проявляется как событие информационной безопасности, но фактически является ложным).

Цель: Улучшить управляемость

Улучшение управления может быть достигнуто через реализацию следующих
стремлений:

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

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

26.10. Резюме

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

Успех любого значительного IT-проекта измеряется степенью, в которой он
взаимоувязан с бизнес-требованиями, поддерживает и дает возможность
предприятию достигать своих бизнес-целей. Бизнес-сценарии – это важная
техника, которая может использоваться на различных стадиях описания
Корпоративной Архитектуры или любого другого важного IT-проекта для
получения характеристик архитектуры непосредственно из высокоуровневых
требований бизнеса. Бизнес-сценарии используются, чтобы помочь
выявить и понять бизнес-потребности и, таким образом, определить
бизнес-требования к разработке архитектуры, и, в конечном счете, к IT.

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

Источник

Фото: Надежда Бужан, probusiness.io

Фото: Надежда Бужан, probusiness.io

Конец года — самое время, чтобы определить путь на несколько лет вперед. На конференции Capital Day основатель и управляющий партнер КГ «Здесь и Сейчас» Александр Паньков представил пошаговую инструкцию по сценарному подходу к стратегическому планированию. Использовав его, ваша компания получит как минимум 3 сценария на будущее. Действуйте!

Стратегия, по мнению Александра Панькова и КГ «Здесь и Сейчас», — это эффективный способ достижения поставленных целей, который отличает компанию в умах потребителя от ряда других компаний, удовлетворяющих те же потребности, и ведущий к безусловному выбору данной компании ее целевыми клиентами.

— Стратегия — это игра в будущее, но все равно что-нибудь неожиданное «прилетит». А вот насколько может «прилететь» и насколько можно подготовиться, зависит от вас.

Стратегическое планирование делится на 2 вида — моноподход (разработка одного базового сценария) и сценарный подход, где сценариев множество, на практике — от 2 до 5. Наиболее популярный вариант сценарного подхода — «3 в одном», то есть разработка пессимистического, базового и оптимистического сценариев. Для этого я предпочитаю выработать стратегию, а потом сформировать 2−3 внешних сценария и проверить, насколько стратегия к ним устойчива.

О сценарном подходе и расскажу подробнее.

Этапы сценарного подхода

Нажмите, чтобы увеличить

Слайд из презентации Александра Панькова

Слайд из презентации Александра Панькова

Этап 1. Определение влияющих факторов — «Что оказывает влияние на мой бизнес?». Вы должны выбрать и проранжировать факторы, которые могут серьезно (!) на вас повлиять.

Пример. Мы работали с компанией со штатом 25 человек, которая хотела увеличить количество сотрудников в два раза. Собственник посчитал, что определяющий влияющий фактор в этом вопросе — демографическая яма, из-за чего он не сможет найти достаточно специалистов. Но какая демографическая яма может быть при 50 будущих сотрудниках?! Или сеть булочных, которая говорит: «Что будет, если Трамп с Китаем не договорится?» Хана вашим булочным, перестанут люди батоны есть. Ведь это же смешно. Этап 2. Формирование сценариев — «Как будет развиваться ситуация?». Вы должны хорошо понимать отраслевые, потребительские, страновые тренды и смотреть, что может повлиять в лучшую или худшую сторону.

Пример. В пессимистическом сценарии одной компании из небольшого белорусского города — выход крупного конкурента на рынок этого города в 2020 году. Компания посчитала, что это будет означать для нее минус 40% в выручке и минус 55% в прибыли от текущего года, то есть попадание на грань выживания. При этом возможно, что этот крупный игрок на их рынок и не выйдет — но ведь это реальная угроза, а не «Трамп и Китай».

Фото: Надежда Бужан, probusiness.io

Фото: Надежда Бужан, probusiness.io

Этап 3. Оценка реалистичности сценариев — «Насколько в зависимости от стечения обстоятельств будут различаться мои действия?». Чтобы здесь не оказалось прилета инопланетян, вы должны оценить вероятности трех сценариев, выявить безальтернативные элементы и проработать, что будете делать, если плохой сценарий вас «догонит». Один из руководителей мне говорил: «Ничего страшного, если нас догонит пессимистический сценарий, мы там разберемся». Не разберетесь! В стрессе вы будете принимать неправильные решения, потому что время будет идти на минуты.

Помните анекдот про три конверта? Приходит молодой сотрудник в компанию, его встречает руководитель и дает три конверта: «Если совсем плохо будет, открывай по одному». Проходит три месяца, потихоньку начинают прилетать проблемы. Он вскрывает первый конверт: «Вали все на меня. Твой предшественник». Спустя время вскрывает второй: «Признай ошибки». И вот третья волна, он вскрывает третий, а там: «Готовь три конверта».

Фото: Надежда Бужан, probusiness.io

Фото: Надежда Бужан, probusiness.io

Этап 4. Разработка плана действий — «Что делать в случае наступления различных сценариев?». По большому счету, это и есть «три конверта». Составляем стратегический фокус, позиционирование, бизнес-модель, план стратегических инициатив — и варианты их реализации для разных сценариев, а также маркеры для мониторинга и оценки сценариев — чтобы понять, когда к ним нужно обращаться.

Стратегия может быть устойчива во всех трех вариантах.

Ключевые ошибки сценарного подхода

1. Нереалистичные сценарии (пример про демографическую яму).

2. Смотрим цифры и не видим трендов.

3. Отсутствуют маркеры для мониторинга ситуации, оценки сценария, перехода от одного сценария к другому (нет точки принятия решения).

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

5. Отсутствует аналитика. Приведу очень простой пример. Недавно один руководитель мне говорит: «Я бы хотел лучше управлять будущим, собирать информацию». Я ему отвечаю: «Структуру компании открой, пожалуйста, и пальчиком покажи, где у тебя сбор аналитики? Кто в твоей компании за это отвечает?» Про какие сценарии мы можем говорить, если в компании нет механизма сбора информации?

6. Нет компетенций по определению влияющих на сценарии развития факторов.

7. Нет плана перехода от одного сценария к другому. Вы должны понимать, где точка невозврата.

Фото: Надежда Бужан, probusiness.io

Фото: Надежда Бужан, probusiness.io

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

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

Как обнаружить, что вы действуете не по стратегии

Разработанная стратегия — всего лишь 20% успеха, а 80% — это ее реализация. Часто руководитель говорит: «У меня не работает стратегия», и выясняется, что у них «текучка, новые указы, изменения…» Уже через год принятая стратегия устаревает, и ее можно выбросить.

Фото: Надежда Бужан, probusiness.io

Фото: Надежда Бужан, probusiness.io

Что делать? Наш подход — механизмы обнаружения отклонений.

1. Организационные:

  • Стратегический комитет — раз в месяц на 4−5 часов. Это собрание топ-менеджеров и приглашенных сотрудников. Берем план стратегических инициатив, и каждый отчитывается, что сделано. К этому дню маркетологи, которые следят за маркерами, готовят отчет.
  • Квартальные сессии — раз в 3 месяца. Однодневные сессии, куда маркетологи приносят действия конкурентов и, снова, ключевые маркеры.
  • Полугодовые срезы (на два дня). Смотрим все изменения за полгода. В моей практике бывают ситуации, когда некоторые топ-менеджеры до 6-го месяца не добегают, потому что кроме «оперативки» ничего не делают. Вы должны это четко и отслеживать, и мотивировать.

2. Матрица (список) рисков.

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

4. Аналитика по рынку. Классическая ошибка — объединять функции маркетолога-продвиженца с функциями аналитика. Это два разных человека! Кстати, найти аналитика очень просто: берете сотрудника с математическим образованием и отправляете на курс маркетинга. Этого будет достаточно, чтобы через год у вас был классный, сильный аналитик.

5. План перехода стратегии от сценария к сценарию (правило трех конвертов).

Если что-то пошло не так

1. Прогон через бизнес-модель. Напомню, что бизнес-модель в рамках стратегии — это то, как мы получаем прибыль (портрет ключевого клиента, конкурентные преимущества, ключевые точки контакта с клиентом, партнеры). Это приведет либо к корректировке стратегии, либо к полной ее смене.

2. Пересмотр стратегического плана — «вскрываем конверт», то есть тут же обращаемся к альтернативным сценариям.

3. Пересмотр метрик аналитики.

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

Выводы

1. Стратегию нужно постоянно адаптировать к реалиям рынка, если они серьезно меняются. Если изменения незначительные, достаточно «отшлифовать» бизнес-модель и не отклоняться от стратегии.

2. Необходимо создавать стратегию, устойчивую к различным сценариям. Я всегда с удивлением смотрю на людей, которые говорят, что в Беларуси невозможно вести бизнес из-за жуткой неопределенности. Но более определенной страны я не знаю! 25 лет спокойствия, все управляемо. И то, что мы с вами потеряли в 2007, 2011, 2014 годах — наша вина, мы плохо анализировали события.

3. Если изменения кардинально меняют вашу бизнес-модель, не бойтесь. Смело меняйте стратегию.

Читайте также

  • Как получить кредит на бизнес — очень простые советы финансиста

  • 2+2+1. Простой инструмент для изучения конкурентов

Источник

Image via Shutterstock.

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

На собеседовании порой можно услышать следующее определение «Это такая UML-диаграмма с человечками и овалами». Давайте разберемся, что это такое, и рассмотрим несколько простых примеров.

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

Мне нравится определение из книги Коберна (советую, ее, кстати, всем аналитикам): «Вариант использования фиксирует соглашение между участниками системы о ее поведении. Вариант использования описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях».

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

Текст vs диаграмма/схема

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

  • Такой формат более понятен заказчикам (а они тоже предпочитают читать и согласовывать варианты использования).
  • Текст проще и быстрее отредактировать, чем диаграммы и текст.

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

Кому и в каких случаях нужны сценарии

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

— Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.

— Тестировщику. Почти готовый тест-кейс :-)

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

А также другим участникам процесса.

В каких случаях они нужны:

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

— Для поддержки системы. Чтоб выявить ошибку, разобраться, на каком шаге что пошло не так.

— Если вам нужно описать какую-то часть функциональности, работы пользователя с интерфейсом, etc. в виде сценария. Тогда вы можете взять шаблон юзкейса за основу и использовать его для описания сценария. Например, основу требований к вашему мобильному приложению составляет описание пользовательского интерфейса. Но выполнение некоторых функций имеет много нюансов, которые нужно дополнительно описать при помощи таблички: «действие — отклик системы», или даже совместить такую табличку со сценарием.

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Действующие лица Администратор, Система
Цель Изменить статус учетной записи пользователя на «активный».
Предусловие Учетная запись пользователя не активна.

Успешный сценарий:

  1. Администратор выбирает пользователя и активирует «Разблокировать».
  2. Система переключает учетную запись пользователя в статус «активный», и посылает сообщение (тут можно сослаться на текст сообщения из списка сообщений, см. примечание ниже) пользователю на email (если «User Account → email» не пусто).
Результат Учетная запись пользователя была переведена в статус «активный».

Пример 2. Авторизация пользователя:

Действующие лица Пользователь, Система
Цели Пользователь: авторизоваться в системе и начать работать;
Система: идентифицировать пользователя и его права.

Успешный сценарий:

  1. Пользователь запускает систему. Система открывает сессию пользователя, предлагает ввести логин и пароль.
  2. Пользователь вводит логин и пароль.
  3. Система проверяет логин и пароль.
  4. Система создает запись в истории авторизаций (IP адрес пользователя, логин, дата, рабочая станция).
  5. Система выдает пользователю сообщение по поводу успешной авторизации (ссылка на сообщение).
Результат Пользователь успешно авторизирован и может работать с системой.
Расширения:
*а Нет доступа к БД.
Система выдает сообщение (ссылка на сообщение).
Результат: пользователь не может войти.
1а В настройках безопасности для данного IP адреса существует запрет на вход в систему.
Результат: форма логина не предоставляется, система выдает сообщение пользователю (ссылка на сообщение).
2а Пользователь выбирает: «Напомнить пароль».
Вызывается сценарий «Напомнить пароль».
3а Пользователь с введенными логином и паролем не найден.
Результат: отказ в авторизации.
Система выдает сообщение (ссылка на сообщение).
Переход на шаг 2.
3б Количество неудачных попыток авторизоваться достигло максимального, установленного в настройках.
Результат: пользователь не может войти.
Выдается сообщение: (ссылка на сообщение).
Вход с IP адреса Пользователя заблокирован на время, установленное в настройках.

Важные моменты

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

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

— Если в двух и более сценариях повторяется одинаковый набор шагов, есть смысл вынести эти шаги в отдельный сценарий, и ссылаться на них. Документ будет легче. А если что-то в этих шагах поменяется, то достаточно будет изменить в одном месте.

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

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

— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.

Правильных и полезных вам сценариев! Вопросы, примеры, предложения, комментарии приветствуются. Спасибо за внимание.

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

Источник

Владимир Репин

Член ABPMP Russia

Доцент

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье Владимира Репина рассмотрена методика формирования модели сквозного процесса масштаба компании в среде Business Studio. Приводится пример модели в нотации IDEF0. Рассматриваются сценарии выполнения сквозного процесса. Представленная методика может быть использована при работе с любым программным продуктом, предназначенным для проектирования архитектуры бизнес-процессов организации.

Введение

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

В качестве примера я выбрал процесс «Разработка нового изделия: от идеи до постановки на производство» и создал его модель в Business Studio.

Обращаю внимание, что у меня не было цели создавать модель «идеального» процесса с претензией на «лучшую практику». Цель построения модели — показать возможности методологии моделирования сквозных процессов масштаба компании в среде Business Studio.

Модель сквозного процесса в нотации IDEF0

На рис. 1 представлена контекстная модель этого процесса. Видно, что стрелки приходят «ниоткуда» и уходят в «никуда». Понятно, что у сквозного процесса есть внутренние поставщики и потребители (процессы). Но на контекстной диаграмме Business Studio, увы, нельзя показать междиаграммные ссылки на другие процессы модели (техническое ограничение). С этим придется мириться. С другой стороны, в данном случае важно разработать модель отдельного сквозного процесса, а не всей компании.

Рис. 1. Диаграмма процесса «Разработка нового продукта». Контекст.

Сквозной процесс строится из кусков — функциональных процессов подразделений разного уровня. Предполагается, что, перед тем, как начать строить модель сквозного процесса, вы четко понимаете структуру процессов (функций), выполняемых в подразделениях. Более того, желательно иметь все эти процессы в виде иерархического справочника в Business Studio (только реестр, диаграммы можно сгенерировать, но они будут без связей).

На модели А0 сквозного процесса можно использовать блоки (процессы), которых нет в функциональной модели (реестрах функциональных процессов подразделений). Почему так?

Дело в том, что видение сквозного процесса масштаба компании, его структуры является предметом для обсуждения и согласования топ-менеджеров, например, в рамках проведения Процессного комитета (создание которого рекомендует BPM CBOK).

Другими словами, группировка процессных категорий на диаграмме А0 сквозного процесса (см. рис. 2) может отличатся от существующих структурных подразделений компании. Это две большие разницы.

Рассмотрим диаграмму процесса «Разработка нового продукта» (рис. 2). Видно, что рассматриваемый сквозной процесс является весьма масштабным. Он состоит из блоков (процессных категорий), которые сами по себе являются сложными.

Рис. 2. Диаграмма процесса «Разработка нового продукта».

Очевидно, что процесс такого уровня сложности невозможно представить в виде какой-то одной цепочки операций (Work Flow — поток работ, в нотации eEPC или BPMN), выполняемых конкретными сотрудниками. (Теоретически, это сделать можно, но модель будет включать несколько тысяч шагов и сотни шлюзов, что сделает ее абсолютно нечитаемой и практически неприменимой.)

Если мы декомпозируем, например, «Выполнение НИОКР», то, скорее всего, на диаграмме увидим процессы, которые тоже нерационально представлять в виде диаграмм Work Flow.

Очевидно, что сквозной процесс такого масштаба нуждается в постоянном административном управлении. Поэтому наличие на схеме блока «Управление разработкой новых и изменением текущих продуктов» представляется вполне оправданным.

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

На рис. 3 показана диаграмма процесса «Разработка требований к новому продукту».

Рис. 3. Диаграмма процесса «Разработка требований к новому продукту».

Семь процессов, представленные на диаграмме, выполняются последовательно только в идеальном случае (кроме блока «Анализ необходимости внесения изменений в существующий продукт»).

В реальности часть из них может работать одновременно, с разными задачами. Видно, что возможны возвраты и переделки, например, «Анализ возможности и необходимости создания нового продукта», «Разработка ТЗ на новый продукт» и «Принятие решения по новому продукту».

Если рассматривать блоки деятельности, представленные на схеме 3, как Work Flow (т. е. на следующем уровне), то для каждого такого процесса возможные различные условия:

  • старта в части запуска предыдущими процессами;
  • завершения в части запуска других процессов.

Сценарии выполнения сквозного процесса

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

Рис. 4. Диаграмма процесса «Разработка требований к новому продукту». Сценарии.

Желтый сценарий — «идеальный», когда всё делается с первого раза и продукт получается удачный.

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

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

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

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

  • для понимания процесса и возможностей его оптимизации;
  • для определения требований в рамках регламентации сквозного процесса;
  • для автоматизации сквозного процесса в BPMS системе — нужна архитектура процессов и понимание того, при каких условиях и с какими данными эти процессы будут последовательно запускаться в работу.

Часто бывает, что при построении модели выхватывают какой-то один сценарий или микс 2–3 сценариев. При этом забывают о том, что возможны и другие сценарии. Результат — рыхлая, фрагментарная модель, которая никуда не годится (процесс не может быть выполнен).

Попытка регламентировать, а уж тем более автоматизировать такой «дырявый» сценарий приведет к тому, что постоянно будет требоваться ручное управление. При этом я не хочу сказать, что для начала автоматизации нужно знать всё. Нет. Можно начинать автоматизировать процесс по частям. Но при этом понимание архитектуры сквозного процесса в целом поможет существенно сократить время на последующие переделки.

Для анализа некоторых возможных сценариев выполнения сквозного процесса можно построить соответствующую матрицу — см. пример ниже.

Таблица. Сценарии выполнения сквозного процесса. Пример.

№ Наименование процесса Сценарий А Сценарий Б Сценарий В
1 Управление разработкой новых и изменением текущих продуктов
1.1. Планирование разработки новых видов продукции + + −
1.2. Управление проектом разработки нового вида продукции + + −
1.3. Анализ инвестиционной привлекательности новых видов продукции + + −
1.4. Формирование отчетов по разработке новых видов продукции + + −
2 Разработка требований к новому продукту
2.1. Управление разработкой требований к новому продукту + + +
2.2. Поиск идей по новым продуктам + + −
2.3. Оценка и отбор идей по новым продуктам + + +
2.4. Проведение консультаций с постоянными клиентами по новому продукту − + −
2.5. Анализ возможности и необходимости создания нового продукта + + −
2.6. Анализ необходимости внесения изменений в существующий продукт − − +
2.7. Разработка ТЗ на новый продукт + + −
2.8. Принятие решения по новому продукту + + +
3 Выполнение НИОКР
3.1. Управление процессами НИОКР + + −
3.2. Анализ инновационных технологий и продуктов конкурентов + + −
3.3. Разработка/изменение дизайна продукта − + +
3.4. Выполнение научно-исследовательских работ + + −
3.5. Выполнение опытно-конструкторских работ + + −
3.6. Проведение верификации на компьютерной модели − + −
4 Разработка технологии производства нового продукта
4.1. Управление разработкой технологии производства + + +
4.2. Разработка НТД по продукту + + +
4.3. Тестирование новых видов сырья и упаковки + + −
4.4. Разрабокта нормативов по новому продукту + + −
5 Подготовка и производство пробных партий нового продукта
5.1. Управление подготовкой и производством пробных партий + + −
5.2. Подготовка оборудования + + −
5.3. Подготовка остатки + + −
5.4. Закупка сырья для пробных партий − + −
5.5. Изготовление пробной партии + + −
5.6. Тестирование пробной партии + + −
6 Запуск нового продукта в серийное производство
6.1. Управление запуском серийного производства нового продукта + + −
6.2. Заключение договоров с поставщиками − + −
6.3. Закупка, монтаж и пуско-наладка оборудования − + −
6.4. Модернизация оборудования + − −
6.5. Сертификация продукта + + −
6.6. Внесение изменений в НТД + + +
6.7. Внесение изменений в НМД + + −
6.8. Определение цены на новый продукт + + −
6.9. Обучение производственного персонала + + −
6.10. Обучение сбытового персонала + + −

Некоторые процессы в этой таблице требуют декомпозиции еще на один уровень, прежде чем их можно будет описать в формате Work Flow (например, в нотации BPMN).

Анализ сценариев

Далее, если все процессы будут описаны в формате Work Flow, можно будет для каждого процесса рассчитать показатели выполнения одного экземпляра:

  • минимальное, нормативное, максимальное время выполнения;
  • затраты на выполнение.

(Кстати, для целей анализа времени выполнения и затрат можно использовать функционал имитационного моделирования в Business Studio).

Затем, с учетом среднего количества запусков каждого процесса (возможны итерационные повторения), можно рассчитать показатели конкретного сценария сквозного процесса в целом:

  • общее время выполнения;
  • совокупные затраты.

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

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

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

Очевидно, что общие показатели для «сквозного процесса в целом» (а не отдельного типового сценария) будут, в значительной мере, «средней температурой по больнице». Выбор и расчет показателей для сквозного процесса такого масштаба является весьма сложной задачей.

Резюме.

Если цель проекта — повышение эффективности сквозного процесса, то можно и нужно сразу браться за его описание и анализ, не пытаясь создать полную, комплексную архитектуру процессов в Business Studio. Используя функциональные возможности системы, можно:

  • построить архитектуру сквозного процесса;
  • описать всего его подпроцессы в нотации BPMN и увязать их по входам/выходам и условиям запуска;
  • провести анализ процессов с использование движка имитационного моделирования (или без него), определить время выполнения процессов и соответствующие затраты;
  • построить матрицу сценариев выполнения сквозного процесса;
  • выполнить анализ и оптимизацию сквозного процесса;
  • регламентировать сквозной процесс;
  • разработать систему целей и показателей для управления сквозным процессом (для основных сценариев);
  • разработать техническое задание на автоматизацию сквозного процесса.

Опубликовано по материалам:
http://www.finexpert.ru/view/stsenarii_vypolneniya_skvoznogo_protsessa/956

Март 2019 г.

Рекомендуемые материалы по тематике

Современные методы разработки системы корпоративных регламентов

Декомпозиция процессов в нотации BPMN в Business Studio

Процессные команды как основа культуры эффективности

Глоссарий. Положение о структурном подразделении

Источник
Содержание
Введение
 

Что такое сценарий использования (и что не является им)

Сценарии использования – это программные требования, которые определяют функциональность

Ссылки позволяют пользователям восстановить всю историю

Заключение

Введение

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

Ивар Якобсон ввел сценарии использования. Мария Эриксон работала с Якобсоном и была соавтором одной из его книг. Курт Биттнер и Ян Спенс также написали популярную книгу по использованию сценариев использования. Эти пионеры и многие другие люди в IBM, которые имеют многолетний опыт работы с заказчиками в разработке хороших сценариев использования, внесли свой вклад в технологии, описанные в этой статье. Дать хороший сценарий использования не легко, но, к счастью, наш опыт может быть Вашим руководством. Концепций и принципы, собранные здесь, представляют опыт многих людей в IBM, и они образуют основу проверенных передовых методов. Многие советы, приведенные в данном документе, являются частью методологии IBM Rational® Unified Process® (RUP®), другие являются новыми и не представлены в RUP.

Что такое сценарий использования (и что не является им)

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

Сценарий использования – это история о том, как бизнес или система и пользователи взаимодействуют. Варианты использования являются частью стандарта Object Management Group (OMG) Unified Modeling Language (UML). Этот стандарт говорит нам, что части сценария использования выражается диаграммами – рисованные фигуры, овалы и линии – и это дает нам определение сценария использования. Но это не говорит нам, как структурировать или писать. Поэтому нам остается читать книги или статьи (подобной этой), чтобы попытаться выяснить правильные методы.Итак, какой правильный путь? Лучший способ – это способ, который работает на Вас, не отходя слишком далеко от определения, что такое вариант использования: 

Вариант использования – это спецификации набора действий, выполняемых системой, который дает заметный результат, который, как правило, значим для одного или нескольких субъектов или других заинтересованных сторон системы (UML 2).

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

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

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

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

Сценарии использования – это программные требования, которые определяют функциональность

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

Сценарии использования описывают поведение (по крайней мере, выходы), которое является видимым для пользователя. Существуют и другие типы требований кроме функциональных, их, как правило, называют нефункциональными или вспомогательными требованиями. Эти требования, как правило, также указываются выражением «должен», но они содержат отличную от сценариев использования информацию. Они описывают необходимые качественные показатели системы: насколько быстра она должна быть, как надежна, как безопасна и другие качественные атрибуты. Сценарии использования должны описывать, что система должна делать. Они должны выражать интерактивные шаги, которые пользователь должен предпринять для достижения значимого результата.

Сценарии использования описывают и функциональность и результаты. Сценарий использования описывает функциональные возможности, но он также должен описывать результат. Это важно, и это отражается в первом определении, которое говорит, что прецеденты обеспечивают «значимый результат для одного или нескольких субъектов или других заинтересованных сторон системы». Одна из общих проблем, наблюдаемых в организациях, которые только начали использовать сценарии использования, является то, что они не понимают этот фокус на значимости. И в результате они делают много небольших сценариев использования, которые не дотягивают до полной истории. Они не нацелены на взаимодействие, определяющие значимость и интересы для субъектов, участвующих в сценарии использования. Распространенной ошибкой является путать требования со спецификациями проектирования. Этот подход часто можно увидеть в его воздействии на этапе тестирования проекта. Если тесты, основанные на сценариях использования, отражают юнит-тесты, а не приемочные испытания пользователя, их может быть, возможно, слишком много и они на слишком низком уровне.Как, например, один клиент IBM взаимодействовал с около 10 людьми, работающими над проектом, который должен был длиться около года. Первоначально в организации было около 150 сценариев использования, потому что было непонимания их цели. После глубокой экспертизы, было установлено, что многие из их вариантов использования были действительно спецификациями проектирования, а не требованиями, и другие были слишком сосредоточены на настолько незначительных взаимодействиях, что они не показывали никакой значимости для субъекта или заинтересованных сторон. 

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

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

Совет: Не забывайте о диаграммах

Сценарии использования представлены графически в виде овалов на диаграммах сценариев использования, и они также выражаются как текстовые спецификации (см. рисунки 1 и 2). Текст, безусловно, суть модели сценария использования, и Вы можете, конечно, извлечь пользу от текстового описания без рисования диаграмм. Однако схема может помочь представить требования на высоком уровне. Это также помогает заинтересованным сторонам увидеть, что находится в границах и что выходит за границы. Субъекты вне разрабатываемой системы и сценарии использования внутри. Это особенно важно для обзорных диаграмм сценариев использования, которые показывают всех участников и варианты использования на одной диаграмме.

Люди являются наиболее важным элементом сценария использования

Совет: Люди-субъекты являются наиболее важным элементом

Рисованные фигуры, применяемые в диаграммах сценариев использования, называются субъектами. Они показывают, любое лицо (или роль), другие системы или, возможно, даже устройство, которое находятся за пределами разрабатываемой системы, но взаимодействуют с ней. Люди-субъекты представляют наиболее интересные и сложные взаимодействия для большинства систем, а также взаимодействие человека и системы, где реальная значимость сценария использования вступает в перспективе. Функциональность, вложенная в сценарий использования, поможет субъектам делать свою работу или задачу существенно лучше.

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

Создание стиля для сценария использования позволяет писать и читать их быстрее и проще.

Совет: Идите за потоком

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

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

Сценарии использования должны иметь один основной поток и несколько альтернативных потоков. Сценарий использования должен иметь один основной поток и несколько альтернативных потоков. Основной поток (см. рисунок 1) объясняет, что происходит, когда все идет правильно и сценарий использования достигает свою цель. Иногда его называют сценарий «верного пути» и он происходит чаще всего. Иногда авторы сценария использования пытаются описать несколько основных потоков, но это может уменьшить понятность сценария использования, поскольку потребителю сложнее понять истинные цели. Поэтому наиболее общий сценарий должен быть основным в процессе, выступающим в качестве одного основного потока. 

Рисунок 1. Хорошо написанный сценарий использования, который рассказывает, как студент регистрируется на курсы.

Альтернативные потоки объясняют отклонение от основного потока. Альтернативные потоки (см. рисунок 2) объясняют, что происходит, когда по каким-то причинам происходит отклонение от основного потока. Эти отклонения могут или не могут быть помечены как исключения или ошибки. В любом случае, они не встречаются так часто, или не так важны, как основной поток. В документе сценария использования каждый тип потока описывается в своем собственном разделе. Иногда альтернативные потоки разбиты на более подробные категории такие, как пользовательские ошибки и исключения. Отметим, что низкоуровневые коды ошибок выходят за рамки альтернативных потоков. 

Рисунок 2. Альтернативные потоки описывают возможные результаты, когда они начинаются и когда они заканчиваются.

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

Ссылки позволяют пользователям восстановить всю историю

Хорошая практика разбивать на модули сценарий использования, разделив его на несколько потоков. Но чтобы быть в состоянии рассказать всю историю, Вы также должны иметь какой-то способ сложить кусочки снова вместе, чтобы проиллюстрировать конкретные непрерывные сценарии. Это достигается с помощью ссылок, которые по существу определяют начало и конец альтернативного потока, ссылаясь на конкретный шаг в основной поток или иной альтернативный поток (см. рисунок 3). Создание легко понимаемого сценария использования требует последовательной техники с использованием ссылок.

Совет: Помещайте ссылки в альтернативных потоках, а не основных потоках

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

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

Ссылки указывают на то, что является причиной для начала альтернативного потока и что система делает в ответ. Альтернативные потоки содержат ссылки (Альтернативные потоки объясняют, что происходит при возникновении ошибки или когда происходят ожидаемые результаты, но они не столь важны как основной поток). Это то, где проявляется важность ссылок. Каждый альтернативный поток начнется где-то в сценарии использования. Он может отходить от одного из шагов в основном потоке или расширяться от другого альтернативного потока. И когда альтернативный поток заканчивается, сценарий использования, как правило, продолжается в другом месте.Альтернативный поток объясняет, что явилось причиной для старта и что система делает в ответ на альтернативный поток. Альтернативные потоки не только содержат ссылки на то, где они начинаются и где они возобновятся, они также говорят, что заставило их начаться и что система делает в ответ. Смотря ниже в процесс разработки, эта информация будет полезна для написания тестов. 

Совет: Сценарии описывают полную историю

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

Удобочитаемость может пострадать, если присутствует оператор «если» в потоке, потому что это обычно означает множественные требования.

Совет: Будьте осторожны с операторами «если»

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

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

Совет: Укажите выбор для субъекта

Субъекты часто делают выбор в сценарии использовании. Рассмотрим пример системы регистрации университета определенного в сценарии использования «Регистрация на курсы». В этом примере шаг главного потока может спросить субъекта: 1) создать график, 2) изменить график и 3) удалить график. Часто авторы сценария использования пытаются использовать оператор «если», чтобы показать, субъект делает выбор, но по причинам, указанным выше, это может быть не лучшая идея. Лучшей альтернативой для того, чтобы все возможности выборы субъекта были перечислены в соответствующем месте и был один выбранный вариант, направляющий в текущий поток, а другие рассматривались в альтернативных потоках. Этот метод сохраняет каждый поток простым и снижает ветвления.

Совет: Убирайте СЧОУ

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

Вместо этого, попробуйте сосредоточиться на вещах, которые субъект действительно хочет сделать, что, как правило, не в действиях создание, чтение, обновление и удаление (СЧОУ).

В нашем примере системы регистрации университета, есть варианты для 1) создания графика, 2) изменения графика и 3) удаления графика. Все они находятся в сценарии использования «Регистрация на курсы», поскольку студент не заботится о создании и изменении графиков; студент хочет только зарегистрироваться. Выбор легкого пути и составление списка всех деятельностей СЧОУ в результате даст в три или в четыре раза больше сценариев использования, чем необходимо и может быстро сделать процесс сложным и трудно управляемым.

Для примера модели сценария использования с большим количеством СЧОУ, рассмотрим в приведенном ниже рисунке из проекта по обновлению баз данных администрирования для программ жилья местного управления. Если взять все деятельности типа СЧОУ, каковы реальные выгоды для бизнеса, производимые от всех усилий для определения этой конкретной модели?

Плохо написанный сценарий использования имеет слишком много действий создания, чтения, обновления и удаления, уменьшая ясность. Рисунок 3. У плохо описанного варианта использования есть слишком много включенных действий типа СЧОУ. Удаление деятельностей СЧОУ упрощает документ. Рисунок 4. Хорошо написанный сценарий использования четко указывает на пути и значимость. Упорядочивание событий в потоке не всегда необходимо для достижения ясности.

Совет: Последовательность событий может быть опциональной

Мы говорим, что шаги в сценарии использования, как правило, упорядочены по времени, но следует учитывать, является ли порядок шагов требованием. Например, субъект должен пройти четыре шага до завершения пятого шага? Обычно ответ будет да, но не всегда. Это очень просто, при разработке текстового описания для сценария использования, уточнить любые временные ограничения и добавить в предложение комментарии такие как «Этот шаг может выполняться в любом порядке» или «Этот шаг может выполняться в любое время перед этим шагом». Дело в том, Вы не хотите ограничивать разработчиков системы наличием неявных временных требований, когда они не являются необходимыми.

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

Совет: Используйте правильный уровень детализации

Один из наиболее часто задаваемых вопросов: «На сколько детально описывать сценарий использования?» Помните, что сценарий использования – это требования. Это не документация по проектированию, и они, конечно, не проект пользовательского интерфейса. Сценарии использования никогда не должны ссылаться на элементы пользовательского интерфейса, такие как домашние страницы, экраны входа или нажатие кнопки.

Кроме того, следует избегать архитектурной детализации. Например, в примере регистрации на курсы, выражение «график сохраняется в базе данных SQL Server» не должно быть в сценарии использования. Часть о сохранении графика необходима, но то где он сохраняется является архитектурной деталью, которая должна быть изменена позже, если администратор базы данных решит, что график должен быть сохранен в другой базе данных.

Совет: Поставьте себя на место субъекта

Сценарии использования отличаются использованием выражения «должен». Так как они указывают упорядоченные по времени шаги, они создают больше контекста, чем автономные выражения «должен», которые не являются зависимыми от времени. Поэтому они в большей степени соответствуют предназначению для пользователей. Имейте это в виду. Если сценарии использования это требования (а они и есть), проектировщики и разработчики будут ограничены тем, что они говорят. Помните об этом, пожалейте субъектов и пишите сценарии использования с помощью методов, которые сделают систему максимально удобной для пользователя.

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

Заключение

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

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

Дополнительная информация

Чтобы узнать больше о том, как писать эффективные сценарии использования и как IBM Rational Software может помочь, пожалуйста, обращайтесь к представителю компании или бизнес-партнеру IBM или посетите:

ibm.com/software/rational/offerings/irm

Источник

Без технической душноты исследуем сценарии «пользователь <—> система». Для продактов, дизайнеров и аналитиков — оставили готовый шаблон

Всем привет! Я Ната, UX/UI дизайнер в Red Collar. В этой статье я расскажу о методологии, которая улучшит коммуникацию внутри команды, а значит и работу над продуктом — Use Case или «юзкейсе», а также поделюсь шаблоном для тех, кто сталкивается с ней впервые.

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

Польза юзкейсов — единое представление о продукте

Если в команде более 5 человек, а проект длится более 3 месяцев, то может возникнуть дискоммуникация. Например:

  • разработчики неправильно поняли сценарий взаимодействия и реализовали фичу не так, как планировалось;

  • в ходе долгих обсуждений внутри команды вы сильно отклонились от первоначальной идеи и точно воспроизвести её не можете;

  • дизайнеры спроектировали функциональность, которая изначально не планировалась;

  • один и тот же кейс в разных местах реализован по-разному, что увеличивает время разработки и усложняет UX;

  • при тестировании пропускаются значительные ошибки;

  • сменился состав команды: к проекту подключились новые участники, а ведущие члены команды ушли.

Сценарии юзкейсов — как игра в теннис между пользователем и системой

Use Case — это описание взаимодействия с системой в виде последовательности действий для достижения конкретного результата. По сути, это метамодель, которая иллюстрирует не саму систему, а набор функциональных требований к ней.

Методология была разработана в 80-х Иваром Якобсоном. Для всех желающих погрузиться в тему глубже есть бесплатная книга Use-Case 2.0, также другие ссылки по теме оставлю внизу статьи.

Для наглядности юзкейс можно сравнить с игрой в теннис, где один игрок это пользователь, другой — система. Удар ракеткой это действие, которое совершает пользователь, после чего мяч переходит системе, и далее система ему отвечает. Разница только в том, что в юзкейсе пользователь или система могут подряд совершить несколько действий.

Юзкейсы существуют в двух равнозначных видах: UML-диаграмма или текстовый документ. По желанию их можно совмещать

«Основной юзкейс» — сценарий успеха: участники + действия + результат + доп. условия

Единого формата для написания юзкейсов не существует. Каждая компания сама определяет для себя формат и уровень детализации. Опишу основной принцип написания.

Основные элементы юзкейса:

1. Понятный заголовок, желательно, чтобы он содержал результат юзкейса. Пример, «Создание заявки».

2. Действующие лица или участники. Можно выделить такие варианты:

  • «Пользователь и система». Например, при авторизации.

  • «Несколько пользователей и система». Например, если мы описываем общение в чате.

  • «Система и система». Например, если мы описываем внутренние процессы внутри системы.
  • «Несколько систем и система».

3. Описание последовательности действий в виде сценария.

4. Результат, то есть то, к чему должны прийти пользователь или система.

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

Пример простого юзкейса

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

  • контекст использования;
  • откуда происходит переход к юзкейсу;
  • дополнительные условия;
  • триггер;
  • цель;
  • изменения в технологии.

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

Пример развернутого юзкейса с пояснениями

«Альтернативный юзкейс» — сценарий ошибки

Рассмотрели вид основных сценариев юзкейсов, а что если возникла ошибка или пользователь столкнулся со сложностями? Для этого создается альтернативный юзкейс: когда результат основного не был достигнут. Например, пользователь не смог зарегистрироваться, так как имя уже занято или с указанной почты уже создана учетная запись.

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

Пример юзкейса с альтернативными сценариями внутри основного

Чеклист для написания юзкейсов

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

Вначале сделайте единый шаблон и заведите словарь

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

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

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

Советы, которые ускорят написание юзкейсов:

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

Так нужен ли вам юзкейс?

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

Всем крутых продуктов!

Ната Нефедьева

Шаблон юзкейса + дополнительные материалы

Подготовила для вас шаблон юзкейса, открыт всем в гуглдоке.

1. Статьи и бесплатные книги о юзкейсах от создателя методологии Ивара Якобсона — даст более полное представление об инструменте «из первых рук» (en)

2. Короткое видео с простым объяснением инструмента от бизнес-аналитика + ссылка в описании к видео на их шаблон юзкейсов (en)

3. Короткое видео о юзкейсах для новичков от UX/UI дизайнер в Siemens (ru)

4. Статья от Usability.gov с краткой информации о юзкейсах и примером их заполнения (en)

5. Статья от системного аналитика, где подробно рассказывается о методологии и опыте ее применения в QIWI (ru)

Источник

Понравилась статья? Поделить с друзьями:
  • Бизнес план детской студии праздника
  • Бизнес план детских праздников бизнес план организация детских праздников
  • Бизнес план детская студия праздников
  • Бизнес план воздушные шары оформление праздников
  • Бизнес план аниматоры на детские праздники