Насколько подробно описывать задачи по БД?
Вопрос от подписчика: «Насколько подробное должно быть описание БД для постановки задач на разработку? Прорабатывать ли вопросы безопасности, методы резервирования, варианты отказоустойчивости?»
На самом деле, уровень детализации задачи зависит от предпочтений команды. Мы выделили 2 уровня описания задачи по БД, смотрите их в картинках. 👆
Главное, чтобы было описание всех сущностей, связей между ними и атрибутов. Также указываем нефункциональные требования с позиции, а что критично для бизнеса: какой допустимый объём потери данных; какой прогнозируемый рост данных (например, через год) и пр.
По безопасности системный аналитик продумывает роли, уровни доступа и сценарии использования. А вот выбор алгоритмов шифрования для паролей или определение методов хранения паролей (как правильно «подсолить») — это задача сотрудника, который ответственен за техническую часть проекта. Если этот ответственный — системный аналитик, то это его задача. Но чаще всего это работа техлида или разработчика.
Важно понимать, что команда разработки занимается не только новыми фичами, но и обслуживанием и поддержкой. Разработчики постоянно следят за метриками и ищут пути улучшения. Поэтому такие задачи, как балансировка нагрузки, резервирование и прочие выполняются фоном, без запроса от заказчика или владельца продукта. Это то, о чём разработчики думают по умолчанию, без задачи от системного аналитика. 😅
❗️Если вы занимаетесь проработкой всех этих вопросов, возможно, ваш техлид перекладывает на вас часть своих обязанностей.
#questions
Вопрос от подписчика: «Насколько подробное должно быть описание БД для постановки задач на разработку? Прорабатывать ли вопросы безопасности, методы резервирования, варианты отказоустойчивости?»
На самом деле, уровень детализации задачи зависит от предпочтений команды. Мы выделили 2 уровня описания задачи по БД, смотрите их в картинках. 👆
Главное, чтобы было описание всех сущностей, связей между ними и атрибутов. Также указываем нефункциональные требования с позиции, а что критично для бизнеса: какой допустимый объём потери данных; какой прогнозируемый рост данных (например, через год) и пр.
По безопасности системный аналитик продумывает роли, уровни доступа и сценарии использования. А вот выбор алгоритмов шифрования для паролей или определение методов хранения паролей (как правильно «подсолить») — это задача сотрудника, который ответственен за техническую часть проекта. Если этот ответственный — системный аналитик, то это его задача. Но чаще всего это работа техлида или разработчика.
Важно понимать, что команда разработки занимается не только новыми фичами, но и обслуживанием и поддержкой. Разработчики постоянно следят за метриками и ищут пути улучшения. Поэтому такие задачи, как балансировка нагрузки, резервирование и прочие выполняются фоном, без запроса от заказчика или владельца продукта. Это то, о чём разработчики думают по умолчанию, без задачи от системного аналитика. 😅
❗️Если вы занимаетесь проработкой всех этих вопросов, возможно, ваш техлид перекладывает на вас часть своих обязанностей.
#questions
👍8🔥4💯2
T-shape = как легко забыть системный анализ
Рубрика: взгляд СА на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера.
Мне захотелось поделиться своим отношением к T-shape.
СА могут привлечь к разным задачам, вплоть до развёртывания приложений, написания сложных SQL-миграций, кодинга, настройки различных инструментов и пр.
С одной стороны, мы расширяем кругозор. Но с другой, если эта «Tи-шейпная» задача — не разовая акция, и теперь занимает 1 день из 5 — это уже не ОК. Так аналитик занимается системным анализом всё меньше, и в итоге выходит на рынок с большим опытом, но слабым в СА: он становится невнимательным, забивает на документацию и пр.
НО! Есть практики, с которыми мы сталкиваемся часто. Мы рисуем макеты и тестируем ПО. К этому я отношусь спокойно. 😅 Но и здесь: мы не нарисуем макеты идеально, не продумаем адаптивность, не исправим автотесты и т. д. То есть, эту работу мы не выполним на 100% качественно.
...
А как вы относитесь к T-shape? Был ли у вас подобный опыт?
#sa_dev
Рубрика: взгляд СА на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера.
Мне захотелось поделиться своим отношением к T-shape.
СА могут привлечь к разным задачам, вплоть до развёртывания приложений, написания сложных SQL-миграций, кодинга, настройки различных инструментов и пр.
С одной стороны, мы расширяем кругозор. Но с другой, если эта «Tи-шейпная» задача — не разовая акция, и теперь занимает 1 день из 5 — это уже не ОК. Так аналитик занимается системным анализом всё меньше, и в итоге выходит на рынок с большим опытом, но слабым в СА: он становится невнимательным, забивает на документацию и пр.
НО! Есть практики, с которыми мы сталкиваемся часто. Мы рисуем макеты и тестируем ПО. К этому я отношусь спокойно. 😅 Но и здесь: мы не нарисуем макеты идеально, не продумаем адаптивность, не исправим автотесты и т. д. То есть, эту работу мы не выполним на 100% качественно.
...
А как вы относитесь к T-shape? Был ли у вас подобный опыт?
#sa_dev
👍9🔥3👏3💯2
Шаблон в User Story — необязательный 😱
Вовсе не обязательно следовать шаблону «Я, как <роль>, хочу <то-то>, чтобы <что-то>».
Фразы вроде «Регистрация» или «Авторизация» тоже могут быть историями, если команда понимает, что за ними стоит.
Суть User Story — зафиксировать потребность пользователя, а не следовать формату ради самого формата. История может быть записана любым удобным способом, главное, чтобы при просмотре карточки участники обсуждения вспомнили, о чём шла речь и что нужно сделать.
❗Безусловно, шаблон полезен. Если можно указать роль пользователя и его цель — сделайте это. Но иногда это излишне. Например, когда приложение имеет только одну роль — Клиент, или если задача техническая. А бывает, что цель неочевидна, и попытка следовать шаблону приводит к созданию несуразных формулировок в роде «потому что потому».
Вовсе не обязательно следовать шаблону «Я, как <роль>, хочу <то-то>, чтобы <что-то>».
Фразы вроде «Регистрация» или «Авторизация» тоже могут быть историями, если команда понимает, что за ними стоит.
Суть User Story — зафиксировать потребность пользователя, а не следовать формату ради самого формата. История может быть записана любым удобным способом, главное, чтобы при просмотре карточки участники обсуждения вспомнили, о чём шла речь и что нужно сделать.
❗Безусловно, шаблон полезен. Если можно указать роль пользователя и его цель — сделайте это. Но иногда это излишне. Например, когда приложение имеет только одну роль — Клиент, или если задача техническая. А бывает, что цель неочевидна, и попытка следовать шаблону приводит к созданию несуразных формулировок в роде «потому что потому».
👍7🔥3💯3
Доброе утро, коллеги! 🌅
Понедельник — это очередной шанс начать неделю продуктивно и с новыми идеями. Да здравствует «новая жизнь»! 🙌
Да, может быть, ещё не все проснулись, но уже пора разгоняться. Чтобы немного облегчить начало рабочей недели, напомните себе:
- Что вас ждёт в конце этой недели? Маленькие цели ведут к большим победам.
- Какие 3 задачи сегодня нужно закрыть, чтобы почувствовать себя молодцом?
- Чем порадуете себя после работы? Очень важен позитивный настрой на всю неделю.
Кофе уже на столе? ☕
Погнали! 🚀
Понедельник — это очередной шанс начать неделю продуктивно и с новыми идеями. Да здравствует «новая жизнь»! 🙌
Да, может быть, ещё не все проснулись, но уже пора разгоняться. Чтобы немного облегчить начало рабочей недели, напомните себе:
- Что вас ждёт в конце этой недели? Маленькие цели ведут к большим победам.
- Какие 3 задачи сегодня нужно закрыть, чтобы почувствовать себя молодцом?
- Чем порадуете себя после работы? Очень важен позитивный настрой на всю неделю.
Кофе уже на столе? ☕
Погнали! 🚀
❤6👍3💯3
Пример описания задачи по БД
Ранее мы говорили о шаблоне описания задачи по БД. Сегодня разберём пример — всё смотрите в картинках. 👆
Наша задача — проработать модель данных, уточнить требования и обсудить всё с командой. Важно отметить, что СУБД ещё не выбрана.
#db
Ранее мы говорили о шаблоне описания задачи по БД. Сегодня разберём пример — всё смотрите в картинках. 👆
Наша задача — проработать модель данных, уточнить требования и обсудить всё с командой. Важно отметить, что СУБД ещё не выбрана.
#db
👍10🔥5❤🔥4💯1
Чем больше всего нравится заниматься на работе? 🔍 У каждого системного аналитика есть свои любимые задачи. Что вам приносит наибольшее удовольствие в работе?
Anonymous Poll
26%
1️⃣ Проектировать API
5%
2️⃣ Разбираться с брокерами
21%
3️⃣ Описывать задачи для фронтенда, продумывая UI
22%
4️⃣ Рисовать макеты и продумывать пользовательский интерфейс
25%
5️⃣ Работать с базами данных
37%
6️⃣ Рисовать диаграммы
18%
7️⃣ Вести документацию
32%
8️⃣ Моделировать бизнес-процессы
23%
9️⃣ Общаться с заказчиками и собирать требования
37%
1️⃣ 0️⃣ Продумывать бизнес-логику
🤩6🥰4🙏3💯1
Добавляете новое обязательное поле в БД? Не забудьте продумать миграцию!
Представьте, что нужно добавить новое обязательное поле в БД — customer_type. Его возможные значения: BASIC и PREMIUM.
Что делать с записями, которые уже есть в базе данных? Поле должно быть заполнено, так как оно обязательное.
❗Необходимо продумать миграцию данных: как будем добавлять новое поле и что делать с уже существующими записями? Проставим им значение по умолчанию — BASIC.
Пример миграции:
Что делать?
1️⃣ Оповестите бизнес-команду о добавлении нового обязательного поля и о том, что все текущие записи в БД будут автоматически обновлены со значением BASIC.
2️⃣ Протестируйте миграцию на тесте.
3️⃣ После успешного тестирования добавьте поле в продовую базу и проведите миграцию для существующих записей.
#db
Представьте, что нужно добавить новое обязательное поле в БД — customer_type. Его возможные значения: BASIC и PREMIUM.
Что делать с записями, которые уже есть в базе данных? Поле должно быть заполнено, так как оно обязательное.
❗Необходимо продумать миграцию данных: как будем добавлять новое поле и что делать с уже существующими записями? Проставим им значение по умолчанию — BASIC.
Пример миграции:
ALTER TABLE customersADD COLUMN customer_type ENUM('BASIC', 'PREMIUM') NOT NULL DEFAULT 'BASIC';UPDATE customersSET customer_type = 'BASIC'WHERE customer_type IS NULL;Что делать?
1️⃣ Оповестите бизнес-команду о добавлении нового обязательного поля и о том, что все текущие записи в БД будут автоматически обновлены со значением BASIC.
2️⃣ Протестируйте миграцию на тесте.
3️⃣ После успешного тестирования добавьте поле в продовую базу и проведите миграцию для существующих записей.
#db
👍8🔥2👏2💯1
Сущность ≠ Таблица ❗
Зачастую путают понятия «сущность» и «таблица», думая, что это одно и то же. Но это не так.
Сущность — это абстрактный объект, который моделирует реальный мир, например, «Поставщик» и «Покупатель».
Таблица — это уже конкретная структура в базе данных, которая хранит данные о сущности. 🗃️
Пример:
Представьте, что в компании есть поставщики и покупатели. Для бизнеса — это разные сущности, но у них много общих атрибутов: имя, контактная информация, реквизиты и прочее. Вместо того чтобы создавать отдельные таблицы для поставщиков и покупателей, их можно объединить в одну таблицу Контрагенты, где будут храниться данные об обеих сущностях. Дополнительное поле может указывать, является запись «Поставщиком» или «Покупателем».
Такое решение позволяет более эффективно управлять данными и избежать дублирования информации.
#db
Зачастую путают понятия «сущность» и «таблица», думая, что это одно и то же. Но это не так.
Сущность — это абстрактный объект, который моделирует реальный мир, например, «Поставщик» и «Покупатель».
Таблица — это уже конкретная структура в базе данных, которая хранит данные о сущности. 🗃️
Пример:
Представьте, что в компании есть поставщики и покупатели. Для бизнеса — это разные сущности, но у них много общих атрибутов: имя, контактная информация, реквизиты и прочее. Вместо того чтобы создавать отдельные таблицы для поставщиков и покупателей, их можно объединить в одну таблицу Контрагенты, где будут храниться данные об обеих сущностях. Дополнительное поле может указывать, является запись «Поставщиком» или «Покупателем».
Такое решение позволяет более эффективно управлять данными и избежать дублирования информации.
#db
👍10❤4🔥2💯1
Что лучше использовать — ENUM или справочник?
На самом деле вопрос не в том, что лучше, а какие данные вы собираетесь хранить в поле.
🔹 ENUM — отличный выбор, когда значения заранее известны и редко изменяются. Например, если тип клиента может быть только «Basic» или «Premium», тогда ENUM подходит идеально. Это решение упрощает архитектуру, так как нет необходимости создавать дополнительную таблицу.
🔹 Справочник лучше использовать, если возможные значения могут изменяться со временем или пополняться. Например, для поля «Специализация врача» справочник будет подходящим вариантом, так как список специализаций может расширяться, и каждая специализация может иметь дополнительную информацию (описание, коды, и т.д.).
Сравнение подходов см. в картинках👆
#db
На самом деле вопрос не в том, что лучше, а какие данные вы собираетесь хранить в поле.
🔹 ENUM — отличный выбор, когда значения заранее известны и редко изменяются. Например, если тип клиента может быть только «Basic» или «Premium», тогда ENUM подходит идеально. Это решение упрощает архитектуру, так как нет необходимости создавать дополнительную таблицу.
🔹 Справочник лучше использовать, если возможные значения могут изменяться со временем или пополняться. Например, для поля «Специализация врача» справочник будет подходящим вариантом, так как список специализаций может расширяться, и каждая специализация может иметь дополнительную информацию (описание, коды, и т.д.).
Сравнение подходов см. в картинках👆
#db
👍8❤3💯3