Разбираем тенденции IT-образования, на которые стоит обратить внимание в 2022 году.
Под словом «артефакт» в бизнес-анализе понимают целый перечень разнообразных и очень важных для успеха проекта документов - диаграммы и схемы, спецификации и прототипы, user stories и многое другое. Какие из артефактов должны быть в постоянном арсенале каждого бизнес-аналитика? Выяснили у Юлии Пшевлоцкой, Business Analyst iTechArt.
Артефакт в бизнес-анализе: что включаем в это понятие
Под словом «артефакт» понимают что-то условно вещественное, материальное, то, что является итогом какой-то деятельности. Если говорить об этом термине применимо к бизнес-анализу, можно обратиться к классическому определению 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:
- Несмотря на то, что формула, по которой строится история, довольна проста, очень важно выдержать все 3 части, не забыв последнюю. Именно благодаря ей мы видим, что случается с пользователем после совершенного действия.
- Нельзя мешать несколько юзер ролей в одну историю. Если существуют идентичные действия для нескольких ролей, нужно продумать, как объединить их.
- Желательно организовать структуру юзер историй такой, чтобы работа над ней не требовала длительного времени (наиболее оптимальный вариант - 1-2 дня). Тогда команда сможет постепенно продвигаться по статусам и реализовывать запланированный функционал итеративно.
Риски, связанные с артефактами в бизнес-анализе
Если нет минимального набора артефактов, того же features list, то стартовать проект крайне рискованно. Без зафиксированных требований будут страдать и сроки реализации, и конечное решение. Ведь если клиент в самом начале не до конца понимает, чего он хочет, без прописанных договоренностей может получится ситуация, что окончательный результат его не удовлетворил. Безусловно, кто-то готов допускать эти риски и начинать работу без артефактов, но такая ситуация скорее исключение, чем правило.
И, конечно, после того, как список артефактов определен, он не должен лечь мертвым грузом где-то в компьютере бизнес-аналитика. Желательно, чтобы к нему было обращение у всех вовлеченных в проект членов команды.
Артефакты должны обновляться по мере изменений в проекте. Если забыть дополнить документ один раз, потом второй, количество правок вырастет, как снежный ком. А что если проект долгосрочный, часть команды поменялись? Пиши пропало - знания о системе уходят, и начинаются страдания новой команды. В конечном итоге, всё равно придётся всё задокументировать. Поэтому лучше дополнять артефакты сразу и не подвергать себя риску.