Читать книгу Бизнес-анализ от а до я: гид для начинающих - - Страница 11

И вот пропустив несколько процессных шагов (пока) в данной истории и получив подписанное функциональное требование я сажусь за написание/создание дизайна к этому требованию. Описываю я функциональный дизайн в документе, который называется Спецификация по функциональному дизайну (Functional Design Specification). Уточнение – то, что я описываю ниже (да и выше) не является общей лучшей-практикой, которую я очень рекомендую здесь, нет. Любой подход к написанию требований зависит от окружающего контекста.

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

Теперь можно написать краткое и простым языком описание, о чем будет этот дизайн и для этого у меня есть раздел, который так и называется «Описание». Прочитав этот раздел, любой человек клиент, разработчик, проектный менеджер и кто угодно – сможет понять, в чем смысл этого дизайна и о чем это.

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

После этого я описываю входные условия, чтобы необходимая функциональность могла использоваться. «Входные условия»: пользователь должен зайти в систему СУК, выбрать компанию и перейти на главную страницу компании.

Затем я описываю что же именно – какую функциональность получит пользователь. Обычно я пишу нумерованным списком в логической последовательности шаги, как ведет себя система при определенном варианте/сценарии ее использования – так легче структурировать цепочку действий и в дальнейшем обсуждать любые комментарии («а вот в шаге/пункте 4 у тебя мне кажется нужно …»).

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

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

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

«Кредитный рейтинг» название- текстовое, неизменяемое.

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

«Кредитный статус» название – текстовое, неизменяемое.

Кредитный статус значение – неизменяемое, графическое отображение «круг» с тремя вариантами красный/желтый/зеленый.

«Кредитные условия» название – текстовое, неизменяемое.

Кредитные условия значение – неизменяемые три текстовых поля со «значениями»: а) разрешенная рассрочка: «ХХ» месяцев б) статус контракта: «активен»/«неактивен»/«истек» в) размер задолженности: «нет» / «размер задолженности».

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

Вот и всё – это и есть описание основного блока дизайна. Естественно, я специально взял наиболее простую функциональность, чтобы не потратить 10-20 страниц только на описание дизайна.

После описания сценария я добавляю еще раздел «Изменение данных» – в данном дизайне он будет пуст или я укажу «изменений данных не предусмотрено», так как у пользователя нет возможности изменить какие-либо данные для данной функциональности.

Функциональный дизайн готов к использованию разработчиками! Но это еще не всё – в большинстве случаев функциональность для пользователя должна «идти» вместе визуальной и дата составляющими. Ведь кроме понимания, как должна быть реализована функциональность, команде разработчиков так же надо знать, как эта функциональность будет выглядеть и откуда будут поступать необходимые динамические данные для этой визуализации. Для этих целей я создаю еще два документа – Спецификацию по пользовательскому интерфейсу (СПИ/ User Interface Specification) и Спецификация по модели данных(СМД/ Data Model Specification). Эти два документа являются тоже частью дизайна требования. СПИ содержит дизайн макеты, как будет визуально выглядеть раздел кредитная история для пользователя. А СМД содержит описание, где будут храниться данные, которые я описал в функциональном дизайне. Почему визуальная составляющая хранилась в отдельном документе? На тот момент я не обладал достаточным опытом, чтобы изменить подход, но вот сейчас я предпочитаю самый оптимальный подход это описание и функциональной части и визуальной в одном месте – это даёт любому пользователю артефакта сразу понятную картину, что, как и где должно работать. А вот модель данных должна на мой взгляд создаваться отдельно и не может быть представлена кусками в каждом функциональном дизайне. Цель документирование всей модели данных в одном месте это визуализировать и дать полную картину именно о модели данных и о ее корректности и логичности и связей между всеми объектами и атрибутами и их свойствами. Не буду углубляться сейчас, так как вернемся к этому позже в следующих шагах в деталях.

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

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