Сказочный вопрос: кто такой бизнес-аналитик?

Один раз мне задали вопрос: чем бизнес‑аналитик отличается от секретаря? Казалось бы, разработке ПО в России уже больше 2х десятков лет, но роль бизнес‑аналитика до сих пор вызывает вопросы.

В принципе, вместо секретаря можно добавить любую другую профессию и спросить: а чем БА отличается от бухгалтера, от юриста или технического писателя?

Разработка любого продукта или ИТ проекта начинается с формирования команды. Как это происходит: допустим, Заказчик у нас сразу есть. Кто еще нужен в команде?

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

• Нужен Дизайнер. Чтобы были красивые и удобные интерфейсы

• Нужен Тестировщик. Кто‑то же должен найти баги, мы знаем, что кода без багов не бывает.

• Народу у нас в команде уже много, очевидно нужен Руководитель проекта

А еще часто кто‑то произносит: нам нужен Бизнес‑аналитик! Только что же он будет делать — многие не знают. Кто этот человек? Что он делает?

Допустим нам нужен в команду аналитик, а какой? Бизнес аналитик, системный или фул стек? А чем вообще отличается БА и СА?

Давайте разбираться

Под словами Бизнес‑аналитик чаще всего подразумеваются минимум 2 разные профессии:

1-я — это сотрудник бизнес‑ подразделения какой‑то компании, который действительно занимается анализом бизнеса компании. Графики, отчетность, прогнозы развития той или иной услуги, выручки, окупаемости и т. д.

2-я — это сотрудник ИТ подразделения или ИТ компании. Это тот БА, который является частью команды разработки какого‑либо программного обеспечения. Именно про этого БА дальше и пойдет речь.

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

А не может ли Заказчик сразу ставить задачу разработке так, чтобы они понимали?

Нет не может

Бизнес заказчик или Product Owner часто (не всегда, но часто) описывает некий образ результата, который он хочет получить. Например: Реализовать возможность работать с комментариями в задаче. Создавать, удалять, редактировать. И может добавить: ну как везде.  Какие вам еще требования нужны? 

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

• в каком формате показывать дату и время комментария?

• а ФИО пользователя

• а аватарку показывать?

• а сортировать в порядке убывания или возрастания?

• а кто должен иметь права на редактирование?

• а если, а если, а если?

В худшем случае разработчик сделает как сам понял/придумал/видел где-то.

Так вот, БА — это тот человек, который опишет (и это очень важно. Не расскажет, не споет, не станцует и не запишет голосовое. Он напишет!) очень подробно, что же мы хотим получить на выходе. Это и будут наши требования — которые разработка возьмет на вход.

Требования

Требования можно разделить на бизнес требования и системные.

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

Системные требования — это описание того, как разработка должна реализовать бизнес‑требования. Описания методов, таблиц в БД, полей, API и т. д.

Аналитик, который пишет бизнес требования — бизнес аналитик. А аналитик, который пишет системные требования — системный аналитик.

Если очень упростить, то БА — это человек который пишет человеческим, русским языком. Он описывает ЧТО нужно сделать. А СА — описывает КАК разработка должна это сделать. т. е. пишет системные требования на уровне таблиц БД, задач на бек, фронт и т. д.

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

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

Фиксация и управление требованиями

Все требования бизнес аналитик обязательно фиксирует. Это могут быть документы совершенно разного уровня: ТЗ, ЧТЗ, БФТ, Спецификация, Use case, user story, постановка. Это могут быть документы в word по ГОСТу или странички в Базе знаний. Но требования должны быть зафиксированы.

Требования должны быть записаны, пронумерованы (желательно), проверсионированы, трассированы (т. е. связаны между собой).

БА декомпозирует требования: разбивает на более мелкие кусочки, чтобы разработке было проще их кодить.

И важный шаг при работе с любыми требованиями — их согласовать! Это отдельный скил для БА, уметь согласовать документ с разными заказчиками, особенно если у них вообще разные цели и задачи на систему.

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

Что еще важного делает БА?

Конечно же, проектирует бизнес‑процессы! Существует множество нотаций, у каждого БА есть свои любимые. Я считаю, что хороший бизнес процесс — это тот, который понятен и бизнес-заказчику, и разработчику без специальной подготовки.

Бизнес‑процесс может описывать как поведение одного пользователя в одной системе (например, работу с комментариями в задаче) или длинный сквозной бизнес — процесс через много систем (например, вы платите в личном кабинете за интернет и через 5 минут вам его разблокируют. Здесь будет порядка 10 систем участников и важно доработать каждую систему так, чтобы в итоге этот бизнес‑процесс заработал).

Ну вот, допустим, наш БА написал требования, оформил их в ТЗ или постановку. И все? Сел отдыхать? Плохой БА — возможно, но про таких и говорить не стоит. Мне очень нравится известная фраза: претензий к пуговицам нет, но костюмчик не сидит.

Бизнес- аналитик — это тот человек, который отвечает за то, чтобы костюмчик сидел

• БА участвует в грумингах и обсуждениях с разработкой. Когда пишешь требования очень важно понимать, что и как можно реализовать, а что реализовывать будет очень долго или дорого. Бизнес‑аналитик должен убедиться, что разработка поняла требования правильно. Практика показывает, что любую даже очень однозначную фразу можно трактовать по‑разному. Важно вместе все прочитать, проговорить и зафиксировать так, чтобы точно было понятно всем.

• БА участвует в приемке функционала и проводит его проверку. Аналитик обязательно проверяет в целом, получилось так как задумывалось? Может что‑то было спроектировано неудобно? Что‑то забыли? БА точно знает, как пользователь будет с этим работать, сможет ли?

• Так как БА знает, что для пользователя важно, он еще проверит документацию для пользователя. Действительно ли функционал описан полно? Сделаны ли нужные акценты?

• БА может помогать РО проводить демонстрации продукта, отвечать на вопросы пользователей.

• На моем продукте БА являются еще и входной точкой со стороны 3 линии тех поддержки. Все в обращения, на которые не может ответить 1 и 2 линии, попадают к бизнес‑аналитикам продуктов. Если есть подозрение на дефект — мы передаем его в QA. Если пользователь предлагает какой‑то новый функционал, мы подсказываем, есть ли такое в беклоге развития продукта и если нет, то идем к РО с вопросом.

Часто есть ощущение, что БА только и делает, что со всеми разговаривает.

В принципе так и есть. А требования пишет в свободное от работы время в тишине рано утром или в выходные.

С кем же БА говорит?

1. С заказчиком — это первый шаг, вытащить, что же нужно сделать. И согласовать со всеми.

2. С дизайнером — проектирование интерфейсов никогда не может идти в отрыве от требований.

3. С разработкой — убедится, что разработка понимает, что нужно сделать.

4. С тестированием — помочь определить баг/не баг.

5. С тех писателям — помочь написать документацию.

6. С поддержкой — помочь ответить на вопросы пользователей.

7. С пользователями ‑рассказать о продукте, провести демо.

Ключевой навык Бизнес‑аналитика — умение найти общий язык с разными людьми. Чтобы в итоге костюмчик вашего продукта хорошо сидел.