Приветствую, читатель!

В этой статье я постараюсь рассказать о профессии бизнес-аналитика для начинающих специалистов и тех, кто хочет начать свою карьеру.

Без опыта работы в этой сфере, вы можете задаться резонным вопросом: «В чем разница между бизнес- и системным аналитиком?» Ответ на этот вопрос много раз пытались найти на Хабре, однозначного ответа нет ни у кого, но есть много хороших статей.

Одна из них: Бизнес-аналитик и системный аналитик в IT. Разбираемся в сортах

Введение

Я работаю аналитиком Oracle Siebel CRM уже более 3 лет, более года занимаюсь подготовкой стажеров к суровым реалиям трудовых будней. Как правило, мой стиль обучения состоит из небольших вводных лекций и незамедлительной утилизации стажера на реальные задачи с контролем качества выполнения.

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

Чем занимается аналитик?

Обычно, отвечая на вопрос о своей профессии, я говорю, что аналитик — это переводчик с языка гуманитариев на язык технарей. Но разве бывает в мире все так просто?

На самом деле, аналитика состоит из следующих шагов:

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

Подробнее о каждом шаге

Получение запроса на доработку

Как правило, заказчиками доработок являются люди, далекие от сферы IT. Требования редко бывают систематизированы, описаны четко и логично. Это то, что вам придется исправить, прежде чем передавать задачу разработчику.

Уточнение желаемого результата

Здесь вы должны уточнить, чего конкретно хочет заказчик, с точки зрения IT-системы. Это может быть чем угодно: смена статуса заявки, генерация документа, отправка SMS или E-mail, в общем и целом, все, на что ваша система способна.

Всегда руководствуйтесь следующими принципами на этом этапе:

Для вас не должно быть ни одного абстрактного понятия в постановке задачи от заказчика. Если вы не уверены, что понимание некоторых слов у вас и у заказчика одинаковы, убедитесь в том, что вы пришли к взаимопониманию.
Не бывает глупых вопросов, бывают неправильно сформулированные и неправильно адресованные. Аналитик не является экспертом во всех областях бизнеса, но должен уметь быстро разобраться в новой области. Не бойтесь спрашивать.

Уточнение текущего процесса

Чаще всего текущий процесс работы называют «процесс AS-IS»
После завершения данного этапа, вы должны представить себе процесс в виде черного ящика.

Предварительная проектировка решения

Этот этап подразумевает под собой определение будущего процесса или, как говорят, «процесс TO-BE».

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

Руководствуйтесь следующими принципами:

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

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

Вы могли заметить, что в белом ящике появились «Входные данные 3». Иногда вы можете столкнуться с тем, что для достижения результата недостаточно данных в системе. Возьмем за пример некую справку о заключении договора между компанией заказчика и клиентом, в которой должно быть отражено отчество клиента, не хранящееся в вашей системе. В таком случае, вы обязательно должны сообщить об этом заказчику и предложить решение проблемы, например, добавить поле «Отчество» в систему и обеспечить его заполнение. Для пользователей, в свою очередь, это означает заполнение дополнительного поля при работе с системой, что увеличивает нагрузку на сотрудников компании заказчика, длительность обслуживания клиента. Такие изменения обязательно должны быть согласованы с заказчиком.

Корректировка решения

Порой согласование новых шагов процесса проходит с замечаниями к вашему решению от заказчика. В таком случае, вы должны скорректировать предлагаемое решение. Но такое происходит не всегда. Если вам удалось избежать замечаний, значит вы — молодец и закончили проектировку еще на шаге «Предварительная проектировка решения»

Согласование процесса

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

Оформление технического задания

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

Тестирование функционала

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

Документация

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

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

Передача функционала заказчику

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

Вывод

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

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

Надеюсь, моя статья помогла вам сложить впечатление об аналитике и привела к осознанию вашего пути в жизни. Успехов!

Про анализ без страшных слов