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

Один раз мне задали вопрос: чем бизнес-аналитик отличается от секретаря? Казалось бы, разработке ПО в России уже больше 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. С пользователями –рассказать о продукте, провести демо.

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

Спасибо!

Спасибо!

© Habrahabr.ru