Раскадровка · Конспекты по бизнес-анализу

Что это#

Раскадровка (storyboard) — последовательность набросков, экранов или сцен, которая проводит пользователей через то, что система будет делать в типичной ситуации. Леффингуэлл и Уидриг описывают три типа раскадровки — по степени участия пользователя:

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

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

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

Когда применять#

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

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

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

Выберите один сценарий, который важен и в котором вероятно непонимание.
Перечислите «кто», «что» и «как»: действующих лиц, шаги взаимодействия и переходы между состояниями.
Выберите тип: пассивный — для первого разговора, интерактивный — когда нужно, чтобы пользователи что-то попробовали сами.
Делайте черново. Бумага, стикеры, наброски на доске или простая презентация. Рекомендации Леффингуэлла и Уидрига: - Не вкладывайте много. Если раскадровка выглядит законченной, заказчики стесняются просить изменения и могут даже захотеть оставить её в качестве продукта. - Сделайте её лёгкой для изменения — за считаные часы. - Не делайте её слишком хорошей. Используйте материалы или инструменты, которые не могут случайно превратиться в рабочий код. - По возможности делайте её интерактивной: чем больше взаимодействия, тем больше реакций и тем больше требований.
Проведите пользователей по раскадровке и намеренно вызывайте комментарии «да, но…».
Меняйте её на месте, где это возможно, и показывайте снова.
Записывайте реакции как требования, вопросы и решения.

Шаблон#

Шаблон

Раскадровка: <название сценария>   Тип: пассивная / активная / интерактивная   Версия: <n>

| Кадр | Кто (действующее лицо) | Что происходит | Как (переход к следующему кадру) | Реакции / вопросы |
|------|------------------------|----------------|----------------------------------|-------------------|
| 1    |                        |                |                                  |                   |
| 2    |                        |                |                                  |                   |

Пример#

Леффингуэлл и Уидриг рассказывают о проекте, который застрял из-за споров о дизайне передней панели прибора. Пять профессионально нарисованных цветных вариантов только подливали масла в огонь. На следующий день один из членов команды принёс фетр, ножницы и маркеры и предложил заказчику прямо на встрече вырезать и переставлять элементы панели. Меньше чем за час заказчик остановился на одном варианте. Черновая версия сработала там, где отполированные провалились, по двум причинам: она была интерактивной (что заказчику делать с пятью картинками, если ни одна не подходит до конца?) и легко менялась. Экспертом в предметной области был сам заказчик; получив инструмент для правок, он сам и решил свою проблему.

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

Частые ошибки#

Шлифовать раскадровку → оставляйте её черновой, чтобы люди не стеснялись её менять.
Делать её в инструментах для разработки продукта → используйте материалы, которые не могут стать продуктом.
Показывать один раз и поздно → показывайте рано, меняйте, показывайте снова.
Только пассивные показы для новой системы → переходите к интерактивной версии как можно раньше.
Не фиксировать реакции → записывайте каждое «да, но…» и превращайте его в требование или вопрос.
Защищать раскадровку → она существует, чтобы её критиковали; благодарите за каждое возражение.

Чек-лист#

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

Источники и что почитать#

D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. Гл. 12.