Всем привет!

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

🟢 Микросервисы: от бизнес-процессов до интеграционного взаимодействия
🌟Сегодня в 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️⃣: Проектирование архитектуры

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

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


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

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

💥 Продолжаем с этапами разработки ПО! 💥

На первых трёх этапах разработки ПО:
1️⃣ Сбор и анализ требований
2️⃣ Документирование требований
3️⃣ Проектирование архитектуры
аналитик задействован на все 200%.

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

Этап 4️⃣: Разработка системы

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

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


Этап 5️⃣: Тестирование созданной системы

Тестирование системы — это комплексная проверка её алгоритмов на:
🔹корректную работу в разных операционных системах (Mac, Windows, другие), браузерах (например Яндекс Браузер, Mozilla Firefox, Safari, Chrome) и на разных устройствах (смартфоны, планшеты, компьютеры);
🔹 соответствие полученного результата ожиданиям в прописанных требованиях;
🔹 наличие «слепых зон» в логике работы функциональности, которые не были обозначены на этапе аналитики.

В тестировании участвует инженер по тестированию (по-другому — тестировщик). Он проверяет созданный продукт на соответствие требованиям и договорённостям, которые аналитик выявил на этапе сбора и анализа, и зафиксировал на этапе документирования. Все найденные несоответствия или слепые зоны тестировщик подробно описывает и обсуждает с аналитиком. В случае если работа функциональности отличается от указанной логики в требованиях, тестировщик «откатывает» задачу обратно на этап разработки.


Этап 6️⃣: Внедрение и перевод в поддержку и развитие

Внедрение системы — это обучение пользователей, выдача учётных записей и поддержка пользователей в начале работы с системой.
Чтобы продукт «ушёл в народ», нужно подружить пользователя с ПО:
🔹 продемонстрировать ПО в действии,
🔹 написать инструкцию и ответить на возникшие вопросы.

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

Так как IT-продукт — это система, которая живёт и развивается, жизненный цикл может воспроизводиться несколько раз.

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

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

👀 А ВОТ И КВИЗ! #quizGetAnalyst

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

Итак, ваша задача:
1. Внимательно прочитайте предложенные высказывания на тему цикла разработки ПО.
2. Отметьте все верные высказывания, а все неверные не отмечайте. Получается, верных высказываний может быть несколько.

А потом вместе проверим и обсудим ответы в комментариях. Удачи! 🥷

Друзья, внеплановый мем 😅
#GAhahaha

👋 Итак, друзья, результаты КВИЗ-а!

1. 🔴 Бизнес- и системные аналитики на первых трёх этапах действительно являются прямыми исполнителями. На этапе разработки, тестирования и внедрения аналитики тоже привлекаются, но в качестве экспертов и согласующих. Итог: аналитик привлекается на всех этапах цикла разработки ПО.

2. 🔴 Количество этапов в разработке ПО не зависит от методологии разработки ПО. В каскадной (или, по-другому, водопадной) модели и в гибких методологиях цикл разработки состоит из тех же чередующихся этапов.

3. 🟢 🔴 Вы не попались на шалость! Если говорить про этапы жизненного цикла ПО, то проектирование архитектуры — это отдельный шаг в этом цикле, поэтому утверждение можно считать неверным.
Но если все три этапа объединить одним процессом — процессом сбора требований, то по результатам этого процесса аналитик предоставляет артефакт в виде требований к ПО и его архитектуре. Поэтому высказывание также можно считать утвердительным. Короче говоря, важна верная аргументация.

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

4. 🟢 Этапы разработки ПО — это цикличный процесс. Каждое новое обновление внутри проектирумой системы запускает этот процесс с начала.

5. 🟢 ПО может проходить не все этапы цикла разработки — всё зависит от сложности и даже типа задачи. Например, задачи на рефакторинг не подразумевают сбор требований.

Ну как вы, справились? По результатам КВИЗа мы решили, что вы просто умницы! 😎

🔥 МОТИВАЦИЯ НА ЭТИ ВЫХОДНЫЕ 🔥