Всем привет!

Отличной всем недели!😉

Новеньким в канале советую посмотреть закрепленные сообщения, там можно познакомитсья со мной и выбрать сервис менторов для записи. Пс, советую GetMentor, как говорится, без комиссии и переплат😅

А сейчас предлагаю выбрать темы, на которые мы поговорим в течении недели.
(Сейчас тут появится опрос🙃)

Всем привет!

Продолжаем тему развития бизнес аналитика. Сегодня обсудим развитие через углубление экспертных знаний в бизнес анализе. 😎🤓🥸🧐

И на этом пути есть такой парадокс: с одной стороны это углубление в бизнес-анализ, с другой стороны это расширение своих знаний и навыков в нем. Как это возможно? 🤯

Очень часто говорю, что бизнес-анализ широкое направление. Это скорее подходы и инструменты, которые можно применить во всех сферах, где ведется бизнес.

В B2B, B2C, B2G, в промышленности, в производстве, в разработке, везде можно применить подходы бизнес-анализа, нужно только подобрать подходящие. Т.е. чтобы развиваться как эксперт в бизнес-анализе нужно изучать больше сфер и инструментов.

В том же BABOK указано и четко сформулировано 5 ракурсов бизнес-анализа:
• Agile;
• BI (Business Intelligence);
• Информационные технологии;
• Бизнес-архитектура;
• Управление бизнес-процессами.

Работая в ИТ аналитик постепенно набирается опыта в среднем по двум ракурсам, и это при условии, что задачи аналитику поступают разнообразные. Чаще бывает, когда аналитик устраивается в компанию на однообразные задачи, например заказную разработку однотипных систем и годами применяет инструменты только из одного ракурса - информационных технологий.

Можно привести и другой пример: аналитик в продуктовой компании или заказной разработке разноплановых систем, тогда аналитик может развиваться по трем ракурсам - Agile, Информационные технологии и Управление бизнес-процессами.

Примерами для ракурсов BI и бизнес-архитектуры будут BI-аналитики и аналитики в консалтинговых компаниях, которые как раз занимаются задачами бизнес-архитектуры и иногда анализом бизнес-данных.

Вот и получается, что для того, чтобы стать экспертом нужно расширять свой проф. кругозор и учиться применять больше инструментов бизнес-анализа.

Приводить полный список возможных инструментов, практик и методов бизнес-анализа тут не буду, их всегда можно посмотреть в BABOK.)

А каким ракурсом занимаетесь или хотите заниматься вы?🙃

Ха-ха!

Поделюсь своей небольшой радостью🙃
Мое фото разместили на сайте Практикума.)

Как приятно стать лицом наставников в Яндекс.Практикума))
В разделе «Станьте проводником в мир новых профессий».
https://practicum.yandex.ru/job

Вопросы на собеседовании. Пример из жизни.🙃

На собеседовании вам дают ситуацию: вы сходили к двум стейкхолдерам и выяснили, что требования от них противоречат друг другу. Что будете делать?😳

Возможно первое решение, которое придет вам в голову - это диалог. Сесть с двумя стейкхолдерами, менеджерами и обсудить приоритетность требований.

Однако, это не единственное решение и порой не самое подходящее.

Для таких ситуаций существует специальный инструмент, который поможет в целом выстроить коммуникацию на проекте - карта стейкхолдеров.

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

Также следует учесть, что решение конфликта может зависеть от типа продукта или проекта. В случае, если это продукт B2C, то ценность для клиента будет важнее всего. В случае B2B, необходимо договариваться со стейкхолдерами в первую очередь.

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

Знали о карте, пользовались?

Вчера вышел мой авторский пост для канала Эйч)
Наболевшая и нашумевшая тема, чем отличаются системный и бизнес аналитик😅

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

Продолжим разговор о том, как можно развиваться в области бизнес аналитики в IT сфере. Мы уже рассмотрели разные направления развития – процессное и экспертное. А сегодня поговорим об интересном и перспективном развитии в техническом IT направлении – становлении системного аналитика и в дальнейшем возможности стать Solution Architect.

🔹 Для начала, хочу сказать, что если вы уже работаете в IT команде, то стать системным аналитиком будет проще. Достаточно просто взаимодействовать с разработчиками и обсуждать с ними технические вопросы. Да, это потребует активной коммуникации и задавания интровертам вопросов😋, чтобы они начали что-то объяснять, но скажу вам, это стоит того. Через такие обсуждения можно лучше понять, как устроены системы и как они функционируют. И это необходимо для карьерного роста в техническом направлении.

🔹 Чтобы стать системным аналитиком, придется овладеть определенными навыками и знаниями. К примеру, языки проектирования, такие как IDEF0 и UML, обязательны к изучению. Также важно понимать архитектуру систем в разных платформах, будь то мобильные или веб-приложения. Работа с интеграциями и их проектирование, включая API, json, xml, xsd, Swagger – также необходимы для успешной работы системного аналитика.

🔹 Хочу поделиться с вами еще несколькими рекомендациями для развития: изучайте стандарты и ГОСТы.
К примеру,
ГОСТ 34.602-2020 для создания автоматизированных систем,
ГОСТ 19.201-78 для создания технического задания программного обеспечения,
ГОСТ 28195-89 о требованиях к качеству программного обеспечения, и, конечно же,
ГОСТ Р ИСО/МЭК 250 ... с требованиями к качеству автоматизированных систем.

🔍 И в последние годы стали очень актуальны системные аналитики DWH, которые занимаются корпоративными хранилищами данных. Если вы интересуетесь этой областью, рекомендую углубить свои знания и навыки в этом направлении.

А вам интересно как устроены системы?🙃

Всем привет и отличного начала недели!

Продолжим про вопросы на собеседовании, которые могут задать аналитику.

Представьте, вам задали вопрос:
«Что такое SDLC и расскажите про ответственность аналитика на каждом этапе»
Как на него ответить наиболее выигрышным образом?

Для этого лучше придерживаться следующего подхода:
🟣 Определяем SDLC и перечисляем его основные этапы;
🟣 Рассказываем ответственность аналитика на этапах;
🟣 Приводим примеры своего опыта, и если требуется объясняем какие навыки и знания помогают вам успешно выполнять свою часть работы по SDLC.

Сегодня определим SDLC и перечислим его этапы.

Итак, что такое SDLC?🤯

SDLC (Software Development Life Cycle) или Жизненный Цикл Программного Обеспечения - это период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. (В Википедии самое простое определение).

Жизненный Цикл может соответствовать разным моделям, самые известные это модель гибких методологий (Agile) и каскадная модель (Waterfall).

Жизненный Цикл ПО состоит из следующих этапов:
• Анализ и сбор требований;
• Планирование;
• Проектирование;
• Разработка;
• Тестирование;
• Эксплуатация (включает в себя развертывание, внедрение и сопровождение).

Разбираем в следующем посте ответственность аналитика на этапах?🙃

Хей-хей!
Всем привет!

Сегодня опубликовала статью, которую писала для Solvery (площадка менторов и наставников в ИТ).

Материала получилось много, поэтому советую читать в спокойной обстановке.)

Спойлер: описание вакансий таит в себе много дополнительной и важной информации о компании и роли.

Как читать вакансии между строк и как понять, что компания вам подходит

Всем привет из моего непредвиденного, но необходимого перерыва.👻

Вторую половину прошлой недели пришлось посвятить отдыху и перезагрузке. Объемная статья для vc далась с трудом, надеюсь, что подготовка следующей будет заметно легче.🤤 В общем, у меня был day off, чтобы не быть тем самым бессмертным пони из стишка.🤗

Перейдя полностью на удаленный режим работы и еще и совмещая несколько видов деятельности порой очень легко вылететь из размеренного ритма работы и жизни. Что я порой и делаю. Особенно, если интенсивность хотя бы на одном из проектов начинает резко нарастать. В таких случаях, двух выходных бывает недостаточно. Иногда спасают российские праздники, а иногда нужно эти праздники устроить самостоятельно.)

Чем полезны day off:
🟣 Восстановление энергии и профилактика выгорания
🟣 Восстановление или поддержание work-life balance
🟣 Улучшение творческого мышления и продуктивности
🟣 Укрепление здоровья и благополучия

А что вы думаете про day off? Берете их на работе при потребности?

Как SDLC связан с методологиями разработки ПО?

В прошлый раз мы говорили про то, что такое SDLC и наткнулись на интересный вопрос, чем жизненный цикл отличается от методологий разработки ПО?

Жизненный цикл - это состав работ, которые нужно сделать для получения ПО. Методология - это один из способов провести весь необходимый состав работ для получения ПО.

Сейчас будет странная аналогия. Обед. Обед состоит из нескольких блюд + напитки. И блюда, и напитки как составляющие обеда, нужно приготовить. Какими именно способами будет приготовлен обед зависит от определенных условий, но в любом способе потребуется выполнить какой-то набор действий или работ, чтобы получить обед.

То же самое с разработкой ПО.

🗒 При применении Waterfall, по сути, нужно лишь последовательно выполнить этапы SDLC. Результат работы предыдущего этапа должен стать входными данными для начала следующего.

💃 При использовании Agile придется немного перестроиться и представить конечное ПО в виде небольших кусков готовых к использованию, т.е. поделить работы каждого этапа на итерации с работающим инкрементом в результате.

🤯 Если требуется систематизировать процессы работ между разработчиками и операционными командами, то часто прибегают к методологии DevOps. Сейчас даже отдельных специалистов, которые занимаются автоматизированием развертывания сервисов и резервного копирования называют - девопсами. Но эта часть работ наступает только тогда, когда приходит момент развернуть готовое ПО или сервис в среде, где им смогут пользоваться.

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

Получается, что Agile и Waterfall применяют для работы с требованиями и планирования, а DevOps используют для развертывания и резервного копирования полученного ПО или сервиса.

Однако, важно помнить, что мое описание очень сильно упрощено и является скорее концептуальным, нежели практическим описанием отличий методологий.😅