Хотите посмотреть на подходы к проектированию REST API в разных проектах? Сложности в попытках освоить Postman? Хотите повысить свою квалификацию и расти в карьере? 💼

Бесплатный мастер-класс, где вы сможете не только смотреть, но и попробовать!

🚀 26 июля в 19:00 Мск
🟢 REST API за вечер: от концепции до Postman
ЗАПИСАТЬСЯ НА МАСТЕР-КЛАСС

За один вечер:
🌟 поймете основы работы с REST API,
🌟 научитесь читать и описывать объекты данных систем в JSON-формате,
🌟 узнаете, как правильно определять названия методов.
🌟 перенесете результаты проектирования REST API в документацию Postman.

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

Готовы к переменам? До встречи в прямом эфире через 5 дней ❤️

Конечно спешат, ведь сегодня воскресенье!😉

Поговаривают, что если работать там, где нравится, то на работу спешишь, как на праздник и понедельники не страшны 👍 Что думаете?

Друзья, всем отличного воскресенья. А завтра продолжим делать шаги навстречу работе мечты вместе с командой GetAnalyst 🚀💥

Лучший способ понять теорию — получить больше опыта в разных проектах.

Новый гайд для системных аналитиков:
📚 Процесс работы системного аналитика: практическое руководство, примеры и шаблоны

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

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

На связи Нина 🥷, бизес-аналитик команды GetAnalyst.

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


Я пришла в сферу IT неподготовленной — вообще-то по специальности я HR. Но так получилось, что на собеседовании удалось пройти тестовое задание на позицию джуна аналитика и вот я с удовольствием застряла тут на целых 5 лет (и не собираюсь уходить😉)!

Когда я слушала разговоры своих коллег, я выхватывала из контекста слова «шина» (причём тут колёса?), «кейс» (чемоданчик?), «юзабилити» (чтокаволити?!) и тому подобное.

Моя ошибка в начале пути — я стеснялась задавать вопросы. Ведь я могу показаться глупой и руководитель разочаруется, что сделал мне оффер 😖 Поэтому я постоянно гуглила или додумывала смысл услышанного, что не всегда давало качественные, а главное правильные результаты.

Спустя какое-то время я поняла, что грамотный специалист из области аналитики всегда задаёт вопросы. Я начала «окучивать» своего наставника вопросами по типу «а что это?», «а как это работает?», «а где про это почитать?» и так далее. Скоро страх получить отказ или косой взгляд прошёл совсем и сейчас я могу задавать вопросы заказчику до тех пор, пока не получу точный однозначный ответ. В нашей профессии больше знаешь — крепче спишь 🙃

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


🚀 26 июля в 19:00 Мск пройдёт бесплатный мастер-класс по REST API, где вы самостоятельно выполните интеграционный кейс, который сможете добавить в резюме.
🤓 Но самое главное – вы сможете задать 1000 и 1 вопрос о профессии и API одному из лучших специалистов в сфере системного анализа, Екатерине Ананьевой!💥

🔽🔽🔽

ЗАПИСАТЬСЯ НА МАСТЕР-КЛАСС

🔼🔼🔼

Я не знаю, как вы, а я точно иду, потому что такое пропустить нельзя (а какая запись в резюме будет шикарная!)

🚨 Whoop-whoop! 🚨

Друзья, уже сегодня мастер-класс по REST API! Надо быть! 😎

Поймай волну вечера 🏄

REST API за вечер: от концепции до Postman
Уже сегодня в 19:00 по Мск!
РЕГИСТРАЦИЯ НА МАСТЕР-КЛАСС

Привет! Надеюсь, ты уже поставил напоминание? Мы поставили 😉

🕘 За 3 часа - ссылка на вебинарную комнату в почту
🕘 За 15 минут - напоминание во всех каналах и соцсетх GetAnalyst

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

Сегодня будем работать с инструментом Postman. Создадим документацию и примеры ответов для фронтенд-разработчиков. Зарегистрируйтесь заранее.

Прокачаете резюме ключевыми словами: REST API, JSON, Postman. И всё это в уютной домашней обстановке, за чашечкой любимого напитка. Можно будет задать мне вопросы в прямом и обсудить вопросы 🚀

Делай шаг, чтобы стать более ценным специалистом для твоей компаниии. Магия начинается уже сейчас 🪄🔮

Уже через 3 часа! Мастер-класс Екатерины Ананьевой!

📹 REST API за вечер: от концепции до Postman
⏰ 19:00 - 21:00 Мск

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

Любому специалисту очень важно уметь писать не только грамотно, но и понятно.

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

Сегодня главный копирайтер команды GetAnalyst Наташа (мы с любовью и обожанием зовём её «Нат» 🖤) делится рекомендациями, которые помогут описать сложную тему простым языком. #expertGetAnalyst

⬇️⬇️⬇️

«Если разработчик ничего не ответил на требования, проверьте его пульс» 🙃

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


Почему так происходит?

🔹Текст, выглядит как огромная простыня, где конца и края не видно. Нет структуры в требованиях, отсутствуют абзацы и отступы.

🔹 Длинные, как товарный локомотив, предложения, которые только начал читать и уже устал.

🔹 Много лишних вводных слов, в которых теряется суть и необходимо напрячься, чтобы её «выловить».

🔹 Мысль перескакивает с одной на другую. Читатель путается, теряется смысл повествования.


👩: Чтобы излагать требования чётко не нужно быть гуру копирайтинга или внуком филолога.

Краткость и ясность требований — это ключевые факторы, которые влияют на качество разработки. Это как волшебство вне Хогвартса 🪄
Если требования имеют общую или неоднозначную формулировку, это может привести к ошибкам в конечном решении и задержкам в сроках 😖


Что делать, чтобы этого избежать?

1️⃣ Делите на логические блоки;
Уже визуально такой текст выглядит проще. Благодаря абзацам читателю легче ориентироваться в повествовании.

2️⃣ Сокращайте предложения;
Если видите, что предложение уже растягивается на четыре строчки, то смело его делите на два.

👩: Также можно проверить сложность предложения, прочитав его вслух. Если дыхания не хватает — вы знаете, что делать.

3️⃣ Забудьте про слова «вероятно», «однако», «действительно», «наконец» и другие;
Эти вводные слова не дают полезной информации и утяжеляют текст.

4️⃣ Один абзац — одна мысль.
Каждый абзац должен содержать только одну главную идею. Это помогает читателю лучше понимать текст и улучшает его восприятие.


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


Если хотите больше углубиться в тему, можете изучить книгу «Пиши, сокращай» от М.Ильяхова и Л. Сарычевой. На конкретных примерах авторы показывают, что такое плохой текст и как его улучшить.

🌟 Запускаем подкаст 🌟
GetAnalyst: Опыт экспертов

Одна из самых востребованных тем - прохождение собеседований. Записали подкаст по разбору задачи на асинхронные запросы в REST API.

Прежде чем смотреть видео до конца, попробуйте решить задачу сами, а потом сверить ответ 😉

Собеседование на системного аналитика: разбор задачи на асинхронные запросы
Подкаст с Никитой Румянцевым
Ведущий fullstack-аналитик в Fertami LTD

Если вам понравилось видео - поддержите ❤️ в YouTube, и предлагайте в комментариях темы, которые хотели бы обсудить 🙂

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

Продолжаем нашу рубрику #студентыGetAnalyst.
И сегодня хотим похвастаться отзывом Александры – студентки пятого потока программы «Дизайн REST API»🥳💥

⬇️⬇️⬇️

👩🏼: Я пришла в системный анализ из бизнес-анализа и уже имела разноплановый интересный опыт в качестве аналитика.
Также я частично касалась разработки, выполняла функции оунера на проектах и возглавляла отдел аналитиков до 10 человек.

У меня была необходимость систематизировать и упорядочить знания по базам данных, API и Интеграциям. Знания были, но очень разобщённые 👀

💥 Курс помог собрать и упорядочить знания в целостную систему. Появилась экспертная уверенность и понимание работы с интеграциями.
Очень понравилась подача Екатерины. У неё есть талант преподавания: все четко и по делу.

В результате:
1️⃣ стала легко работать с базами данных на любом уровне (логическом, физическом),
2️⃣ поняла, как работать ЕR-диаграммами и связями (один ко многим — один к одному).
3️⃣ теперь могу прочитать и даже грамотно написать JSON.

Я уверенно приступаю к задаче, вижу, в какую сторону «копать» в рамках задачи и как взаимодействовать с разработчиками.

Планирую менять работу на более интересную. Уверенно чувствую себя на собеседованиях после курса.

🔥🔥🔥

P. S. Александра поделилась, что заинтересовалась программами GetAnalyst после просмотра обучающих видео на youtube-канале проекта.

Если тоже хотите углубиться в системный анализ, то подписывайтесь на наш yt-канал 👌

Как насчёт завершить рабочую неделю темой, про которую спрашивают на собеседованиях у аналитиков? 👀

Наверняка вы не раз натыкались на формулировки «методология разработки продукта», «гибкая разработка», «в рамках итерации» или «работаем по Agile» и так далее.
Причём эти фразы можно слышать не только в сфере IT – выстроенный флоу работы проник во многие сферы нашей жизни, начиная от маркетинга и заканчивая управлением операционной работой на заводах. А ещё про методологии разработки ПО часто спрашивают на собеседованиях и, что удивительно, не все верно называют отличия этих методологий. Короче, рассказываем!😎 #hardGetAnalyst


Любой продукт (не обязательно из сферы IT) разрабатывается путём прохождения определённых этапов от создания идеи и до конечной «продажи» продукта клиенту.

🥷: Пути – это различные успешные практики или методологии, следование которым позволяет предугадать качество конечного продукта.

Самыми популярными методологиями разработки ПО на текущий момент принято считать:
1️⃣ Водопадную модель
2️⃣ Инкрементальную модель
3️⃣ Итерационную модель
4️⃣ Гибкую модель.

Разберём каждую из методологий немного подробнее.

1️⃣ Водопадная модель (с англ. waterfall model)

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

🥷: Это значит, что пока не будет завершён этап аналитики, задача не может перейти на этап разработки, а пока она не будет разработана – невозможен переход на этап тестирования.

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

Это кажется логичным: что проектной команде разрабатывать, если нет документации от аналитика? 🧐

Если конечные требования к решению известны и точно не будут изменяться, водопадная методология разработки действительно сэкономит ресурсы компании на разработку. Но в реальной жизни риск изменения требований чаще всего есть всегда: аналитик не учёл некоторые моменты, заказчик «передумал» или приоритет задачи изменился и спустя время предыдущие требования становятся неактуальными.

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



2️⃣ Инкрементальная модель (с англ. incremental model)

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

На первом этапе полностью проектируется основная часть системы с базовой функциональностью. Затем система обрастает дополнительными полноценными возможностями или по-другому «инкрементами».

🥷: Отсюда и название методологии — инкрементальная.

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

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

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


Продолжим с двумя другими методологиями в субботу, а в понедельник запустим КВИЗ! Ставьте 🔥, если ждёте!