Про #софтскилы в 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
REST API - самый популярный интерфейс обмена данными между системами ⚡️
Поэтому совсем скоро будет еще один проект, с которым мы начнем работать с нуля до постановок задач на REST API - на практическом курсе "Дизайн REST API", 6-ой поток! 🚀
Это уникальная программа, собранная на основе реального опыта в проектировании систем, в которой мы с коллегами в течение двух месяцев работаем над проектом, где нужно продумать всё: от требований и БД до REST API.
‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️
АНКЕТА ПРЕЗДАПИСИ REST API
Фокус на практике, а результат - личный проект в Postman и Swagger, постановки задач в Jira+Confluece, которые пополнят портфолио 📈
Поэтому совсем скоро будет еще один проект, с которым мы начнем работать с нуля до постановок задач на REST API - на практическом курсе "Дизайн REST API", 6-ой поток! 🚀
Это уникальная программа, собранная на основе реального опыта в проектировании систем, в которой мы с коллегами в течение двух месяцев работаем над проектом, где нужно продумать всё: от требований и БД до REST API.
‼️ До 20 ИЮЛЯ открывается анкета предзаписи, по которой можно принять участие в программе на специальных условиях ‼️
АНКЕТА ПРЕЗДАПИСИ REST API
Фокус на практике, а результат - личный проект в Postman и Swagger, постановки задач в Jira+Confluece, которые пополнят портфолио 📈
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1
Привет-привет! Продолжим работу над проектом с автосервисом 🚘
Для реализации функциональности веб-приложений мы будем реализовывать REST API. Он нужен для обмена данными с сервером.
Напоминание:
Часть клиента - экранные формы для пользователей.
Часть сервера - база данных и методы API. Базу данных мы уже делали.
REST API (Representational State Transfer) - это архитектурный стиль проектирования. Он использует протокол HTTP для общения между клиентом и сервером.
⚠️ Важный момент: REST - именно стиль, а протокол - HTTP.
Когда мы работаем над функциональными ребованиями, то часто применяем CRUD-модель, чтобы описать всю функциональность для каждой сущности в системе. CRUD представляет собой четыре основных функции, которые напрямую связаны с REST API:
1. CREATE (Создать):
Это процесс создания новой записи в системе.
REST API: метод POST.
Пример: когда владелец автомобиля создает заявку на обслуживание авто на сайте, сайт может отправить POST-запрос на сервер автосервиса для создания новой записи.
2. READ (Прочитать):
Это операция получения или чтения данных из системы.
REST API: метод GET.
Пример, когда владелец автомобиля хочет узнать статус ремонта своего автомобиля по уникальному номеру заявки на сайте, то сайт может отправить GET-запрос на сервер автосервиса с этого номера, чтобы получить ее статус.
3. UPDATE (Обновить):
Это операция обновления существующих данных в системе.
REST API: метод PUT или PATCH.
Пример: когда владелец автомобиля хочет изменить контактные данные или информацию об автомобиле, сайт может отправить PUT или PATCH запрос на сервер автосервиса.
4. DELETE (Удалить):
Это процесс удаления данных из системы.
REST API: метода DELETE.
Пример: когда владелец автомобиля хочет удалить свою заявку, чтобы удалить данные из БД автосервиса, сайт может отправить DELETE-запрос на сервер.
Важно помнить, что конкретное использование этих методов REST API может отличаться в зависимости от специфики API или системы. Даже POST иногда нужно использовать для получения данных 💻
Для реализации функциональности веб-приложений мы будем реализовывать REST API. Он нужен для обмена данными с сервером.
Напоминание:
Часть клиента - экранные формы для пользователей.
Часть сервера - база данных и методы API. Базу данных мы уже делали.
REST API (Representational State Transfer) - это архитектурный стиль проектирования. Он использует протокол HTTP для общения между клиентом и сервером.
⚠️ Важный момент: REST - именно стиль, а протокол - HTTP.
Когда мы работаем над функциональными ребованиями, то часто применяем CRUD-модель, чтобы описать всю функциональность для каждой сущности в системе. CRUD представляет собой четыре основных функции, которые напрямую связаны с REST API:
1. CREATE (Создать):
Это процесс создания новой записи в системе.
REST API: метод POST.
Пример: когда владелец автомобиля создает заявку на обслуживание авто на сайте, сайт может отправить POST-запрос на сервер автосервиса для создания новой записи.
2. READ (Прочитать):
Это операция получения или чтения данных из системы.
REST API: метод GET.
Пример, когда владелец автомобиля хочет узнать статус ремонта своего автомобиля по уникальному номеру заявки на сайте, то сайт может отправить GET-запрос на сервер автосервиса с этого номера, чтобы получить ее статус.
3. UPDATE (Обновить):
Это операция обновления существующих данных в системе.
REST API: метод PUT или PATCH.
Пример: когда владелец автомобиля хочет изменить контактные данные или информацию об автомобиле, сайт может отправить PUT или PATCH запрос на сервер автосервиса.
4. DELETE (Удалить):
Это процесс удаления данных из системы.
REST API: метода DELETE.
Пример: когда владелец автомобиля хочет удалить свою заявку, чтобы удалить данные из БД автосервиса, сайт может отправить DELETE-запрос на сервер.
Важно помнить, что конкретное использование этих методов REST API может отличаться в зависимости от специфики API или системы. Даже POST иногда нужно использовать для получения данных 💻
👍13🔥6❤1
Время квиза! Какой метод используется для подтверждения заявки на обслуживание менеджером?
Anonymous Quiz
45%
POST
16%
GET
38%
PATCH
1%
DELETE
Какой метод используется для отображения списка заявок клиентов на экране у менеджера?
Anonymous Quiz
8%
POST
89%
GET
2%
PUT
1%
PATCH
Какой метод используется для просмотра деталей существующей заявки менеджером?
Anonymous Quiz
8%
POST
85%
GET
4%
PUT
2%
PATCH
Какой HTTP метод используется для отмены заявки на обслуживание?
Anonymous Quiz
8%
POST
24%
PATCH
27%
DELETE
41%
PATCH и DELETE
Какой метод используется для добавления автомобиля к существующему клиенту?
Anonymous Quiz
28%
POST, PATCH
22%
POST, PUT
37%
POST, PATCH, PUT
14%
POST
❤7