🙌 Всем привет и ОСТОРОЖНО, СПОЙЛЕР!🚨
Если вы не прошли последний КВИЗ по типам требований (листайте вверх ⬆️), то предлагаем сначала ответить на все вопросы, а потом уже читать этот пост. Потому что сейчас мы всей командой намерены рассказывать вам про ответы 🥷💥
Первые два вопроса были после теоретических частей про бизнес- и функциональные требования. Поэтому начнём с них.
1️⃣ Укажите ошибочное высказывание о бизнес-требованиях.
☝️ Условие сообщает, что из предложенных вариантов только один является ошибочным, его-то и необходимо определить.
Первый вариант. Мы с вами знаем, что бизнес-требования оттого и имеют приставку “бизнес-”, потому что отражают интересы компании в изменениях.
Второй вариант. Чаще всего этот тип требования поступает от заказчика в полном или неполном виде (кривое-косое, без метрик или сразу прекрасное, да ещё и с отработанной продуктовым аналитиком концепцией решения🌈)
Четвёртый вариант. И конечно идеальное бизнес-требование должно содержать метрику успеха (на сколько планируется изменить текущий показатель?), на основании которой можно понять, в каком случае изменение считается спроектированным успешно и интересы бизнеса достигнуты.
Например:
Необходимо увеличить на 17% количество лидов от партнёра, завершивших последний этап регистрации на нашем сайте.
👌 Если по результатам выхода решения для требования обозначенный показатель будет достигнут, значит метрика оказалась достижимой, а реализация – успешной.
Бизнес-требования – это недетализированная формулировка, отражающая интересы бизнеса в изменениях, и этот тип требования не готов к передаче в разработку.
Теперь мы с вами понимаем, что одно бизнес-требование может породить множество различных вариантов решений в существующих процессах.
Например:
🔹 придумать систему лояльности для пользователей, которые приходят от партнёра;
🔹 упростить систему регистрации;
🔹 просить пользователей предоставлять необходимую для регистрации в нашей системе информацию партнёру и через согласие клиента получать эти данные, чтобы автоматически завершать регистрацию за лида.
Вариантов может быть множество, поэтому задача аналитика – найти решение поставленной бизнесом задачи. Именно поэтому бизнес-требование не годится для передачи в разработку – в нём нет конкретики реализации, а есть только цель.
Получается, что ошибочным высказыванием будет третий вариант. Его и выбираем ☑️
🕺🏻 перерыв на победную ламбаду 💃🏻
2️⃣ Укажите верное высказывание о функциональных-требованиях
☝️ Исходя из условия мы знаем, что верное высказывание только одно, а остальные – ошибочные.
Первый вариант. Функциональные требования отражают задачу пользователя (что он хочет уметь делать), но точно не отражают цель, ради которой он ожидает выполнять это действие.
Давайте вспомним про шаблон пользовательской истории.
Как [роль], я хочу [задача], чтобы [цель].
Как пользователь сайта, я хочу авторизоваться с помощью почты, чтобы быстрее попасть в личный кабинет.
Функциональное требование из этого пользовательского будет отражать ожидаемое действие пользователя – авторизация с помощью адреса почты. Часть с описанием цели в пользовательском требовании необходима для понимания мотивации для выполнения действия и для определения успешного выбора действия для достижения пользовательской цели.
Из-за того, что функициональное требование рождается из пользовательского, информация о том, для чего пользователю нужна эта функция, на этом уровне уже излишняя.
Второй вариант. Функциональные требования сообщают разработчикам, какой результат должен получиться в результате проектировки. Какая бы экспертиза в архитектурном проектировании и системе не была у аналитика, написание кода – это не наша зона ответственности. Наша задача – предоставить чёткие атомарные (неделимые) требования к решению.
Если вы не прошли последний КВИЗ по типам требований (листайте вверх ⬆️), то предлагаем сначала ответить на все вопросы, а потом уже читать этот пост. Потому что сейчас мы всей командой намерены рассказывать вам про ответы 🥷💥
Первые два вопроса были после теоретических частей про бизнес- и функциональные требования. Поэтому начнём с них.
1️⃣ Укажите ошибочное высказывание о бизнес-требованиях.
☝️ Условие сообщает, что из предложенных вариантов только один является ошибочным, его-то и необходимо определить.
Первый вариант. Мы с вами знаем, что бизнес-требования оттого и имеют приставку “бизнес-”, потому что отражают интересы компании в изменениях.
Второй вариант. Чаще всего этот тип требования поступает от заказчика в полном или неполном виде (кривое-косое, без метрик или сразу прекрасное, да ещё и с отработанной продуктовым аналитиком концепцией решения🌈)
Четвёртый вариант. И конечно идеальное бизнес-требование должно содержать метрику успеха (на сколько планируется изменить текущий показатель?), на основании которой можно понять, в каком случае изменение считается спроектированным успешно и интересы бизнеса достигнуты.
Например:
Необходимо увеличить на 17% количество лидов от партнёра, завершивших последний этап регистрации на нашем сайте.
👌 Если по результатам выхода решения для требования обозначенный показатель будет достигнут, значит метрика оказалась достижимой, а реализация – успешной.
Бизнес-требования – это недетализированная формулировка, отражающая интересы бизнеса в изменениях, и этот тип требования не готов к передаче в разработку.
Теперь мы с вами понимаем, что одно бизнес-требование может породить множество различных вариантов решений в существующих процессах.
Например:
🔹 придумать систему лояльности для пользователей, которые приходят от партнёра;
🔹 упростить систему регистрации;
🔹 просить пользователей предоставлять необходимую для регистрации в нашей системе информацию партнёру и через согласие клиента получать эти данные, чтобы автоматически завершать регистрацию за лида.
Вариантов может быть множество, поэтому задача аналитика – найти решение поставленной бизнесом задачи. Именно поэтому бизнес-требование не годится для передачи в разработку – в нём нет конкретики реализации, а есть только цель.
Получается, что ошибочным высказыванием будет третий вариант. Его и выбираем ☑️
🕺🏻 перерыв на победную ламбаду 💃🏻
2️⃣ Укажите верное высказывание о функциональных-требованиях
☝️ Исходя из условия мы знаем, что верное высказывание только одно, а остальные – ошибочные.
Первый вариант. Функциональные требования отражают задачу пользователя (что он хочет уметь делать), но точно не отражают цель, ради которой он ожидает выполнять это действие.
Давайте вспомним про шаблон пользовательской истории.
Как [роль], я хочу [задача], чтобы [цель].
Как пользователь сайта, я хочу авторизоваться с помощью почты, чтобы быстрее попасть в личный кабинет.
Функциональное требование из этого пользовательского будет отражать ожидаемое действие пользователя – авторизация с помощью адреса почты. Часть с описанием цели в пользовательском требовании необходима для понимания мотивации для выполнения действия и для определения успешного выбора действия для достижения пользовательской цели.
Из-за того, что функициональное требование рождается из пользовательского, информация о том, для чего пользователю нужна эта функция, на этом уровне уже излишняя.
Второй вариант. Функциональные требования сообщают разработчикам, какой результат должен получиться в результате проектировки. Какая бы экспертиза в архитектурном проектировании и системе не была у аналитика, написание кода – это не наша зона ответственности. Наша задача – предоставить чёткие атомарные (неделимые) требования к решению.
🔥2
Третий вариант. Функциональные требования отражают интересы заказчика в лице бизнеса и/или пользователей. Если проектная команда будет создавать систему только исходя из интересов бизнеса, лояльность пользователей к продукту будет снижаться. А ноу юзерс, ноу ханей, ю ноу? 🍯🐝
Продуктом пользуется человек и платит за этот продукт бизнесу. Поэтому необходимо учитывать обе стороны.
Четвёртый вариант. CRUD-модель работы с данными (создание, чтение, изменение и удаление) действительно упрощает первичный сбор требований с заказчика. Тут действует принцип Парето (Vilfredo Federico Damaso Pareto), где 20% усилий в виде четырёх вопросов к функциональным возможностям внутри решения дают 80% результата. Пробуйте применить в работе – будете приятно удивлены 😊
Кстати, четвёртый вариант будет верным высказыванием.Пикачу, выбираем тебя ☑️
А сейчас перерыв на чашечку чая (или что там у вас в субботу?🙃) и через пару часов продолжаем.
Продуктом пользуется человек и платит за этот продукт бизнесу. Поэтому необходимо учитывать обе стороны.
Четвёртый вариант. CRUD-модель работы с данными (создание, чтение, изменение и удаление) действительно упрощает первичный сбор требований с заказчика. Тут действует принцип Парето (Vilfredo Federico Damaso Pareto), где 20% усилий в виде четырёх вопросов к функциональным возможностям внутри решения дают 80% результата. Пробуйте применить в работе – будете приятно удивлены 😊
Кстати, четвёртый вариант будет верным высказыванием.
А сейчас перерыв на чашечку чая (или что там у вас в субботу?🙃) и через пару часов продолжаем.
👍5❤1
Переходим к серии вопросов по всей теме типов требований.
1️⃣ Верно ли, что бизнес-требования имеют средний уровень детализации ожидаемых возможностей к ПО?
Нет, неверно. Средний уровень детализации имеют пользовательские, но никак не бизнес-требования. «Они настолько верхнеуровневые, что даже Гулливер задирает голову» 😁
2️⃣ Верно ли, что требования переходного периода реализуются для того, чтобы переход между текущим состоянием системы и её будущим состоянием произошёл с меньшими осложнениями?
Эбсолютли райт! 🎉 Чтобы подготовить систему к новому состоянию, можно ещё до выхода функциональности в продакшн внести изменения в существующие процессы.
Например:
Если в приложении для доставки блюд не выводился состав блюд, но в рамках новой функциональности эта возможность планируется, то уже сейчас можно запрашивать эту информацию у ресторанов и сохранять в системе.
Вот вам и плавный переход между состояниями системы.
3️⃣ Верно ли, что пользовательские требования чаще всего формулируются по шаблону пользовательских историй?
Запрос пользователя безусловно можно сформулировать в формате, ближе к функциональным требованиям.
Например:
Пользователь должен иметь возможность указывать банковскую карту для оплаты.
Но если бы мы знали цель пользователя (чтобы что?): удобно и быстро проводить оплату без повторного ввода номера карты, то функциональное требование бы изменилось на:
Пользователь должен иметь возможность привязывать банковскую карту к личному профилю.
В первом случае пользователь будет иметь возможность указывать банковскую карту каждый раз для проведения оплаты (что не решает его проблему, которая не указана), а во втором – сможет указать её единожды и постоянно оплачивать с помощью неё доставку.
Именно поэтому пользовательские требования лучше формулировать по шаблону User story.
4️⃣ Верно ли, что нефункциональные требования влияют на функциональные возможности проектируемой системы?
Нефункциональные требования влияют на результат функциональных требований, но не на сами алгоритмы выполнения функции. Процесс всё равно выполнится – успешно или неуспешно, но он будет завершён. Огромное вам спасибо за обсуждение в комментариях – там мы постарались разобрать формулировку вопроса и аргументировать разные точки зрения (это было супер!) 🖤
1️⃣ Верно ли, что бизнес-требования имеют средний уровень детализации ожидаемых возможностей к ПО?
Нет, неверно. Средний уровень детализации имеют пользовательские, но никак не бизнес-требования. «Они настолько верхнеуровневые, что даже Гулливер задирает голову» 😁
2️⃣ Верно ли, что требования переходного периода реализуются для того, чтобы переход между текущим состоянием системы и её будущим состоянием произошёл с меньшими осложнениями?
Эбсолютли райт! 🎉 Чтобы подготовить систему к новому состоянию, можно ещё до выхода функциональности в продакшн внести изменения в существующие процессы.
Например:
Если в приложении для доставки блюд не выводился состав блюд, но в рамках новой функциональности эта возможность планируется, то уже сейчас можно запрашивать эту информацию у ресторанов и сохранять в системе.
Вот вам и плавный переход между состояниями системы.
3️⃣ Верно ли, что пользовательские требования чаще всего формулируются по шаблону пользовательских историй?
Запрос пользователя безусловно можно сформулировать в формате, ближе к функциональным требованиям.
Например:
Пользователь должен иметь возможность указывать банковскую карту для оплаты.
Но если бы мы знали цель пользователя (чтобы что?): удобно и быстро проводить оплату без повторного ввода номера карты, то функциональное требование бы изменилось на:
Пользователь должен иметь возможность привязывать банковскую карту к личному профилю.
В первом случае пользователь будет иметь возможность указывать банковскую карту каждый раз для проведения оплаты (что не решает его проблему, которая не указана), а во втором – сможет указать её единожды и постоянно оплачивать с помощью неё доставку.
Именно поэтому пользовательские требования лучше формулировать по шаблону User story.
4️⃣ Верно ли, что нефункциональные требования влияют на функциональные возможности проектируемой системы?
Нефункциональные требования влияют на результат функциональных требований, но не на сами алгоритмы выполнения функции. Процесс всё равно выполнится – успешно или неуспешно, но он будет завершён. Огромное вам спасибо за обсуждение в комментариях – там мы постарались разобрать формулировку вопроса и аргументировать разные точки зрения (это было супер!) 🖤
👍5🔥1
🏎💨 Ну и последние два вопроса КВИЗа (финишная прямая, ребята! )
5️⃣ Укажите бизнес-требование в представленном перечне
Для этого давайте тезисно вспомним, что содержит бизнес-требование:
🔸 описание цели изменения с точки зрения бизнеса (выгода);
🔸 идеально, если содержит метрику успешности (с единицами измерения).
Проанализируем варианты ответов.
Первый вариант. Описание содержит конкретную функциональную возможность внутри решения и совсем не сообщает, какую цель преследует бизнес. Больше похоже на детализацию требования до функциональной возможности.
Второй вариант. Бизнес хочет увеличить количество участников сообщества (это цель), приведена даже метрика успеха – 20% (это мера ожидаемого результата). И даже рассказали про верхнеуровневую концепцию решения в конце. Класс, берём! ☑️
Третий вариант. Непонятно, для каких целей планируем создать платформу. А как мы уже знаем, для достижения бизнес-цели можно найти множество путей с различной стоимостью и затратами.
6️⃣ Укажите функциональное требование в представленном перечне
Начнём со второго варианта. Функциональное требование не должно содержать информацию о том, как именно нужно достичь поставленной цели. Никаких названий полей в требовании быть не должно – разработчик имеет бОльшую экспертизу в написании кода.
☝️ Очень важно, что мы говорим именно про формулировку требований к ПО. Если же мы описываем AS IS-работу системы (бэкенд логика, интеграционное взаимодействие и тд), то детализация до системного уровня зачастую необходима для чистого понимания текущих процессов.
Третий вариант содержит два сложноизмеримых термина: “хорошо” и “недолго”. Функциональные требования должны пониматься однозначно всеми участниками проектной команды, потому что для разных людей есть своё понимание хорошего и быстрого. Не подходит.
Ну а первый вариант достаточно понятно сообщает о том, что необходима функциональная возможность отправки код-пароля на привязанный номера телефона пользователя. Наверняка дальше аналитик опишет ограничения и правила, на основании которых сформируются требования к код-паролю и логике определения номера,но это уже совсем другая история.
Фух, ну и потрудились мы с вами в субботу! Спасибо вам за участие в КВИЗе и за общение в комментариях! 🖤
Мы же здесь не только мемы смотрим, а вообще-то общаемся с единомышленниками и развиваем экспертизу в системном и бизнес-анализе – ЭТО ЛИ НЕ ЧУДО?😊🎉
Отличных выходных, друзья!
5️⃣ Укажите бизнес-требование в представленном перечне
Для этого давайте тезисно вспомним, что содержит бизнес-требование:
🔸 описание цели изменения с точки зрения бизнеса (выгода);
🔸 идеально, если содержит метрику успешности (с единицами измерения).
Проанализируем варианты ответов.
Первый вариант. Описание содержит конкретную функциональную возможность внутри решения и совсем не сообщает, какую цель преследует бизнес. Больше похоже на детализацию требования до функциональной возможности.
Второй вариант. Бизнес хочет увеличить количество участников сообщества (это цель), приведена даже метрика успеха – 20% (это мера ожидаемого результата). И даже рассказали про верхнеуровневую концепцию решения в конце. Класс, берём! ☑️
Третий вариант. Непонятно, для каких целей планируем создать платформу. А как мы уже знаем, для достижения бизнес-цели можно найти множество путей с различной стоимостью и затратами.
6️⃣ Укажите функциональное требование в представленном перечне
Начнём со второго варианта. Функциональное требование не должно содержать информацию о том, как именно нужно достичь поставленной цели. Никаких названий полей в требовании быть не должно – разработчик имеет бОльшую экспертизу в написании кода.
☝️ Очень важно, что мы говорим именно про формулировку требований к ПО. Если же мы описываем AS IS-работу системы (бэкенд логика, интеграционное взаимодействие и тд), то детализация до системного уровня зачастую необходима для чистого понимания текущих процессов.
Третий вариант содержит два сложноизмеримых термина: “хорошо” и “недолго”. Функциональные требования должны пониматься однозначно всеми участниками проектной команды, потому что для разных людей есть своё понимание хорошего и быстрого. Не подходит.
Ну а первый вариант достаточно понятно сообщает о том, что необходима функциональная возможность отправки код-пароля на привязанный номера телефона пользователя. Наверняка дальше аналитик опишет ограничения и правила, на основании которых сформируются требования к код-паролю и логике определения номера,
Фух, ну и потрудились мы с вами в субботу! Спасибо вам за участие в КВИЗе и за общение в комментариях! 🖤
Мы же здесь не только мемы смотрим, а вообще-то общаемся с единомышленниками и развиваем экспертизу в системном и бизнес-анализе – ЭТО ЛИ НЕ ЧУДО?😊🎉
Отличных выходных, друзья!
🤩6❤1
Встречаются как-то на планёрке в ZOOM бизнес-аналитик, системный аналитик и аналитик данных. Еще, конечно, владелец бизнеса и руководитель проекта 😄
Владелец бизнеса говорит:
- Надо создать новый онлайн-магазин с украшениями.
🌟 Бизнес аналитик пойдёт проводить исследование: изучит конкурентов, проанализирует целевую аудиторию, текущие тенденции в отрасли. ОБЯЗАТЕЛЬНО разберётся в законодательстве: посмотрит законы и правила, регулирующие онлайн-торговлю, чтобы убедиться, что новый онлайн-магазин будет соответствовать всем требованиям.
После всё структурирует, опишет бизнес-процессы и определит требования к функциональности магазина, чтобы затем передать их системному аналитику.
🌟 Теперь в игру вступает системный аналитик
СА рассмотрит информацию от БА и проанализирует бизнес-процессы, чтобы понять, как пользователь будет себя вести, зайдя на сайт. На какие кнопки будет нажимать: что ему нужно, чтобы товар добавился в избранное. Решать, какие должны быть инструменты, чтобы клиент совершил целевое действие — зарегистрировался или купил.
Затем начнёт проектирование системы, опишет сценарии работы пользователей, определит ключевые данные и разработает алгоритмы их обработки, разработает требования к интеграции систем - обмену данными между ними, поставит задачи на разработчиков, а затем задокументирует решение.
В процессе разработки системный аналитик будет следить за тем, чтобы все требования были учтены и решать возникающие проблемы. Он также поможет с тестированием системы и может обучить пользователей её использованию.
Весь процесс очень интересный, насыщенный, кропотливый.
🌟 Теперь поприветствуем аналитика данных
Этот специалист будет после анализировать данные о продажах, когда запустится сайт и находить, что ещё можно докрутить и доработать.
Например, он увидит, что хорошо продаются определённые кольца, значит, хорошо могут пойти комплекты — кольцо с серьгами в одном стиле.
Или, что пользователи добавляют в корзину товары, но не переходят к оплате. Значит что-то у нас с процессом не так.
Владелец бизнеса говорит:
- Надо создать новый онлайн-магазин с украшениями.
🌟 Бизнес аналитик пойдёт проводить исследование: изучит конкурентов, проанализирует целевую аудиторию, текущие тенденции в отрасли. ОБЯЗАТЕЛЬНО разберётся в законодательстве: посмотрит законы и правила, регулирующие онлайн-торговлю, чтобы убедиться, что новый онлайн-магазин будет соответствовать всем требованиям.
После всё структурирует, опишет бизнес-процессы и определит требования к функциональности магазина, чтобы затем передать их системному аналитику.
🌟 Теперь в игру вступает системный аналитик
СА рассмотрит информацию от БА и проанализирует бизнес-процессы, чтобы понять, как пользователь будет себя вести, зайдя на сайт. На какие кнопки будет нажимать: что ему нужно, чтобы товар добавился в избранное. Решать, какие должны быть инструменты, чтобы клиент совершил целевое действие — зарегистрировался или купил.
Затем начнёт проектирование системы, опишет сценарии работы пользователей, определит ключевые данные и разработает алгоритмы их обработки, разработает требования к интеграции систем - обмену данными между ними, поставит задачи на разработчиков, а затем задокументирует решение.
В процессе разработки системный аналитик будет следить за тем, чтобы все требования были учтены и решать возникающие проблемы. Он также поможет с тестированием системы и может обучить пользователей её использованию.
Весь процесс очень интересный, насыщенный, кропотливый.
🌟 Теперь поприветствуем аналитика данных
Этот специалист будет после анализировать данные о продажах, когда запустится сайт и находить, что ещё можно докрутить и доработать.
Например, он увидит, что хорошо продаются определённые кольца, значит, хорошо могут пойти комплекты — кольцо с серьгами в одном стиле.
Или, что пользователи добавляют в корзину товары, но не переходят к оплате. Значит что-то у нас с процессом не так.
👍4
Все три роли — бизнес-аналитик, системный аналитик и аналитик данных нередко работают ВМЕСТЕ для успешной реализации проекта 🌟🌟🌟
Порой, когда мы смотрим какое-то приложение, заказываем еду, или кладём в корзину онлайн-магазина классную футболку, мы даже не догадываемся, какая огромная работа аналитиков и команды разработчиков стоит за этим.
И именно IT-аналитики помогают сделать эти системы и превратить их в реальность 🙌
Если вы только ищете себя в IT и хотите получить ответ на вопрос "В чем разница между аналитиками?", то новая статья поможет вам 😉
Порой, когда мы смотрим какое-то приложение, заказываем еду, или кладём в корзину онлайн-магазина классную футболку, мы даже не догадываемся, какая огромная работа аналитиков и команды разработчиков стоит за этим.
И именно IT-аналитики помогают сделать эти системы и превратить их в реальность 🙌
Если вы только ищете себя в IT и хотите получить ответ на вопрос "В чем разница между аналитиками?", то новая статья поможет вам 😉
getanalyst.ru
Какие бывают аналитики в IT и в чем отличия: бизнес-аналитик, системный аналитик, аналитик данных
Часто те, кто только начинают погружаться в IT, или думают о смене профессии в этом направлении, то сразу вспоминают о тестировщиках или программистах. Но если вы ступили на путь карьеры в IT и копаете глубоко, то скорее всего уже встретились с профессиями…
👍1🔥1
Системный аналитик - это такой навигатор в команде, который смотрит на всю карту IT-проекта целиком и понимает, как сделать путь разработки от точки А до точки B максимально эффективным 🌍
У нас в сообществе GetAnalyst важен опыт. Я хочу рассказать про IT-проекты, на которых работают системные аналитики, обсудить зону ответственности и границы между бизнес-анализом и системным анализом.
⚡️ Почему в IT нужны системные аналитики:
про опыт работы в IT-проектах
🗓 22 июня в 19:00 Мск
🟢 Расскажу, что делать со скилами системного аналитика в Европе и США, что такое проекты на фриланс для аналитиков и как их искать.
🟢 Как начать карьеру с позиции системного аналитика.
🟢 Какие тренды сейчас с учетом развития AI и ML, и как быть востребованным на рынке труда.
Регистрируйся по ссылке, чтобы не пропустить!
У нас в сообществе GetAnalyst важен опыт. Я хочу рассказать про IT-проекты, на которых работают системные аналитики, обсудить зону ответственности и границы между бизнес-анализом и системным анализом.
⚡️ Почему в IT нужны системные аналитики:
про опыт работы в IT-проектах
🗓 22 июня в 19:00 Мск
🟢 Расскажу, что делать со скилами системного аналитика в Европе и США, что такое проекты на фриланс для аналитиков и как их искать.
🟢 Как начать карьеру с позиции системного аналитика.
🟢 Какие тренды сейчас с учетом развития AI и ML, и как быть востребованным на рынке труда.
Регистрируйся по ссылке, чтобы не пропустить!
👍2
Forwarded from GetAnalyst - Навыки • Системный анализ • Бизнес-анализ
This media is not supported in your browser
VIEW IN TELEGRAM
Когда системный аналитик хорошо проработал Use Cases 😎
🤣7👍1
🌴 Все так мечтают об удалёнке, забывая, что при таком формате работы нужно ещё больше дисциплины, чем при работе в офисе 🐝
Но как же прекрасно, что в сфере IT можно работать как угодно:
🔹 из офиса,
🔹 удалённо (из дома / кофейни, с пляжа и так далее),
🔹 гибридно (и так, и сяк).
Именно благодаря комфортным условиям вокруг рабочего места действительно получается сконцентрироваться на работе и выдавать качественный результат команде разработки 😎
Но как же прекрасно, что в сфере IT можно работать как угодно:
🔹 из офиса,
🔹 удалённо (из дома / кофейни, с пляжа и так далее),
🔹 гибридно (и так, и сяк).
Именно благодаря комфортным условиям вокруг рабочего места действительно получается сконцентрироваться на работе и выдавать качественный результат команде разработки 😎
🔥4
Несколько раз в своей жизни я задавала себе вопрос - а зачем я нужна на проекте?
😞 Разработчики могут все и без меня.
Но потом я начинала разбираться в том, какие результаты моей работы есть в созданных IT-продуктах и.... Вклад огромный! Профессия системного аналитика вдохновляет!
Но вопросы по ней были 😄
1. Когда поступила в университет, то не понимала кто я. Очень надеялась, что научат программировать и все.
2. Когда только начинала работать в команде с опытными разработчиками, моих технических знаний не хватало. Постоянно были вопросы к постановкам задач - основная обязанность системного аналитика. Но в итоге благодаря этим ошибкам я быстро выросла от джуна до мидла за пол года.
3. Когда мне захотелось подработку и фриланс, а затем свой бизнес, то я думала, что так могут только программисты и тестировщики. Системный аналитик может работать только в компании. А оказалось, что это не так, и моих скилов хватает на большее.
Были и другие моменты, но это те, которые круто влияли на мою жизнь.
⚡️ Почему в IT нужны системные аналитики: про опыт работы в IT-проектах
🗓 22 июня в 19:00 Мск
🟢 ЗАРЕГИСТРИРОВАТЬСЯ
Уже завтра расскажу про то, как становятся системными аналитиками и как можно расти на примерах из своего опыта.
Я прошла пусть от стажера системного аналитика до основателя IT-компаний. Многократно поменяла жизнь, города и страны. И продолжаю расти благодаря IT 🚀 Хочу поделиться с вами как профессия Системного аналитика повлияла на мою жизнь на примере своих проектов.
На вебинаре будет необычный подарок. В этот раз никаких гайдов и чеклистов (хотя...😉). Это будет что-то большее 😉
До встречи завтра!
P.S. ⚡️🗓 До 21 июня 23:59 Мск открыта предзапись на практический курс Системный аналитик: с нуля до опыта работы на проекте. Заявка по предзаписи гарантирует скидку и место на обучение в группе до 20 человек 🎁
😞 Разработчики могут все и без меня.
Но потом я начинала разбираться в том, какие результаты моей работы есть в созданных IT-продуктах и.... Вклад огромный! Профессия системного аналитика вдохновляет!
Но вопросы по ней были 😄
1. Когда поступила в университет, то не понимала кто я. Очень надеялась, что научат программировать и все.
2. Когда только начинала работать в команде с опытными разработчиками, моих технических знаний не хватало. Постоянно были вопросы к постановкам задач - основная обязанность системного аналитика. Но в итоге благодаря этим ошибкам я быстро выросла от джуна до мидла за пол года.
3. Когда мне захотелось подработку и фриланс, а затем свой бизнес, то я думала, что так могут только программисты и тестировщики. Системный аналитик может работать только в компании. А оказалось, что это не так, и моих скилов хватает на большее.
Были и другие моменты, но это те, которые круто влияли на мою жизнь.
⚡️ Почему в IT нужны системные аналитики: про опыт работы в IT-проектах
🗓 22 июня в 19:00 Мск
🟢 ЗАРЕГИСТРИРОВАТЬСЯ
Уже завтра расскажу про то, как становятся системными аналитиками и как можно расти на примерах из своего опыта.
Я прошла пусть от стажера системного аналитика до основателя IT-компаний. Многократно поменяла жизнь, города и страны. И продолжаю расти благодаря IT 🚀 Хочу поделиться с вами как профессия Системного аналитика повлияла на мою жизнь на примере своих проектов.
На вебинаре будет необычный подарок. В этот раз никаких гайдов и чеклистов (хотя...😉). Это будет что-то большее 😉
До встречи завтра!
P.S. ⚡️🗓 До 21 июня 23:59 Мск открыта предзапись на практический курс Системный аналитик: с нуля до опыта работы на проекте. Заявка по предзаписи гарантирует скидку и место на обучение в группе до 20 человек 🎁
🌎 Системный аналитик в США и Европе 🌎 #expertGetAnalyst
Многие IT-специалисты сейчас стремятся получить работу в Европе или США, хотя бы удаленно. Аналитики не исключение.
При этом желание не всегда связано с переездом. Многим интересно получить опыт работы в зарубежных компаниях, посмотреть, как выстраиваются процессы, перенять классный опыт и расширить круг знакомств.
Первое, что делает будущий соискатель — изучает вакансии. И есть челлендж поиска работы для системных аналитиков 😱
В США и Европе название позиций, которым соответствуют навыки системного аналитика, отличаются. Разные компании используют различные термины для описания одной и той же должности. Позиция "Системный аналитик" есть, но иногда ее обызанности скрыты под другими названиями: бизнес-аналитик, аналитик информационных систем, технический менеджер проекта, продукт-менеджер, бизнес-консультант в IT и другие.
Важно понимать, что название позиции не является самоцелью.
Роль системного аналитика может включать в себя разные наборы обязанностей: всё зависит от того, как её видят в конкретной компании. Поэтому лучше сразу знакомиться с подробным описанием вакансии: сверяться по задачам, которые нужно выполнять с тем, что умеете вы.
Радует, что с навыками системных аналитиков мы с вами нигде не пропадем! Они всегда покрывают навыки бизнес-аналитика. То есть системный аналитик это продолжение карьеры бизнес-анаитика в техническом направлении, которое ведет к росту технический компетенций и росту дохода 🙌
Самый лучший способ понять, что нужно работодателю — это откликнуться на вакансию, попробовать получить приглашение и пройти собеседование. Это ни к чему не обязывает, но точно расширяет границы восприятия и помогает определить точки роста. А также повысить уверенность и попрактиковаться в коммуникациях с работодателем.
Помните, главное — не название профессии, а прокаченные hard и soft skills.
Развивайтесь и совершенствуйтесь. Тогда вы будете востребованы в любой стране 😉
Про поиск работы в мире можно почитать 👉 здесь
Многие IT-специалисты сейчас стремятся получить работу в Европе или США, хотя бы удаленно. Аналитики не исключение.
При этом желание не всегда связано с переездом. Многим интересно получить опыт работы в зарубежных компаниях, посмотреть, как выстраиваются процессы, перенять классный опыт и расширить круг знакомств.
Первое, что делает будущий соискатель — изучает вакансии. И есть челлендж поиска работы для системных аналитиков 😱
В США и Европе название позиций, которым соответствуют навыки системного аналитика, отличаются. Разные компании используют различные термины для описания одной и той же должности. Позиция "Системный аналитик" есть, но иногда ее обызанности скрыты под другими названиями: бизнес-аналитик, аналитик информационных систем, технический менеджер проекта, продукт-менеджер, бизнес-консультант в IT и другие.
Важно понимать, что название позиции не является самоцелью.
Роль системного аналитика может включать в себя разные наборы обязанностей: всё зависит от того, как её видят в конкретной компании. Поэтому лучше сразу знакомиться с подробным описанием вакансии: сверяться по задачам, которые нужно выполнять с тем, что умеете вы.
Радует, что с навыками системных аналитиков мы с вами нигде не пропадем! Они всегда покрывают навыки бизнес-аналитика. То есть системный аналитик это продолжение карьеры бизнес-анаитика в техническом направлении, которое ведет к росту технический компетенций и росту дохода 🙌
Самый лучший способ понять, что нужно работодателю — это откликнуться на вакансию, попробовать получить приглашение и пройти собеседование. Это ни к чему не обязывает, но точно расширяет границы восприятия и помогает определить точки роста. А также повысить уверенность и попрактиковаться в коммуникациях с работодателем.
Помните, главное — не название профессии, а прокаченные hard и soft skills.
Развивайтесь и совершенствуйтесь. Тогда вы будете востребованы в любой стране 😉
Про поиск работы в мире можно почитать 👉 здесь
👍4👎1
Привет-привет! Вчера провели эфир на котором обсудили как системному аналитику живется в мире IT, какие у него зоны ответсвенности и задачи.
Самое-самое:
🌟 Откуда приходят в профессию и как начать работу по специальности без опыта (картинка к посту + много крутых комментариев было в эфире)
🌟 Челленджи аналитика - какие задачи выходящие за пределы специальности может решать системный аналитик.
🌟 Возможности карьерного роста через развитие определенных навыков и желание.
🌟 Собеседование: ошибка и лайфхак (неожиданно, по вопросам из чата).
🌟 Вакансии и стажировки.
Разбирали IT-проект, с которым продолжим работу на следующей неделе 😉
Для тех, кто не успел подключиться, проведем повтор.
📹 Сегодня в 15:00 Мск
🟢 ЗАРЕГИСТРИРОВАТЬСЯ можно по той же ссылке.
Если уже регистрировались, то просто подключайтесь по ссылке, которая придет за 15 мин до начала трансляции.
Очень активно провели весь эфир! Спасибо за ваши вопросы - они сделали его еще лучше, чем я ожидала! ❤️
Самое-самое:
🌟 Откуда приходят в профессию и как начать работу по специальности без опыта (картинка к посту + много крутых комментариев было в эфире)
🌟 Челленджи аналитика - какие задачи выходящие за пределы специальности может решать системный аналитик.
🌟 Возможности карьерного роста через развитие определенных навыков и желание.
🌟 Собеседование: ошибка и лайфхак (неожиданно, по вопросам из чата).
🌟 Вакансии и стажировки.
Разбирали IT-проект, с которым продолжим работу на следующей неделе 😉
Для тех, кто не успел подключиться, проведем повтор.
📹 Сегодня в 15:00 Мск
🟢 ЗАРЕГИСТРИРОВАТЬСЯ можно по той же ссылке.
Если уже регистрировались, то просто подключайтесь по ссылке, которая придет за 15 мин до начала трансляции.
Очень активно провели весь эфир! Спасибо за ваши вопросы - они сделали его еще лучше, чем я ожидала! ❤️
❤1