Алоха! Я что-то ушла в лето и в отпуска, и совсем забросила вести свои рубрики на канале😟
Но я исправлюсь, и сегодня продолжу тему #карьерныйпуть бизнес-аналитика
В этот раз я ушла из нефтяной отрасли и пошла попробовать себя в сфере финансов (деньги, кредиты, займы и тд)
#карьерныйпуть | @ba_and_sa
Короч, попала я на проект по кредитам и микрозаймам, как раз в разгар перехода из одной системы в другую, еще и с финансами (легких путей не ищем🤯 ). Перед нами стоял один из важных и сложных проектов, где нам нужно было перейти на новую систему, также переделать весь пользовательский интерфейс.
📝Проект был большой, аналитиков было порядка 5-10, со временем появились еще, и это я не считаю, аналитиков с соседних проектов. Я долго вливалась в проект, у меня был свой наставник, так как сфера новая и я в ней плавала. Но, наставник был 3 месяца, это как раз мой испытательный срок. С течением времени, я сама стала наставником для других новеньких аналитиков.
🏯Что касается самой компании, то там было много демократии, много волокиты с документами. Даже на испытательном сроке у меня были определенные задачи и наставник, в конце был собес, где я рассказала о своих успехах, защитила сделанные задачи и получила обратную связь о моей работе. И да, подготовила письменный отчет, дала свои замечания и предложения по выполнению испытательного срока.
🧚🏻♂️Если говорить о моих обязанностях, то в них входило:
- сбор требований (с уже имеющейся системы, с уже имеющейся документации, с заказчиков, с внутренних пользователей)
- описание документации (тут все по классике - подробное описание для бизнеса, и внутрянку нужно было описывать🤯 (это интеграции, если они были, связь с БД, а это были внешние поставщики, и их было сложно поймать и уговорить на встречу, также шарить нужно было в коде, бегать вечно за занятыми и неразговорчивыми разрабами 👩💻 , и еще кучу системных штучек)
- проведение презентации разработанной документации вместе с прототипами перед разработчиками, а потом перед заказчиками
- процесс согласования (оч сложный, муторный и долгий)
- разработка прототипов в фигме (где еще было общение с дизайнерами)
- проведение тестирования (хоть у нас был отдел тестирования, и не маленький, а мы все равно должны были тестировать разработанную фичу по своей документации, вместе с тестировщиками)
💻Основные системы - это Confluence (введение и описание документации), Jira (управление проектами), Фигма (прототипы)
Три раза в неделю был созвон - два раза со своей проектной командой, и один раз со всеми ИТ командами, это я не считаю созвоны по работе, там я вообще не выходила из Скайпа почти 🗣️
Сложностей было оч много - и с недопонимание между командой, и заказчиками (как всегда). И со сроками, точнее не всегда был поставлен реальный срок сдачи проекта/задачи. И с введением проектов, типо странный не до Agile, и многое другое (об этом позже)
В целом, проект был интересный, тут уже было больше системности, чем бизнес-анализа, было много общения, сложные задачи… Но! Сфера «ФИНАНСЫ» - это дремучий лес, в который ты заходишь, а как выйти не знаешь, ну это с моей точки зрения!
Ушла я с этой работы в очень короткий второй декрет😊 , но вышла из него уже на новое место работы!
Источник: @ba_and_sa
Но я исправлюсь, и сегодня продолжу тему #карьерныйпуть бизнес-аналитика
В этот раз я ушла из нефтяной отрасли и пошла попробовать себя в сфере финансов (деньги, кредиты, займы и тд)
#карьерныйпуть | @ba_and_sa
Короч, попала я на проект по кредитам и микрозаймам, как раз в разгар перехода из одной системы в другую, еще и с финансами (легких путей не ищем
📝Проект был большой, аналитиков было порядка 5-10, со временем появились еще, и это я не считаю, аналитиков с соседних проектов. Я долго вливалась в проект, у меня был свой наставник, так как сфера новая и я в ней плавала. Но, наставник был 3 месяца, это как раз мой испытательный срок. С течением времени, я сама стала наставником для других новеньких аналитиков.
🏯Что касается самой компании, то там было много демократии, много волокиты с документами. Даже на испытательном сроке у меня были определенные задачи и наставник, в конце был собес, где я рассказала о своих успехах, защитила сделанные задачи и получила обратную связь о моей работе. И да, подготовила письменный отчет, дала свои замечания и предложения по выполнению испытательного срока.
🧚🏻♂️Если говорить о моих обязанностях, то в них входило:
- сбор требований (с уже имеющейся системы, с уже имеющейся документации, с заказчиков, с внутренних пользователей)
- описание документации (тут все по классике - подробное описание для бизнеса, и внутрянку нужно было описывать
- проведение презентации разработанной документации вместе с прототипами перед разработчиками, а потом перед заказчиками
- процесс согласования (оч сложный, муторный и долгий)
- разработка прототипов в фигме (где еще было общение с дизайнерами)
- проведение тестирования (хоть у нас был отдел тестирования, и не маленький, а мы все равно должны были тестировать разработанную фичу по своей документации, вместе с тестировщиками)
💻Основные системы - это Confluence (введение и описание документации), Jira (управление проектами), Фигма (прототипы)
Три раза в неделю был созвон - два раза со своей проектной командой, и один раз со всеми ИТ командами, это я не считаю созвоны по работе, там я вообще не выходила из Скайпа почти 🗣️
Сложностей было оч много - и с недопонимание между командой, и заказчиками (как всегда). И со сроками, точнее не всегда был поставлен реальный срок сдачи проекта/задачи. И с введением проектов, типо странный не до Agile, и многое другое (об этом позже)
В целом, проект был интересный, тут уже было больше системности, чем бизнес-анализа, было много общения, сложные задачи… Но! Сфера «ФИНАНСЫ» - это дремучий лес, в который ты заходишь, а как выйти не знаешь, ну это с моей точки зрения!
Ушла я с этой работы в очень короткий второй декрет
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
Так же были вопросы при смене работы, но в этот раз выходя из второго декрета:
1️⃣ . Почему я захотела уйти на новую работу, а не вернуться на прежнюю? - во-первых сфера «финансы» это не совсем то, в чем я хочу вариться, и я уже обдумывала уйти оттуда. Также отталкивало меня вся волокита с документами и демократией, это только отнимало много времени и сил! И я считала это пустой тратой времени. Что касается ЗП - так она была хорошая, выше рынка, тут вопросов не было, но чтобы получить больше, это опять прохождение собеса, опять что-то приходилось доказывать, опять куча документов, повышение квалификации, и может через время тебе повышали зп😲
2️⃣ . Были у меня страхи переходить на другую работу и были мысли не выходить из декрета? - нет, в декрете в этот раз сидеть долго не хотела, хотела выйти на работу. Сфера деятельности была не моя, с самой командой мы сильно не общались, чтобы привязаться к ним, сильного комфорта не было! Поэтому я с легкостью ушла с этого места работы
3️⃣ . Какие знания я извлекла с места работы? - ну я познала как работает банк, что такое кредиты и, что там спрятано, многое я даже не знала и не могла представить, что это так 😂 Я столкнулась с новыми трудностями, которые нужно было решать быстро и самой (идти было не к кому). Я больше погрузилась и проработала свои навыки в системном анализе.
4️⃣ . Предложила бы я эту компанию для других? - да! Если тебе нравится сфера - финансы, и ты готов работать с кучей документов, то это хорошая компания. С достойной ЗП, с очень интересными проектами (если говорить о тех, в которых я была), с разными заказчиками и тд
#карьерныйпуть | @ba_and_sa
#карьерныйпуть | @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
Как приоритизировать проекты в рамках компании, или как мы научились сравнивать несравнимое
Перейти | BA|SA
Перейти | BA|SA
Хабр
Как приоритизировать проекты в рамках компании, или как мы научились сравнивать несравнимое
Базовая проблема любого бизнеса сводится к тому, что задач всегда больше, чем ресурсов. И если вы находите дополнительный источник ресурса, то получаете еще больше входящих идей, задач и предложений...
Алоха! В продолжении поста о моих походах на собеседования, делюсь тестовым заданием на позицию Бизнес/системный аналитик с опытом работы 3+ с одной из вакансии👇
#вакансии #собеседование | @ba_and_sa
Тема: Анализ требований и проектирование системы управления задачами
Мне предстояло разработать спецификацию требований для системы управления задачами, используемой командой разработчиков в IT-компании.
Моя задача заключается в следующем:
Прям на собеседовании:
1. Сбор требований: Определить функциональные и нефункциональные требования к системе.
2. Создание модели пользовательских сценариев: Описать, как разные типы пользователей будут взаимодействовать с системой.
3. Проектирование архитектуры системы: Определить основные компоненты системы и их взаимодействие.
Задание на дом:
4. Оценка рисков: Выявить потенциальные риски, связанные с реализацией проекта, и предложить меры по их минимизации.
5. Моделирование бизнес-процессов: Описать основные процессы, связанные с управлением задачами, создать диаграмму потоков, диаграмму активности
✅ Краткое описание моего ответа:
📋 Сбор требований
Функциональные требования:
- Управление задачами: Пользователи могут создавать, редактировать, удалять задачи.
- Статусы задач: Возможность изменять статус задачи (новая, в работе, завершенная, отклоненная).
- Приоритеты задач: Установка приоритета (низкий, средний, высокий) для каждой задачи.
- Командная работа: Назначение задач на участников команды и возможность добавления соисполнителей.
- Оповещения: Уведомления о новых задачах и изменениях статусов по email и в приложении.
- Поиск и фильтрация: Функционал для поиска задач по различным критериям (поиск по названию, фильтры по статусу и приоритету).
- Отчеты: Генерация отчетов о выполненных задачах и анализ времени, затраченного на выполнение задач.
Нефункциональные требования:
- Производительность: Система должна обрабатывать до 1000 запросов в минуту.
- Безопасность: Обеспечение конфиденциальности данных пользователя через шифрование.
- Надежность: Доступность системы не менее 99.9%.
- Масштабируемость: Возможность добавления новых функций без значительных изменений в архитектуре.
📈 Создание модели пользовательских сценариев
Пользовательские роли:
- Администратор: Может управлять пользователями, изменять настройки системы, просматривать отчеты.
- Разработчик: Может создавать и управлять своими задачами, назначать задачи другим пользователям, комментировать задачи.
- Менеджер: Может просматривать статус задач, генерировать отчеты о выполнении задач, изменять приоритеты.
Сценарий использования:
- Разработчик заходит в систему, создает новую задачу, назначает ее себе и устанавливает срок выполнения. Затем он добавляет комментарий к задаче и устанавливает статус "в работе".
- Менеджер заходит в систему и просматривает все задачи команды. Он замечает, что одна из задач имеет высокий приоритет, и изменяет статус с "в работе" на "приостановлена" для пересмотра.
🚀 Проектирование архитектуры системы
Компоненты системы:
- Клиентская часть: веб-интерфейс для пользователей, реализующий взаимодействие с API.
- Серверная часть: RESTful API для обработки запросов от клиентской части.
- База данных: хранилище для хранения информации о задачах, пользователях и их взаимодействиях.
- Система уведомлений: модуль, отправляющий уведомления по email и в приложении.
Взаимодействие компонентов:
- Клиентская часть отправляет запросы к серверной API для создания, изменения и удаления задач.
- Серверная часть обрабатывает запросы и взаимодействует с базой данных для хранения информации.
- Система уведомлений получает данные о изменениях задач и рассылает уведомления.
————————————
Так же мне были даны дополнительные задания, которые я выполнила после собеса🤯
⚠️ Оценка рисков - распишем позже
🧑💻 Моделирование бизнес-процессов - тоже опишу позже
Продолжение следует👉
Источник: @ba_and_sa
Картинка
#вакансии #собеседование | @ba_and_sa
Тема: Анализ требований и проектирование системы управления задачами
Мне предстояло разработать спецификацию требований для системы управления задачами, используемой командой разработчиков в IT-компании.
Моя задача заключается в следующем:
Прям на собеседовании:
1. Сбор требований: Определить функциональные и нефункциональные требования к системе.
2. Создание модели пользовательских сценариев: Описать, как разные типы пользователей будут взаимодействовать с системой.
3. Проектирование архитектуры системы: Определить основные компоненты системы и их взаимодействие.
Задание на дом:
4. Оценка рисков: Выявить потенциальные риски, связанные с реализацией проекта, и предложить меры по их минимизации.
5. Моделирование бизнес-процессов: Описать основные процессы, связанные с управлением задачами, создать диаграмму потоков, диаграмму активности
📋 Сбор требований
Функциональные требования:
- Управление задачами: Пользователи могут создавать, редактировать, удалять задачи.
- Статусы задач: Возможность изменять статус задачи (новая, в работе, завершенная, отклоненная).
- Приоритеты задач: Установка приоритета (низкий, средний, высокий) для каждой задачи.
- Командная работа: Назначение задач на участников команды и возможность добавления соисполнителей.
- Оповещения: Уведомления о новых задачах и изменениях статусов по email и в приложении.
- Поиск и фильтрация: Функционал для поиска задач по различным критериям (поиск по названию, фильтры по статусу и приоритету).
- Отчеты: Генерация отчетов о выполненных задачах и анализ времени, затраченного на выполнение задач.
Нефункциональные требования:
- Производительность: Система должна обрабатывать до 1000 запросов в минуту.
- Безопасность: Обеспечение конфиденциальности данных пользователя через шифрование.
- Надежность: Доступность системы не менее 99.9%.
- Масштабируемость: Возможность добавления новых функций без значительных изменений в архитектуре.
Пользовательские роли:
- Администратор: Может управлять пользователями, изменять настройки системы, просматривать отчеты.
- Разработчик: Может создавать и управлять своими задачами, назначать задачи другим пользователям, комментировать задачи.
- Менеджер: Может просматривать статус задач, генерировать отчеты о выполнении задач, изменять приоритеты.
Сценарий использования:
- Разработчик заходит в систему, создает новую задачу, назначает ее себе и устанавливает срок выполнения. Затем он добавляет комментарий к задаче и устанавливает статус "в работе".
- Менеджер заходит в систему и просматривает все задачи команды. Он замечает, что одна из задач имеет высокий приоритет, и изменяет статус с "в работе" на "приостановлена" для пересмотра.
Компоненты системы:
- Клиентская часть: веб-интерфейс для пользователей, реализующий взаимодействие с API.
- Серверная часть: RESTful API для обработки запросов от клиентской части.
- База данных: хранилище для хранения информации о задачах, пользователях и их взаимодействиях.
- Система уведомлений: модуль, отправляющий уведомления по email и в приложении.
Взаимодействие компонентов:
- Клиентская часть отправляет запросы к серверной API для создания, изменения и удаления задач.
- Серверная часть обрабатывает запросы и взаимодействует с базой данных для хранения информации.
- Система уведомлений получает данные о изменениях задач и рассылает уведомления.
————————————
Так же мне были даны дополнительные задания, которые я выполнила после собеса
⚠️ Оценка рисков - распишем позже
Продолжение следует
Источник: @ba_and_sa
Картинка
Please open Telegram to view this post
VIEW IN TELEGRAM