Требования и дизайны
Коротко Требование представляет потребность в форме, с которой могут работать люди; дизайн делает то же для решения. Если держать их раздельно, легче не зафиксировать решение слишком рано — и при этом по-прежнему пользоваться эскизами и моделями, чтобы понять, что людям действительно нужно.
По материалам: IIBA, Руководство BABOK® v3, разд. 2.5 и разд. 11 (ракурс «Информационные технологии»).
На этой странице
Главные идеи#
Два вида представлений#
Руководство BABOK® проводит явное различие:
- Требование (requirement) представляет потребность. В центре внимания — ценность, которую вы получите, когда требование будет выполнено.
- Дизайн (design) представляет решение. В центре внимания — то, как решение принесёт эту ценность, когда будет создано.
Руководство BABOK называет и то и другое «представлениями», которые должны быть пригодны для использования: это что-то написанное, нарисованное или смоделированное, что другие люди могут понять, обсудить и взять в работу. Требованием может быть предложение, пользовательская история или бизнес-цель. Дизайном — макет экрана, модель процесса, эскиз дашборда, модель данных или прототип.
Одни и те же техники работают для обоих#
Требования и дизайны выявляют, моделируют и анализируют одними и теми же техниками: интервью, семинарами, прототипированием, моделированием процесса и другими. Это одна из причин, почему на практике граница между ними плохо видна.
Связь между ними рекурсивна#
Требование порождает дизайн. Когда этот дизайн показывают заинтересованным сторонам, появляются новые или исправленные требования. Они ведут к пересмотренному дизайну, и так далее. Фокус часто смещается с «потребности» на «решение» и обратно, и никто этого не замечает. Руководство BABOK отмечает: чем ближе вы к пониманию и удовлетворению потребности, тем меньше значит это различие.
Аналитик всегда отчасти занимается дизайном#
Руководство BABOK прямо говорит, что бизнес-аналитик в той или иной степени отвечает за дизайн. В какой именно — зависит от ракурса. Например, в ракурсе «Информационные технологии» слово «дизайн» часто оставляют за архитекторами и разработчиками: аналитик определяет требования к решению, а технический дизайн оставляет им. В работе с процессами или бизнес-архитектурой аналитик может отвечать за модели процессов и карты возможностей, а это и есть дизайны.
Как применять#
- Помечайте свои артефакты. Для каждого документа, модели или эскиза отметьте, формулирует он потребность или предлагает решение. Модель процесса в целевом состоянии — дизайн; цель, которой она служит, — требование.
- Получив дизайн, извлеките из него требование. Заинтересованные стороны часто выражают потребности в виде решений («добавьте выпадающий список», «сделайте приложение»). Запишите предложение как вариант дизайна, а затем спросите, для чего оно. См. принцип «Зачем? Что? Как?».
- Используйте дизайны для выявления. Покажите черновой макет или прототип как можно раньше. Реакция на что-то конкретное вскрывает требования, которые абстрактные вопросы упускают.
- Поддерживайте трассировку от дизайна к требованию. Каждый экран, отчёт или шаг процесса должен указывать на требование, которое он удовлетворяет. Элемент дизайна, который ни к чему не трассируется, — это разрастание границ или пропущенное требование.
- Договоритесь, кто отвечает за какие дизайны. На каждом проекте решите, какие дизайны готовит аналитик (например, модели процессов, вайрфреймы), а какие относятся к архитекторам, UX-дизайнерам или разработчикам.
- Допускайте больше одного дизайна на требование. Требование, которое может удовлетворить только один дизайн, скорее всего, само является замаскированным дизайном.
Пример#
В «Мастерской», вымышленной сети из 12 веломастерских, аналитик раскладывает первые материалы по парам:
| Требование (потребность) | Дизайн (одно из возможных решений) |
|---|---|
| Клиенты могут узнать статус ремонта, не звоня по телефону. | Шаблоны SMS для каждого статуса заказа плюс макет страницы статуса. |
| Управляющие видят запас запчастей во всех 12 мастерских в одном месте. | Эскиз дашборда: по строке на мастерскую, низкий остаток подсвечен. |
| Сотрудники стойки приёма тратят меньше времени на запись клиентов. | Модель целевого процесса записи с онлайн-самообслуживанием. |
| Механики записывают запчасти, использованные в каждом заказе, прямо во время ремонта. | Экран планшета с полем поиска запчасти и кнопкой количества. |
Когда аналитик показывает экран планшета механикам, они замечают, что руки у них обычно в смазке и им удобнее сканировать штрихкод на запчасти. Эта реакция даёт новое требование (запчасти можно записывать без ввода текста) и другой дизайн (сканирование штрихкода). Требование остаётся стабильным, а дизайн меняется.
Подводные камни#
- Утверждение макета как «требований». Экран фиксирует одно решение. Когда экран меняется, никто не знает, какие его части были существенны. Записывайте лежащие в основе потребности отдельно.
- Отказ рисовать. Некоторые аналитики совсем избегают дизайнов, чтобы «оставаться нейтральными». Так теряется мощный инструмент выявления. Рисуйте, но помечайте эскиз как один из вариантов.
- Избыточная детализация в требовании. «Система должна показывать красный баннер вверху экрана» — это дизайн. Спросите, для чего нужен баннер.
- Различие как правило, за соблюдением которого нужно следить. Цель — ясность в том, что зафиксировано (потребность) и что может меняться (решение), а не надзор.
Источники и что почитать#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Разд. 2.5 (требования и дизайны); разд. 11 (ракурс «Информационные технологии»).