Что такое артефакты в бизнес-анализе и для чего они нужны

Артефакт в бизнес-анализе: что включаем в это понятие

Под словом «артефакт» понимают что-то условно вещественное, материальное, то, что является итогом какой-то деятельности. Если говорить об этом термине применимо к бизнес-анализу, можно обратиться к классическому определению IIBA (International Institute of Business Analysis). Эта организация предоставляет условный уровень стандарта по бизнес-анализу, сертификации и т.п. Согласно IIBA, артефактом является «любой объект, имеющий отношение к решению, созданный в ходе работы по бизнес-анализу». Таким образом, артефактом можно назвать любой документ, который был создан бизнес-аналитиком для решения своих задач.

Список основных артефактов бизнес-аналитика

Самый первый артефакт, над которым начинает работать бизнес-аналитик, как ни банально это прозвучит, но это его собственный план работы. Ведь перед тем, как начать работу над проектом, аналитик должен получить вводные: чего хочет клиент, какое решение он хочет найти и для чего и т.п. При подготовке этого плана, если команда состоит из нескольких человек (например, есть не только BA, но и дизайнер, техлид или архитектор, которые тоже могут иметь отношение к составлению определенных артефактов), я прописываю всё, что нам понадобится сделать, в какой очередности и примерное время, которое на это потребуется.

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

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

V&S (vision and scope) - более обширный документ. В зависимости от потребностей проекта он может содержать бизнесовую часть (стратегия, видение продукта, который должен получится, какие-то маркетинговые нюансы - сравнение с конкурентами, анализ рынка и проч.) и скоуп - описание возможной версии MVP (минимально жизнеспособный продукт) и последующих версий. Этот артефакт важен тем, что по результатам его составления может быть принято решение о том, что идея нежизнеспособна и не стоит начинать проект.

SRS (software requirements specification, или, попросту говоря, спецификации) - следующий уровень, к которому приступают только тогда, когда есть понимание задач. Это самый что ни на есть классический артефакт, с которым работает BA. Название документа говорит само за себя - он полностью описывает то, как должна быть реализована система. В спецификациях указываются допущения, если мы их принимаем, и ограничения, связанные с будущей имплементацией (например, доступность приложения только на определенных языках или присутствие продукта на каких-то рынках, где есть специфические условия оплат/доставок и проч.).

Диаграммы и схемы (сюда относят process flow, use cases, user journey maps и многое другое). Данная категория артефактов может быть в пограничной зоне ответственности между BA и системным аналитиком, архитектором.

С помощью process flow отображается, как система будет справляться с ключевым процессом в приложении; что, зачем и куда отправляется, как обрабатывается и что получается на выходе. Use cases позволяют на основе потока идей визуализировать варианты использования системы; показывают, кто будет взаимодействовать с системой и какой функционал будет доступен. User journey maps визуализируют путь пользователей.

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

User stories - достаточно распространенный формат документации в связи с повсеместным использованием Agile/Scrum. История пользователя описывается в форме паттерна:

Как < тип пользователя >, я хочу < сделать что >, чтобы < для чего >.

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

Mock data (specific representative test data) - наборы данных, которые позволят увидеть результат работы того или иного функционала с данными, которые наиболее приближены к реальным обстоятельствам.

Meeting minutes and other communication-related documents - важные артефакты, про которые не стоит забывать. У бизнес-аналитика всегда много коммуникации с клиентом и командой, после совещаний происходят какие-то договоренности. Митинг может быть сегодня, а возможность приступить к правкам - лишь спустя 3-4-5 дней, память будет не та, а когда всё записано - ничего не упустишь.

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

Инструменты, которые упрощают работу с артефактами

В основном бизнес-аналитики пользуются инструментами типа Confluence/Jira, там миллион темплейтов на разные темы. Тот же Notion набирает популярность. Однако с опытом, когда накапливается бэкграунд из проектов, у каждого BA появляются какие-то кастомные варианты.

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

Важные особенности артефактов бизнес-аналитика

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

Если сроки ограничены, к примеру, речь идет о стартап проекте, где нужно как можно быстрее сделать «скелет» продукта, то, понятное дело, в арсенале BA не будет тяжеловесных документов-талмудов, потому что все может быстро поменяться. Скорее всего, основополагающим в таком случае будет features list и process flow diagram - он поможет собрать разрозненные представления воедино, сразу увидеть какие-то зависимости (например, что-то невозможно какой-то шаг, не реализовав до этого другую функцию).

Если же клиент пришел с идеей, но сам до конца не уверен, нужна она ему или нет, что он получит от этого проекта, не анализировал рынок, не знает о потенциальных возможностях для роста - тогда команда всё же проведет предварительное исследование, чтобы разобраться в целях и задачах - на выходе получим vision&scope, второй частью может быть features list.

Клиент из числа enterprise-компаний? Тогда выбор артефактов будет зависеть от задач. Если это поддержание тяжеловесной системы, без каких-то больших нововведений, то скорее всего в ход пойдут спецификации, диаграммы и схемы. А вот если речь идет про супер новый независимый модуль, то может быть применен стартап-подход. Итого: список артефактов должен определяться потребностями конкретного проекта.

Пара ремарок про user stories:

1. Несмотря на то, что формула, по которой строится история, довольна проста, очень важно выдержать все 3 части, не забыв последнюю. Именно благодаря ей мы видим, что случается с пользователем после совершенного действия.
2. Нельзя мешать несколько юзер ролей в одну историю. Если существуют идентичные действия для нескольких ролей, нужно продумать, как объединить их.
3. Желательно организовать структуру юзер историй такой, чтобы работа над ней не требовала длительного времени (наиболее оптимальный вариант - 1-2 дня). Тогда команда сможет постепенно продвигаться по статусам и реализовывать запланированный функционал итеративно.

Риски, связанные с артефактами в бизнес-анализе

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

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

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