Британские учёные выяснили, что 98% людей, которые печатали на конфетных ноутбуках, становятся айтишниками!

Но это неточно 😅

Всем отличной рабочей недели! 🚀

Уже через 3 часа! Практический вебинар с Екатериной Ананьевой и Никитой Румянцевым!

📹 Микросервисы: от бизнес-процессов до архитектурного решения
⏰ 19:00 - 21:00 Мск

Ссылку на прямой эфир пришлем в канал за 15 минут до начала.

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

🥷: Иными словами, аналитик ставит задачи на разработку не только бэкенд-логики, но и на фронтенд, и даже на дизайн.

На самом деле, один из важных hard skills аналитика – это прототипирование. Прототип – это черновой вариант продукта, который погрузит наблюдателей (заказчика, дизайнеров, разработчиков) в предметную область задачи.

Перед тем, как аналитик пойдёт к дизайнеру, важно иметь на руках прототип интерфейса — то, как должен выглядеть продукт и какие функциональности в нём должны быть отражены для пользователя. Именно на этапе создания прототипа интерфейса аналитик руководствуется своими знаниями UX/UI.


Тема UX и UI довольно увлекательная. Конечно, нет необходимости погружаться в детали проектирования дизайна интерфейса сильно глубоко. Ваша задача понимать:
🔹 как общаться с дизайнером и быть с ним «на одной волне»,
🔹 как передавать ему требования к интерфейсу и
🔹 как участвовать в оценке финального дизайна.
А знания в теме UX/UI — это отличный инструмент для аргументации в этих вопросах.


Далее хотим поделиться с вами лёгким чтивом для аналитиков о правилах проектирования дизайна интерфейсов:
1. Алан Купер, «Психбольница в руках пациентов»
2. Кирилл Егерев, «Этой кнопке нужен текст»
3. Артемий Лебедев, «Ководство» — некоторые главы лежат в бесплатном доступе на его сайте и постоянно обновляются, там же можно купить электронную версию 😉
4. Стив Круг, «Не заставляйте меня думать».


Всем отличных выходных, друзья! 😘 #hwGetAnalyst

Всем привет!

У нас переезд между почтовыми сервисами и нестабильно уходят письма 😔

🟢 Микросервисы: от бизнес-процессов до интеграционного взаимодействия
🌟Сегодня в 18:00 Мск - ссылка на вебинарную комнату:
https://pruffme.com/webinar/?id=f5dbe802611de4369f61521c1d91dd8d

Доп. повторы организуем завтра в 15:00 и 19 Мск, т.к. не всем пришла ссылка на трансляцию. Благодарим за понимание 🙏

👋 Одни из ТОП-навыков для резюме аналитиков: знание инструментов Postman и Swagger.

Эти инструменты незаменимы для системных и бизнес-аналитиков, которые участвуют в проектировании API. Но чем же они отличаются? А чем похожи? Давайте разбираться. #hardGetAnalyst


1️⃣ Postman — это интуитивно-понятное приложение, которое позволяет отправлять запросы к API и получать ответы от него.
Эти функции полезны для тестирования, отладки и проверки работоспособности API.

Postman также предоставляет возможность сохранять запросы и создавать коллекции запросов, что делает процесс тестирования API более организованным и быстрым. А ещё в нем можно вести API-документацию и писать автотесты для системной логики (бэкэнда). Наш босс Екатерина говорит, что этот инструмент вообще мастхэв и ультраприорити. Честно говоря, мы с ней согласны!

2️⃣ Swagger — это набор инструментов, который позволяет создавать документацию для API.
Swagger использует язык описания OpenAPI, благодаря чему автоматически генерирует документацию для API. Это упрощает процесс описания и тестирования API.

🥷: Документировать API можно и другими способами (например, с помощью Git-документации или Confluence). Поэтому аналитику осваивать Swagger однозначно нужно, но не так срочно, как Postman, например.


Знание Postman и Swagger может быть полезным для системных и бизнес- аналитиков при общении с разработчиками и тестировщиками. А ещё использование Postman и Swagger помогает:
🔹улучшить процесс проектирования API;
🔹упростить процесс тестирования и документирования;
🔹повысить качество кода за счет написания автотестов.

Оба инструмента бесплатные. Поэтому вы можете начать осваивать их самостоятельно в любой момент или обучаться этим навыкам вместе с командой GetAnalyst на наших вебинарах и курсах 🪄

Мем смешной, а ситуация страшная 🤡

#GAhahaha

Знакомо чувство, когда предстоит работа над новым проектом или в новой компании, а у тебя нет необходимых навыков? Либо ты в теории понимаешь, что делать, но не было реальной практики? Или, возможно, ты давно в IT, но какие-то технические моменты оставались за кадром: разработчики всегда всё делали сами. А теперь техническую проработку будут ждать от тебя, как от системного аналитика.

В случае интеграционных проектов часто возникают вопросы:
1️⃣ С чего начать работу с требованиями?
2️⃣ Что включать в задачи и какие документы формировать в процессе?
3️⃣ Какие инструменты нужно знать?

Многие системные аналитики утопают в деталях на старте, теряя видение общей картины. Давайте на практике разберемся, как начать работу с интеграциями и фокусироваться на главном в ходе работы над проектом!

📅 Интеграции: пошаговый план работы на проекте
6 сентября, 19:00 МСК
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Что вас ждёт:
🌐 Интеграции: что это и почему так важно в современном IT.
📝 Постановка задач: формулирование требований, взаимодействие с заказчиками и проработка деталей.
🛠 Инструменты аналитика: практика работы с Postman.
⚠️ Подводные камни, типичные ошибки и способы их решения.

Сделайте интеграции вашим сильным профессиональным навыком! Регистрируйтесь, и получайте свой опыт! 🚀

❗️Уже через 3 часа❗️

Практический вебинар с Екатериной Ананьевой!

📹 Интеграции: пошаговый план работы на проекте
⏰ 19:00 - 21:00 Мск

Ссылку на прямой эфир пришлем в канал за 15 минут до начала.

Вау. Вау. Вау! Это было круто и мы хотим это повторить!

Коллеги, вчера прошел практический вебинар
🧩 Интеграции: пошаговый план работы на проекте
и он был похож на что-то необыкновенное!

Я очень хочу поблагодарить коллег, кто был онлайн и работал со мной в пряом эфире, задавал вопросы через микрофон. Давайте все поставим ❤️ Катерине и Тиму в благодарность за активность!


О важном 👇

1. Я проводила этот вебинар с целью напомнить о старте потока по проектированию Интеграциий систем, но уже в понедельник мы поняли, что этот вебинар не нужен. Поток закрыт.
Почему я провела его ни смотря на перегрузку, с учетом конференции в понедельник и большого объема задач по текущим проектам?
Я обещала. Я сделала. И я счастлива, что еще один практический кейс у вас в копилке ❤️

2. Что будет в этот раз с повтором, и еще раз про то, почему я не публикую записи.
Коллеги, когда я создала GetAnalyst, я публиковала записи. Кому это было нужно? Никому. Откладывали на потом и никто не смотрел. Потом. Потом. Никогда. И зачем?
Я понимаю, что есть удобство по времени и среда 19Мск не всегда всем удобна. Но....
Благодаря текущему подходу с повторами вы онлайн и вы работаете в эфире. Вы задаете вопросы и я отвечаю сразу.
Про повтор: ждем сообщения от команды GetAnalyst здесь, на почте и на странице регистрации.


Я люблю GetAnalyst. Я хочу развивать наше сообщество. Но давайте хотя бы на минутку задумаемся.... Как много времени я дарю вам?

Я вижу коллег, кто со мной уже очень давно и ценит каждый мой эфир. И я вижу негодование "почему нет записей" и "инфоцыганство". Пусть это будет чем угодно, но я искренне горжусь людьми, кто благодаря GetAnalyst вырос и реализовал свои цели.

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

Всем крутого дня! Вернусь скоро с маппингом по сценарию с платежами 😊

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

Начало рабочей недели хотим сделать продуктивным, но не слишком сложным (ведь понедельники и так не сахар!😅). Сегодня подробнее разберём тему разработки ПО, а именно — сам процесс разработки IT-продукта #hardGetAnalyst

Создание и сопровождение любого IT-продукта – это многократно повторяющийся процесс внутри компании. Этот процесс называют жизненным циклом разработки ПО.

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

Создание любого ПО можно разделить на шесть этапов:

1️⃣ Сбор и анализ требований.
2️⃣ Документирование требований.
3️⃣ Проектирование архитектуры.
4️⃣ Разработка системы.
5️⃣ Тестирование созданной системы.
6️⃣ Внедрение и перевод в поддержку и развитие.

Далее подробнее о каждом из них.

Этап 1️⃣: Сбор и анализ требований

Для начала команда должна сформулировать, что она создаёт и зачем. Для этого необходимо собрать требования у заказчика.

Заказчик — это человек или группа людей, выступающие от лица пользователей ПО. Часто это руководитель отдела или владелец бизнеса.

Заказчик может отлично знать проблемные точки в своих процессах, но при этом не понимать, что с ними делать.
Перед стартом работы аналитик собирает требования у заказчика:
🔹 задаёт уточняющие вопросы,
🔹 анализирует работу конкурентов,
🔹 изучает уже существующую документацию,
🔹 анализирует обратную связь от пользователей,
🔹 наблюдает за процессами и так далее.

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


Этап 2️⃣: Документирование требований

После сбора информации аналитик перекладывает своё видение на «бумагу». Формируется документ, в нём прописывают:
🔹 требования к функционалу, который планируется разработать;
🔹 процессы в их нынешнем состоянии (AS IS)
🔹 и то, к какому виду они должны прийти после разработки (TO BE).

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


Этап 3️⃣: Проектирование архитектуры

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

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


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

🥷: Кстати говоря, про этапы разработки ПО часто спрашивают на собеседованиях 😉