В этой статье я постараюсь рассказать о профессии бизнес-аналитика для начинающих специалистов и тех, кто хочет начать свою карьеру.
Без опыта работы в этой сфере, вы можете задаться резонным вопросом: В чем разница между бизнес- и системным аналитиком? Ответ на этот вопрос много раз пытались найти на Хабре, однозначного ответа нет ни у кого, но есть много хороших статей.
Одна из них: Бизнес-аналитик и системный аналитик в IT. Разбираемся в сортах
Введение
Я работаю аналитиком Oracle Siebel CRM уже более 3 лет, более года занимаюсь подготовкой стажеров к суровым реалиям трудовых будней. Как правило, мой стиль обучения состоит из небольших вводных лекций и незамедлительной утилизации стажера на реальные задачи с контролем качества выполнения.
В условиях самоизоляции я столкнулся с интересным кейсом: работая консультантом на компанию с жесткими требованиями к безопасности, у меня не было возможности закреплять переданные теоретические знания практическим применением. Это столкнуло меня с очень интересным вызовом для ментора: необходимостью подавать теорию таким образом, чтобы минимизировать абстрактные для стажера понятия, подготавливая его к реальным задачам без практического опыта. Полученный опыт я попытаюсь зафиксировать в данной статье.
Чем занимается аналитик?
Обычно, отвечая на вопрос о своей профессии, я говорю, что аналитик это переводчик с языка гуманитариев на язык технарей. Но разве бывает в мире все так просто?
На самом деле, аналитика состоит из следующих шагов:
- Получение запроса на доработку системы
- Уточнение желаемого результата, получаемого пользователем в конце вашего процесса
- Уточнение текущего процесса работы
- Предварительная проектировка решения
- Согласование с заказчиком дополнительных шагов процесса, если они необходимы для достижения результата,
- Корректировка решения
- Согласование процесса с заказчиком
- Оформление технического задания для разработчика
- Тестирование основных сценариев работы функционала
- Оформление документации, написание пользовательских инструкций
- Передача функционала заказчику
Подробнее о каждом шаге
Получение запроса на доработку
Как правило, заказчиками доработок являются люди, далекие от сферы IT. Требования редко бывают систематизированы, описаны четко и логично. Это то, что вам придется исправить, прежде чем передавать задачу разработчику.
Уточнение желаемого результата
Здесь вы должны уточнить, чего конкретно хочет заказчик. Это может быть чем угодно: смена статуса заявки, генерация документа, отправка SMS или E-mail, в общем и целом, все, что может делать IT-система.
Всегда руководствуйтесь следующими принципами на этом этапе:
- Для вас не должно быть ни одного абстрактного понятия в постановке. Если вы не уверены, что понимание некоторых слов у вас и у заказчика одинаковы, убедитесь в том, что это не так.
- Не бывает глупых вопросов, бывают неправильно сформулированные и неправильно адресованные. Аналитик не является экспертом во всех областях бизнеса, но должен уметь быстро разобраться в новой области. Не бойтесь спрашивать.
Уточнение текущего процесса
Чаще всего текущий процесс работы называют процесс AS-IS
После завершения данного этапа, вы должны представить себе процесс в виде черного ящика.
Предварительная проектировка решения
Этот этап подразумевает под собой определение будущего процесса или, как говорят, процесс TO-BE.
После завершения данного этапа, ваш черный ящик должен превратиться в белый, то есть вы точно должны знать, что происходит внутри процесса. Выглядит это примерно так:
Руководствуйтесь следующими принципами:
- Процесс нужно разделить на арифметические и логические функции. Квадраты внутри белого ящика это и есть данные функции.
- При проектировке вы должны ответить себе на все вопросы а что, если... касательно своего решения. Если в будущем вам зададут вопрос, начинающийся с этих слов, а вы не сможете ответить, значит вы проделали работу плохо.
Согласование дополнительных шагов
Вы могли заметить, что в белом ящике появились Входные данные 3. Иногда вы можете столкнуться с тем, что для достижения результата недостаточно данных в системе. Возьмем за пример некую справку о заключении договора между компанией заказчика и клиентом, в которой должно быть отражено отчество клиента, не хранящееся в вашей системе. В таком случае, вы обязательно должны сообщить об этом заказчику и предложить решение проблемы, например, добавить поле Отчество в систему и обеспечить его заполнение. Для пользователей это означает заполнение дополнительного поля при работе с системой, что должно быть согласовано с заказчиком.
Корректировка решения
Порой согласование новых шагов процесса проходит с замечаниями к вашему решению от заказчика. В таком случае, вы должны скорректировать предлагаемое решение. Но такое происходит не всегда, что означает, что вы молодец и закончили проектировку еще на шаге Предварительная проектировка решения
Согласование процесса
После завершения проектировки, процесс нужно согласовать с заказчиком. Формат согласования чаще всего зависит от реалий конкретной компании и конкретного заказчика. Это могут быть текстовые описания процесса, описание в нотации описания бизнес-процессов или устное согласование.
Оформление технического задания
Формат технического задания также зависит от принятых в компаниях заказчика и исполнителя норм и, часто, от компетенции разработчика: неопытным разработчикам нужно более детальное описание процесса. За свою карьеру я встречал компании, в которых вообще не было технических заданий и все обсуждалось в свободном формате, но у всех постановок есть общая черта: вы должны описать арифметические и логические функции, определенные на шаге проектирования, текстом или визуально, в виде блок-схем.
Тестирование функционала
Предугадывая вопрос, да, аналитики часто занимаются тестированием. Но, как правило, это тестирование поверхностное, чтобы убедиться в том, что разработчик правильно вас понял. Обычно оно ограничивается прохождением основных сценариев работы, чтобы выявить наличие критичных дефектов, то есть багов, которые не позволяют достичь желаемого результата никаким путем. Поиском мелких дефектов и тестированием функционала в разных условиях занимаются специалисты QA.
Документация
Пожалуй, это самый нелюбимый этап большинства аналитиков, но ваше экспертное знание функционала должно быть зафиксировано в письменном виде. Пишите документацию хорошо: процесс в ней должен быть описан достаточно подробно, чтобы непросвещенный специалист мог понять, что происходит внутри белого ящика, и достаточно коротко, чтобы это можно было прочитать и не уснуть.
Пользовательские инструкции это короткая памятка для конечного пользователя вашего функционала, в которой действия пользователя описаны по шагам. Этот вид документации должен состоять из списка действий, в нем не должно содержаться технических терминов.
Формат данных документов тоже зависит от норм, принятых в конкретной компании-заказчике.
Передача функционала заказчику
Самая приятная часть работы. Здесь вы демонстрируете выполненную работу заказчику, собираете лавры, гордитесь проделанной работой и заряжаетесь позитивом для следующей задачи.
Вывод
Работа аналитика включает в себя кучу общения, мозговых штурмов и использование всех возможностей логики, которой вас одарила природа.
Если вам доставляет удовольствие систематизация и оптимизация, если вы любите, чтобы в жизни все было четко и логично, работа аналитиком доставит вам кучу удовольствия, и вы наверняка добьетесь вершин в карьере.
Надеюсь, моя статья помогла вам сложить впечатление об аналитике и привела к осознанию вашего пути в жизни. Успехов!
