Как работается бизнес аналитикам?
Если есть тут девушки, работающие на этой замечательной должности, поделитесь впечатлениями плиз :) Что входит в обязанности, как зарплата, всегда ли эта работа связана с командировками и т.д. Какие требования к кандидатам обычно предъявляются? Минусы-плюсы. Интересует все.
Давно назревает тема смены работы, как вариант рассматриваю именно эту область. Сейчас работаю так же в IT, но в конторе со своеобразными "старыми", если так можно сказать, традициями, нет возможности поучиться на живом профессиональном примере.
Все очень зависит от места работы.
Если БА в интеграторе, то ездить придется постоянно к клиентам и подстраиваться под их график работы (пытались меня ангажировать на один проект в Солнцево со встречами в 9-10 часов вечера). Или иногда прямо рабочее место у клиента устраивают (от недели до нескольких месяцев), а это может быть в другом конце города и никого ваше удобство перемещения не интересует. Хорошо еще, если есть возможность отказываться от неудобных проектов, а то еще и спрашивать не будут. Соответственно зависит от количества проектов у интегратора. В одной из знакомых компаний - есть проекты-людей чуть ли не с улицы набирают, нет проектов - всех предупреждают об увольнении.
Лучше всего быть БА в конкретном бизнесе - когда есть стабильное место работы, знакомая предметная область, в которой постоянно варишься. Или в компании, которая аутсорсит западные проекты, тогда если и поездки, то только зарубеж, а остальное время просто контакт по почте и телефону.
Иногда можно работать из дома, иногда это не допускается по политике заказчика - нет доступа к ресурсам. Лично у меня, когда даже нет проекта, требуется присутствие в офисе в определенное время, чтобы можно было оперативно решить вопросы и с заказчиками и с разработчиками, а в целом график достаточно гибкий и "можно договориться" при отсутствии переговоров. Иногда при отсутствии проектов я совершенно официально на глазах у руководства занимаюсь своими делами.
Зарплата - очень зависит от конкретного работодателя.
Требования - UML, RUP, иногда ARIS, use-cases, ERwin, BPwin, презентации, блок-схемы алгоритмов, хорошее знание баз данных, SQL- PL/SQL чтобы была возможность самостоятельного тестирования, желательно языки программирования используемые представлять себе, чтобы была возможность и код посмотреть, если что-то срочно надо выяснить (правда, если в конторе есть деление на BA и FA - functional analyst - то код это скорее для FA, хотя и BA тоже не помешает).
а как вырасти до этого БА?не с улицы ж идти без опыта написания тз и прочих навыков, без знания области, а в институтах этому не учат...
и где найти работу не в интеграторе, полюбому начало карьеры там???через аналитика просто?
можно просто начать в бизнесе разработчиком или тестировщиком и вырасти. У меня как раз начиналось с бизнеса, потом были интеграторы уже в качестве аналитика.
В институтах учат, и достаточно давно. В Бауманке это ИУ-5 еще с 90х годов и отдельные дисциплины есть в рамках ИУ-7.
Обычно в аналитики можно перейти из разработчиков (в моем случае) или тестировщиков, даже без профильного образования, просто в рамках карьерного роста и опыта работы с чужими спецификациями.
Знание предметной области - обычно либо вторая вышка (либо основная вышка до работы в ИТ), либо уже просто знакомство в процессе работы. Знаю многих людей, которые предметные области осваивали просто в ходе очередного проекта, да и сама такая же, т.к. многое из текущей работы с финансовыми технологиями у нас в России еще просто не используется.
Есть профильное сообщество www.uml2.ru, они год назад устраивали цикл обучающих семинаров, там должны были остаться ссылки на видео. Может, и сейчас есть какая-то программа.
В Люксофте есть класс аналитика в тренинговом центре в т.ч. для сторонних слушателей.
Есть классический труд Алистера Коберна "Современные методы описания функциональных требований к системам" ("Writing Effective Use Cases" ).
у обычных системных аналитиков зп от 50 до 100т.р. в среднем, больше 100 - редкость, это ведущие и руководители отделов, меньше 50 - это без опыта вообще.
обязанности - требования, описания, схемы по разным методологиям-нотациям, постановки, аналитические проработки. командировки обычно нечастые, зависит от компании и проекта. общение с системным архитектором, разработчиками, руководителями, бизнес-аналитиками (если таковые есть), клиентами, экспертами.
бизнес-аналитики обычно делают все то же примерно, но без постановок и технических схем. соответственно для бизнес-аналитиков знание предметной области важнее обычно, командировки чаще.
плюсы-минусы как в любой офисной работе. рутины довольно много...
Спасибо за столь развернутые ответы. Эх, более чем вероятная перспектива разъезжать в лучшем случае по всей Москве несколько огорчает:( Хочется оседлости.
Смотрю вакансии, разницу между системным и бизнес аналитиком улавливаю с трудом, такое впечатление, что просто кто как называет.
Очень размытая граница на самом деле. И очень зависит от штатного расписания работодателя. И в ряде случаев зависит от конкретного проекта и его ресурсов-бюджета.
А Вы как из разработчиков перешли, в текущей компании, или с должностью и место работы сменили? Реально ли, интересно, устроиться без опыта работы именно аналитиком, но просто подковавшись согласно предъявляемым требованиям? Особенно учитывая возраст в 30 с хвостом лет... :(
Да просто как разработчик и тестированием занималась, и требованиями, и с бизнесом общалась - у нас весь отдел был "на все руки" без четкого деления. Потом раз написала требования для своей же разработки, второй раз. Ну а потом искала уже прицельно именно с должностью "аналитик".
Кстати, проще всего начинать именно в бизнесе, т.к. можно просто почитать книжку, нахвататься теории, а потом на всех собеседованиях говорить о том, что у вас все коллеги работали "универсалами" и в т.ч. использовали юз кейсы, рисовали диаграммы в Rational Rose и т.д., а вот теперь хотите сосредоточиться чисто на анализе. Обычно тестовые задания просят сделать или в ролевые игры по сбору требований играют на собеседованиях, это достаточно легко.
Аналитиков как раз любят из бывших программистов и тестеров, т.к. они реально знают принципы работы систем и уже занимаются анализом исходя из своего опыта работы. А то общалась я с одним аналитиком после ВШЭ - там была неплохая теория и подготовка звучных презентаций, но техническая сторона оставалась совсем плохо проработана и многие аспекты упущены.
По сути у нас так и есть, коллеги работают "универсалами", только в Rational Rose никто диаграмм не рисует, в лучшем случае что-то делается в Visio, кое-какие доки в ворде, а большая часть в головах программеров живет:) Так получаются незаменимые люди, сдвинуть эту ситуацию у нас уже не удастся:(. А если кто и уходит, то вполне себе по коду остальные сидят и разбирают всю логику, сама несколько раз в такой ситуации оказывалась.
А поподробнее насчет собеседования можете рассказать? Какие могут быть тестовые задания, про ролевые что-нибудь интересно было бы услышать.
Спасибо, что так подробно отвечаете.
Тестовое задание - например, дают функционал - "фирма оформляет на свои услуги счета-фактуры". Надо разрисовать общую юз кейс диаграмму (какие вообще кейсы есть - CRUD(create, read, update,delete), поиск, печать, групповая печать, просмотр перед печатью; как они вызываются друг из друга - через включение или расширение с правильной UML-нотацией и с правильными экторами - внешними и внутренними) и сделать описание всех кейсов - предусловия, постусловия, экторы, основной ход событий, альтернативные потоки.
Ролевая игра - вы-аналитик, вас отправляют к новому клиенту, про которого известно только то, что он прислал запрос на фирму с целью возможного заключения договора на разработку. Вас посылают на самое первое интервью. Принимающий на работу играет роль заказчика - либо такого работника старой формации, который изначально делает неправильную постановку в плане функционала, а вам надо выяснить реальные потребности; либо продвинутого в компьютерных технологиях и автоматизации заказчика, который настаивает на конкретном решении, а вам надо выяснить, почему решение именно такое, и понять, в какие стороны возможны альтернативы для последующих предложений. А потом принимающий на работу играет роль ИТ-начальства, которому вы отчитываетесь о встрече, а он смотрит, какие выводы вы сделали из его ответов в роли заказчика, сколько информации запомнили-записали, и как это расходится с его внутренним видением ситуации, которую он пытался до вас донести или наоборот запутать для вас в роли заказчика.
Прикольно:) Спасибо. Меня вот интересует еще чисто психологический фактор: как представитель заказчика обычно настроен на разговор? Понимаю, вопрос типа средней температуры по больнице, но лично Ваш опыт каков?
И я вот еще как-то себе представляла, что БА начинает общаться с заказчиком только после того как заключен договор на разработку, а оказывается, от него (БА) еще и зависит сама возможность его заключения?
У меня был один случай, когда я пришла уже в идущий проект, из которого уволился один аналитик, а еще один потребовал себе частичную занятость. Меня в лоб спросили, а как долго я собираюсь работать именно в этом проекте, с очень неприятной интонацией. В ответ на это я так же жестко ответила, что я не могу им гарантировать, что завтра на меня не свалится кирпич или кто-нибудь не врежется в нашу машину. Дальше как-то все пошлО более доброжелательно. Еще пара случаев была неприятных - мы выиграли один из тендеров, который должна была выиграть компания, уже сделавшая пару разработок именно в этом заказчике; а второй случай, когда мы пришли в контору, где был вроде как собственный сотрудник, мнящий себя аналитиком, а мы раскритиковали все его требования. В других случаях приходили на доброжелательную атмосферу.
Обычно еще БА делает экспертные оценки (есть разные методика) на этапе пресейла проекта (т.е. когда разработчик пытается прикинуть сумму договора, которую хочет получить, прежде чем сделать предложение клиенту), когда по минимально известным требованиям пытаются грубо прикинуть необходимый функционал. Но на это обычно привлекают людей с опытом работы в данной предметной области, которые представляют себе, о чем может идти речь. На этапе пресейла может быть проведено несколько встреч для уточнения требований к функционалу и архитектуре системы.
Есть разница - бизнес-аналитик общается с конечными пользователями и определяет бизнес-требования к системе (use-cases for example). Системный аналитик прекрасно знаком с внутренностями системы. Он переводит бизнес-требования в требования к системе, которые используются разработчиками для разработки кода. Ну во многих компаниях действительно это одна роль.
По моему опыту: если проект большой, то аналитики "становятся" бизнес-аналитиками, т.к. объем требований большой, время ограничено и поэтому на подробные алгоритмы времени уже не хватает, там выделяют человека на проектирование БД, архитектора, выверяющего алгоритмы и т.д,; если проект маленький, то архитектор "по совместительству", аналитики - и бизнес и системный в одном флаконе.
С другой стороны вот сейчас на некоторых проектах я FA, а BA у нас западные, которые лучше в бизнесе разбираются; а на других проектах, которые больше связаны с удобством использования системы, я BA и непосредственно общаюсь с бизнесом.