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

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

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

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

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

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

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

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

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

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

Командный игрок