×Закрыть

Business Analysis — з чого почати?

Друзі, привіт!)

Планую перекваліфікуватися на ВА. Хочу спитати поради, з яких матеріалів краще почати і що необхідно знати?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чтоб быть BA необходимо иметь навыки и знания в сфере промышленного маркетинга, статистики, немного высшей математики, и ИТ . Опыт работы в крупных, системных финансовых компаниях (Банки) на должности аналитики.

BABOK
Software Requirements by Karl Wiegers
English
SRS
Дальше можно выбрать домен и в него копать.

BABOK ні?

Да бабок надо побольше :)
А мотоцикл зачем :)

Перечитал ешё раз и кажется понял.
Мотоцикл это Хийтачи что ли?

джуну... та только голову засорит.
Только ооочень умному джуну)

а в БА надо каких-то других кроме умных?

Ленивых!
как и везде в общем, типа в девелопмент нужны глупыши)

SQL + DB (популярную базу выбирай по колличеству вакансий в регионе где планируешь работать). NoSQL как факультатив, не думаю что знание его сильно увеличит результат учебы и шансы
BI + DWH основы (тот же совет по выбору, смотря что популярнее SAP BO or Cognos etc), даже если идешь работать там где нет репортинга — это тебя научит думать категориями данных обьектов и тд
Бизнесс домен — с этим сложнее всего, так как если с техническими скилами — источник знаний не имеет особого значения, то в этой категории нанимателю важно понять откуда и как ты получила опыт и знания в области
Agile (product owner role) + SDLC
Стуктуры данных (xsd+xml, json), популярные стандарты в области, если финансы — SWIFT FpML FIX FIXML. Если Телекомы — то протоколы\стандарты\вендоры которые наиболее близки к бизнесу, VAS etc.
Английский — ну тут все ясно
Артефакты проекта типа BRD, FRD, SRS, TDD, Run-book, Responsibility Matrix, Backlog, Mapping- типы документов и других обьектов которые нужны на проекте и с которыми ты будешь работать\взаимодействовать

Если повезет попасть в продуктовую компанию, то желательно иметь понимание бизнес моделей: en.wikipedia.org/wiki/Business_model
и что с ними делать: strategyzer.com/...​del-generation#learn-more

джуну?) доверить строить новые или рефакторить существующие процессы?) да вы шутник
Я уж не говорю о том что бизнес аналитик процессов не имеет ничего общего с айти, это уже бизнес юнит а не технический и там нужны совсем другие скилы чем у классического БА в ИТ

да, в стране аутсорсии существуют только «классические БА в ИТ» )

да при чем тут страна, ты понимаешь разницу между ИТ БА и Бизнес Девелопмент БА? Второе не имеет никакого отношения к айти, смысл это советовать в теме — ищу работу в ИТ

имеет и более непосредственное чем SQL+БД. )
И кажется, я четко написал, что мой совет относится к случаю продуктовой компании где вы сами делаете продукт. Для кого вы его делаете, в чем ценность продукта, какие ресурсы задействованы и т.д. Никто здесь не требует экспертных знаний, но понимать что делается и для чего делается считаю просто необходимо.

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

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

SQL + DB

Підкажіть, а навіщо ВА знати БД?

Примеры на оракле
— что бы когда сроки горят и на странный вопрос клиента «а загружаем ли мы ISIN в базу из источника абс» вместо того что бы начать бегать по девам и копаться в мусоре, аналитик могбы написать select * from all_tab_columns where column_name like ’%ISIN%’ and table_name like ’%ABC%’ (конечно есть варианты которые не покрыты но знать то надо свою систему)
— или что бы когда понадобилось поменять в тестовых данных CLOB с текстом с кучей неизолированных спец символов, аналитик мог бы добавить rowid к селекту и заменить занчение прям в окошке тода, а не начать править текст изолирую там все что ругается
— и что бы понимать что такое схема
— и что бы потом сверху было намного проще понимать архитектуру DWH в ERD физической модели данных
— что бы клиент настроить для подключения к базе (в запущеных случаях)
— а xml из базы распарсить прям из селекта без тупых лайков?
— а построить иерархию использую штатные средства БАЗЫ?
— а развернуть данные пивотом?

И это я еще не говорю про такие темы как БА в програмно-железном комлексе типа Teradata

А если МонгоДБ? как ты оттуда извлечешь данные не зная основ этой БД?

Так это же Business Intelligence, а не Business Analysis, не?

BA — это типа requirements engineer, у нас, во всяком случае.

Большинство проектов где реально нужны ба — содержат огромное колличество бизнес данных, банки, телекомы, ритейл
Что бы написать правильные требования для девов на таких проектах — тебе нужно очень много анализа данных, в большинстве случаев бизнес тебе скажет бизнес терминологию а тебе нужно уже в конкретных значениях объяснить это девайс в требованиях. Не зная как та или иная сущность отображены в данных ты создашь неправильное требование.
Плюс, свои требования надо проверять, сработают ли они, и в большинстве случаев это будет проверка на реальных данных
А UAT? На каждый вопрос почему тут нет значения абс, а вот тут 3 левых значения ввв — будешь бегать к девам и у них переспрашивать?)
А прод ишью? SL3 все мало мальски бизнес вопросы не всегда сможет решить, пойдут к тебе.
И это на всех континентах так)

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

Да, но для этого обычно достаточно общих поверхностных технических и отраслевых знаний — для того, чтобы понять, что подается на входе и описать, что требуется на выходе. Плюс знание своего продукта / спектра продуктов. Внутрь продукта БА не лезут, для этого есть разработчики. Максимум БА посмотрят полусырую фичу на дев-сервере, чтобы просто быть в курсе происходящего и проверить, не забыли ли они чего в реквайрментсах.

А UAT? На каждый вопрос почему тут нет значения абс, а вот тут 3 левых значения ввв — будешь бегать к девам и у них переспрашивать?)

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

Плюс, свои требования надо проверять, сработают ли они, и в большинстве случаев это будет проверка на реальных данных

Сами, что ли, прототипируют и кьюэят? Это уже не БА, а терминаторы какие-то.

Внутрь продукта БА не лезут, для этого есть разработчики.

Это ба-импотент который не может ответить на 80% вопросов бизнеса относительно системы за которую жтот БА отвечает)

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

бгг тоесть вместо того что бы просто посмотреть в базу и увидеть что эти значения пришли из апстрима в соответствии с требованиями которые ба написал — ты предлагаешь пойти длинным окружным путем, создать баг, а на выходе получить все тот же ответ — пришли из апстрима и были загружены в соответствии с бизнес требованиями))) отличное использование ресурсов

Сами, что ли, прототипируют и кьюэят? Это уже не БА, а терминаторы какие-то.

Во первых это ты прототипом называешь селекты которые просто проверят сходу, работает ли заказанная бизнес логика или нет?)) камон
А вот про куа не зря ты упомнула, ты же понимаешь что спеки БА никто не тестит, их воспринимают на входе как факт не требующий проверки. А бизнес не всегда понимает твою трансляцию в логику самой системы и может подписать не проверяя детали.
И получим что заказала джоин девам, те сделали в акурат по спеке, но условия джоина оказались недостаточны. И всего лишь селект на 5 строчек от БА мог это все предотвратить перед тем как заказывать разработку) И самое смешное что и КУА не найдут ошибки, джоин работает как заказывали. И только под релиз, во врея ЮАТ — выявят ошибкуи нао будет в срочном порядке все переделывать (а ведь это может повлиять на весь дизайн фичи)

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

Может, и хорошо, если БА может сам запулить селект на пять строчек, но зачем? Внятное описание ничуть не хуже селекта, с учетом того, что БА с тем же успехом может ошибиться в условиях селекта, как и в описании.

Может, и хорошо, если БА может сам запулить селект на пять строчек, но зачем? Внятное описание ничуть не хуже селекта, с учетом того, что БА с тем же успехом может ошибиться в условиях селекта, как и в описании.

Что ж у вас за БА там такие))))
Я вот просто не представляю как БА на ДВХ проекте может что либо написать без работы с базой, это не БА а ненужная прослойка тогда.

Я могу привести пример множество проектов в ДойчеБанке, БанкофАмерика, Киевстаре, Лайфе, ЮБС банке — где вашего аналитика просто бы не взяли на работу так как это абсурд работать на проекте где 95% ценности находится именно в данных (таких как ДВХ проекты) и БА в ИТ не может на эти данные интеллектуально посмотреть в базе\источниках

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

Имхо, вы спорите о двух возможных ролях на противоположных краях спектра, «IT ВА как product owner» и «IT BA как system analyst». Первый больше о куда копать, второй — где и как копать. Для свитчеров и джунов, имхо, обсуждение роли настоящего product owner не имеет большого смысла, разве что есть хороший SME бекграунд в востребованной индустрии. «BA как business model/process analyst», имхо, вспомнили вообще зря

Согласен с каждым словом что ты написал, респект!

Я думал ,что бизнес -аналитик должен в первую очередь вести диалог с стейкхоледерами, и разрабатывать требования и спецификации к ПО)
SQL, и DB — конечно нужно знать, но это не на первом месте, имхо.
Более важно UML и BPMN нотации..
То что ты написал -это больше для бизнес-аналитика внутреннего айти-отдела, имхо.

По порядку:
BPMN — обычно не нужно знать ИТ аналитику, потому что бизнес процессы — это забота бизнес юнита, не айти
UML — yes

Значит так, возможны 2 структуры
1) Business <-> BA\Product Owner <-> dev — как понятно из схемы тут аналитик должен знать все, и бизнес и технолоджи, никуда не дется
2) Business <-> BA <-> FA\SA <-> dev — вот тут то про что ты говоришь, НО вот БА тут обычно — даже не ИТ, обычно в такой структуре это часть бизнеса, CIO юнит в больших корпорациях

BA-business analyst
FA-functional analyst
SA-system analyst

Спасибо за пояснение.
Или в реалии украинских продуктовых компаний, часть бизнес процессов клиента, таки становятся и заботой BA.. Иногда и аутсорса, но реже.
Я уже не первый раз замечаю, что ты заточен под крупных корпоративных клиентов. Не под крупных, а под огромных даже)
А мы тут курочка по зернышку)

ну в 95% случаев этот БА будет настоящим БИЗНЕС аналитиком а не частью айти

Я уже не первый раз замечаю, что ты заточен под крупных корпоративных клиентов. Не под крупных, а под огромных даже)
А мы тут курочка по зернышку)

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

По поводу диалога со стейкхолдерами — давайте все же оставаться в рамках исходного вопроса и отталкиваться от реалий рынка труда для Junior BA. Иначе дискуссия превращается в спор «какой BA более правильный BA». Так вот реалии, на мой взгляд, таковы, что основные роли Junior BA это де-факто: junior functional analyst, technical writer, junior data analyst и (отдельная категория) sales analyst. Ни одна из этих полей не предполагает общения со стейкхолдерами, а все вопросы адекватного интервьювера на этот счёт, имхо, должны закрываться умением грамотно формулировать свои мысли на английском языке. Даже базовая теория на данном этапе (не говоря о бездумной зубрежке BABOK) с практической точки зрения совершенно преждевременна.
В реальной жизни украинского (и многого другого) ИТ, business analyst — это комбинация знаний предметной области, технических навыков (код, кстати, тоже не помешает уметь читать :)) и практических навыков работы с требованиями, а не мастерство переговоров с многочисленными стейкхолдерами. Умеете это делать хорошо — сразу идите в менеджеры проектов, там тоже есть junior позиции (где, конечно, первое время придётся поработать jira admin и accountant, но все равно, путь ближе)

Ну тут однозначно вільна розмовна англійська, аби зрозуміти клієнта ну і хоча б трохи розбиратись в технологічному стекові аби вміти донести клієнтові технічні рішення і говорити з девелоперами хоча б на приблизно одній мові.
Ідеально, це мати якийсь досвід і навички в сфері бізнесу клієнта, аби розуміти, що саме йому потрібно.
Зустрічне запитання, а як саме ви уявляєте роботу БА ?

дякую за відповідь!
от власне, що я вивчила фронт-енд, останнім часом мені стало нудно і зрозуміла, що не хочу цим займатись. Відверто кажучи, монотонна робота. А в свою чергу BA — це людина-конектор між замовником та девелоперами.
Англійська розмовна +, а от із навчичками в сфері бізнесу треба попрацювати

да там конкретики никакой, пойду там отпишусь)

Якщо не подобається монотонна робота то БА не вихід. 1 година розмов, все інші 9 годин робочого дня це робота з документами. Здається ви дещо ідеалізуєте роботу аналітика.

Будете сидеть 6 часов на митингах а потом еще 6 писать митинг ноутс а потом еще 6 их согласовывать а потом еще 6 писать тз в потом еще 6 править его) Ну а потом новый день начнется и так по кругу)

А що саме для вас найбільш нудне у фронтенді? Тут таке діло, що із виходом банківських проектів з України, більша частина позицій аналітиків на існуючих проектах — це знову ж таки описувати вимоги для фронтенду (де ВА здорово витискають UXD, до речі)

Подписаться на комментарии