Последовательность выполнения работ по аналитике

Сегодня постараемся разобраться в каком порядке выполнять работы аналитику. Всё многообразие ситуаций и систем в одной статье нам рассмотреть не удастся, поэтому обозначу допущения:

1. Проектирование монолита рассматривать не будем – этот тип систем отмирает. Поговорим про разработку веб-приложений, мобильных приложений и бэка для них.

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

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

⭐ показать как разделяются задачи бизнес и системной аналитики,

⭐ слегка затронуть вопросы разделения задач в таск-трекерах на фронт и бэк-разработчиков,

⭐ показать почему нельзя проектировать отдельно фронт и отдельно бэк.

Бэк (бэкенд, backend, back) — серверная часть веб-приложений и сайтов. Он отвечает за работу баз данных, серверов и логику, которая происходит на серверной стороне.

Фронт (фронтэнд, frontend, front) — клиентская часть веб-приложений или мобильные приложения, которые взаимодействует с пользователем.

Для упрощения всего процесса будем считать, что началом работ является поступление от заказчика (или формирование командой продукта) набора бизнес-требований к доработке продукта.

На первом этапе бизнес-аналитик должен декомпозировать общую постановку на отдельные функции.

Далее выполняется проработка клиентского пути (это задача со звездочкой, которая зачастую не решается командой совсем, либо решается отдельным продуктовым аналитиком – но об этом стоит поговорить отдельно) .

На следующем шаге бизнес-аналитик рисует прототип интерфейса и пишет описание к нему, которое включает в себя состав полей, типы элементов экранной формы (выпадающий список, текстовое поле и т. д.), способы получения данных для этих полей (ручное заполнение, расчетное значение, получение с бэка) , маски ввода, ФЛК, условия видимости, доступности, обязательность заполнения. Этот набор информации является постановкой задачи дизайнеру, который отрисует макеты. На этом этапе возможен возврат задачи на бизнес-аналитика, если дизайнер ограничен используемыми в компании компонентами или предложит более дружественное клиенту распределение элементов по экранной форме. Бывают команды, в которых макеты рисует бизнес-аналитик, но не будем о грустном.

Кажется, что после завершения работы над макетами можно ставить задачу на фронт-разработчика. Сделайте минуту перерыва в чтении и ответьте на вопрос – какой информации не хватает на данном этапе, чтобы передать задачу в разработку фронту? Свои ответы можно написать в комментариях, а потом вернуться и дочитать статью.

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

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

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

А теперь аналитику снова придется вернуться к фронтовой части и прописать для каждого элемента экранной формы метод и параметр для его взаимодействия с бэком – только в этом случае постановка на фронт может считаться достаточно качественной.

Схема процесса приведена на рисунке 👇

Хочу узнать ваше мнение:

В какой нотации нарисована данная схема?

Как ее можно улучшить?

Жду ответы на все три вопроса в комментариях или в телеграм-канале