Привет-привет!
Знакомо ощущение, когда глаз дергается и сердце замирает? 😁
Делитесь в комментариях, что еще вызывает такие же эмоции))
Знакомо ощущение, когда глаз дергается и сердце замирает? 😁
Делитесь в комментариях, что еще вызывает такие же эмоции))
🔥12😁10😱1
У вас бывало такое, что вы используете приложение, или смотрите, как в регистратуре в поликлинике не могут сделать какую-то элементарную вещь с вашим приемом к врачу, и в голове:
"Ну это же элементарно! Почему у вас это не работает?!" 🤯
Бытовые ситуации вдохновляют меня на разбор ошибок проектирования, которые ведут к костылям и неудобству по развитию системы.
Дано:
1. Автосалон 🚘
Продает авто и занимается сервисным обслуживанием (плановый технический осмотр - ТО), ремонтом.
2. Есть учет всех клиентов. Общий.
3. Для автомастерской есть учет истории визитов каждой машины.
4. Процессы:
+ ведение базы всех клиентов,
+ покупка авто,
+ запись на прием в автомастерскую с уведомлениями клиента,
+ создание отчетов о выполненных работах.
Кажется, все просто. Но если погружаться в разбор бизнес-процессов, то можно найти элементарный, который не учли: перевод машины между владельцами.
Что случилось, в чем ошибка бизнес-аналитика и что из-за нее не учли в системном анализе? Как дорого будет стоить ее исправление?
Будем последовательно разбираться. И проектировать нормально. Рассмотрим полный цикл: требования, БД, бэкенд, фронтенд, интеграции 🙌
Вводную и погружение в контекст сделала в формате видео. Смотреть тут 👀
"Ну это же элементарно! Почему у вас это не работает?!" 🤯
Бытовые ситуации вдохновляют меня на разбор ошибок проектирования, которые ведут к костылям и неудобству по развитию системы.
Дано:
1. Автосалон 🚘
Продает авто и занимается сервисным обслуживанием (плановый технический осмотр - ТО), ремонтом.
2. Есть учет всех клиентов. Общий.
3. Для автомастерской есть учет истории визитов каждой машины.
4. Процессы:
+ ведение базы всех клиентов,
+ покупка авто,
+ запись на прием в автомастерскую с уведомлениями клиента,
+ создание отчетов о выполненных работах.
Кажется, все просто. Но если погружаться в разбор бизнес-процессов, то можно найти элементарный, который не учли: перевод машины между владельцами.
Что случилось, в чем ошибка бизнес-аналитика и что из-за нее не учли в системном анализе? Как дорого будет стоить ее исправление?
Будем последовательно разбираться. И проектировать нормально. Рассмотрим полный цикл: требования, БД, бэкенд, фронтенд, интеграции 🙌
Вводную и погружение в контекст сделала в формате видео. Смотреть тут 👀
YouTube
1. Системный анализ проекта с нуля: Сбор бизнес-требований, погружение в контекст
Проектирование с нуля системы для Автосервиса. Подгружаемся в контекст.
Нужно поддержать этот минимум функциональных возможностей:
- вести учет клиентов - потенциальных и текущих,
- фиксировать продажи автомобилей,
- записывать на сервисное обслуживание…
Нужно поддержать этот минимум функциональных возможностей:
- вести учет клиентов - потенциальных и текущих,
- фиксировать продажи автомобилей,
- записывать на сервисное обслуживание…
❤7👍3🔥1
🔥⚠️ Новый проект⚠️ 🔥
🚘 Система для автосалона 🚘
Обеспечить возможности записи машин на прием в автосервис салона, ведения истории их обслуживания. Уведомлять клиентов, владельцев авто, о записи по СМС. В СМС включать ссылку с информацией об услуге.
Порядок работы:
🟡 In Progress - в процессе:
1. Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
2. Определение ролей пользователей и приложений, которые будут задействованы
3. Выделение и описание основных сценариев
4. Проработка альтернативных сценариев
🔵 To Do - к выполнению:
5. Определить список задач к выполнению.
6. Задачи на дизайнера - макеты UI/UX
7. Выделить сущности и спроектировать БД.
8. Сделать постановки задач на фронтенд
9. Сделать постановки задач на бэкенд. Разработать дизайн REST API с документацией в Postman
Хотите что-то еще разобрать на примере этого проекта? Пишите в комментарии 👍
🚘 Система для автосалона 🚘
Обеспечить возможности записи машин на прием в автосервис салона, ведения истории их обслуживания. Уведомлять клиентов, владельцев авто, о записи по СМС. В СМС включать ссылку с информацией об услуге.
Порядок работы:
🟡 In Progress - в процессе:
1. Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
2. Определение ролей пользователей и приложений, которые будут задействованы
3. Выделение и описание основных сценариев
4. Проработка альтернативных сценариев
🔵 To Do - к выполнению:
5. Определить список задач к выполнению.
6. Задачи на дизайнера - макеты UI/UX
7. Выделить сущности и спроектировать БД.
8. Сделать постановки задач на фронтенд
9. Сделать постановки задач на бэкенд. Разработать дизайн REST API с документацией в Postman
Хотите что-то еще разобрать на примере этого проекта? Пишите в комментарии 👍
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥8
Про #софтскилы в IT. Сегодня у нас в гостях #эмпатия 🤗
Эмпатия - это способность понимать и разделять чувства другого человека. Это один из главных инструментов в работе аналитика.
👩💻👨💻 Аналитик - это "переводчик" между разработчиками и бизнес-заказчиками.
Он должен понять, что хочет заказчик, и объяснить команде так, чтобы они могли реализовать это в IT-продукте. Именно тут приходит на помощь эмпатия. Она позволяет аналитику глубже проникнуть в потребности клиента, понять его боли и желания.
🔹 На собеседовании
При приеме на работу важны не только ваши технические навыки, но и soft skills, среди которых есть эмпатия. Работодатели и HR часто используют ситуационные вопросы или ролевые игры для оценки вашего уровня эмпатии. Например, вам могут предложить рассказать о ситуации, когда вы помогли коллеге решить проблему, или когда ваши действия помогли улучшить отношения в команде. Будьте готовы ответить⚡️
🔹 В команде
В работе с командой эмпатия помогает понять взгляды и ожидания каждого участника, что помогает создать более продуктивную рабочую атмосферу и облегчает общение.
🔹 Практические советы
1. Практикуйте активное слушание.
Когда вам говорят, старайтесь не только слушать, но и понимать, что чувствует собеседник. Представляйте себя на его месте, проживайте те же эмоции. Это поможет лучше понимать людей вокруг.
2. Отслеживайте свои эмоции. Разберитесь, какие эмоции вызывают в вас те или иные ситуации. Отходите в сторону и смотрите на свою реакцию. Это поможет лучше понимать чувства других людей.
3. Обратите внимание на язык тела - открытые (дружба) и закрытые (защита) позы.
Очень часто наши истинные чувства проявляются не в словах, а в жестах. Пробуйте отслеживать в диалогах с близкими в каком положении ваши руки, ноги.
Помните, эмпатия - это не то, что вы "включаете" в определенный момент. Это - навык, который развивается и совершенствуется в течение всей жизни.
Эмпатия - ваш верный помощник как в карьере, так и в жизни 🤗
Так что вперед, к пониманию и взаимопониманию! 🚀
Эмпатия - это способность понимать и разделять чувства другого человека. Это один из главных инструментов в работе аналитика.
👩💻👨💻 Аналитик - это "переводчик" между разработчиками и бизнес-заказчиками.
Он должен понять, что хочет заказчик, и объяснить команде так, чтобы они могли реализовать это в IT-продукте. Именно тут приходит на помощь эмпатия. Она позволяет аналитику глубже проникнуть в потребности клиента, понять его боли и желания.
🔹 На собеседовании
При приеме на работу важны не только ваши технические навыки, но и soft skills, среди которых есть эмпатия. Работодатели и HR часто используют ситуационные вопросы или ролевые игры для оценки вашего уровня эмпатии. Например, вам могут предложить рассказать о ситуации, когда вы помогли коллеге решить проблему, или когда ваши действия помогли улучшить отношения в команде. Будьте готовы ответить⚡️
🔹 В команде
В работе с командой эмпатия помогает понять взгляды и ожидания каждого участника, что помогает создать более продуктивную рабочую атмосферу и облегчает общение.
🔹 Практические советы
1. Практикуйте активное слушание.
Когда вам говорят, старайтесь не только слушать, но и понимать, что чувствует собеседник. Представляйте себя на его месте, проживайте те же эмоции. Это поможет лучше понимать людей вокруг.
2. Отслеживайте свои эмоции. Разберитесь, какие эмоции вызывают в вас те или иные ситуации. Отходите в сторону и смотрите на свою реакцию. Это поможет лучше понимать чувства других людей.
3. Обратите внимание на язык тела - открытые (дружба) и закрытые (защита) позы.
Очень часто наши истинные чувства проявляются не в словах, а в жестах. Пробуйте отслеживать в диалогах с близкими в каком положении ваши руки, ноги.
Помните, эмпатия - это не то, что вы "включаете" в определенный момент. Это - навык, который развивается и совершенствуется в течение всей жизни.
Эмпатия - ваш верный помощник как в карьере, так и в жизни 🤗
Так что вперед, к пониманию и взаимопониманию! 🚀
❤6👍1
Давайте назовем проект для автосалона PorscheLab 🚘, и погнали проектировать.
1️⃣ Структура документации.
Проект новый - сразу создаю пространство (спейс) в Confluence и выстраиваю структуру.
Коллеги, я создала не новый спейс, а раздел в уже существующем пространстве "GetAnalyst - Public Projects" по причинам удобства. У меня в нем шаблоны уже заготовлены.
В идеальном мире 1 проект = 1 спейс Confluence.
Так как у меня сразу же есть понимание какие приложения нужны, то выстроила структуру так: на каждый компонент БД+Backend, Дизайн, Сайт, CRM - свой раздел. За ними закреплены соответствующие исполнители: фронтендеры, бэкендеры, дизайнеры, тестировщики.
В ходе работы структура документации может меняться - это нормально. Предварительно выбираю такую.
Главное, чтобы команде было понятно, как выстроена документация на систему.
2️⃣ В разделе требований сразу же завожу свалку "Meeting Notes" - заметки со встреч.
Эта свалка нужна, чтобы потом можно было восстановить хронологию событий 😄 Вспомнить то, что я забыла и не вынесла по какой-то причине в требования после встреч.
Неструктурированные заметки сумасшедшего и куча файлов от заказчика будут появляться после каждой встречи и из писем. Много всего. Чтобы это все не раскидывать по гугл-дискам, "Загрузкам" на рабочем компьютере и в "Избранных" в почте, создается раздел с этими заметками.
⚡️ Рекомендую ввести правило:
Я получил информацию -> Перенес в свалку заметок за сегодняшний день в Confluence.
Это еще и помогает своевременно делиться информацией сразу со всей командой, в том числе с коллегами-аналитиками.
3️⃣ Описание бизнес-процессов и вопросы заказчику
Мы собрали информацию на первой встрече. Вопросы по процессам у меня уже есть, но пока нигде четко не зафиксированы. Бизнес-процессы понятны (вроде), но нигде не описаны.
Начинается работа аналитика, с конечными результатами для IT-проекта:
+ описание бизнес-процессов As Is,
++ разработка требований To Be,
+++ выделение задач на команду,
++++ передача в оценку.
P.S. Ссылкой на Miro делюсь 😉
1️⃣ Структура документации.
Проект новый - сразу создаю пространство (спейс) в Confluence и выстраиваю структуру.
Коллеги, я создала не новый спейс, а раздел в уже существующем пространстве "GetAnalyst - Public Projects" по причинам удобства. У меня в нем шаблоны уже заготовлены.
В идеальном мире 1 проект = 1 спейс Confluence.
Так как у меня сразу же есть понимание какие приложения нужны, то выстроила структуру так: на каждый компонент БД+Backend, Дизайн, Сайт, CRM - свой раздел. За ними закреплены соответствующие исполнители: фронтендеры, бэкендеры, дизайнеры, тестировщики.
В ходе работы структура документации может меняться - это нормально. Предварительно выбираю такую.
Главное, чтобы команде было понятно, как выстроена документация на систему.
2️⃣ В разделе требований сразу же завожу свалку "Meeting Notes" - заметки со встреч.
Эта свалка нужна, чтобы потом можно было восстановить хронологию событий 😄 Вспомнить то, что я забыла и не вынесла по какой-то причине в требования после встреч.
Неструктурированные заметки сумасшедшего и куча файлов от заказчика будут появляться после каждой встречи и из писем. Много всего. Чтобы это все не раскидывать по гугл-дискам, "Загрузкам" на рабочем компьютере и в "Избранных" в почте, создается раздел с этими заметками.
Я получил информацию -> Перенес в свалку заметок за сегодняшний день в Confluence.
Это еще и помогает своевременно делиться информацией сразу со всей командой, в том числе с коллегами-аналитиками.
3️⃣ Описание бизнес-процессов и вопросы заказчику
Мы собрали информацию на первой встрече. Вопросы по процессам у меня уже есть, но пока нигде четко не зафиксированы. Бизнес-процессы понятны (вроде), но нигде не описаны.
Начинается работа аналитика, с конечными результатами для IT-проекта:
+ описание бизнес-процессов As Is,
++ разработка требований To Be,
+++ выделение задач на команду,
++++ передача в оценку.
P.S. Ссылкой на Miro делюсь 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍4❤2
Описание процессов AS IS + TO BE ✍️
На этапе описания процессов AS IS + TO BE поисходит структурирование информации, полученной в ходе встреч, исследования предметной области и общения с сотрудниками компании. Это необходимый шаг. Именно благодаря ему определяется реальный объем работ и формируются требования на разработку - ТЗ.
ТЗ - техническое задание, договор с заказчиком.
В ходе описания процессов у аналитика возникает множетсво уточнений и вопросов к заказчику.
*Хороший тон: не заваливать заказчика сообщениями в мессенджере каждый час, а один раз на созвоне задать все сразу.
⚠️ Что я заметила? Всегда прохожу один и тот же цикл:
1. Придумала 10 вопросов.
2. Пока дописывала ТЗ и разбиралась в деталях - отбросила 8.
3. На встречах 1-2 раза в неделю обсудила вопросы и продемонстрировала макеты экранов, чтобы показать, что примерно будет результатом работ.
Получила ответы и комментарии. Прошла еще круг после встречи. И так до готовности ТЗ. Уровнь детализации зависит от вашей компании, проекта и заказчика.
Описание бизнес-процессов и понимание, как они затем лягут на систему - зона ответственности бизнес- и системных аналитиков 🙌
1. Запись машины в сервис по телефону через менеджера или на сайте, с SMS-уведомлениями клиента:
1.1. Первичная запись с регистрацией клиента и авто
1.2. Повторная запись старого клиента со старым авто
1.3. Повторная запись старого клиента с новым авто
1.4. Повторная запись - новый клиент со старым авто (изменен владелец)
1.5. Повторная запись - добавлен второй владелец
1.6. ... еще что-то подскажете или найдем по ходу дела)))
2. Получение информации о записи клиентом через сайт, по ссылке из SMS
3. Получение истории обслуживания автомобиля мастером и менеджером.
4. Отмена записи:
4.1. мастером,
4.2. менеджером,
4.3. клиентом на сайте.
5. Получение информации о клиенте:
5.1. Список авто.
5.2. История обращений - общая по всем авто.
5.3. Редактирование информации.
6. и так далее 🙌
Обратите внимание, как начинает пополняться Confluence⚡️
На этапе описания процессов AS IS + TO BE поисходит структурирование информации, полученной в ходе встреч, исследования предметной области и общения с сотрудниками компании. Это необходимый шаг. Именно благодаря ему определяется реальный объем работ и формируются требования на разработку - ТЗ.
ТЗ - техническое задание, договор с заказчиком.
В ходе описания процессов у аналитика возникает множетсво уточнений и вопросов к заказчику.
*Хороший тон: не заваливать заказчика сообщениями в мессенджере каждый час, а один раз на созвоне задать все сразу.
1. Придумала 10 вопросов.
2. Пока дописывала ТЗ и разбиралась в деталях - отбросила 8.
3. На встречах 1-2 раза в неделю обсудила вопросы и продемонстрировала макеты экранов, чтобы показать, что примерно будет результатом работ.
Получила ответы и комментарии. Прошла еще круг после встречи. И так до готовности ТЗ. Уровнь детализации зависит от вашей компании, проекта и заказчика.
Описание бизнес-процессов и понимание, как они затем лягут на систему - зона ответственности бизнес- и системных аналитиков 🙌
1. Запись машины в сервис по телефону через менеджера или на сайте, с SMS-уведомлениями клиента:
1.1. Первичная запись с регистрацией клиента и авто
1.2. Повторная запись старого клиента со старым авто
1.3. Повторная запись старого клиента с новым авто
1.4. Повторная запись - новый клиент со старым авто (изменен владелец)
1.5. Повторная запись - добавлен второй владелец
1.6. ... еще что-то подскажете или найдем по ходу дела)))
2. Получение информации о записи клиентом через сайт, по ссылке из SMS
3. Получение истории обслуживания автомобиля мастером и менеджером.
4. Отмена записи:
4.1. мастером,
4.2. менеджером,
4.3. клиентом на сайте.
5. Получение информации о клиенте:
5.1. Список авто.
5.2. История обращений - общая по всем авто.
5.3. Редактирование информации.
6. и так далее 🙌
Обратите внимание, как начинает пополняться Confluence
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤4🔥3
GetAnalyst_Шаблон_требований_описание_процессов_Запись_машины_в.pdf
161.7 KB
⭐️ Шаблон документации - бизнес-процессы, без технических деталей ⭐️
Результат работы - описание процессов AS IS+TO BE по проекту PorscheLab.
Ключевое:
🔶 Сейчас заполнена основная информация по процессам.
🔶 Выделены основные процессы. Нет сильного дублирования информации, есть ссылочность внутри документа.
🔶 Я не сторонник писать, чтобы было больше текста. Можно описать отдельно AS IS, отдельно TO BE, чтобы как по ГОСТу, но задача спроектировать систему и скорее отдать задачи в разработку, а не лить воду.
🔶 Меньше текста, короче предложения - лучше читаемость, больше счастья.
🔶 Шаблон может быть доработан: добавить критерии приемки, добавить User Story на место общего описания, добавить диаграммы, можно поменять формат описания сценариев (я использовала Use Case без тех деталей). Это один из возможных вариантов.
Сохраняем, пользуемся ⭐️ Есть, что добавить или можете поделиться своими шаблонами? Комментарии ❤️
Результат работы - описание процессов AS IS+TO BE по проекту PorscheLab.
Ключевое:
🔶 Сейчас заполнена основная информация по процессам.
🔶 Выделены основные процессы. Нет сильного дублирования информации, есть ссылочность внутри документа.
🔶 Я не сторонник писать, чтобы было больше текста. Можно описать отдельно AS IS, отдельно TO BE, чтобы как по ГОСТу, но задача спроектировать систему и скорее отдать задачи в разработку, а не лить воду.
🔶 Меньше текста, короче предложения - лучше читаемость, больше счастья.
🔶 Шаблон может быть доработан: добавить критерии приемки, добавить User Story на место общего описания, добавить диаграммы, можно поменять формат описания сценариев (я использовала Use Case без тех деталей). Это один из возможных вариантов.
Сохраняем, пользуемся ⭐️ Есть, что добавить или можете поделиться своими шаблонами? Комментарии ❤️
❤12👍4🔥1
На прошлой неделе мы опубликовали пост с подходом к решению задач для системного аналитика - порядок работы.
Собрали для вас список ссылок на посты с примерами 😉🔗
1. Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
https://t.me/getanalysts/713
2. Определение ролей пользователей и приложений, которые будут задействованы
Указаны далее для каждого сценария
+ в работе с архитектурой, которая создается совместно с системным аналитиком на старте IT-проекта
https://t.me/getanalysts/734
https://t.me/getanalysts/735
https://t.me/getanalysts/739
https://t.me/getanalysts/742
https://t.me/getanalysts/746
https://t.me/getanalysts/747
https://t.me/getanalysts/749
3. Выделение и описание основных сценариев + 4. Проработка альтернативных сценариев
https://t.me/getanalysts/718
до https://t.me/getanalysts/720
5. Задачи на дизайнера
Примера постановки задачи нет. Если нужен, ставим ❤️ к посту
----
Про уровень детализации требований:
https://t.me/getanalysts/762
----
10. Задачи на фронтенд / мобильные
https://t.me/getanalysts/773
до https://t.me/getanalysts/776
-----
Прежде чем ставить задачи на бэкенд
https://t.me/getanalysts/790
-----
6. Определение сущностей и свойств + 7. Задачи на БД
https://t.me/getanalysts/794 (шаблон Confluence)
8. Задачи на подготовку тестовых данных
Примера нет. Просим тестировщиков обычным текстом заготовить данные в определенных форматах, если это необходимо. Не обязательный шаг.
9. Задачи на разработку методов Backend (API)
https://t.me/getanalysts/797 (шаблон Confluence)
11. Задачи на тестирование
Без примера 🙂 Исходная задача переходит в статус "Ready for Testing", либо создается подзадача на тестировщика.
12. Задачи на сохранение важных артефактов по документации после разработки - документация
Без примера 🙂 Это текстовое описание в Jira: указания что-где поправить, что дописать, и куда перенести, по окончании разработки.
Чтобы сохранить, пересылаем себе в ЛС! Делаем репосты коллегам и ставим 🔥
Собрали для вас список ссылок на посты с примерами 😉🔗
1. Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
https://t.me/getanalysts/713
2. Определение ролей пользователей и приложений, которые будут задействованы
Указаны далее для каждого сценария
+ в работе с архитектурой, которая создается совместно с системным аналитиком на старте IT-проекта
https://t.me/getanalysts/734
https://t.me/getanalysts/735
https://t.me/getanalysts/739
https://t.me/getanalysts/742
https://t.me/getanalysts/746
https://t.me/getanalysts/747
https://t.me/getanalysts/749
3. Выделение и описание основных сценариев + 4. Проработка альтернативных сценариев
https://t.me/getanalysts/718
до https://t.me/getanalysts/720
5. Задачи на дизайнера
Примера постановки задачи нет. Если нужен, ставим ❤️ к посту
----
Про уровень детализации требований:
https://t.me/getanalysts/762
----
10. Задачи на фронтенд / мобильные
https://t.me/getanalysts/773
до https://t.me/getanalysts/776
-----
Прежде чем ставить задачи на бэкенд
https://t.me/getanalysts/790
-----
6. Определение сущностей и свойств + 7. Задачи на БД
https://t.me/getanalysts/794 (шаблон Confluence)
8. Задачи на подготовку тестовых данных
Примера нет. Просим тестировщиков обычным текстом заготовить данные в определенных форматах, если это необходимо. Не обязательный шаг.
9. Задачи на разработку методов Backend (API)
https://t.me/getanalysts/797 (шаблон Confluence)
11. Задачи на тестирование
Без примера 🙂 Исходная задача переходит в статус "Ready for Testing", либо создается подзадача на тестировщика.
12. Задачи на сохранение важных артефактов по документации после разработки - документация
Без примера 🙂 Это текстовое описание в Jira: указания что-где поправить, что дописать, и куда перенести, по окончании разработки.
Чтобы сохранить, пересылаем себе в ЛС! Делаем репосты коллегам и ставим 🔥
❤30🔥17👍6💯3
Проектирование БД - фундамент, на котором держатся системы.
Баг, про который я рассказала в первом видео по проекту PorscheLab, с которым я столкнулась в реально работающей системе:
У одного автомобиля может быть несколько владельцев, в разные периоды времени.
Разработчики этого не учли.
⚠️ Как его решают? Никак, методом "костылей".
Видимо история обслуживания автомобиля будет утеряна при переводе его на нового владельца.
Т.е. старое авто пересоздадут как новое, без истории обслуживания.
⚠️ Почему такое "решение"?
Плохо спроектированная БД, которая не учитывает этот Use Case - перевод одного авто между клиентами автосалона.
⚠️ В чем проблема БД?
Сейчас связь в реляционной БД:
▫️1 авто - 1 владелец,
▫️1 владелец - много авто.
= 1-ко-многим.
Нужно было:
▫️1 авто - много владельцев в разные периоды,
▫️1 владелец - много авто.
= многие-ко-многим.
Чтобы исправить ситуацию, минимум 10 задач на разработчиков, если не 20. Почему?! Что за задачи?!
Надо соблюдать обратную совместимость при проектировании БД. А лучше проектировать фундамент аккуратно, со взглядом в будущее.
У нас будет продуманная БД!
Смотрим новое видео-обучение:
2. Определение сущностей и проектирование логической модели БД
Баг, про который я рассказала в первом видео по проекту PorscheLab, с которым я столкнулась в реально работающей системе:
У одного автомобиля может быть несколько владельцев, в разные периоды времени.
Разработчики этого не учли.
⚠️ Как его решают? Никак, методом "костылей".
Видимо история обслуживания автомобиля будет утеряна при переводе его на нового владельца.
Т.е. старое авто пересоздадут как новое, без истории обслуживания.
⚠️ Почему такое "решение"?
Плохо спроектированная БД, которая не учитывает этот Use Case - перевод одного авто между клиентами автосалона.
⚠️ В чем проблема БД?
Сейчас связь в реляционной БД:
▫️1 авто - 1 владелец,
▫️1 владелец - много авто.
= 1-ко-многим.
Нужно было:
▫️1 авто - много владельцев в разные периоды,
▫️1 владелец - много авто.
= многие-ко-многим.
Чтобы исправить ситуацию, минимум 10 задач на разработчиков, если не 20. Почему?! Что за задачи?!
Надо соблюдать обратную совместимость при проектировании БД. А лучше проектировать фундамент аккуратно, со взглядом в будущее.
У нас будет продуманная БД!
Смотрим новое видео-обучение:
2. Определение сущностей и проектирование логической модели БД
YouTube
2. Системный анализ для проекта: определение сущностей и проектирование логической модели БД
Проект:
Система для Автосервиса.
Шаблоны документации Confluence для системных аналитиков:
https://t.me/getanalysts/828
Видео про БД с нуля:
https://www.youtube.com/watch?v=Y9V1h6IICL0
О сообществе:
https://getanalyst.ru/about
В видео:
✔️ Проектирование…
Система для Автосервиса.
Шаблоны документации Confluence для системных аналитиков:
https://t.me/getanalysts/828
Видео про БД с нуля:
https://www.youtube.com/watch?v=Y9V1h6IICL0
О сообществе:
https://getanalyst.ru/about
В видео:
✔️ Проектирование…
❤7👍2
В продолжение к видео о важности БД, я рекомендую посмотреть вебинар про связь базы данных и дизайна методов REST API (Backend) 👀
На видео я рассказывала про обратную совместимость. Изменение структуры хранения данных ведет к доработкам логики работы сервера....
На видео я рассказывала про обратную совместимость. Изменение структуры хранения данных ведет к доработкам логики работы сервера....
YouTube
Связь базы данных и дизайна REST API / Вебинар 17.02.2022
На вебинаре сделали модель базы данных и дизайн REST API:
— построили логическую модель базы данных
— описали JSON-объекты и методы REST API
— разобрали, какие бывают ошибки и как их избежать
Бесплатные вебинары GetAnalyst:
https://getanalyst.ru/events
…
— построили логическую модель базы данных
— описали JSON-объекты и методы REST API
— разобрали, какие бывают ошибки и как их избежать
Бесплатные вебинары GetAnalyst:
https://getanalyst.ru/events
…
🔥5❤1
Работа с опытными коллегами - это радость ❤️
Профессия системного аналитика - это непрерывная возможность для роста и обучения. Мы расширяем свой кругозор, знакомясь с разными проектами (банки, туризм, страхование, социальные сети, медицина и другие), улучшаем как технические навыки, так и навыки мягкого взаимодействия (soft skills) в ходе ежедневной работы.
Мы учимся через опыт взаимодействия с другими людьми. Про бизнес нам рассказывают заказчики, а вот сложные детали проектирования объясняют опытные коллеги разработчики и старшие аналитики.
Бывает, что приходится задавать самые странные вопросы. Иногда страшно, что спрашиваешь что-то глупое. Но все же... Они терпеливо рассказывают, объясняют, или отправляют что-то почитать 😄
Спасибо разработчикам, кто с удовольствием делится своим опытом, рассказывает про то, как надо делать, и как не надо. Спасибо старшим коллегам, которые также передают свой опыт и направляют в решении задач. И за то, что скидывают шаблоны, примеры постановок задач, чтобы было на что ориентироваться❤️
Ведь потом, через время, становится круто, когда начинаешь всех их по-настоящему понимать: говоришь на их языке, понимаешь технические детали проектов! Это не только ускоряет и упрощает процесс работы, но и придает уверенность!
Карьера в IT - это процесс непрерывного обучения и развития, и круто, когда есть возможность обучаться у лучших ❤️
Давайте мысленно вспомним тех, кто помогал или помогает нам расти, и выразим им огромную благодарность за то, что нам посчастливилось взаимодействовать с этими талантливыми людьми!
P.S. А еще можно написать ✉️
Профессия системного аналитика - это непрерывная возможность для роста и обучения. Мы расширяем свой кругозор, знакомясь с разными проектами (банки, туризм, страхование, социальные сети, медицина и другие), улучшаем как технические навыки, так и навыки мягкого взаимодействия (soft skills) в ходе ежедневной работы.
Мы учимся через опыт взаимодействия с другими людьми. Про бизнес нам рассказывают заказчики, а вот сложные детали проектирования объясняют опытные коллеги разработчики и старшие аналитики.
Бывает, что приходится задавать самые странные вопросы. Иногда страшно, что спрашиваешь что-то глупое. Но все же... Они терпеливо рассказывают, объясняют, или отправляют что-то почитать 😄
Спасибо разработчикам, кто с удовольствием делится своим опытом, рассказывает про то, как надо делать, и как не надо. Спасибо старшим коллегам, которые также передают свой опыт и направляют в решении задач. И за то, что скидывают шаблоны, примеры постановок задач, чтобы было на что ориентироваться❤️
Ведь потом, через время, становится круто, когда начинаешь всех их по-настоящему понимать: говоришь на их языке, понимаешь технические детали проектов! Это не только ускоряет и упрощает процесс работы, но и придает уверенность!
Карьера в IT - это процесс непрерывного обучения и развития, и круто, когда есть возможность обучаться у лучших ❤️
Давайте мысленно вспомним тех, кто помогал или помогает нам расти, и выразим им огромную благодарность за то, что нам посчастливилось взаимодействовать с этими талантливыми людьми!
P.S. А еще можно написать ✉️
❤16
Как простым языком объяснить, что приложение - это не просто красивые экраны? 🤓
Что за красивой картинкой пользовательского интерфейса с кнопками и полями ввода скрываются сервер, база данных, сервисы, микросервисы... И API 🙌
API - это программный интерфейс, который нужен для обмена данными между Frontend (UI - пользовательский интерфейс приложения) и Backend.
С API можно встретиться:
▫️ при постановках задач на Backend - сопоставление данных JSON-БД,
▫️при проектировании интеграций - когда нужно сопоставить данные между нашей БД и API чужой системы (P.S. сопоставление = маппинг), а еще протестировать в Postman.
И потом всю информацию по созданному API еще надо документировать - Swagger и опять же Postman в этом прекрасные помощники!
Сейчас один из наиболее популярных программных интерфейсов REST API. Умение его создавать с нуля - это ценный навык в сфере IT.
В моем опыте были как аналитики, так и разработчики, которым приходилось передавать опыт проектирования и стандартизации REST API в проекте, чтобы не было тут "так", а там "сяк". Чтобы не было хаоса в структуре запросов и с вашей системой было приятно взаимодействовать другим программистам.
И теперь я передаю этот опыт вам. Будем разбирать проектирование REST API на примере нашего проекта с автосервисом PorscheLab и не только, чтобы у вас были знания о принятых стандартах в отрасли и понимание, как это работает в реальной жизни! 🚀
Что за красивой картинкой пользовательского интерфейса с кнопками и полями ввода скрываются сервер, база данных, сервисы, микросервисы... И API 🙌
API - это программный интерфейс, который нужен для обмена данными между Frontend (UI - пользовательский интерфейс приложения) и Backend.
С API можно встретиться:
▫️ при постановках задач на Backend - сопоставление данных JSON-БД,
▫️при проектировании интеграций - когда нужно сопоставить данные между нашей БД и API чужой системы (P.S. сопоставление = маппинг), а еще протестировать в Postman.
И потом всю информацию по созданному API еще надо документировать - Swagger и опять же Postman в этом прекрасные помощники!
Сейчас один из наиболее популярных программных интерфейсов REST API. Умение его создавать с нуля - это ценный навык в сфере IT.
В моем опыте были как аналитики, так и разработчики, которым приходилось передавать опыт проектирования и стандартизации REST API в проекте, чтобы не было тут "так", а там "сяк". Чтобы не было хаоса в структуре запросов и с вашей системой было приятно взаимодействовать другим программистам.
И теперь я передаю этот опыт вам. Будем разбирать проектирование REST API на примере нашего проекта с автосервисом PorscheLab и не только, чтобы у вас были знания о принятых стандартах в отрасли и понимание, как это работает в реальной жизни! 🚀
👍14