Конкурсу быть

У тебя есть возможность высказаться и выиграть 😇

Механика:
В комментариях под этим постом расскажи про самое ужасное место работы или ситуацию с работодателем.

Условия:
1. Быть подписанным на канал
2. Поделиться каналом или постом (можно в сторис ТГ, можно в личные коллеге, можно в чаты)
3. Быть в IT или около 🙂

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

На кону:
Бесплатная часовая консультация со мной.

Итоги конкурса символично подведу 9 мая.

Аналитик в связке с UX/UI дизайнером: помощник или враг?

Важно❗️
Никто из этой связки — ни аналитик, ни дизайнер — не может быть помощником или врагом.

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

UX/UI-дизайнер для аналитика — смежная роль, которая выполняет свои обязанности. То же самое делает разработчик.
Аналитик в связке с разработчиком всегда должны работать последовательно, совместно, и у них должно быть продуктивное взаимодействие. То же самое с UX-дизайнером, с тестировщиком — с любой ролью, особенно если мы говорим про гибкие подходы к разработке.

В целом работа строится от того, какая ответственность на дизайнере. Есть такие проекты или продукты, где дизайнер отвечает только за внешний вид, то есть это скорее UI-дизайнер.
Бывают проекты, где дизайнер следит за внешним видом и User experience, в таком случае аналитик помогает дизайнеру, либо не мешает. Аналитик работает с функциональными и с пользовательскими требованиями. И эти пользовательские требования должны быть созвучны с тем, что делает UX-дизайнер.

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

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

И если часть исследований UX-дизайнер и аналитик могут между собой поделить, то написание или описание требований, ТЗ, постановку задач лучше оставлять за аналитиком. Здесь компетенция аналитика будет больше.

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

Проект
Аналитик пишет полное ТЗ, функциональные и нефункциональные требования к продукту или проекту, занимается документацией, готовит low-fi прототипы и потом этот пакет документов отдает дизайнеру на доработку.
Требования дизайнер использует как входные данные, в то время как low-fi прототипы перестроит, чтобы нарастить больше UI-компонентов правильных форматов, размеров, цветов и так далее по гайду. Еще может построить интерактивные прототипы или макеты интерфейсов для пользовательских исследований.

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

Согласны?)

Не забывайте писать свои истории тут. Конкурс длится до 9 мая.

С победителем проведу часовую консультацию.

Вопрос — ответ

В Москве метель в мае — странно, а я — интроверт и жду ваших вопросов 😄

Задавайте вопросы на темы поиска работы аналитикам, сложности при повышении, методики на проектах и выстраивания процессов. Всё обсудим.

Итоги конкурса

С праздником, друзья!
И победитель «битвы» с рассказами про ужасное место работы — Карина.

Я ориентировалась на свое мнение и смотрела на вашу реакцию.

Карина, жди меня в понедельник у себя в личных сообщения :)

Всем большое спасибо за участие. Будут новые конкурсы — буду ждать ваши истории!

Учусь ли я после 9+ лет в анализе и чему?

Учиться — это акутально, нужно всегда и никогда не поздно.

IT — это та сфера, которая быстро развивается и не стоит на месте. С того времени, когда она только стала популярна в мире, многое уже поменялось. Каждый час появляются новые подходы, практики, методики, теории, которые нужно проверять и исследовать. Поэтому в любой профессии в IT всегда будет чему поучиться, каким бы опытом или багажом специалист не обладал.

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

Еще учусь организаторским способностям с точки зрения организации встреч, мастер-классов.

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

Учиться приходится как софтовым, так и хардовым навыкам, но эффективнее смотреть на чужой опыт плюс ретроспектировать собственный 😉

Кто о чем, а мы о деньгах, или сколько стоит сотрудника нанять?

https://habr.com/ru/articles/812195/

Какие бывают аналитики: 10 ролей и еще 3

https://habr.com/ru/companies/simbirsoft/articles/811881/

Всем привет-привет!

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

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

Как у вас?
👍 — тип-топ
🥲 — дайте ещё шашлыка

Из чего состоит техническое собеседование для БА?

Техническое собеседование или оценка навыков бизнес-аналитика проводится в 3-4 основных форматах:

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

Формат экзамена
Знаком нам всем со школы. Похоже на вопрос-ответ, но в строгих и стрессовых обстоятельствах. Сухо гоняют по теоретическим вопросам и не дают никакой обратной связи. Дал академическое определение — молодец. Не дал — понятно, идем дальше. Причем при таком формате вопросы часто абсолютно никак не связаны с опытом, а только с теорией.

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

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

Это основные форматы технических собеседований.

Если пост наберет 20 реакций, дальше расскажу какие темы и вопросы точно будут на технических собеседованиях для бизнес-аналитика 😉

Кто я для кого я пишу?

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

Меня зовут Лариса. Я бизнес аналитик в ИТ индустрии. Наставник в Яндекс.Практикуме и эксперт в Эйч.

Мой опыт:
Работала в заказной, продуктовой разработке и консалтинге. В сферах edtech, medtech, fintech, e-commerce, govtech. Развивала как отдельных аналитиков, так и отдел анализа. Нанимала ит-специалистов и сама не раз искала работу, поэтому понимаю как устроен найм в ИТ компаниях и как строить траекторию поиска, чтобы попасть в компанию мечты.

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

Я в цифрах:
10+ опыта в ИТ
> 7-ми команд запустила
> 20 человек в управлении
> 100 консультаций на Эйч
> 200 часов консультаций собственной практики

Я в названиях:
EPAM, ВТБ, TeDo ex.PWC, LetuTech — компании, где работала
Альфа-Банк, Epam Systems (Грузия), Mind Box, Anderson Lab, e.l.f Beauty (Британия), X5 и др. — компании, куда помогла трудоустроиться своим менти
GetMentor, Эйч — где я ментор
DUMP — где я спикер

Связь со мной — @ldansarunova

Хорошие, плохие требования

На тему плохих, хороших требований хочется порассуждать с двух сторон или двух «шляп», если вы меня понимаете.)

Когда я размышляю как человек со своими идеями, то в голову приходят банальная адекватность и практическая применимость, например:

— Однозначность: хорошие требования должны быть четкими и однозначными. Это позволяет избежать двусмысленностей и недоразумений на всех этапах проекта.

— Достоверность: требования должны быть основаны на реальных потребностях бизнеса и клиентов. Их цель – точно отражать задачи и ожидания заказчика.

— Измеримость: хорошие требования могут быть измерены и проверены на соответствие. Они должны быть конкретными и недвусмысленными.

— Полнота: важно учесть все необходимые детали и особенности требований, чтобы избежать дополнительных корректировок и уточнений в будущем.

— Гибкость: хорошие требования должны быть гибкими и адаптивными к изменениям. Часто требования могут меняться в процессе работы над проектом, и важно иметь возможность быстро и эффективно их корректировать.

Но, надевая вторую «шляпу» эксперта, вспоминаешь про проф. литературу и сухие правила.
Кто помнит свойства требования, пишите в комментарии — обсудим.)

Золотой кандидат

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

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

Десятками отсматривала резюме, с единицами, но каждый день проводила собеседования. Еще верила в мифическую и повсеместную конструктивность и думала, что резюме — это все что нужно для понимания подойдет человек в мою команду или нет. Наивно, правда?

И вот мы сидим с Product Owner в зуме и ждем кандидата, на которого возложили надежды. Нам так понравилось его резюме, казалось — это идеальный кандидат. Разработчик, который работал в fintech, лидировал трех других разработчиков, умеет проводить Agile-события и тд. Не кандидат, а золото.

После 10 минут мы поняли — фейк. Он не мог связать двух слов: ни про Agile, ни про себя и свой опыт. Причем буквально! Это не та история, где человек разволновался и не мог понять чего от него ждут. Человек написал все популярные слова в резюме, но на самом деле этим не занимался.

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

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

https://habr.com/ru/articles/803983/

Техническое собеседование для БА: какие вопросы и темы?

Вы молодцы — поставили больше 20 реакций на прошлый пост, а я пишу продолжение.

Вопросы для БА можно разделить на 4 группы:

Определение бизнес-требований
Могут подобрать банальные вопросы из разряда:
— Какие методики и инструменты вы используете/знаете для сбора и анализа бизнес-требований?
— Как вы определяете приоритеты бизнес-требований и каким образом они связаны с целями бизнеса?
— Как вы взаимодействуете с заказчиками и заинтересованными сторонами для выявления и уточнения бизнес-требований?
— Какие действия вы предпринимаете, если бизнес-требования конфликтуют друг с другом или с техническими ограничениями?
Тут же могут быть вопросы про виды стандартов или документации.

Умение работать с базами данных
Здесь хотят знать ваш уровень владения SQL, понимание структуры БД и моделирования. Спросят, например:
— Какие СУБД вы использовали?
— Какие типы соединений (join) в SQL вы знаете и в каких случаях их следует применять?
— Каким образом вы оптимизируете запросы к базам данных для улучшения производительности?
— Приходилось ли строить модели данных?

Моделирование процессов
Вопросы, направленные на понимание того, сколько нотаций вы знаете, сколькими из них владеете, действительно ли умеете моделировать.
— Какие инструменты вы используете для моделирования бизнес-процессов?
— Какие нотации вы знаете для моделирования бизнес-процессов и в каких случаях их следует использовать?
— Как вы проводите анализ и оптимизацию бизнес-процессов на основе моделей?
— Как вы обеспечиваете взаимодействие между заинтересованными сторонами в процессе моделирования бизнес-процессов?

Жизненный цикл ПО
Блок неоднозначный и широкий. Сюда попадают вопросы, несвязаные с предыдущими темами, но напрямую указывают на понимание процесса разработки, архитектуры и роли БА в этих вещах. Например:
— Какую роль бизнес-аналитик играет в процессе создания архитектуры ПО?
— Какие методологии разработки ПО вы знаете и применяли?
— Каким образом вы взаимодействуете с другими членами команды при проектировании архитектуры?
— Какова роль бизнес-аналитика в процессе внедрения разработанного ПО?

ВАЖНО!
Все примеры вопросов подходят только уровня Стажер или Джун. Для более высоких грейдов вопросы более точечные и включают названия конкретных инструментов или методов.

И давайте снова будем друг другу полезны.
Если пост наберет 50 реакций, расскажу какие темы и вопросы точно будут для Миддлов 😉

Выложила видео на Ютуб

Резюме бизнес аналитика: разбираю резюме опытного аналитика и даю рекомендации.
Благодарю Веронику за предоставленные резюме на РУ и EN версии.

Полезные тайминги:
1:00 — резюме на русском
2:25 — желаемая должность
5:00 — опыт работы
10:02 — достижения
17:30 — совмещения работ
29:34 — про нерелевантный опыт
32:25 — образование
34:08 — навыки
38:53 — резюме на английском

Смотреть тут — https://youtu.be/n_RbTQ58VXA?si=YZWxAqJeWRDQ_8P1&t=3

Эфиру быть

Всем привет-привет, хорошего, продуктивного дня.

У меня вчера был прямой эфир в Карьерном центре Яндекс.Практикума. Проводила тестовое техническое собеседование для БА. Было много вопросов, разбирали почему могут отказывать, сколько отказов можно получать, из-за чего они появляются на горизонте, как HR могут скрывать некоторые вещи, о которых мы можем догадываться и многое другое.

На этом фоне я подумала, может быть, нам с вами тоже провести такой эфир.

Оставляйте вопросы по трудоустройству в комментариях. Разберём на эфире 26 мая в 18:00.