+7(499)495-49-41

Бизнес юзкейс в ит

Кейс: как мы подготовили IT-системы для работы 12 тысяч магазинов к высокому сезону | Rusbase

Бизнес юзкейс в ит

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

По нашему опыту, в продуктовой рознице самое горячее время – период с 1 ноября по 15 января. Рост количества транзакций у других ритейлеров может произойти и в другое время: в преддверии 23 февраля, 8 марта или школьных каникул.

Так что берите на заметку наш опыт, чтобы воспользоваться им в нужный момент. Мы начали готовить IT-системы к высокому сезону очень заранее – за 6 месяцев.

Наши главные цели:

  • Создать запас прочности и надежности
  • Устранить возможные риски
  • Подготовить запасные ресурсы к периоду пиковых нагрузок

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

Итак, как мы готовим наши сани летом.

1. Проверяем инфраструктуру

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

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

Тут важен такой принцип: если что-то может сломаться, оно сломается. Поэтому для нас не существует оборудования, которое не будет протестировано.

  • Нужно тестировать и core-элементы системы.

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

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

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

  • Важно проверить средства и качество связи.

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

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

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

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

2. Проверяем программное обеспечение

  • В первую очередь мы проверяли и обновляли кассовое ПО.

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

За 6 месяцев мы сделали это несколько раз. Перед установкой новых версий кассовых программ  мы обязательно проверяли их на тестовых объектах и ставили в «продуктив» только  стопроцентно работающие версии.

Если все-таки случались ошибки  – «откатывали» ПО на предыдущую версию.

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

  • Параллельно мы обновили ПО  на 42 тысяч пин-падов – устройств для безналичной оплаты.

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

  • Отдельно мы занимались ключевыми системами, стабилизируя их работу.

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

3. Проверяем точность работы бизнес-процессов

Так как в прошлом году появились онлайн-кассы, мы начали отслеживать очередь отправки чеков в ФНС на всех кассах и регулировать их работу. Еще одна «превентивная мера» — проверка сертификатов ЭЦП для торговли алкоголем. Суммарно по итогам проверки мы перезаписали 5138 ключей ЕГАИС.

Также важно было убедиться на 100% в  точности работы бизнес-процессов – то есть взаимодействия между бизнес-единицами компании.

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

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

Несмотря на то что сеть магазинов и количество оборудования за год увеличились почти на 30%, мы получили меньше обращений от торговых точек о сбоях в работе оборудования, обеспечив 99,34% доступности сервисов и систем.

Чеклист для поддержки: что проверить перед горячим сезоном

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

Как это сделать

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

Материалы по теме:

Большие данные в ритейле: что они дают и как с ними работать

Как повысить продажи в e-commerce – пять проверенных способов

Хотите предугадывать будущее ритейла? Следите за рынком Китая

10 необычных технологий в ритейле, которые выходят в мировой топ

Самые горячие инструменты торговли в XXI веке

Актуальные материалы — в Telegram-канале @Rusbase

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Источник: https://rb.ru/opinion/kejs-it/

Как и зачем писать Use Cases

Бизнес юзкейс в ит
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. Система выдает пользователю сообщение по поводу успешной авторизации (ссылка на сообщение).
РезультатПользователь успешно авторизирован и может работать с системой.
Расширения:
Нет доступа к БД.Система выдает сообщение (ссылка на сообщение).Результат: пользователь не может войти.
В настройках безопасности для данного IP адреса существует запрет на вход в систему.Результат: форма логина не предоставляется, система выдает сообщение пользователю (ссылка на сообщение).
Пользователь выбирает: «Напомнить пароль».Вызывается сценарий «Напомнить пароль».
Пользователь с введенными логином и паролем не найден.Результат: отказ в авторизации.Система выдает сообщение (ссылка на сообщение).Переход на шаг 2.
Количество неудачных попыток авторизоваться достигло максимального, установленного в настройках.Результат: пользователь не может войти.Выдается сообщение: (ссылка на сообщение).Вход с IP адреса Пользователя заблокирован на время, установленное в настройках.

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

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

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

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

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

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

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

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

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

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

Источник: https://dou.ua/lenta/articles/use-cases/

Бизнес-кейс. IT-антиквариат

Бизнес юзкейс в ит

Представляю вашему вниманию новый кейс по менеджменту.

Введение

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

Проблема

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

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

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

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

Динамика отрасли с 2007 по 2013 год

По материалам Коммерсанта

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

По результатам встречи Осипу быстро стало ясно, что вся IT-инфраструктура и системы ужасно устарели, и что более существенно — критические вопросы отдела были вообще пропущены при собеседовании и заступлении на пост.

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

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

Разворот проблемы

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

  1. Перемещение существующего оборудования на коммерческий объект коллокации для снижения вероятности потенциального эпикфейла.

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

  2. Покупка нового оборудования и его установка в надлежащих условиях, скорее всего, в коммерческом учреждении коллокации, как описано в первом пункте.

  3. Миграция всего функционала в облако и полная ликвидация внутренней аппаратной инфраструктуры.

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

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

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

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

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

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

Результаты

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

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

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

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

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

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

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

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

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

Источник: https://habr.com/post/293392/

Use Case в дизайне: пример применения пользовательских сценариев от стартапа Trucker Path — Офтоп на vc.ru

Бизнес юзкейс в ит

Николай Ковалюнас, дизайнер продукта в компании-разработчике приложения для дальнобойщиков Trucker Path, написал для vc.ru колонку о том, как применять пользовательские сценарии в рабочем процессе.

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

В общем, ничто не мешает приступить к работе. Первое, что приходит в голову, — открыть тетрадь для скетчирования, Sketch, или Photoshop, или, может, редактор кода, и начать накидывать экраны. Но нет. Здесь необходим Use Case.

Что это? Давайте разберемся.

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

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

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

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

Из чего состоит Use Case

В зависимости от сложности и детализированности Use Case может содержать следующие элементы:

  • Название (Name) — название Use Case: короткое, понятное, отражающее суть.
  • Краткое описание (Brief Description) — текст, описывающий данный Use Case.
  • Участники (Actors) — список участников взаимодействия. Часто состоит из одного человека.
  • Предусловия (Preconditions) — условия, которые должны быть выполнены перед началом реализации данного Use Case.
  • Триггер (Trigger) — событие или условие, которое заставляет пользователя приступить к выполнению Use Case.
  • Базовый сценарий (Basic Flow) — последовательность действий, которые выполняет участник для успешного достижения цели. Также может называться Normal Flow, Primary Scenario и Happy Path.
  • Альтернативные сценарии (Alternative Flows) — описание альтернативных сценариев выполнения Use Case. Важное условие альтернативных сценариев — участник в итоге успешно достигает цели.
  • Исключительные сценарии (Exceptional Flows) — все, что может привести участника к невыполнению Use Case.
  • Постусловие (Post Conditions) — результат после выполнения Use Case.

К счастью, на практике не всегда нужно использовать все пункты. Всё зависит от того, для чего и кого вы его пишете.

Итак, возвращаемся к нашей задаче. Открываем обычный текстовый редактор. Очень неплох iA Writer, но сгодится любой. Я, например, использую Google Docs — им удобно делиться с коллегами.

Пишем Use Case

На самом деле, пример взят из реального опыта. В Trucker Path у меня была задача на импорт списка перевозчиков посредством CSV. Приступим.

Как видите, мы использовали далеко не все составляющие Use Case, что вполне нормально. Теперь напишем последовательность шагов для Basic Flow.

Basic Flow (B1)

  1. Пользователь начинает импорт перевозчиков.
  2. Пользователь нажимает импорт перевозчиков через CSV-файл.
  3. Система дает возможность выбрать файл с компьютера или перетащить его для загрузки.
  4. Пользователь использует выбор файла с компьютера.
  5. Пользователь выбирает CSV-файл со списком перевозчиков.

  6. Система обрабатывает выбранный файл.
  7. Система проверяет файл на наличие ошибок.
  8. Система не находит ошибок, препятствующих дальнейшей работе.
  9. Система выводит предпросмотр данных загруженного файла.
  10. Система предлагает сопоставить типы данных.

  11. Пользователь сопоставляет типы данных с теми, что есть в системе.
  12. Пользователь нажимает импорт.
  13. Система импортирует данные.
  14. Система проводит все необходимые проверки.
  15. Система успешно заканчивает импорт перевозчиков.
  16. Система показывает обновленный список перевозчиков.

  17. Система информирует пользователя об успешном завершении задачи.
  18. Пользователь видит обновленный список перевозчиков.

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

Не забывайте помимо действий пользователя описывать действия системы. Отсутствие этого описания — одна из самых частых ошибок.

Use Case можно сопроводить быстро заскетчированными основными экранами — так проще донести до другого человека суть происходящего. Ниже пример таких экранов. Часто можно обойтись просто скетчами в тетрадке, так ещё быстрее.

Теперь самое важное. То, что получилось, нужно обсудить с менеджером продукта. Идеально, если есть возможность сделать это лично. Иногда бывает полезно пригласить ещё и кого-нибудь из команды инженеров.

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

А значит, в дальнейшем нас ждет меньше непредвиденных изменений.

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

Что это означает для нас? Объем работы сократился на 30−40%, что довольно ощутимо. Если бы мы сразу начали рисовать дизайн, то потратили бы немало времени впустую, потому что работу в итоге пришлось бы переделывать. А так мы сразу обнаружили расхождение между предложенным и оптимальным решением.

Что дальше

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

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

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

Его стоит писать, чтобы решить задачу быстро и эффективно.

Заключение

Если вы ещё сомневаетесь, а нужно ли использовать такую штуку в рабочий процесс, кратко обозначу семь причин полюбить Use Case:

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

Источник: https://vc.ru/flood/18197-trucker-path-design

Поделиться:
Нет комментариев

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

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.