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

Что это#

Прототипирование (prototyping) выявляет и проверяет потребности заинтересованных сторон: строится модель решения или его части, и её итеративно улучшают вместе с теми, кто будет ею пользоваться.

Руководство BABOK® различает два подхода:

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

Руководство также перечисляет виды прототипов по назначению: проверка концепции (proof of concept) проверяет, работает ли выбранный подход к решению, не моделируя его внешний вид и процессы; прототип для изучения формы (form study) проверяет размеры, внешний вид и эргономику без функций; прототип удобства использования проверяет, как с ним взаимодействуют пользователи; визуальный прототип показывает внешний вид без полной функциональности; функциональный прототип проверяет функциональность и бизнес-правила. Способы построения — раскадровка, бумажное прототипирование, моделирование потока работ и симуляция.

Две оси Вигерса#

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

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

Ещё два связанных инструмента. До горизонтального прототипа набросайте карту диалогов — основные экраны и переходы между ними (Маглинец отмечает, что она хорошо ложится на диаграмму состояний). И подумайте о раскадровке: Леффингуэлл и Уидриг описывают пассивную, активную и интерактивную раскадровку.

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

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

Учебные материалы называют сильные стороны техники: она даёт наглядную картину будущего состояния, а заинтересованные стороны участвуют в её создании и дают обратную связь.

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

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

Сформулируйте вопрос, на который должен ответить прототип: какие требования уточнить или какой риск снизить.
Выберите тип: горизонтальный или вертикальный, одноразовый или эволюционный. Начните с самой низкой детализации, которой хватит для ответа на вопрос.
Спланируйте ход: выберите сценарии, которые нужно охватить, и набросайте карту диалогов.
Сделайте прототип быстро и с реалистичным содержанием. Маглинец указывает на два преимущества бумаги: люди думают о функциях, а не о цвете кнопок, и никто не решит, что система почти готова.
Отметьте ожидаемые объёмы и частоту. Маглинец, опираясь на Леффингуэлла, советует указывать типичные объёмы данных и частоту каждого сценария: для выбора из двух вариантов подходит флажок, из нескольких десятков — выпадающий список, из тысяч — поиск с фильтрами; самые частые сценарии должны требовать меньше всего шагов.
Проверьте с пользователями: дайте им пройти сценарии, наблюдайте, где они медлят, и спросите, чего не хватает и что не так.
Зафиксируйте находки как новые или изменённые требования и запишите открытые вопросы.
Повторяйте, пока не получите ответ на вопрос, а затем остановитесь.
Решите судьбу прототипа. Одноразовый код должен быть выброшен; скажите об этом явно.

Пример#

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

Находки:

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

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

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

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

Чек-лист#

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

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

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.36 «Прототипирование».
Учебные материалы по бизнес-анализу (модуль «Выявление и сотрудничество»).
Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 5 (классификация прототипов по К. Вигерсу; бумажные прототипы; пометки об удобстве использования по Д. Леффингуэллу).
D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. (Раскадровка.)
И. Корнипаев. Управление требованиями: слайды курса. (Опасности прототипов.)