Алоха! Сегодня продолжим тему #карьерныйпуть бизнес-аналитика, которую я начала в прошлый раз, где рассказала о своем первом месте работы в хлебобулочном производстве

#карьерныйпуть | @ba_and_sa

Итак, с булочками я закончила и перешла к нефтяной промышленности. До начала работы я прошла порядка 5-10 собесов, и с каждым собесом улучшала свои знания, так как готовилась к каждому) Если говорить именно про мой собес, который я прошла, так это было три собеса: знакомство с hr, техническое (где мне дали тестовое задание) с руководителями (их было два, и тот и тот искал себе сотрудника), заключительное с hr, с моим будущим руководителем и еще был чел, но я не поняла кто это был)) оффер мне прислали через 2 недели после 3го собеса. Я получила два оффера, но пошла туда, где была больше зп😁

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

В первые три месяца (как раз испытательный срок) в основном я занималась изучением документации и погружением в процессы производства.

Постепенно я начала полноценно работать, и это было не совсем то, что я хотела, и что мне говорили на собесе😞, как же я "люблю" такие ситуации

Короче, в основные мои задачи входило:
- В СЭД принимала документ на проверку, читала его, при необходимости вносила корректировки, согласовывала и отправляла на редакцию
- описывала процесс документооборота в компании в нотации BPMN

Конечно же это было не то, чем я хотела заниматься, я просто тупо сидела с компом в обнимку и всю свою работу проводила один на один с ним (( а бизнес-аналитик, это в первую очередь - общение, развитие, моделирование, а не чтение уже написанной документации😮 и как вы понимаете, там я проработала не долго (8 месяцев)

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

Спустя время я начала задумываться о смене работы, и в один день мне написала моя бывшая руководительница, что она ищет новых аналитиков для нового проекта, но также в этой же компании, но в другом центре, т.е. мне нужно было просто перевестись внутри компании на другое ЮЛ и переехать в другой офис, я согласилась, но об этом позже….))

Так же были вопросы при смене работы:

1️⃣. Почему я захотела уйти? - ну самое главное - я занималась, не тем, чем хотела, для меня это веская причина сменить место работы! В целом все хорошо было, и рабочее место комфортное было, и коллектив дружный (женский, кстати 🤦‍♀️) да и было комфортно работать и всегда хотелось идти на работу!!! Но, карьерного роста - нет, повышения ЗП - нет, при обращении к руководителю с просьбой сменить проект или заняться тем, чем я хочу - игнор, поэтому все шло к увольнению

2️⃣. Были у меня страхи переходить на другую работу? - уходя с этой работы был только один страх - потеря комфорта в плане рабочей обстановки (офис, люди и тд.) моментами я даже просто сидела и зависала в телефоне или в инете, так как работы ну вообще не было, а мне за это еще и платили)) А вот в плане выполнения задач, страха никакого не было, наоборот хотела уйти и сменить уже просто чтение документации на работу головой))

3️⃣. Какие знания я извлекла с места работы? - узнала нефтяную промышленность изнутри, познала, как работают другие аналитики, так сказать, изучала их косяки и знания, тоже чем-то опыт)) ну и конечно же поняла, что документооборот — это не мое!! и я сразу поняла, что следующие вакансии буду рассматривать только в ИТ направлении

4️⃣. Предложила бы я эту компанию для других? - если тебе нравится документооборот, возиться с бумажками изучать процессы, а не писать их самому, то почему бы и нет! ну или для первой работы бизнес-аналитика, тоже можно попробовать!

#карьерныйпуть | @ba_and_sa

🔥Алоха! Часто мне пишут с просьбой раскрыть какую-нибудь тему по аналитике/анализу, поэтому я решила написать этот пост, где в комментариях вы можете поделиться своими предпочтениями и интересами, а мы постараемся подготовить для вас еще более интересный контент в будущем!))

#расширяемкругозор | @ba_and_sa

Если есть интересующая вас тема - пишите 👇

Алоха! Ребят, сегодня предлагаю обсудить тему, которую предложил наш подписчик!

#вопросотподписчика | @ba_and_sa

Небольшая предистория:

Наш подписчик устроился в компанию - крупная финансовая структура (Заказчик), на роль БА на проект внедрение EPM-системы.

Компания Заказчик имеет классическую орг. структуру, что влияет на состав Команды проекта и их взаимодействие:
⁃ РП - сотрудник из отдельного подразделения в структуре Компании Заказчик, выполняет функции связи с внутренними командами, KPI, которого зависит от количества проектов, а не на их сроках.
⁃ группа стекхолдеров (5 чел), каждый шарит в своих процессах, но никто не шарит во всех, т.е. нет целостной картины и понимания целевого процесса;
⁃ Продакт менеджер - по сути, инициативный сотрудник из подразделения вызвавшийся лидировать проект, тоже не имеющий целостной картины
⁃ Бизнес-аналитик (наш подписчик) , который собирает требования, согласовывает и передает их контрагенту для разработки;

Команда контрагента (проектный тип команды):
⁃ РП
⁃ Помощник РП
⁃ бизнес-аналитики (3 чел)
⁃ разработчики

Функции, которые легли на подписчика - БА:
- сбор требований и работа с ними
- формирование БТ
- первичная приемка
- процесс согласования (в 2-3 этапа внутри Банка)

Выполняя эти функции, наш подписчик столкнулся со следующими проблемами.

1. переданные требования видоизменяются, тк на стороне Контрагента их подстраивают под возможности системы и реализовывают иначе, это приводит к:
⁃ Постоянной работе с изменением требований (проект крупный, одно требование тянет другое)
⁃ Если не фиксировать изменения, то будут проблемы с приемкой функционала
2. происходит двойная работа, на стороне Заказчика собираются требований, потом на стороне Контрагента их опять пережевывают и уточняют, снова согласовывают.
3. работа с изменениями требований забирает отведенное время на сбор требований по новым фичам

——————————————————

⁉️ Вопросы на порассуждать:

1️⃣Нужен ли БА на стороне Заказчика?
2️⃣Какого типа требования должны собираться БА Заказчика, и как с ними должен работать Контрагент?
3️⃣Как история повернется дальше и что можно было бы сделать иначе?

Это довольно частая ситуация, когда Заказчик работает с контрагентом, и при таком раскладе часто бывают разные трудности для работы БА.

У меня тоже была такая ситуация, я о ней чуть позже расскажу, поделюсь своими трудностями и как я их решала! А вы поделитесь своим опытом и помогите разобраться нашему подписчику с его ситуацией)) 🧐👇

В продолжении предыдущего поста я поделюсь своим опытом работы в цепочке «Заказчик - БА - Контрагент»

Продолжение #вопросотподписчика | @ba_and_sa

Цель проекта: разработка и внедрение системы для внутреннего пользования на заводе - это если вкратце, т.е. главный пользователь - заводчане и главные стейкхолдеры со стороны Заказчика

Теперь расскажу о составе команды:

ЗАКАЗЧИК:
- РП, так же один из главных стейкхолдеров (шарил во всей внутрянки проекта со стороны пользователей)
- Стейкхолдеры - порядка 10 чел (с разным функционалом, разное количество стейкхолдеров)
- Администратор проекта - протоколист
- Бизнес-аналитик - я🫡

КОНТРАГЕНТ:
- Тимлид Разработки (один из стейкхолдеров)… Кстати, у меня с ним был конфликт, о котором я говорила ранее 🤺
- Системный аналитик, но больше даже Технический писатель
- Команда разработки
- Архитекторы
- Дизайнеры

Но в моей истории у меня был доступ и к внутренней документации, и прямой доступ к стейкхолдерам и была более полная картина того, что хочет Заказчик, а вот к ИТ сфере проходов было мало, меня не допускали к многим данным, да и разрабов я не видела, общение было в основном только с Лидом и тех.писом (он прям спасал в некоторых ситуациях)

У меня в обязанности входило:
- сбор и анализ требований
- формирование БТ, куда входили: ФТ, НФТ, БП, use case, и тд! Но полноценное написание ТЗ было на стороне Контрагента
- моделирование Бизнес-процессов
- формирование сторонней документации (например инструкции для пользователей)
- согласование со всеми стейкхолдерами, инструкции и Бизнес-процессы надо было еще и с заводом согласовывать 🤯
- ведение дорожной карты вместе с контролем сроков выполнения совместно с РП и Тимлидом разработки
- тестирование продукта, после разработки и после тестирования со стороны Контрагента

Трудности, с которыми я столкнулась:
- занятые стейкхолдеры - вечная проблема!
- мало информации со стороны контрагента, еще и натянутые отношения были с Тимлидом, а он был главным стейкхолдером со стороны Контрагента
- не было доступа к многим данным, тяжело писать НФТ для системы
- трудно было найти разработчиков, так же для описания НФТ, чаще обращалась к их аналитику, а он уже по разрабам бегал
- вести единую дорожную карту с Контрагентом, они могли не успевать по срокам, а я не в курсе

🤔Моя методика работы или советы:

- больше живого/онлайн общения со всеми заинтересованными сторонами, как и со стороны Заказчика, так и Контрагента
- на берегу, я сразу пошла к главному заказчику, для обсуждения методики согласования всех изменений. Мы установили сроки и, если они были нарушены, то согласование считалось полученным. Также перед разработкой мы с РП выбирали главные и ценные БТ и реализовывали все понемногу, тем самым документ был не на 100 стр 🤦🏼‍♀️
- После сбора требований я сразу писала док и параллельно процесс, для успешного процесса у меня было много общения с пользователями- заводчанами
- раз в неделю у нас была встреча с Тимлидом разработки и его Тех.писом, где мы обсуждали все мои накопившиеся вопросы
- была объемная и детализированная дорожная карта
- до релиза я тестировала разработанный функционал и согласовывала, если все ложилось на мой процесс
- Контрагент готовил презентацию по релизу для заказчика, я участвовала в процессе подготовки.

Я уже не вдавалась в подробности, но общую картину рассказала))