⚡️Друзья, новость-молния⚡️
Новый подкаст🤩

⏯ ЭПИЗОД 14:
ИДЕМПОТЕНТНОСТЬ И КОММУТАТИВНОСТЬ API:
ЧТО ЭТО И КАК ПРИМЕНЯЮТ НА ПРАКТИКЕ

Как повторные запросы API могут привести к сбоям в системе? Почему важно, чтобы результат операций оставался корректным, даже если их порядок выполнения изменится?

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

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

Эпизод рекомендуется к прослушиванию как для начинающих, так и для опытных системных аналитиков, стремящихся углубить свои знания в теме проектирования REST API 🙂

Ведущая:
⭐ Екатерина Ананьева,
Основатель сообщества GetAnalyst

Гости:
⭐ Елизавета Акманова,
Старший системный аналитик UseTech

Сегодня делимся историей нашей Елизаветы, как она пришла в системный анализ #expertGetAnalyst


Работать в ИТ изначально не планировала.
Но благодаря старшим друзьям-физикам по университету, после учёбы сразу попала в эту перспективную среду и начала свой путь🙌

Начинала с консультирования пользователей информационных систем в качестве техподдержки.
Опыт оказался ценным!

📌 Во-первых, научилась смотреть на системы глазами пользователей, понимать сложности, которые возникают в процессе.
📌 Во-вторых, поняла, как докапываться до проблемы, задавая вопросы, а затем объяснять решение максимально развёрнуто и понятно. Снова и снова)

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

Работа была однообразной.
В какой-то момент задумалась:
- Что ждёт меня дальше? 👇👇👇

Поскольку никогда не видела себя разработчиком, то стала смотреть в сторону технических писателей. Даже прошла профессиональные курсы, которые дали фундамент для работы с документами. Но в то же время осознала, что МОГУ и ХОЧУ большего😎

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

Аналитик зачастую должен:
▪️ Понимать и БА, и СА,
▪️ Тестировать,
▪️ Писать документацию (ха-ха),
▪️ Мониторить команду разработки,
▪️ Вести переговоры со стейкхолдером
и т.д.

Этакая многорукая Шива, которая во всём разбирается😅

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

К сожалению, за всей работой не замечала, как много уже знаю, и всё ещё не чувствовала себя «настоящим» системным аналитиком😒

Поэтому когда меня поставили единственным аналитиком на проекте, то испытала шок.

Но именно это стало переломным моментом. Без веры в свои силы было тяжело, но я двигалась вперёд, преодолевая сложности и набираясь опыта. Глаза боятся, а руки делают👌

Ещё один плюс работы аналитиком: каким бы опытным ты ни был, тебе всегда есть куда развиваться.

Поэтому в последующие годы я сменила несколько разных интересных проектов.
✔️ Укрепила позиции в профессии,
✔️ Поверила в себя
✔️ Обрела поддерживающую профессиональную среду и снова почувствовала необходимость изменений.

Системный аналитик всегда в профессиональном движении.
Сейчас двигаюсь к следующей цели — стать тимлидом.
И путь интереснее конечной цели😏

Друзья, среда - маленькая пятница. Как ваше настроение?😎

▶️ Профессия Системный аналитик: с чего начинается работа? ◀️

Представьте, ресторатору нужно открыть новое заведение. Он поручает всё помощнику.

Но тот понимает, для того чтобы приступить к работе, необходимо:
1️⃣ задать нужные вопросы (какая кухня, каких гостей хочет видеть ресторатор, где брать аренду, бюджеты),
2️⃣ проанализировать специфику задач (рецепты блюд, особенности),
3️⃣ просчитать риски (прибыли и убытки в момент открытия),
4️⃣ собрать команду (повара, официанты, менеджеры).
Это очень важный этап, от которого будет строиться вся дальнейшая работа по открытию заведения.

Так и в работе аналитика. Пока не будут определены точные требования к ПО от заказчика и не будет прописано ТЗ, об успешной дальнейшей работе не может быть и речи.

Согласитесь, последует «неловкая» ситуация, когда ресторатор поймёт, что хотел интерьер в стиле минимализм, а получил бохо. Или посадочных мест должно было быть 50, а вышло всего 30.

Чтобы сформулировать адекват­ное требование важно как можно грамотнее собрать и проанализировать информацию.

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

Только когда требования собраны и документ согласован с заказчиком можно начинать программировать систему. Этот документ с требованиями - техническое задание (ТЗ), которое готовит системный аналитик.

#hardGetAnalyst