Сегодня в 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) карты, который формирует представление об основных функциях внутри ПО.

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

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

🔘🔘🔘

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

ШАГ 4: Описываем задачи пользователей

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

Пользовательская задача (User Task) — это более конкретное описание действий, которые пользователь должен выполнить в рамках активности.

Каждую активность можно поделить на несколько мелких задач. Иными словами, задачи – это действия, которые можно совершить внутри активности.

🥷: Например, для активности "Указать маршрут" в приложении для заказа такси можно обозначить следующие задачи:
- Указать точку отправления
- Указать точку прибытия

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



ШАГ 5: Оформляем пользовательские истории

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

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

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

1. Как [кто-то] — например пользователь или роль;
2. Я хочу [чего-то] — выполнить какую-то задачу;
3. Чтобы [что-то] — достигнуть конкретную цель.

🥷: Например, для задачи "Указать точку отправления" можно сформулировать следующие истории:
- Как пользователь приложения для заказа такси, я хочу указать точку отправления на карте, чтобы быстро указать адрес, откуда меня нужно забрать.
- Как пользователь приложения для заказа такси, я хочу ввести адрес отправления вручную, чтобы не искать отправную точку сложным для меня способом.
- Как пользователь приложения для заказа такси, я хочу, чтобы точка отправления определилась автоматически, чтобы не указывать отправную точку самостоятельно.
и так далее.

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


🥵 Ребят, ну как вы? Уже утомились? Мы на финишной прямой!


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


🔘🔘🔘

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

Если всё ок, далее расскажем про последний шаг построения карты пользовательских историй и дадим готовый шаблон User story map, который вы сможете применять в работе уже сегодня (а лучше с понедельника! 😀)

ШАГ 6: Разделение User Story Map на релизы или итерации

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


Итерация (англ. iteration) — это согласованный период работы в виде отрезка времени, в течение которого разрабатывается часть ПО.

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

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


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

Релиз (англ. release) — выпуск готового для использования продукта.

Один из вариантов такого разделения — определение MVP (Minimal Viable Product — минимально жизнеспособный продукт). Для этого в первый релиз вносят только основные функциональные возможности, чтобы приложение выполняло основную свою задачу. В последующие релизы будут вынесены дополнительные возможности.


🙂🙂🙂


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

🥷: User Story Map – это отличный способ передавать требования для дизайна прототипа. Так, дизайнер получит необходимую, а главное, понятно оформленную информацию о функциональных возможностях на интерфейсе ПО и не будет «скован» жесткими требованиями к решению. А значит сможет творить! Поэтому использовать карту в работе можно для крупной новой функциональности внутри ПО, а не только для проектировании целого продукта.

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

На прошлой неделе мы спрятали тему User story map за теоретическим описанием и попросили вас догадаться о ней в обмен на книгу.
Кстати говоря, книга* нашла своего победителя! 🎉

Также среди ответов были предложены три других формата описания возможностей продукта: Road map, Use case и Customer journey map (CJM). И мы подумали: а ведь действительно эти способы визуализации продуктовых возможностей можно с лёгкостью перепутать, если не знать разницу между ними.

В 80% случаев на собеседованиях на позицию БА / СА уровня middle и выше справшивают хотя бы один вопрос из этих трёх тем.

А раз спрашивают, то постараемся подготовиться, чтобы с лёгкостью щелкать такие «орешки» на интервью в компанию мечты 💪 Ну что, а ю рэди?


* «Пользовательские истории. Искусство гибкой разработки ПО», автор: Джефф Паттон.
Рекомендуем для глубокого погружения в USM.

Привет! 🙋‍♀️

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

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

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


С одной из техник описания пользовательских требований вы уже знакомы — это пользовательская история (англ. user story). Да что там знакомы – вы теперь можете целую карту историй построить (USM)!

🥷: Шаблон для построения USM мы давали вот тут.

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

#hardGetAnalyst

⬇️⬇️⬇️