❗️Уже через 3 часа❗️

Практический вебинар с Екатериной Ананьевой!

📹 Собеседование на системного аналитика: подготовка на практике
⏰ 19:00 - 21:00 Мск

Ссылку на прямой эфир пришлем в канал за 15 минут до начала.

Привет! 👋

Вчера у нас получилось 4 часа разбора вопросов про резюме и собеседования! Вау! 🤩 И это практически применимая информация, которую еще можно дополнить!!! Это самый длинный вебинар на моей памяти и всё, что связано с трудоустройством, обычно было так.

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

Что решили сделать с получившимся вебинаром, потому что 4 часа это реально много:

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

2. Уведомление о возможности посмотреть вебинар в записи опубликуем здесь и отправим на почту в ближайшие дни.


И хочу дополнительно оставить здесь ссылки на 2 статьи, которые вчера разбирали:
✅ Ресурс для публикации резюме по всему миру + не забываем про ведение LinkedIn.
✅ Карта навыков Системного аналитика, на котором базировался наш заполняемый документ по навыкам.

Спасибо вам большое за ваше активное участие! Очень много вопросов разобрали дополнительно ❤️

Привет, коллеги! Продолжим знакомство с интеграционным проектом GetDelivery 👀

Для работы с задачами на интеграции есть определенный порядоку работы:

1️⃣ Подготовка.
Знакомство с проектом, запрос документации и доступов к внешним системам.

2️⃣ Сбор и анализ требований.
Бизнес-цель разработки интеграции.
Бизнес-задачи интеграции.
Бизнес-требования.
Функциональные требования.
Нефункциональные требования.
Разработка верхнеуровневой схемы архитектуры.

3️⃣ Анализ API документации.

4️⃣ Тестирование API.

5️⃣ Разработка логики и алгоритмов.

6️⃣ Анализ данных = Маппинг данных.

7️⃣ Разработка схемы архитектуры - детализация и уточнение исходного варианта, с учетом собранных требований.

8️⃣ Постановка задач на разработчиков.

9️⃣ Участие в релизе, сопровождении и сохранении документации.

Подробнее про каждый этап можно почитать в моей статье с пошаговой инструкцией работы с задачами на интеграции.

План есть - можно начинать работу! 🚀

▫️Этап 1. Подготовка к работе с проектом на интеграции ▫️

📌 Знакомство:

Этот пост показывает, как я последовательно анализирую новый проект на старте, и за какие “подводные камни” я цепляюсь.

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

Для себя, в самом начале, я определяю процесс работы пользователя в системе.

Что у нас будет в GetDelivery по успешному сценарию:

1. Пользователь вводит информацию о габаритах груза и инициирует поиск вариантов перевозки груза во внешних системах: Деловые Линии, СДЭК и Возовоз.

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

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


2. Пользователь получает результат и выбирает наиболее удобный вариант отправления груза. Обязательно показать стоимость.

Тут есть вопросы:

- Как мы работаем с тарифами? Я помню, что при отправлении грузов есть варианты по обычной и ускоренной доставке. Может быть предусмотреть указание этого фильтра на этапе ввода габаритов груза, на самом старте? А после поиска можно в дополнение показывать цены на остальные тарифы сразу, либо по нажатию на специальную кнопку. В общем этот вопрос решаем. Согласуем с заказчиком на этапе дизайна.

- Верно ли мы понимаем, что после выбора варианта отправления, мы должны перенаправить пользователя для оформления заказа на соответствующий сайт, где он заполнит все формы и оплатит заказ на отправление?

Ответ на этот вопрос может поменять стоимость разработки в два раза. Относится к стыку бизнес- и системного анализа.

Как будем делать с учетом вводных? Пишите в комментариях 🙂

Продолжение 👇

👀Перенаправить пользователя для оформления заказа на соответствующий сайт, где он заполнит все формы и оплатит заказ? Или нет?

Это хороший вопрос, где начинается сочетание системного и бизнес-анализа.

Оба варианта допустимы. И давайте их разберем:


Вариант 1. Делаем перенаправление на соответствующий сайт СДЭК, Деловые линии или Возовоз, чтобы клиент завершил свой заказ там.

Плюсы:
+ Не надо писать логику формирования заказа в нашей системе.

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

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

- Как мы собираемся поддерживать уведомления, если в нашу систему не попадет информация о статусе заказа после оплаты. Мы делаем интеграцию к СДЭК, а не СДЭК к нам.
Когда мы создаем интеграцию, нам важно понимать, что это мы должны инициировать запрос и получение данных. А как нам СДЭК сообщит о том, что заказ оплачен, если после перехода на его сайт наше приложение потеряло с ним связь - это вопрос. Может через веб-хук? Но его могут поддерживать не все системы.
Нам надо реализовать единый процесс по оформлению заказа в нашем агрегаторе доставок для всех внешних систем. Так что хорошо бы изучить вопрос и сравнить возможные решения - внешних систем уже сейчас несколько и их будет больше в нашем агрегаторе.

- Пользователю скорее всего придется вводить все параметры для заказа по габаритам заново, если только их нельзя передать в СДЭК (и другие системы) каким-то образом через url-запроса.


Вариант 2. Делаем оформление заказ и прием платежей на нашей стороне.
...

Продолжение 👇

‼️ Вопросы из чата от подписчика, которые нужно разобрать ‼️

❓А клиенты это кто? Физические лица или бизнес (юр.лица, поставщики маркетплейсов) - хороший вопрос.

Надо будет погрузиться на этапе исследования и детализации требований. Ответы будут понятны на этапе исследования UI (пользовательский интерфейс) и API (программный интерфейс).


❓А если у перевозчиков для разных категорий клиентов разные тарифы, как это учесть? - хороший вопрос, дублирует первый и наводит на правильные мысли.
Будет следовать из ответа на вопрос выше. Если это есть в СДЭК, Деловых Линиях и в Возовозе как обязательные параметры, то надо будет у нас это сделать на стартовом экране. И поставить значение по умолчанию - физические лица.


❓А груз каких максимальных габаритов может быть? - уже не думаю об этом.

Это бизнес СДЭК, Деловых Линий и в Возовоза. Если мы зададим негабаритный груз для СДЭКа, то он вернет нам ошибку, когда будем запрашивать у него стоимость перевозки. А значит в результате поиска, если такая ошибка, возможности перевозки негабаритного груза будут отсутствовать.
Хотя в целом ограничения на адекватность размеров тоже полезно ввести в систему. А то мало ли 2 километра посылки будет к перевозке 😄


❓А доставка только по России? - не первоочередный вопрос, но важный. Влияет на стоимость задачи.

Смогу разобраться на этапе исследования API-документации внешних систем. Мне в любом случае надо будет решить как я буду делать заполнение пункта отправления и прибытия. Вероятно придется подключить какой-то справочник адресов. Например https://dadata.ru/. Но там только адреса России и СНГ.

⬇️⬇️⬇️

⬇️⬇️⬇️

❓А как учитывать акции перевозчика, если они будут? - хороший вопрос, серьезно влияет на UI и интеграцию.

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


❓А если у разных поставщиков разные возможности доставки? Нужно ли это знать клиенту? (авиа, экспресс, авто) - вопрос не первоочередный, слишком закапываетесь в детали на старте. Но вопрос нужный на этап анализа API-документации UI внешних систем.

Надо посмотреть показывают это СДЭК, Возовоз и ДЛ или нет. Если нет на этапе поиска, то и нам не надо. Возможно в карточках с результатами поиска. Принимать решение будем после анализа 10 таких почтовых служб - как у них выглядят поисковики.


❓А нужны ли клиенту доп. услуги, например, доставка на дом?- вопрос не первоочередный, слишком закапываетесь в детали на старте.
Будем разбирать возможности внешних систем по API-документации и UI позже, на следующих этапах аналитики. Пока можно дать ответ только по бизнесу, но теническую возможность надо будет подтвердить.

P.S. Спасибо за активность!)

🤩 4 часа самой важной информации: про резюме и собеседования! Вау! 🤩

Это был самый длинный вебинар! И для того, чтобы вы смогли посмотреть его в удобное время и в удобном режиме, мы даем доступ к нему!

📚 Собеседование на системного аналитика: подготовка на практике
📅 ДО 26 НОЯБРЯ - ВОСКРЕСЕНЬЕ!
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Внутри:
1. Про профессию Системного аналитика: главные навыки и обязанности.
2. Карта резюме и рекомендации по оформлению.
3. Пример задачи с собеседований и особенности подготовки.
4. Рекомендации по поиску работы.

Продуктивного обучения! 🌟🌟🌟

Продолжение 👇

Вариант 2. Делаем оформление заказа и прием платежей на нашей стороне.

Этот вариант сложнее с точки зрения технической реализации. Но у него есть преимущество - полный контроль процесса и данных у GetDelivery.


Плюсы:

+ Мы сможем отслеживать заказы, которые оформлены с использованием нашей системы: будем создавать заказы и контролировать прием платежей, вызывая внешние системы по API.

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

В этой интеграции GetDelivery - мастер-система / управляющее приложение.


+ После создания заказа мы сможем по API отслеживать его статус, получать и отправлять клиенту уведомления об изменении статуса заказа, если внешняя система представляет соответствующие API-методы. Эту возможность нужно будет уточнить на этапе изучения документации внешних систем.


+ Если на нашей стороне организован прием платежей, то получается, что мы будем получать деньги от клиента первее чем СДЭК или другую компанию.

Это звучит привлекательно для бизнеса. Но требует уточнения: как затем деньги будут поступать в СДЭК - должны ли мы сделать оплату за клиента с нашего счета сразу, или потом сформировать отчет обо всех заказах за месяц и выполнить единый банковский перевод, вне системы. Нужно уточнять условия сотрудничества и взаиморасчетов с каждой из компаний.


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


👇👇👇

👇👇👇

Минусы:

- Придется дополнительную интеграцию с платежной системой, чтобы принимать платежи за заказы у нас. Либо смотреть, как предлагают работать с платежами внешние системы СДЭК, Деловые Линии и Возовоз, с которыми мы интегрируемся.

Исходя из этого принимать решение о дополнительной интеграции с платежной системой типа ЮКасса, Райф Пэй или другая.


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


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



🟢 Вариант 2 мне больше нравится для реализации интеграции, т.к. он удобен для пользователя, и наша система имеет больше контроля.

Но прежде чем принимать окончательное решение о выборе этого варианта, я должна внимательно изучить API-документацию - прием платежей, и условия сотрудничества - как будут рассчитываться между собой GetDelivery и СДЭК, Деловые Линии, Возовоз. Это поможет мне принять окончательное решение по реализации формирования заказов и платежной части.

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




📌 Запрос документации внешних систем:
Всё получено.


📌 Запрос доступов к внешним системам:
Можно писать письма СДЭК, Деловые Линии и Возовоз, на запрос тестовых доступов. Для этого нам может потребоваться подпись договора или NDA. Так часто бывает с интеграциями. Поэтому запрос доступов это самый первый шаг, чтобы далее не было блокирующих моментов для проектирования и разработки интеграций


Этап 1️⃣
Подготовка ✅

▫️Этап 2 проектирования Интеграций. Сбор и анализ требований ▫️

Этот этап включает формирование полных требований по IT-проекту. От заказчика должны быть получены все вводные, проведено исследование действующих бизнес-процессов AS IS, и сформированы требования к TO BE.

С какими проблемами можно столкнуться на этапе сбора и анализа требований проекта? 🤯
Заказчик хочет, но это сделать невозможно. Требования не реализуемы.

Для бизнес-аналитиков и системных аналитиков, кто не сильно погружается в детали технического проектирования, это может стать сюрпризом. Неприятным сюрпризом, если “это не реализуемо” от разработчиков всплывает на этапе реализации программы, после подписания договора на разработку по ТЗ с заказчиком.


Почему “это не реализуемо” случается на этапе сбора и анализа требований?

⛔ Аналитик знал о необходимости интеграций с внешними системами в проекте, но не проверил в API-документации наличие соответствующих методов.

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

⛔Аналитик не проводил базовое тестирование API (если такая возможность была, например с SOAP, REST, GraphQL это возможно, Postman наш друг).

⛔Не учтены нефункциональные требования, которые помешают реализации бизнес-процесса. Например, ограничение на количество запросов в минуту.

Продолжение 👇

⚠️ Ограничения на платные-бесплатные возможности API, которые не были учтены на этапе сбора и анализа требований, могут привести к дополнительным расходам для заказчика, что не говорит о нереализуемости, но говорит о финансовых вопросах, которые придется решать.


Хотя в последовательности шагов по проектирования интеграции на первом месте у меня стоит этап сбора и анализа требований, результат работы с ним будет уточнен и дополнен на этапе ▫️3 “Анализ API-документации” и ▫️4 “Тестирование API”.

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

Это обходное решение будет принято до момента подписания договора на разработку ПО, что сэкономит много нервов, сил и денег для всех сторон в бизнесе 🙏

Продолжаем работу над интеграцией для GetDelivery. На этапе 2 нужно спроектировать и описать:

☑️ Бизнес-цель разработки интеграции.
☑️ Бизнес-задачи интеграции.
☑️ Бизнес-требования.
☑️ Функциональные требования.
☑️ Нефункциональные требования.
☑️ Разработка верхнеуровневой схемы архитектуры.

🤍 Где всё получается, там есть “Всё получится” 🤍

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

Раньше в карьере я полагалась на наставничество и мотивацию от руководителей, которые всегда говорили: "Всё получится! Если что, не бойся и спрашивай! Обсудим вместе!". Они создавали для меня доверительную атмосферу, где я могла ошибаться и не бояться, где я уверенно спрашивала совета не боялась, что начальник посчитает меня тупой и уволит.

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

Поддержка близких в карьерном росте тоже играет важную роль. Недавно, после перегруженных дней с минимумом количества сна, я чувствовала себя абсолютно истощенной. Много задач, ошибки, много всего происходит, на что я не могу влиять. В голове: “Я сдаюсь… У меня ничего не получается". И в тот момент я получила очень важные и нужные слова поддержки от близкого человека: "Ты уже столько сделала! Смотри, ты переехала сюда совсем одна, строишь бизнес, у тебя международный проект.... Ты чего? Все хорошо будет. Иди отдохни и завтра в новый день. Всё получится. Ведь уже столько получилось! Ты очень умная, ты со всем справишься!".

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

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

Всё получится, ты же уже молодец, смотри сколько всего сделал! Дальше тоже всё будет ещё лучше! Я в тебя верю 🤍

Всем крутого воскресенья!

🌟 Отдыхаем и набираемся сил,
🌟 Досматриваем вебинар про карьеру системного аналитика и собеседования,
🌟 Готовимся к воркшопу по ChatGPT,

и собираем хорошее настроение! 😉😄

Привет, коллеги! Продолжаем разбирать интеграционный проект GetDelivery.

▫️Этап 2 проектирования Интеграций. Сбор и анализ требований▫️

✅ Цель интеграции:

Разработать и запустить логистический сервис-агрегатор GetDelivery, предоставляющий пользователям удобный доступ к актуальной информации о стоимости и условиях отправления посылки через различные компании доставки (Деловые Линии, СДЭК, Возовоз).

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


✅ Задачи интеграции:

✔️ Обеспечить возможность задания параметров груза для расчета стоимости его доставки.

✔️ Реализовать интеграцию с сервисами доставки для получения актуальных условий перевозки и выбора сервиса с наиболее выгодными.
- Деловые Линии,
- СДЭК,
- Возовоз.

✔️ Реализовать интеграцию с сервисами доставки для оформления сервисов заказов через них.

✔️ Уведомлять клиентов об обновлении статусов заказов, оформленных через GetDelivery.

✔️ Формировать для владельца GetDelivery отчетность по полученным выплатам за оплаченные заказы.

✔️ Формировать для владельца GetDelivery аналитику - % пользователей, которые выполнили поиск и оплатили заказ с использованием GetDelivery (= кол-во пользователей оформивших заказы и оплативших их / кол-во выполнявших поиски).


И вот на этом моменте я пошла изучать API-документацию.
Всё ли возможно реализовать технически? И если да, то как?

🤖 Что ждать от ChatGPT 4.0 системным аналитикам? 🤖


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

Я часто повторяю, что ChatGPT это ваш личный ассистент - младший системный аналитик, который помогает! Хоть иногда и с ошибками. На всех программах обучения с этого года я демонстрирую команды, которые можно использовать в работе.

С учетом новых возможностей ChatGPT 4.0, которые позволяют анализировать актуальные данные из Интернета, а не как в предыдущих версиях только до 2021 года, вот как можно применить его в своей работе:


🤖 Анализ API - документации и описание маппингов данных для интеграций

ChatGPT 4.0 принимает к анализу ссылки на веб-страницы. Теперь всю интерактивную API-документацию можно отправить к нему на анализ. Для нашего проекта GetDelivery можно смело проводить анализ API Деловых Линий, СДЭКа и Возовоза, т.к. мы получили на вход ссылки на их API.


🤖 Генерация требований к системе

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

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


🤖 Помощь в моделировании процессов

Аналитик может использовать ChatGPT для генерации идей по описанию новых и улучшению существующих бизнес-процессов.

Например, ChatGPT может помочь описать процесс оформления перевозки грузов, и при необходимости дополнить его API-методами, если оформление перевозки надо делать во внешней системе.


🤖 Поддержка в написании технической документации

ChatGPT может помочь в создании шаблонов документации, в их наполнении, в разработке руководств пользователя, ТЗ и других видов документов, ускоряя процесс документирования.


Что ещё? 👇

👇 Что еще может ChatGPT 4.0?

🤖Интеграция с другими инструментами

ChatGPT 4.0 может быть интегрирован или использован с различными программными инструментами, включая Postman, Swagger, Confluence и другие.

Он может помогать в написании и проверке спецификаций OpenAPI для API, используя актуальные сведения о лучших практиках и стандартах. А также может писать автотесты на ваш API в Postman.


🤖 Улучшение коммуникаций

Теперь можно зачищать свой текст от сложной терминологии прибегая к помощи Искусственного Интеллекта (ИИ). Раньше приходилось вычитывать и править свои тексты вручную, теперь с этим помогает ChatGPT. Генерация понятных объяснений сложных технических концепций может помочь в коммуникации с не-техническими стейкхолдерами.


🤖 Поддержка в принятии решений
🤖 Обратная связь по работе системы и итеративное улучшение
🤖 Самостоятельное обучение и развитие навыков
🤖 Развитие технического английского
🤖 Голосовой набор текста с зачисткой от “шума” и правками по орфографии


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

Яндекс запустил YandexGPT.

⚡ ИИ - новый инструмент IT-команд, который скоро станет обязательным навыком.


Еще не использовали ChatGPT или не знаете как применять? Пока не понимаете как внедрить его в работу, чтобы использовать эффективно?

На воркшопе передам справочник команд. Покажу ChatGPT и YandexGPT!

🤖 Лайфхаки ChatGPT для аналитиков на практике
⚡ 28 Ноября, ВТ | 19:00 (МСК)
🟢 ЗАПИСАТЬСЯ
Разработка требований. Проектирование БД. Создание UML, ER и BPMN диаграмм. Описание интеграционных сценариев. Шаблоны команд и шаблоны проектной документации.


Это тот самый знак, чтобы не откладывать на потом знакомство с ИИ и его самыми актуальными обновлениями 😎

😱 Требования не реализуемы. Тревога. Или? 😱

Я определила бизнес-цели и задачи GetDelivery. Но теперь надо разобраться с их реализуемостью. Это один из главных подвохов в работе с задачами на интеграцию.

Если кто-то сталкивался при разработке требований с термином “Бизнес-правила и ограничения”, то вот они в натуральном виде, только не про бизнес, а технические.

Я ознакомилась с API-документацией и сделала важные заметки для проекта.

✔️ Мы можем оформить заказ, но оплату доставки каждый сервис реализует по-разному.
✔️ Технически мы не имеем возможности менять статус оплаты заказа на доставку груза самостоятельно.

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


В деталях:


🔹 Деловые Линии

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

Как я увидела из первичного знакомства - в методах API явно нигде не отображается комиссия. А значит получение комиссии за каждый заказ будет регулироваться договором сотрудничества с Деловыми Линиями. Что это для нас значит? Нужно будет сделать админку, через которую владелец GetDelivery сможет смотреть отчетность и в которой нужно будет запрограммировать правила выплат для нас от Деловых Линий.



Продолжение завтра👇

🔹 СДЭК 👇

Тут сложнее. Создания платежа и проведения оплаты нет. Работают с квитанциями, наложенными платежами. Можно получить информацию по чеку, но получения ссылки на платежную форму не вижу по документаци.

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

Пока вижу расхождение с Деловыми линиями по платежам. Т.е. до момента создания заказа у нас сценарии одинаковые, а далее нужно думать как сделать единый сценарий. Это повлияет на бизнес-процесс реализации интеграции систем и вообще на бизнес системы-агрегатора GetDelivery. 🔺

Плюс я заметила методы про вызов курьера. Прям явно в требованиях ТЗ напишу, что для СДЭК это мы поддерживать не будем. А то мало ли?...

🔹 Возовоз

Привет JSON-ы и JavaScript примеры запросов для анализа. Возможность создания заказа есть. Возможность оплаты не вижу. Хотя на тестовом демо-сервере для разработчиков она есть.

Партнерские комиссии опять же могут регулироваться только бизнес-договором. И нужно сообщить заказчику о том, что информация по всем взаиморасчетам и учетам прибыли может быть только на нашей стороне. История повторяется.

Итог этапа анализа и сбора требований 🧐

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

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

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


P.S. Почему в этом проекте нужно строить единый сценарий на интеграцию всех систем? 🔺
У нас система-агрегатор. Это означает, что мы создаем единое окно для пользователей. И для систем агрегаторов порой важно выйти за пределы первичных требований и проанализировать больше подобных систем, чтобы быть готовыми к следующим дополнительным интеграциям, которые в будущем попросит заказчик.


P.P.S. А еще документацию на предмет уведомлений надо проанализировать: где вебхуки, где обновления статуса заказа и как это все внедрить в наш проект.

Чтобы перейти к разработке схемы архитектуры GetDelivery, я должна сформулировать бизнес-требования, функциональные и нефункциональные требования?

Для работы мне достаточно описать основной бизнес-сценарий. Сделаю это я в формате Use Case.

Для примера беру сценарий расчета стоимости доставки. Описывать его буду на бизнес-уровне, без технических деталей, но с упоминанием всех внешних систем, с которыми предстоит интеграция. Часть с созданием заказов и уведомлениями не рассматриваю до открытого вебинара (это намек).

Помощник ChatGPT поможет мне с этим. Ускоряю работу 🙌 Я за ним сделала проверку сделала по логике, правки минимальные:


Название Use Case:
Проверка Стоимости Доставки в Сервисе GetDelivery

Предусловие:
Пользователь открыл веб-приложение GetDelivery и ему требуется информация о наиболее выгодных условиях и стоимости доставки его груза (посылки).

Роли:
- Пользователь: Клиент GetDelivery, который ищет информацию о наиболее выгодной стоимости и условиях доставки. Может быть как с авторизацией в GetDelivery, так и без неё.

Приложения и сервисы GetDelivery:
- Веб-приложение - PWA приложение, адаптированное под мобильные устройства;
- Интеграционный сервис Backend сравнения стоимости: собирает данные из разных внешних систем доставки, предоставляет сравнительную информацию и выделяет наиболее выгодную.

Внешние системы:
- Деловые Линии,
- СДЭК,
- Возовоз.


Входные Данные:
- Параметры доставки (адрес отправки, адрес доставки, вес, объем и т.п.).
- Предпочтения пользователя (скорость доставки, стоимость, дополнительные услуги).
* В реализации UI и логики рекомендуется предусмотреть как можно больше подсказок по автозаполнению на этапе ввода, чтобы повысить удобство работы пользователя с GrtDelivery и добавить ценность.


Ожидаемый Результат:
Пользователь получает сравнительную информацию о стоимости доставки от различных сервисов доставки, полученную по API и обработанную соответствующим интеграционным сервисом Backend GetDelivery.


Основной сценарий скоро появится 👀
🔽🔽🔽