💫 Личный опыт: как стать системным аналитиком 💫

Привет!

Мы долго к этому шли и пришли 😎 Ура! Первый эпизод подкаста GetAnalyst - Released! 🎉
Пол года подготовки, как моральной, так и техническо-организационной, и теперь мы готовы стабильно выпускать эпизоды раз в неделю 💫

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

Обсуждается профессия системного аналитика: роль, задачи и путь к карьерному росту.

0:50 - Екатерина Ананьева и сообщество GetAnalyst
4:00 - Кто такой системный аналитик
8:10 - Процесс работы с рабочими задачами
19:10 - Как Екатерина выбрала системный анализ. О мечтах и "Я тоже могу"
23:25 - Поиск работы и портфолио аналитика: первое предложение о работе junior-системному аналитику
37:55 - Почему был создан проект GetAnalyst
40:25 - Идея подкаста GetAnalyst, пожелания и рекомендации подписчикам

Эпизод доступен в:

⏯ Apple Podcast
⏯ Spotify
⏯ Amazon Music
⏯ Telegram

🔗 Обратная связь и предложения

*Яндекс.Музыка, YouTube (будут выпуски с видео-сопровождением) и Google.Podast в процессе. Ссылки добавим.

Подписывайтесь на платформах! Делитесь с коллегами и начинающими системными аналитиками! 🙌

#GAfrindlyreminder о том, чтобы в трудовых буднях вы не забывали о своём физическом и ментальном здоровье 😌

Всем продуктивного завершения трудовой недели и прекрасного отдыха на выходных ❤️

❓ КАК НАЙТИ ЭНЕРГИЮ НА ВСЕ ДЕЛА ❓

Существует так понятие, как «энергия в долг».

Например:
🪫 работаете до 2-х или 3-х ночи, затем просыпаетесь в 7 утра, чтобы снова пойти на работу. И так постоянно.
🪫 пообещали себе привить новую полезную привычку (или отказаться от старой), но так и не удалось запустить процесс . Или запустили, но не нашли сил продолжить.
🪫 привыкли постоянно переносить несрочные, но важные задачи на "потом", которое не наступает никогда. И таких задач уже накопился необъятный бэклог, который морально давит каждое утро после пробуждения.

На самом деле эти и подобные им ситуации забирают вашу энергию!

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

Нам оно надо? Конечно, не надо! 🙌

⬇️⬇️⬇️

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

1️⃣ Не берите новые задачи, пока не закроете старые
Каким бы классным не был новый челлендж, дайте себе возможность выспаться, отдохнуть, провести время с семьёй и наедине с собой, чтобы восстановиться.

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

3️⃣ Попросите помощи
У коллег, друзей и близких. Возможно, какие-то из задач смогут выполнить они или же помогут ускорить реализацию.

4️⃣ Обозначьте границы отдыха / сна / работы
Да, где-то эти границы могут сдвигаться (но на чуть-чуть и не на постоянной основе!), но старайтесь соблюдать свой собственный график.

5️⃣ Устройте день / час закрытия задач
Если есть возможность, возьмите дэйофф на работе и завершите все бытовые дела. Или проснитесь на час раньше обычного, чтобы выполнять по одной задаче из бэклога.

6️⃣«Лягушки» на завтрак
В начале дня рекомендуется решать самые нудные задачи (те самые «лягушки»), или же по одной из тех, что давно откладывали. Так, вторая половина дня будет проходить легче, а ваш бэклог начнёт сокращаться.

Ну и конечно старайтесь не обещать то, что заведомо сложно будет реализовать из-за нехватки сил и времени.
Заботьтесь о себе и отдыхайте с умом 😘

#softGetAnalyst

Сегодня в GetAnalyst будем работать с навыком проектирования БД:

Онлайн-практикум
📚 Проектирование БД с нуля: создание ER-диаграммы
🗓 13 февраля, 19:00 Мск

План:
1. Определение БД и СУБД.
2. Знакомство с проектом и выделение сущностей.
3. Определение логической и физической моделей БД с разбором примеров по проекту.
4. Практика. Фокус на проектировании физической модели БД - PostgreSQL.
5. Обзор шаблона постановки задачи на разработчиков.

Эта практика полезна для тех, кто:
✔️ только начинает осваивать базы данных и переход в системный анализ,
✔️ хочет закрепить свои навыки по проектированию БД,
✔️ хочет разобраться, как требования влияют на БД системы, и почему первым делом при подключении к новому проекту опытные аналитики запрашивают доступ к БД.

Практика проводится в рамках практической программы по проектированию БД и подключиться к ней можно независимо от неё.

Следующие встречи будут на более сложные темы:
✅ Разработка требований к миграциям БД,
✅ Проектирование распределенных БД,
✅ Оптимизация БД. Работа с индексами.
и другие.

Это прекрасная возможность закрепить самую важную часть работы с БД, перед более глубоким погружением!

План работы:
1. Краткая теория по каждому уровню БД.
2. Практика с подключением участников к работе онлайн над общим проектом.
3. Выдача ДЗ.

🔗 Подробности и подключение к участию

До встречи в прямом эфире! 😉

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

Когда продукт IT-компании постепенно укрепляется в доверии пользователей, а интерес к функциональным возможностям этого ПО повышается, ожидания от работы и результатов взаимодействия с этим продуктом тоже растут 📈

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

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

Догадались, о чём будет речь?
Пишите предположения в комментариях ⬇️

Первому, кто угадает название этой техники, вышлем в подарок электронную книгу на эту тему 🎁

✨ КАРТА ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ ✨

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


В современной практике существует решение, которое снизит риск «свернуть не туда» при проектировании ПО – это построить карту планируемых функциональных возможностей от лица пользователей или по-другому – User Story Map.

Карта пользовательских историй (User Story Map) — это техника, которая позволяет расположить пользовательские истории согласно последовательности использования функций продукта.

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


А ещё User Story Map позволяет команде разработки:

1️⃣ увидеть масштаб всего продукта и последовательный путь взаимодействия с ним;
2️⃣ определиться с приоритетами при разработке продукта — решить, какие функции ПО нужно реализовать в первую очередь, а какие перенести на потом;
3️⃣ заранее определить узкие места и возможные конфликты внутри функциональных возможностей внутри ПО.


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


Ставьте 🔥 на этот пост – так мы поймём, интересна ли вам тема визуализации требований.

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

#hardGetAnalyst