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

Привет!

Мы долго к этому шли и пришли 😎 Ура! Первый эпизод подкаста 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

👩‍🎨 СТРОИМ КАРТУ ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ 👨‍🎨

Составить карту пользовательских историй можно с помощью разных инструментов: начиная с аналоговых (стикеров на стене или большой маркерной доски) и заканчивая специальным ПО (Miro, Draw.io, FigJam, Jira, Visual Paradigm и прочие).

🥷: User Story Map создают коллективно. Желательно, чтобы в этом участвовала вся команда разработки и представители пользователей. Эта встреча похожа на мозговой штурм, где регулятором встречи как раз может быть аналитик. Но часто в практике можно встретить, что аналитик выстраивает карту самостоятельно.

Карта пользовательских историй состоит из следующих элементов:

1. Описание персон пользователей продукта
2. Информационный блок о целях и глобальной проблеме, которую решает продукт
3. Перечисление пользовательских активностей на протяжении основного пользовательского пути
4. Описание задач пользователей внутри каждой активности
5. Пользовательские истории внутри каждой задачи (они же требования к реализации возможностей)
6. Разделение всех требований на итерации или релизы

😖 Бррррр! Много слов и ничего непонятно!

Без паники, разберёмся с каждым пунктом последовательно, а в конце дадим вам готовый шаблон, который вы сможете использовать в работе 💪

⬇️⬇️⬇️

ШАГ 1: Описываем персоны

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

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

🥷: Например, олицетворением персоны может быть пользователь определённой возрастной категории, уклада жизни, профессии и так далее.

На карте Персоны размещаются сверху, олицетворяя собой пользователей, чьи интересы планируется учесть в текущем проектировании ПО. Для удобства персоны, которые преследуют одни и те же цели, объединяют в группы. Благодаря этому реализация требования для группы позволит покрыть сразу несколько персон. А это круто! 😎



ШАГ 2: Фиксируем цели и глобальные проблемы, которые решает продукт

Для этого шага необходимо ответить на следующие вопросы:
- Над каким ПО вы работаете?
- Какова его основная задача?
- Какую глобальную проблему пользователей оно решает?

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



ШАГ 3: Заполняем пользовательские активности

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

Активности (User Activities) — это последовательные действия, которые пользователю нужно совершить, чтобы достичь своих целей.

Пользовательские активности — это каркас (backbone) карты, который формирует представление об основных функциях внутри ПО.

🥷: Примером последовательных активностей в приложении для заказа такси будет:
Указать маршрут -> Подтвердить заказ -> Совершить поездку и так далее.

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

🔘🔘🔘

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