Продолжим разговор о том, как можно развиваться в области бизнес аналитики в 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 используют для развертывания и резервного копирования полученного ПО или сервиса.

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

Привет всем!🖖

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

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

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

Шаги для перехода от бизнес-аналитика к Продакт Менеджеру:

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

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

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

Сертификация. На данный момент не существует специальных сертификаций для Продакт Менеджеров. Однако, международные Agile-сообщества предлагают разные программы сертификации, подходящие для этой роли. Например, Организация ICAgile предоставляет ряд сертификатов для Продакт Менеджеров. Также можно получить сертификаты, подтверждающие владение определенными методологиями Agile, такими как PSM для Scrum или RTE для SAFe.

А вы встречали Продакт Менеджеров, которые выросли из бизнес-аналитиков? Поделитесь своими историями в комментариях!

С понедельником, товарищи!)

Режим реактивной белки в колесе активирован😋

Работа над проектом на основной работе, консультации, работа и написание контента по IThumanWork. Как все успевать и при этом не стать зомби?🙃

А как ваши понедельники? Активные?😅

И традиционное голосование за темы постов на этой и возможно следующей неделе.)

Всем хай!

Я с бомбическими новостями 🤗

На YouTube-канале прекрасной Ксении (передаю тебе большой и теплый привет😊) вышло видео, где мы порассуждали о карьерном пути бизнес аналитика.

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

Предлагаю посмотреть/послушать за чашечкой чего-нибудь приятного)

Смотреть здесь: https://youtu.be/CrcWDF8MIg8

Всем привет!

Сегодня я с вакансиями от хорошей компании. 🙃

Звук — это музыка в HiFi-качестве, а также подкасты, аудиокниги, эксклюзивные плейлисты и раздел для детей. Звук работает с тремя аудиториями: B2C, B2B - Звук Бизнес, B2A - Звук Студио

Продукт: https://zvuk.com/
Карьерный сайт: https://career.zvuk.com/

На карьерном сайте найдете вакансии аналитиков с адекватными требованиями и весьма приятными условиями.)
Например вакансии:
🟣 системного аналитика - https://career.zvuk.com/system-analyst;
🟣 продуктового аналитика - https://career.zvuk.com/Product_analyst;
🟣 бизнес аналитика с акцентом на аналитику бизнес данных - https://career.zvuk.com/Business-Analyst

А тем у кого есть управленческий опыт и готов претендовать на позицию Project Manager советую рассмотреть вот эту вакансию: http://hh.ru/vacancy/80375101

Компания строит продуктовые команды и соответствующие процессы работы при этом с заботой о сотрудниках и понимаем их ценности как основного актива. Такие места быстро разбирают, поэтому если вы в поиске, присмотритесь))

Контакт Дарья: @dasha_selezneva

Всем хай!!💃

Надеюсь, начало недели у всех выдалось удачным?🙃 Делитесь в комментариях, мне очень интересно с вами пообщаться.)

Не смотря на активный день и иссякающие силы, я все равно пишу для вас пост.) Потому что обещала и потому что для меня это важно.

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

draw.io или diagrams.net - бесплатный инструмент визуализации. Достаточно универсальный и простой во всех смыслах. Аналитиками часто используется им для моделирования бизнес-процессов, особенно в случаях, когда корпоративных решений нет или нужно смоделировать что-то не слишком сложное. Например, внимание, сделать тестовое задание или потренироваться.😅

Что в нем круто:

🟣 Импорт и экспорт данных. Если есть уже какие-то наработки в подходящих расширениях, то можно импортировать их в рабочую зону Draw.io и продолжить выстраивать схему процесса или обмена данными.

🟣 Создание процессных диаграмм. Несмотря на простоту в инструмент вшито довольно много наборов элементов, включая процессные нотации. Например, BPMN 2.0 и блок-схемы. Также можно других базовых элементов можно изобразить и другие нотации, например простейший EPC. Для большинства бизнесовых задач подходит вполне.

🟣 Визуализация данных. Кроме наборов элементов для процессов есть и наборы для изображения данных. Даже вполне рабочий набор UML или ER, DFD.😉 Для тренировки его точно будет достаточно, правда помучиться с редактированием стрелок и связей все же придется.) Но я говорила, что инструмент простой. В том числе и с точки зрения логики. Он предоставляет наборы элементов, но интеллектуально помогать при построении моделей он не умеет. Это минус, но при свободном использовании - не существенный.

🟣 Совместная работа. Все в лучших традициях Гугл.Диска. Можно включить режим совместного использования и командой работать над одной моделью. Особенно удобно, когда отдельные части модели могут дополняться независимо друг от друга.) Мы со студентами Я.П пользуемся, вполне удачно.)

🟣 Экспорт и представление результатов. Функция экспорта или возможность скачать проработанную модель в привычных форматах pdf или png/jpg оказалась одной из самых конкурентных. И до сих пор остается. Не многие моделеры позволяют выгрузить результат в таких форматах.

Помню, когда-то очень давно работала над моделью процессов работы регистратуры в поликлинике. Нужно было показать Заказчику как много услуг и действий автоматизирует Система и решить какие нужно автоматизировать следующими. У меня вышла модель на 4 листа А3. Формат бумаги А3, чтобы вы понимали, это половина школьного ватмана.)) Вот с такой огромной картой, которую пришлось распечатывать в типографии я месяц ходила к Заказчику.)) И если бы в Draw.io не было этой функции, я бы где-нибудь повесилась😂🤭

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

Пользоваться можно как в Гугл.Диске, так и через приложения (они вроде появились).

Пользуетесь, пробовали?🤔

Всем привет!

С новым проектом, за который я взялась писать посты каждый день стало нереально😅 Но я буду продолжать стараться😉

На этой неделе со студентами Я.П. придумали мне новую тему для поста.

Телеграм каналы с вакансиями для бизнес аналитиков: Как их находить и какие стоящие каналы есть сейчас.

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

1. Используйте поиск по ключевым словам. Рекомендую выполнять именно в качестве первого шага, потому что бесконечно искать альтернативы запросу «бизнес анализ» или «бизнес аналитик» не получится.

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

3. Обратите внимание на значимые бренды в ИТ. Например, каналы технологических компаний. Многие из них публикуют вакансии в свои ряды.

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

Такими нехитрыми шагами я нашла активные каналы с актуальными вакансиями.

Например:

🟣 https://t.me/saba_hunter - канал, где публикуются смешанные вакансии для бизнес и системных аналитиков;
🟣 https://t.me/analyst_job - агрегатор чатов с вакансиями по направлениям;
🟣 @g_jobbot - бот, который можно настроить присылать вам подходящие вакансии по фильтрам.

А как вы ищете каналы с вакансиями в Телеграм?🙃

Всем привет!

Поймала себя на мысли, что мои собственные идеи для постов стали иссякать.

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

Срезаю с мыслями «да кому это интересно», «это и так уже все знают», «зачем вообще об этом говорить - это очевидно» и т.д.

Поэтому я к вам за помощью🙃

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

Буду очень вам благодарна. Плюс буду лучше понимать что вам интересно😋

Вчера получила вопрос, как успешно пройти испытательный срок (ИС) ?

Постараюсь ответить тезисно. Я напишу свои мысли по этому поводу и буду рада увидеть ваши комментарии. Пишите свои мысли и истории того, как вы проходили ИС🙃

Так вот, чтобы пройти испытательный срок не требуется ничего сверхъестественного, только ваше желание. Однако, это желание нужно трансформировать в смелость задавать вопросы и приносить пользу команде как можно раньше.
Все остальные качества или навыки нужны не только во время ИС, например, умение работать в команде или навыки коммуникации. Для прохождения ИС я считаю наиболее критичными эти качества:

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

Приведу в пример наиболее интересную историю из своей проф. жизни. Я тогда была Лидом группы бизнес анализа. В мою группу попал начинающий аналитик, который никогда до этого не занимался анализом. Он был геологом. Удивила?😅

Так вот, он хотел заниматься анализом систем и присоединился к нашей команде из-за прошлого релевантного опыта, ведь мы создавали ПО для геологоразведки.

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

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

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

Дальше пробовать не было смысла. Человек не сумел понять, что промедления и самонадеянность стоили команде и компании чей-то годовой оклад.

А что думаете вы? Или может у вас тоже есть интересные истории про ИС, пишите в комментариях)

Как собрать требования и оформить их в ТЗ так, чтобы не сойти с ума?🤯

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

Сегодня обсудим один из способов сбора требований - изучение нормативной документации.

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

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

На что стоит обращать внимание при изучении НПА (нормативно-правовых актов):

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

🟣 Зависимости между участниками. Кто для кого является триггером или кто кому обязан предоставить информацию или сообщить о чем-то влияющем на процесс. Это тоже стоит отметить на карте или в ваших заметках.

🟣 Части работ или задачи участников. Это даст представление о том, как именно задействован тот или иной участник в процессе. И насколько его работа важна в этом процессе.

🟣 Входы и выходы в задачи. Стоит начать с самых приоритетных для процесса работ. Отметить без чего работа не может начаться и что будет ее результатом.

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

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

Расскажите свои истории того, как вы собирали требования из документации и стейкхолдеров. Обсудим 😉

Всем хай!)

Анализ или аналитика?🧐

Замечаю, что в последнее время появилась такая холиварная тема «как правильно называть деятельность аналитика. Бизнес анализ или бизнес аналитика? Системный анализ или системная аналитика?»

Хотя, не уверена что она только появилась. 🤔Скорее поддерживается в ИТ кругах последний год.

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

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

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

Совет на будущее. Такие яркие темы споров в ИТ были всегда, но они никогда не несли в себе какие-то сильно полезные изменения для индустрии. И смысла тратить на них много сил и внимания - нет никакого.

До «анализа» и «аналитики» такой же глобальной темой были слова «функционал» и «функциональность». И хотя интернет пестрит призывами относительно ИТ использовать только «функциональность», но в жизни это мало кто делает. Возможно из-за банальной причины: слишком сложное и длинное для частого произношения слово.🤗

А вы что думаете?🙃 Натыкались на рассуждения или споры по этому поводу?