Сценарии в интеграции
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)