Многие авторы статей объясняют данную профессию так: "БА (Бизнес-аналитик) - это прослойка между Заказчиком и Командой разработки (дизайнеры, разработчики, тестировщики).

Считаю это грубым описанием. Тогда уж писали бы про "прокладку между"...ну вы поняли.

По моему глубокому убеждению, БА - это своего рода разведчик на АйТишном поле боя, который прорабатывает будущие боевые задачи для разработки функционала приложения.

Чтобы глубже понять смысл работы БА, давайте расскажу в "двух" предложениях, как происходит разработка функционала любого сервиса:

1. У заказчика появляется идея (и деньги) по разработке полезного сервиса, который принесет радость простым пользователям
2. Заказчик заключает договор с IT-компанией на разработку сервиса
3. К заказчику приходит БА и начинает выяснять первоначальные требования к разрабатываемому функционалу:

- Что это будет за функционал
- Как он должен работать
- Есть ли уже разработанный функционал у конкурентов
- Какой результат должен получиться от использования данного функционала

И еще 100500 вопросов, которые покажут общую картину "Чего хочет заказчик"

4. После получения всех требований и фиксации их в документе начинается самое интересное. БА анализирует собранные требования и "раскладывает их по полочкам":

- Это требование относится к работе функционала

- Это требование относится к будущему дизайну

- Это требование относится к работе самой системы сервиса

- Это требование можно взять в анализ чуть позже, когда закончим разработку основного функционала

- Это требование неадекватно, так как временные затраты на его разработку выходят за рамки дедлайна

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

Т.е. по сути аналитик берет консультации у разработчиков и уже корректирует требования в нечто похожее на Техническое Задание (ТЗ).

5. БА описывает логику работы функционала на основе собранных требований от заказчика и проанализированных вариантов решений от команды разработки.

И с этим документом идет к Заказчику, чтобы согласовать разработку функционала:

- Если заказчик вносит корректировки в будущую разработку, то тут аналитик либо защищает документацию, либо соглашается с корректировками и возвращается к 4 пункту

- Если заказчик утверждает будущую разработку, то аналитик приступает к ШЕСТОМУ пункту

6. Описание подробного ТЗ для команды разработки.

В данном случае аналитик может расписывать:

- Макеты и состав элементов будущего интерфейса Дизайнеру

- Логику работы функционала Разработчикам

- Проверку работы функционала на основе кейсов Тестировщикам

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

7. Передача ТЗ команде разработки.

Всё?....

А вот и нет.

После того, как ТЗ было передано на разработку, аналитик начинает прорабатывать будущие задачи на разработку нового функционала. А это, как мы уже поняли - пункт 3 нашего документа.

Цикл повторяется.

Правда есть один маленький нюанс: а что делать, когда команда разработки выполнила поставленную задачу по ТЗ ?

8. Аналитик принимает разработанный функционал у разработчиков согласно ТЗ:

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

а) Разраб не понял задачу и сделал по своему усмотрению

б) Разраб понял задачу, но выполнил по своему видению

в) Разраб вообще не читал документацию и выполнил так, как понял на переговорах

г) Придумайте сами отмазку...

Итог простой - аналитик должен понять проблему и обработать ее.

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

9. После завершения всех проверок и исправления дефектов (если такие будут), аналитик собирает команду разработки и приглашает заказчика на Демо.

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

10. Сопровождение. Здесь аналитик обрабатывает запросы от команды сопровождения, если их не удалось обработать колл-центру или дежурному техническому специалисту.

За такую работу IT-компании готовы платить аналитикам в среднем от 130.000 рублей в месяц с полным соцпакетом и дополнительными плюшками в виде:

- Стоматологии

- Компенсации фитнесса

- Дополнительного обучения

- Техники для работы удаленно

- Уроков английского

- Помощи в переезде в другие города/страны/континенты

Вот так примерно происходит работа Бизнес-аналитика на IT-проекте.

Если вы хотите обучиться данной профессии и войти в МИР IT без знания кода и технического образования, тогда рекомендую рассмотреть обучение в Онлайн-школе IT-технологий ESSENTRIUM https://essentrium.ru/