Почему требования к бизнес и системному аналитику пересекаются. Часть 1

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

Вот перечень требований, который вы вероятно встретите и в описании вакансии бизнес-аналитика и в описании требований к системному аналитику:

1. Языки моделирования, нотации, диаграммы (BPMN, UML, IDEF0, Use Case и User Story).

2. Методологии разработки (Waterfall, scram (agile), kanban (agile)).

3. Методы сбора и описания требований к ПО, сдача работ по контракту (BABOK, Вигерс, ГОСТ).

4. Знание SQL и основы базы данных (простые select'ы, JOIN, агрегирующие функции, изменение данных, проектирование концептуальной и логической модели данных).

Это ошибка работодателей или реальная потребность в дублировании скилов? Давайте разберем по пунктам.

Работа бизнес-аналитика заключается в том, чтобы определить какой продукт мы разрабатываем, а для этого ему необходимо пообщаться с заказчиком работ, с конечными пользователями продукта (с представителями целевой аудитории), определить клиентские пути, которые необходимо будет реализовать в продукте, затем оформить результаты своих трудов в виде некоего документа, согласовать этот документ с заказчиком и передать в работу системному аналитику. Чаще всего этот документ называют бизнес-функциональными требованиями, сокращенно БФТ. Для простоты далее в статье будем использовать именно этот термин.

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

Таким образом в БФТ должен быть:

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

2. Схемы, которые системный аналитик посмотрит в первую очередь, а уж потом перейдет к тексту, если к схеме есть вопросы.

А значит бизнес-аналитик должен уметь максимально хорошо и детально рисовать схемы (чтобы вопросов не возникло), а системный аналитик должен уметь их прочитать. Вот тут и появляется первое пересечение – общепринятые нотации. Если говорить про уже готовые схемы BMPN, IDEF, UML то они достаточно просты для интуитивного понимания, без предварительного изучения нотаций и методологий (т.е. с точки зрения системного аналитика). Но если вы хотите быть хорошим (читай «дорогим») бизнес-аналитиком, то тонкости отрисовки схем в различных нотациях лучше изучить досконально. Какой вид схем предпочитает заказчик и/или потенциальный работодатель на этапе поиска работы угадать невозможно, все основывается на личных предпочтениях или исторических предпосылках. Поэтому если вы хотите быть востребованным бизнес-аналитиком лучше изучить и BMPN2.0 и UML и IDEF0.

Книгой по BPMN я поделюсь в своем Телеграм-канале уже завтра. Но вот кратная подсказка, которую удобно использовать при создании и чтении схем:

http://www.bpmb.de/images/BPMN2_0_Poster_RU.pdf

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

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

Либо бизнес, либо системному аналитику скорее всего придется нарисовать:

* Диаграмму прецедентов или диаграмму вариантов использования (Use case diagram);

* Диаграмму последовательности (Sequence diagram).

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

Кто будет заниматься use-case и sequence-диаграммами (бизнес или системный аналитик) вопрос спорный и ответ опять же зависит от устоявшегося у работодателя разделения зон ответственности. А вот вопрос: Нужно ли рисовать и схему в нотации BPMN2.0 и Sequence-диаграмму UML для одного и того же процесса? Как вы считаете? Обсудим в Tелеграм-канале сразу после изучения BPMN и UML.

Если вы введете в поисковике «Методологии разработки ПО», то найдете множество статей про лучшие методологии. Где-то будет упоминаться 7 лучших, где-то 8. «Зачем это мне? Я же не владелец продукта и не руководитель проекта» - спросите вы. Вам, бизнес или системному аналитику это важно чтобы понимать, как будет устроена ваша ежедневная работа у конкретного работодателя. Не забудьте задать на собеседовании вопрос – по какой методологии принято работать в потенциальной команде.

Waterfall или «Водопад» - каскадная, последовательная разработка продуктов. Это одна из самых старых методологий и ей пользуются все реже, однако она все еще встречается (например, при работе по ФЗ 44 – но об этом в отдельной статье).

Основные принципы работы Waterfall:

* Документы и инструкции — это важно, всё должно быть зафиксировано.

* Следующий этап работы не начинается, пока не закончится предыдущий.

* Пропускать этапы нельзя.

* Нет итераций, есть один общий процесс создания продукта.

* Выявлять и исправлять ошибки — только на этапе тестирования.

* Клиент не участвует в создании продукта после постановки ТЗ.

Разработка при использовании каскадной модели — это пять строго последовательных этапов:
Аналитика ➡ Проектирование ➡ Создание прототипа и дизайн-макетов ➡ Разработка ➡ Тестирование ➡ Эксплуатация и поддержка.

Agile - гибкая методология разработки, обобщающий термин для целого ряда подходов и практик. Agile является скорее философией и набором ценностей, чем конкретной методикой работы.

Система Kanban (один из вариаций Agile) основана на понятии канбан-доски, в которой есть ряд колонок(столбцов), например, схожие с Waterfall (Аналитика, Дизайн, Разработка, Тестирование) и карточки. Основное отличие в том, что карточка задачи может перемещаться из столбца в столбец в любую сторону. Например, если на этапе тестирования задачи команда выявила недоработку аналитики или увидела как улучшить дизайн, то карточка вернется в столбец «Аналитика» или «Дизайн», чего не может произойти при работе по Waterfall.

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

Agile предполагает ряд церемоний и ритуалов, которые будут влиять на вас ежедневно. Например, демо чаще всего проводит либо аналитик, либо тестировщик. Утренний standup возможно вызовет неприятие, если работа команды организована неоптимально.

Так почему же аналитику необходимо изучать и знать методологии? Как минимум потому, что вы возможно тот самый скрам-мастер, который придя в команду спасет команду от утомительных встреч? Или вы лучше всех понимаете, как провести ретро и станете незаменимым в команде? Не забывайте, чем больше мы знаем, тем дороже стоим на рынке.

Если вы дочитали до этого момента – вы молодец! Завтра обсудим зачем аналитику ГОСТы и почему бизнес-аналитик должен немного разбираться в базах данных.