Бизнес-анализ от а до я: гид для начинающих

Михаил Бахрах (2023)

Книга предлагает всестороннее исследование профессии бизнес-аналитика ИТ, основанное на 100% практическом опыте автора, реальных сценариях и решениях. Автор, опираясь на десятилетний опыт работы в качестве бизнес-аналитика ИТ, делится исключительными знаниями, основанными на личных успехах.Роль бизнес-аналитиков ИТ объясняется простыми словами, что делает ее доступной не только для профессионалов в этой области, но также для тех, кто вне мира ИТ и стремится попробовать себя в бизнес-анализе.В отчете LinkedIn за 2020 год навык ИТ бизнес-анализа был классифицирован как пятый по популярности и востребованности.Независимо от того, начинаете ли вы свой путь в качестве бизнес-аналитика ИТ или ищете новые идеи для профессионального роста, эта книга обещает захватывающее путешествие!

Дизайн требования

Получив подписанное функциональное требование, я приступаю к разработке дизайна, который описывается в документе, называемом"Спецификация по функциональному дизайну"(Functional Design Specification). Стоит отметить, что подходы, описываемые здесь, адаптированы под конкретный проект и могут отличаться в зависимости от контекста.

Как начинается процесс? Сначала я создаю уникальный идентификатор для дизайна, например, ФД-СУК-КР-1."ФД"здесь обозначает"Функциональный Дизайн". Затем формируется короткое название дизайна, которое будет использоваться как заголовок документа, например,"Просмотр кредитной информации на главной странице компании". Функциональное требование может соотноситься как с одним, так и с несколькими дизайнами.

Описание дизайна:

"Описание: Данный дизайн позволяет пользователю видеть основные кредитные показатели компании-клиента на главной странице профиля. Эта информация помогает в принятии решений."

Входные условия:

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

Описание функциональности:

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

Шаги/Сценарий:

На странице профиля компании система отображает раздел «Кредитная информация».

В разделе «Кредитная информация» отображаются следующие поля/данные:

Кредитный рейтинг (название) — текстовое, неизменяемое.

Кредитный рейтинг (значение) — неизменяемое, цифровое, двузначное число с поддержкой десятичного значения, диапазон значений от 0 до 10.

Кредитный статус (название) — текстовое, неизменяемое.

Кредитный статус (значение) — неизменяемое, графическое отображение в виде круга с тремя цветами: красный, желтый, зеленый.

Кредитные условия (название) — текстовое, неизменяемое.

Кредитные условия (значение) — неизменяемые, три текстовых поля со значениями:

а) разрешенная рассрочка: «ХХ» месяцев;

б) статус контракта: «активен», «неактивен» или «истек»;

в) размер задолженности: «нет» или «размер задолженности».

Кредитная история (название) — текстовое, неизменяемое, оформлено как ссылка (функциональность вне границ этого дизайна, см. ФД-СУК-КР-4).

Заключение:

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

Изменение данных:

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

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

Для этих целей я разрабатываю два дополнительных документа:

Спецификация по пользовательскому интерфейсу (СПИ / User Interface Specification), которая содержит макеты того, как будет выглядеть раздел «Кредитная история» для пользователя.

Спецификация по модели данных (СМД / Data Model Specification), описывающая хранение данных, использованных в функциональном дизайне.

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

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

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

Вот, собственно, что я хотел рассказать про реальные первые месяцы моей работы бизнес-аналитиком. Я не общался с клиентом и не занимался выявлением бизнес — или функциональных требований — таких обязанностей у меня не было, так как не было и опыта, и нужно было сначала изучить базовые активности. Я даже не знал, какой используется и из чего состоит цикл разработки программы/системы. А использовали мы методологию разработки, которая называется «Водопад» (Waterfall). Почему «Водопад»? Потому что создание системы/продукта поделено на этапы, которые всегда выполняются в последовательном порядке — один за другим. Отсутствие этих навыков и знаний — было ли это плохо или негативно в плане моего опыта? На мой взгляд, нет, так как я получал полноценный опыт в самом базовом и необходимом БА навыке — документирование требований и их дизайна.

То, что я описывал выше, как вы поняли, это «жесткие» навыки (Hard skills). А вот какие из «мягких» навыков (Soft skills) я бы подсветил, в которых я получал опыт и считал важными? Думаю, я стартовал с трех основных мягких навыков, которые я назову в формате ролей: командный игрок, мистер-вопрошайка и тайм-менеджер. Уточню, что некоторые приобретенные способности, которые я называю «мягкими» навыками выше, не являются прямо официальными навыками, которые указаны в книгах, или, возможно, они указаны, но в других терминах. Я написал именно «стартовал», так как все эти три навыка я продолжал развивать на протяжении своей БА карьеры. Расскажу кратко о них и почему именно они мне показались (или нет) важными на старте: