Администрирование интеграции
Не совсем #капитаночевидность что интеграцией нужно управлять и после выкатки на продуктив, она становится узким горлышком.
Часто и разработка, и аналитик забывают о том, что нужна возможность изменения настроек. И тогда разработчик становится частью своего продукта. Но и аналитик тоже может стать "частью команды, частью корабля". У нас был такой случай, мы узнали, что интеграция работает только в купе с аналитиком, тогда, когда он ушёл в отпуск и всё упало.
Так что принцип "сделать так, чтобы ко мне мало прибегали с вопросами" очень мотивирует.
Тех поддержка в таких случаях разводит руками. Потому что им не сделали инструменты управления. Не сделали, вот мы и не можем передать целые куски в поддержку.
Что делать?
✅ Рассматривать тех поддержку, администраторов системы, как полноценных заказчиков. Им поддерживать решение и они должны получать конкретные инструкции. И в интересах команды, всё сделать так, чтобы к ним не бегали по каждому чиху.
✅ Аналитик может просчитать на несколько шагов вперёд, как будет развиваться бизнес. И именно эти точки развития заложить в реализацию.
Какие могут быть параметры настроек?
Например, типичные и часто встречающиеся:
➡️ - тайм зона, бизнес любит расширять свои границы на разные регионы, даже если не сразу говорит, но захватить мир все хотят,
➡️ - включение, отключение целых блоков бизнес-процессов, есть такие моменты, что вот мы сомневаемся, сегодня надо, а завтра нет, лучше добавить и сделать возможность отключения по настройкам,
➡️ - разные форматы данных, например, что-то нужно настроить по умолчанию, или правила валидации, регулярные выражения, шаблоны вывода и т.п.
➡️ - настройки связанные с обработкой ошибок, нужно ли включать повторные вызовы, если была ошибка, сколько раз, за какой период,
➡️ - уровни логирования данных (может быть встроенная функциональность разных платформ, а может быть своя логика),
➡️ - квотирование, есть платные сервисы и каждый их вызов это деньги, а если вы ещё делаете механизм повторных отправок, можно попасть на бабло, так что лучше сразу задуматься как этим управлять и, например, переключать функционал с платного на бесплатный, некоторые государственные сервисы не очень любят, когда их бомбят запросами и тоже могут ввести квоту на количество обращений в день.
Как-то мне аналитик, сказал, вот ты топишь за настройки, а у нас их было так много, что мы запутались.
⚡️ Ну во-первых, можно делать значения по умолчанию, и не трогать ружье, которое висит на стене, но раз в год выстрелит.
⚡️ А во вторых, можно сделать нормальные человекочитаемые названия, и внятное описание и согласовать с администраторами и тех поддержкой, и дать инструкцию, продумать использование этих самых настроек.
Конечно, я могла что-то забыть, и полно все детали в пост не впихнуть, но с думаю мой посыл понятен.
В интеграции много подобных не очевидных нюансов, если хочется глубже в них разбираться приходи на наш курс интеграции, совсем скоро старт потока (16 ноября), и что-то мне подсказывает, что с нового года будет повышение цены.
Запрыгнуть в нашу уютную группу можно оставив заявку на сайте➡️ https://sup.expert/
#интеграция #администрирование #настройки #выводы
Не совсем #капитаночевидность что интеграцией нужно управлять и после выкатки на продуктив, она становится узким горлышком.
Часто и разработка, и аналитик забывают о том, что нужна возможность изменения настроек. И тогда разработчик становится частью своего продукта. Но и аналитик тоже может стать "частью команды, частью корабля". У нас был такой случай, мы узнали, что интеграция работает только в купе с аналитиком, тогда, когда он ушёл в отпуск и всё упало.
Так что принцип "сделать так, чтобы ко мне мало прибегали с вопросами" очень мотивирует.
Тех поддержка в таких случаях разводит руками. Потому что им не сделали инструменты управления. Не сделали, вот мы и не можем передать целые куски в поддержку.
Что делать?
✅ Рассматривать тех поддержку, администраторов системы, как полноценных заказчиков. Им поддерживать решение и они должны получать конкретные инструкции. И в интересах команды, всё сделать так, чтобы к ним не бегали по каждому чиху.
✅ Аналитик может просчитать на несколько шагов вперёд, как будет развиваться бизнес. И именно эти точки развития заложить в реализацию.
Какие могут быть параметры настроек?
Например, типичные и часто встречающиеся:
Как-то мне аналитик, сказал, вот ты топишь за настройки, а у нас их было так много, что мы запутались.
Конечно, я могла что-то забыть, и полно все детали в пост не впихнуть, но с думаю мой посыл понятен.
В интеграции много подобных не очевидных нюансов, если хочется глубже в них разбираться приходи на наш курс интеграции, совсем скоро старт потока (16 ноября), и что-то мне подсказывает, что с нового года будет повышение цены.
Запрыгнуть в нашу уютную группу можно оставив заявку на сайте
#интеграция #администрирование #настройки #выводы
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
Квотирование в интеграции, что это такое и зачем нужно?
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Реальные результаты наших участников курса интеграции.
В большинстве своём на курс приходят ребята, кто был у меня на менторстве, оно и понятно, но и не только! У каждого свои цели. И вот немного классифицирую, по грейдам, кто что уносит и использует на практике:
1.Начну с джунов или тех кто хочет стать системным аналитиком. Очень сложно бывает показать, что именно нужно специалисту для прокачки. Курс интеграции, как курс молодого бойца показывает систему знаний, инструментов, подходов и практик. Что хорошо, мы полностью проходим по пирамиде артефактов и доходим до уровня технологий, данных. Я не хочу давать обещания, которые считаю нереальными. Но то, что джун поймёт, куда ему дальше и что такое системный анализ это точно.
2.По результатам курса можно написать свой собственный план развития, и взять за основу те ссылки, те внешние источники, книги которые мы рекомендуем, и на которые опираемся.
3.Миддл аналитики обретают уверенность! Это очень важно. Они могут чего-то не знать, но понимать объем, границы задачи и чувствовать себя увереннее. Понимают, куда смотреть, что делать.
4.Как так уже давно получилось, что я стала для многих "карьерной феей"))) Ребята после работы со мной идут дальше, есть даже те кто вырос в айти директора, кто-то в архитектора, тим лида. И вот по результатам наших даже двух потоков курса, много кто сменил работу! Пошёл выше по грейдам, прибавил в деньгах. Как говорит Андрей Корниенко, у аналитиков открылись глаза и поняли, что именно они должны делать, отсюда уверенность, энергия перемен и попытка дальше себя развивать, для этого меняют среду. Мы ничего специально не делаем, так получается))) А то компании, чего неладное подумают))
5.Многие отмечали такой факт, что стали увереннее на собеседованиях и смогли ответить на каверзные вопросы. Или честно сказать, что они и в каком объёме могут сделать.
Так что не хочу обещать вам успешный успех, скажу лишь только одно - вы сможете унести столько сколько можете на текущий момент. Есть у нас такие прецеденты, когда участник курса пересмотрел его заново в записи, и вынес новое, чего за первый заход в упор не понимал. Это было любопытно и радостно))
Видео запись и материалы остаются навсегда, как и возможность общения со мной и моим компаньоном. Андрей Корниенко помогает мне на курсе в части технологий, взглядом разработчика и архитектора, что очень важно в работе аналитика.
Приглашаю вас присоединиться к группе, старт уже завтра! В новый год вы вступите с новыми знаниями))
#системныйанализ #курс #курсинтеграции #анонс #результатыучастников #интеграция
Остались вопросы, пишите мне‼️
В большинстве своём на курс приходят ребята, кто был у меня на менторстве, оно и понятно, но и не только! У каждого свои цели. И вот немного классифицирую, по грейдам, кто что уносит и использует на практике:
1.Начну с джунов или тех кто хочет стать системным аналитиком. Очень сложно бывает показать, что именно нужно специалисту для прокачки. Курс интеграции, как курс молодого бойца показывает систему знаний, инструментов, подходов и практик. Что хорошо, мы полностью проходим по пирамиде артефактов и доходим до уровня технологий, данных. Я не хочу давать обещания, которые считаю нереальными. Но то, что джун поймёт, куда ему дальше и что такое системный анализ это точно.
2.По результатам курса можно написать свой собственный план развития, и взять за основу те ссылки, те внешние источники, книги которые мы рекомендуем, и на которые опираемся.
3.Миддл аналитики обретают уверенность! Это очень важно. Они могут чего-то не знать, но понимать объем, границы задачи и чувствовать себя увереннее. Понимают, куда смотреть, что делать.
4.Как так уже давно получилось, что я стала для многих "карьерной феей"))) Ребята после работы со мной идут дальше, есть даже те кто вырос в айти директора, кто-то в архитектора, тим лида. И вот по результатам наших даже двух потоков курса, много кто сменил работу! Пошёл выше по грейдам, прибавил в деньгах. Как говорит Андрей Корниенко, у аналитиков открылись глаза и поняли, что именно они должны делать, отсюда уверенность, энергия перемен и попытка дальше себя развивать, для этого меняют среду. Мы ничего специально не делаем, так получается))) А то компании, чего неладное подумают))
5.Многие отмечали такой факт, что стали увереннее на собеседованиях и смогли ответить на каверзные вопросы. Или честно сказать, что они и в каком объёме могут сделать.
Так что не хочу обещать вам успешный успех, скажу лишь только одно - вы сможете унести столько сколько можете на текущий момент. Есть у нас такие прецеденты, когда участник курса пересмотрел его заново в записи, и вынес новое, чего за первый заход в упор не понимал. Это было любопытно и радостно))
Видео запись и материалы остаются навсегда, как и возможность общения со мной и моим компаньоном. Андрей Корниенко помогает мне на курсе в части технологий, взглядом разработчика и архитектора, что очень важно в работе аналитика.
Приглашаю вас присоединиться к группе, старт уже завтра! В новый год вы вступите с новыми знаниями))
#системныйанализ #курс #курсинтеграции #анонс #результатыучастников #интеграция
Остались вопросы, пишите мне
Please open Telegram to view this post
VIEW IN TELEGRAM
Концептуальное проектирование
Есть две вещи, которые простые, очевидные #капитаночевидность поэтому их мало кто делает.
Первая это Концептуальное проектирование(сюда же DFD отнесу), а второе - это блок-схемы, с помощью которых можно и алгоритм описать и процесс, и сделать это хорошо!
Сегодня решила написать про Концептуальное проектирование.
Что может быть проще - в центр поместить систему, которую мы проектируем, вокруг участников информационного обмена, и стрелками показать направление потоков данных, кто, кому, что передаёт.
Но, в чем трудность?
✅1.Заставить себя мыслить в структуре и разложить по схеме - участники, данные уже не те просто. Скучно, дайте нам сразу строить космический корабль. Чтобы выделить набор данных нужно хорошо понимать, а что мы собственно делаем и промоделировать процессы.
✅2.Если возьмём DFD - да, есть разные нотации, но суть одна и та же, к наших участникам, и данным, добавляется хранение данных. Откуда и куда уходят данные и где остаются.
DFD, концептуальное проектирование заставляет нас думать структурой. И отбрасывать то, что круче, интереснее, можно помоделировать)))
По сути мы наш концепт раскладываем по следующим пунктам:
1.Источник данных
2.Потребитель данных
3.Обработка, работа, логические функции над данными
4.Потоки данных
5.Хранилища данных
И нам неважно, как будет реализована наша концепция, на начальном этапе. Какие технологии передачи данных будут выбраны. Требования ещё не собрали и до структуры хранилищ не добрались, как и до самого кода.
К DFD мы можем подходить, как в слоёному пирогу, как и с ER диаграммами, по этапам:
1.Описать концепцию - участники и потоки данных
2.Добавить логику обработки - получим логический уровень
3.Добавить хранение данных - физический уровень
Но если вы сделаете хотя бы концепцию решения уже станет лучше))) и будут видны участники, системный контекст, границы решения.
Мне нравится статья по этой теме в школе системного анализа и проектирования.
Рекомендую к применению на проектах)
#интеграция #концепция #dfd #системныйаналитик #системныйанализ #системныйконтекст
Есть две вещи, которые простые, очевидные #капитаночевидность поэтому их мало кто делает.
Первая это Концептуальное проектирование
Сегодня решила написать про Концептуальное проектирование.
Что может быть проще - в центр поместить систему, которую мы проектируем, вокруг участников информационного обмена, и стрелками показать направление потоков данных, кто, кому, что передаёт.
Но, в чем трудность?
✅1.Заставить себя мыслить в структуре и разложить по схеме - участники, данные уже не те просто. Скучно, дайте нам сразу строить космический корабль. Чтобы выделить набор данных нужно хорошо понимать, а что мы собственно делаем и промоделировать процессы.
✅2.Если возьмём DFD - да, есть разные нотации, но суть одна и та же, к наших участникам, и данным, добавляется хранение данных. Откуда и куда уходят данные и где остаются.
DFD, концептуальное проектирование заставляет нас думать структурой. И отбрасывать то, что круче, интереснее, можно помоделировать)))
По сути мы наш концепт раскладываем по следующим пунктам:
1.Источник данных
2.Потребитель данных
3.Обработка, работа, логические функции над данными
4.Потоки данных
5.Хранилища данных
И нам неважно, как будет реализована наша концепция, на начальном этапе. Какие технологии передачи данных будут выбраны. Требования ещё не собрали и до структуры хранилищ не добрались, как и до самого кода.
К DFD мы можем подходить, как в слоёному пирогу, как и с ER диаграммами, по этапам:
1.Описать концепцию - участники и потоки данных
2.Добавить логику обработки - получим логический уровень
3.Добавить хранение данных - физический уровень
Но если вы сделаете хотя бы концепцию решения уже станет лучше))) и будут видны участники, системный контекст, границы решения.
Мне нравится статья по этой теме в школе системного анализа и проектирования.
Рекомендую к применению на проектах)
#интеграция #концепция #dfd #системныйаналитик #системныйанализ #системныйконтекст
Записала разбор sequence диаграммы.
Примем тот факт, что автор, никогда не делала раньше sequence диаграмм.
Будет полезно для начинающих и не только. Вдруг ещё что-то заметите, что бы можно было улучшить?)
#sequence #uml #системныйанализ #системныйаналитик #интеграция #разбор
https://youtu.be/JiJDt-jWFtY
Примем тот факт, что автор, никогда не делала раньше sequence диаграмм.
Будет полезно для начинающих и не только. Вдруг ещё что-то заметите, что бы можно было улучшить?)
#sequence #uml #системныйанализ #системныйаналитик #интеграция #разбор
https://youtu.be/JiJDt-jWFtY
YouTube
Разбор диаграммы последовательностей (sequence, UML) с проекта
Разбираю ошибки примера диаграммы последовательности (sequence, UML). Диаграмму предоставила подписчица.
Хотите больше узнать про системный анализ и работу аналитиков в айти? Подписывайтесь на мой телеграм канал - https://t.me/start_in_IT
Хотите, чтобы…
Хотите больше узнать про системный анализ и работу аналитиков в айти? Подписывайтесь на мой телеграм канал - https://t.me/start_in_IT
Хотите, чтобы…
Сначала вы работаете на интеграцию, потом интеграция работает на вас.
Забавно, то, что моя карьера системного аналитика в 2006 году началась с интеграции, и кто бы мог подумать, что я буду учить проектированию интеграций) И интеграции никуда не исчезает за эти годы!
Уже много мной накоплено опыта, и кажется, что про интеграцию сказано всё!
Но так ли оно?
----------------
Поэтому на ближайшие две недели, в рамках своего блога, я объявляю себе челлендж по мини-интеграции, чтобы:
♟Получить чёткий roadmap, как действовать, когда прилетела задача на интеграцию и нужно сесть и написать ТЗ.
♟ Поискать инсайты и новую информацию, чего возможно я, как тренер, ментор, упускаю в системном подходе к проектированию интеграции. И довыявить точки расширения roadmap.
----------------
Не знаю, к чему меня приведёт этот челлендж, но мне интересно, снова систематизировать подходы к проектированию.
Некоторые наши ученики-аналитики говорят, что мы с Андреем Корниенко учим не просто интеграции, а системному анализу через интеграцию.
И нам хочется создать новый продукт, который был бы доступен всем и имел сжатый формат, который бы отвечал аналитику на комплекс его основных вопросов.
----------------
У каждого аналитика могут быть свои цели, например (как их вижу я):
Junior - хочет получить волшебную таблетку, чтобы дали готовые шаблоны, чек-листы, roadmap, чтобы увереннее действовать и решать поставленные задачи.
Middle - хочет расширить свои знания, навыки и опыт, чтобы брать в работу сложные задачи, с запутанной логикой.
Senior - хочет систематизировать свои знания и понять, что не видно, о чем забыл и на что стоит обратить внимание, чтобы повысить свою компетенцию.
Team Lead - хочет грамотно делегировать задачи их декомпозировать, отдавать команде и получать сисиемный хороший результат.
----------------
Вы можете мне дописать свои цели ниже в комментариях, которые вы ждёте от интеграции, и в какую область мне ещё посмотреть.
Ух, ну что ж! Погнали! 🚀
#интеграция #челлендж #проектирование #боли #миниинтеграция
Забавно, то, что моя карьера системного аналитика в 2006 году началась с интеграции, и кто бы мог подумать, что я буду учить проектированию интеграций) И интеграции никуда не исчезает за эти годы!
Уже много мной накоплено опыта, и кажется, что про интеграцию сказано всё!
Но так ли оно?
----------------
Поэтому на ближайшие две недели, в рамках своего блога, я объявляю себе челлендж по мини-интеграции, чтобы:
♟Получить чёткий roadmap, как действовать, когда прилетела задача на интеграцию и нужно сесть и написать ТЗ.
----------------
Не знаю, к чему меня приведёт этот челлендж, но мне интересно, снова систематизировать подходы к проектированию.
Некоторые наши ученики-аналитики говорят, что мы с Андреем Корниенко учим не просто интеграции, а системному анализу через интеграцию.
И нам хочется создать новый продукт, который был бы доступен всем и имел сжатый формат, который бы отвечал аналитику на комплекс его основных вопросов.
----------------
У каждого аналитика могут быть свои цели, например (как их вижу я):
Junior - хочет получить волшебную таблетку, чтобы дали готовые шаблоны, чек-листы, roadmap, чтобы увереннее действовать и решать поставленные задачи.
Middle - хочет расширить свои знания, навыки и опыт, чтобы брать в работу сложные задачи, с запутанной логикой.
Senior - хочет систематизировать свои знания и понять, что не видно, о чем забыл и на что стоит обратить внимание, чтобы повысить свою компетенцию.
Team Lead - хочет грамотно делегировать задачи их декомпозировать, отдавать команде и получать сисиемный хороший результат.
----------------
Вы можете мне дописать свои цели ниже в комментариях, которые вы ждёте от интеграции, и в какую область мне ещё посмотреть.
Ух, ну что ж! Погнали! 🚀
#интеграция #челлендж #проектирование #боли #миниинтеграция
Please open Telegram to view this post
VIEW IN TELEGRAM
Моё лицо выглядит примерно вот так, когда мне говорят - нам нужно ТЗ на интеграцию!
Блин это долго, тяжело, и хочется закричать - не хочу!! Не надо!
А всё потому что на старте, у нас высокая неопределённость. А аналитик думает категорией - "завтра в бой, так, мне нужно sequence, rest api, безопасность, нфт... Блин ещё swagger руками потрогать... А вдруг я что-то забуду?" 🤯
А ещё лучше, когда что-то прилетает, из серии - "я это не знаю"!
И вот я уже вижу, как потихоньку, легко, но верно, я начинаю падать в грязь лицом...
А ещё сверху приправим соусом "ты же специалист, тебе виднее, мы знаем, что ты можешь... ждём ТЗ..."
Вот в такой ситуации, я могу говорить, ребята, возьмите С4, или Uml и ещё 100500 разных подходов. Но лучше выдохнуть, сделать шаг назад, и начать с любой схемы! Нет вы не ослышались, любая диаграмма, картинка, визуализация подойдёт. Упрощайте!
Не нужно мучить себя нотациями, правилами, инструментами, вам нужно понять, а что собственно происходит?
Нарисуйте всё что знаете по задаче, даже если это будут 2 квадратика и стрелочка между ними со словом интеграция.
На днях на менторской сессии, я открыла диаграмму с одного своего проекта, и поняла, что это смесь DFD, Component и даже Deployment diagram. А цель моя была понять объем задачи, получилось? Да! Все красные стрелочки - это объем.
Я часто рассказываю, что когда мне присылают описание API, я просто схематично рисую диаграмму и называю "точки интеграции", визуализирую вызовы, их набор, направление, логику, последовательность.
А самое сокровенное, что я хочу сказать, прикиньте эту диаграмму можно никому не показывать)))
Так что, получая новую задачу по интеграции:
✅Не требуйте от себя быстрого крутого, финального результата
✅Рисуйте визуализацию задачи
✅Начинайте с концептуального или бизнес-уровня
✅Если вы перечислите, хотя бы участников и красными стрелочками покажите, то что нужно разработать, это уже круто!
✅Просто начните, вы уже можете объяснить себе, о чем идёт речь?)
#капитаночевидность
#интеграция #челлендж #мойопыт
Блин это долго, тяжело, и хочется закричать - не хочу!! Не надо!
А всё потому что на старте, у нас высокая неопределённость. А аналитик думает категорией - "завтра в бой, так, мне нужно sequence, rest api, безопасность, нфт... Блин ещё swagger руками потрогать... А вдруг я что-то забуду?" 🤯
А ещё лучше, когда что-то прилетает, из серии - "я это не знаю"!
И вот я уже вижу, как потихоньку, легко, но верно, я начинаю падать в грязь лицом...
А ещё сверху приправим соусом "ты же специалист, тебе виднее, мы знаем, что ты можешь... ждём ТЗ..."
Вот в такой ситуации, я могу говорить, ребята, возьмите С4, или Uml и ещё 100500 разных подходов. Но лучше выдохнуть, сделать шаг назад, и начать с любой схемы! Нет вы не ослышались, любая диаграмма, картинка, визуализация подойдёт. Упрощайте!
Не нужно мучить себя нотациями, правилами, инструментами, вам нужно понять, а что собственно происходит?
Нарисуйте всё что знаете по задаче, даже если это будут 2 квадратика и стрелочка между ними со словом интеграция.
На днях на менторской сессии, я открыла диаграмму с одного своего проекта, и поняла, что это смесь DFD, Component и даже Deployment diagram. А цель моя была понять объем задачи, получилось? Да! Все красные стрелочки - это объем.
Я часто рассказываю, что когда мне присылают описание API, я просто схематично рисую диаграмму и называю "точки интеграции", визуализирую вызовы, их набор, направление, логику, последовательность.
А самое сокровенное, что я хочу сказать, прикиньте эту диаграмму можно никому не показывать)))
Так что, получая новую задачу по интеграции:
✅Не требуйте от себя быстрого крутого, финального результата
✅Рисуйте визуализацию задачи
✅Начинайте с концептуального или бизнес-уровня
✅Если вы перечислите, хотя бы участников и красными стрелочками покажите, то что нужно разработать, это уже круто!
✅Просто начните, вы уже можете объяснить себе, о чем идёт речь?)
#капитаночевидность
#интеграция #челлендж #мойопыт
Как оценить задачу?
Можно смотреть на формулы, уходить в глубину и сложность задачи. Но когда это всё недоступно, или нет опыта, а ответ нужен здесь и сейчас. Просто делаю задачу-шаблон, считаю время и получается некий эталон, на который можно уже накинуть погрешность в несколько дней и дать оценку.
Когда-то так и произошло.
Типичный бизнес любит находу принять решение и щёлкнуть пальцами. Хочу!! Вчера!!
И вот прибегает ко мне чайка менеджер и говорит - срочно нужна интеграция с регионом! Задача первого, высшего, максимального приоритета! Ааааа! Сколько, сколько, сколько? Тебе нужно времени?
Когда меня спрашивают сколько нужно на разработку большой системы с нуля, я всегда говорю полгода. Руководство конечно возмущается, много! Скашивает до 3 месяцев, а в результате полгода...
Но тут была другая история.
Сразу скажу про исходные данные:
✅ Я хорошо знала бизнес.
✅ Я глубоко понимала как работает сфера.
✅ У меня уже был опыт подобных интеграций.
Я сказала месяц.
Отдать должное менеджеру, он сказал времени нет, ТЗ нужно срочно. И что можно сделать для ускорения? Ай зараза....
Я перечислила:
👉получить актуальное описание,
👉тестовый стенд,
👉тестовые данные,
👉контактное лицо, кто ответит на все мои вопросы,
👉понять кто принимает решение на доработку с их стороны, чтобы не тормозили.
И мы решили, что поедем в командировку к нашему партнёру. Нам нужно реализовать использование SOAP API у себя, и понять, все ли данные нужные нам есть, а что должен разработать компаньон.
И вот мы сели в поезд. В гостинице я распечатала описание, вечерком выделила фломастером, всё что мне было непонятно, написала список вопросов. И даже какие-то первые черновые варианты интеграции прикинула.
На следующий день у нас произошла встреча с командой партнёра, я смогла оперативно задать все вопросы, соединить наших разработчиков и разработчиков партнёра. Айти директор компании партнёра посмотрел на нас, обсудили договор, пришли к согласию. Переговоры сначала шли тяжело, но потом пошли в сторону поиска точек соприкосновения. И в итоге мы чётко зафиксировали, что делаем мы, что они и что нам нужно. Я написала отчёт о встрече! Не принебрегайте им!
Все довольны, мы устали часов 6 переговоров... Временами жёстких...
И вот мы уже вечером сидим в поезде обратно в Москву, и молчим...
По приезду, я запираюсь в комнате, ни с кем не общаюсь и с утра до вечера пишу ТЗ.
Забег с командировкой и написанием низкогоуровневого ТЗ с объёмом на 5-6 интеграционных сценариев у меня занял 4 дня.
4 дня это эталон надрывной работы над задачей.
Больше мне не хотелось такого надрыва, да и не всегда партнёр действительно может оперативно принять решения.
После этой истории, на вопрос, сколько тебе нужно времени на ТЗ по интеграции я всегда говорила - месяц!)))
#челлендж #интеграция #оценкаинтеграции #мойопыт
Можно смотреть на формулы, уходить в глубину и сложность задачи. Но когда это всё недоступно, или нет опыта, а ответ нужен здесь и сейчас. Просто делаю задачу-шаблон, считаю время и получается некий эталон, на который можно уже накинуть погрешность в несколько дней и дать оценку.
Когда-то так и произошло.
Типичный бизнес любит находу принять решение и щёлкнуть пальцами. Хочу!! Вчера!!
И вот прибегает ко мне чайка менеджер и говорит - срочно нужна интеграция с регионом! Задача первого, высшего, максимального приоритета! Ааааа! Сколько, сколько, сколько? Тебе нужно времени?
Когда меня спрашивают сколько нужно на разработку большой системы с нуля, я всегда говорю полгода. Руководство конечно возмущается, много! Скашивает до 3 месяцев, а в результате полгода...
Но тут была другая история.
Сразу скажу про исходные данные:
✅ Я хорошо знала бизнес.
✅ Я глубоко понимала как работает сфера.
✅ У меня уже был опыт подобных интеграций.
Я сказала месяц.
Отдать должное менеджеру, он сказал времени нет, ТЗ нужно срочно. И что можно сделать для ускорения? Ай зараза....
Я перечислила:
👉получить актуальное описание,
👉тестовый стенд,
👉тестовые данные,
👉контактное лицо, кто ответит на все мои вопросы,
👉понять кто принимает решение на доработку с их стороны, чтобы не тормозили.
И мы решили, что поедем в командировку к нашему партнёру. Нам нужно реализовать использование SOAP API у себя, и понять, все ли данные нужные нам есть, а что должен разработать компаньон.
И вот мы сели в поезд. В гостинице я распечатала описание, вечерком выделила фломастером, всё что мне было непонятно, написала список вопросов. И даже какие-то первые черновые варианты интеграции прикинула.
На следующий день у нас произошла встреча с командой партнёра, я смогла оперативно задать все вопросы, соединить наших разработчиков и разработчиков партнёра. Айти директор компании партнёра посмотрел на нас, обсудили договор, пришли к согласию. Переговоры сначала шли тяжело, но потом пошли в сторону поиска точек соприкосновения. И в итоге мы чётко зафиксировали, что делаем мы, что они и что нам нужно. Я написала отчёт о встрече! Не принебрегайте им!
Все довольны, мы устали часов 6 переговоров... Временами жёстких...
И вот мы уже вечером сидим в поезде обратно в Москву, и молчим...
По приезду, я запираюсь в комнате, ни с кем не общаюсь и с утра до вечера пишу ТЗ.
Забег с командировкой и написанием низкогоуровневого ТЗ с объёмом на 5-6 интеграционных сценариев у меня занял 4 дня.
4 дня это эталон надрывной работы над задачей.
Больше мне не хотелось такого надрыва, да и не всегда партнёр действительно может оперативно принять решения.
После этой истории, на вопрос, сколько тебе нужно времени на ТЗ по интеграции я всегда говорила - месяц!)))
#челлендж #интеграция #оценкаинтеграции #мойопыт
Сценарии в интеграции
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
ООП - объектно-ориентированный подход к программированию.
Я часто говорю о том, что ООП аналитику нужно знать, ибо именно при таком подходе в разработке, часто и нужен аналитик. Чтобы спроектировать решение.
Возвращаясь к теме интеграции, скажу, что ООП ключевая вещь.
✅Аналитику нужно понимать, какая предметная область лежит в основе решения.
✅Какие объекты предметной области участвуют в процессах (в интеграционных сценариях).
✅И как собственно интеграция влияет на жизненный путь объекта. Как из одного статуса объект переходит в другой, и что при этом происходит.
Например, у нас есть с вами предметная область - ритейл. То есть создаётся корзина, в соответствии с ней заказ, заказ оплачивается, и после оплаты происходит его сборка на складе и отгрузка в доставку.
Рассказывая, что происходит и над какими объектами, мы с вами можем выделить как раз ключевые бизнес объекты, и их статусы.
И как часто бывает, если потянуть за веревочку, мы целый клубок всего находим, где нам нужно понимание ООП:
♟1.Объекты предметной области и связи между ними
♟2.Структура объектов, иерархия данных
♟3.Жизненный цикл ключевых объектов предметной области
♟4.Операции над объектами (основа для API).
И в итоге мы с вами получаем целый пласт информации, которая нам необходима, чтобы в конечном приближение указать детали - доступные операции над структурой объектов, выполняя которые, объекты меняют статусы в соответствии со своим жизненным циклом.
И мы с вами по статусу объекта сможем понять, на каком этапе обработки он находится. Например, заказ собран уже на складе и готов к отгрузке на доставку.
Очень часто, аналитики в задачах интеграции принебрегают анализом таких артефактов, как онтологическая модель предметной области (можно также брать ER - диаграмму или диаграмму классов), диаграмма статусов (state machine) + правила перехода из статуса статус.
Не стоит забывать, что ООП - это один из способов упрощения работы с данными. Когда сложные структуры мы укладываем в объекты, и определяем связи между объектами, и описываем операции над ними, исходя из процессов, в которых участвуют объекты.
По сути ООП - это способ представления нашего реального мира в виртуальном, мы делаем проекцию, таким способом автоматизирую сложные операции реальных процессов.
#челлендж #интеграция #ооп
Так что не стоит забывать про платформу знаний, которая вам необходима, чтобы написать идеальное ТЗ на интеграцию - это ООП.
Я часто говорю о том, что ООП аналитику нужно знать, ибо именно при таком подходе в разработке, часто и нужен аналитик. Чтобы спроектировать решение.
Возвращаясь к теме интеграции, скажу, что ООП ключевая вещь.
✅Аналитику нужно понимать, какая предметная область лежит в основе решения.
✅Какие объекты предметной области участвуют в процессах (в интеграционных сценариях).
✅И как собственно интеграция влияет на жизненный путь объекта. Как из одного статуса объект переходит в другой, и что при этом происходит.
Например, у нас есть с вами предметная область - ритейл. То есть создаётся корзина, в соответствии с ней заказ, заказ оплачивается, и после оплаты происходит его сборка на складе и отгрузка в доставку.
Рассказывая, что происходит и над какими объектами, мы с вами можем выделить как раз ключевые бизнес объекты, и их статусы.
И как часто бывает, если потянуть за веревочку, мы целый клубок всего находим, где нам нужно понимание ООП:
♟1.Объекты предметной области и связи между ними
♟2.Структура объектов, иерархия данных
♟3.Жизненный цикл ключевых объектов предметной области
♟4.Операции над объектами (основа для API).
И в итоге мы с вами получаем целый пласт информации, которая нам необходима, чтобы в конечном приближение указать детали - доступные операции над структурой объектов, выполняя которые, объекты меняют статусы в соответствии со своим жизненным циклом.
И мы с вами по статусу объекта сможем понять, на каком этапе обработки он находится. Например, заказ собран уже на складе и готов к отгрузке на доставку.
Очень часто, аналитики в задачах интеграции принебрегают анализом таких артефактов, как онтологическая модель предметной области (можно также брать ER - диаграмму или диаграмму классов), диаграмма статусов (state machine) + правила перехода из статуса статус.
Не стоит забывать, что ООП - это один из способов упрощения работы с данными. Когда сложные структуры мы укладываем в объекты, и определяем связи между объектами, и описываем операции над ними, исходя из процессов, в которых участвуют объекты.
По сути ООП - это способ представления нашего реального мира в виртуальном, мы делаем проекцию, таким способом автоматизирую сложные операции реальных процессов.
#челлендж #интеграция #ооп
Так что не стоит забывать про платформу знаний, которая вам необходима, чтобы написать идеальное ТЗ на интеграцию - это ООП.
Паттерны интеграций (технологии передачи данных)
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии
Обожаю работать с аналитиками))
Мало того, что аналитик это специалист, который постоянно ищет противоречия, выстраивает логику, делает выводы, но ещё и обладает профессиональным чутьем, где собака зарыта.
От аналитиков всегда прилетают глубокие вопросы. И это действительно здорово!) Потому что не всё видно с первого раза. Плюс я сама расту за счёт такой обратной связи, и мотивация есть двигаться дальше.
-----------------------
За годы работы в качестве тренера, ментора, преподавателя, у меня сложился свой🔝 правил, которые помогают мне определить идеального клиента-аналитика:
⏺ Я не люблю слово преподаватель, потому что оно сразу показывает некую позицию, я вам сейчас преподам. Я люблю работать с аналитиками с позицией "на равных", взрослый - взрослый. Менторская позиция. Мы одинаковые, я просто расскажу своё мнение и способ, как я вижу можно решить твой запрос. Но за тобой всегда своё собственное мнение, что и как делать. Прислушиваться или нет. Именно взрослый человек принимает свои решения и управляет своей жизнью.
⏺ Также я стараюсь выстраивать общение с позиции "со мной всё в порядке", "с тобой всё в порядке". Если человек пришёл учиться или получить от меня комментарии, то это уже стрессовая позиция, не вижу смысла её усугублять и пытаться потешить своё эго.Мест для выпендивания можно найти дофига других)))
⏺ Также не работаю по принципу no pain, no gain. Так много этого надрыва вокруг, критики и давления, что не вижу в таком подходе ничего хорошего, особенно когда говорим про игру вдолгую.
⏺ Конечно круто, когда человек приходит с чётким запросом, знает чего хочет и понимает адекватность своего запроса.Сделай с нуля из меня тим лида, чтобы я зарабатывал полляма и ничего не делал, это не ко мне))
⏺ Умеет и готов работать, плюс создаёт для себя условия успеха, в виде регулярности, дисциплины. Причём дисциплина тут это не хлыст сверху, а неотъемлемая часть жизни. Потому что рутина даёт результат. Но и совсем уж расслабиться и ничего не делать это не про аналитиков))) Ребята аналитики выстраивают себе систему и именно эта система, регулярность, целенаправленность и даёт результат. Я некоторые ещё те ломовые лошади!)
⏺ Конечно приятно работать с людьми с опытом, в том числе и жизненным. Потому что я скорее работаю, как ускоритель той базы которая уже есть. Создавать базу с нуля сложно, и пока я за такое не берусь.
⏺ Взаимодействие строиться на доверие. Ибо нет смысла идти к специалисту, который тебе не нравится, ментально в том числе. Искать когда будет провал или какой либо подвох.
⏺ Границы ответственности. Мне не интересно делать за кого-то его работу, мне интересно видеть прогресс. Переложить с больной головы на здоровую прекрасно, но вам то, что с этого?
-----------------------
Есть такое понятие сложный клиент, вот я бы скорее сказала, что клиент есть клиент, и он может быть не ваш, либо вы не можете найти подход и общий язык. Да, есть и такие, кто будет хлопать дверью, кричать. Это нормально, все мы разные и хотим разного)))
Комфортное открытое пространство общения, где можно задавать вопросы и обсуждать все свои проблемы, вот к чему я всегда стремлюсь. Конечно у меня нет нимба над головой и я тоже могу и уставать, и какой-то бред ляпнуть, но возвращаемся к пункту, взрослый - взрослый. Взрослый принимает свои ошибки и их исправляет.
Вот именно за таким общением я вас и приглашаю в нашу 🔥 мощную команду февральского потока интеграции. Уже много интересных ребят с разных компаний придёт))
Будет мощно, жарко и всем придётся поработать! Но есть ради чего стараться!
А мы с Андреем постараемся сработать ускорителями вашего профессионального роста😎
#интеграция #челлендж #топ #клиенты
Мало того, что аналитик это специалист, который постоянно ищет противоречия, выстраивает логику, делает выводы, но ещё и обладает профессиональным чутьем, где собака зарыта.
От аналитиков всегда прилетают глубокие вопросы. И это действительно здорово!) Потому что не всё видно с первого раза. Плюс я сама расту за счёт такой обратной связи, и мотивация есть двигаться дальше.
-----------------------
За годы работы в качестве тренера, ментора, преподавателя, у меня сложился свой
⏺ Я не люблю слово преподаватель, потому что оно сразу показывает некую позицию, я вам сейчас преподам. Я люблю работать с аналитиками с позицией "на равных", взрослый - взрослый. Менторская позиция. Мы одинаковые, я просто расскажу своё мнение и способ, как я вижу можно решить твой запрос. Но за тобой всегда своё собственное мнение, что и как делать. Прислушиваться или нет. Именно взрослый человек принимает свои решения и управляет своей жизнью.
⏺ Также я стараюсь выстраивать общение с позиции "со мной всё в порядке", "с тобой всё в порядке". Если человек пришёл учиться или получить от меня комментарии, то это уже стрессовая позиция, не вижу смысла её усугублять и пытаться потешить своё эго.
⏺ Также не работаю по принципу no pain, no gain. Так много этого надрыва вокруг, критики и давления, что не вижу в таком подходе ничего хорошего, особенно когда говорим про игру вдолгую.
⏺ Конечно круто, когда человек приходит с чётким запросом, знает чего хочет и понимает адекватность своего запроса.
⏺ Умеет и готов работать, плюс создаёт для себя условия успеха, в виде регулярности, дисциплины. Причём дисциплина тут это не хлыст сверху, а неотъемлемая часть жизни. Потому что рутина даёт результат. Но и совсем уж расслабиться и ничего не делать это не про аналитиков))) Ребята аналитики выстраивают себе систему и именно эта система, регулярность, целенаправленность и даёт результат. Я некоторые ещё те ломовые лошади!)
⏺ Конечно приятно работать с людьми с опытом, в том числе и жизненным. Потому что я скорее работаю, как ускоритель той базы которая уже есть. Создавать базу с нуля сложно, и пока я за такое не берусь.
⏺ Взаимодействие строиться на доверие. Ибо нет смысла идти к специалисту, который тебе не нравится, ментально в том числе. Искать когда будет провал или какой либо подвох.
⏺ Границы ответственности. Мне не интересно делать за кого-то его работу, мне интересно видеть прогресс. Переложить с больной головы на здоровую прекрасно, но вам то, что с этого?
-----------------------
Есть такое понятие сложный клиент, вот я бы скорее сказала, что клиент есть клиент, и он может быть не ваш, либо вы не можете найти подход и общий язык. Да, есть и такие, кто будет хлопать дверью, кричать. Это нормально, все мы разные и хотим разного)))
Комфортное открытое пространство общения, где можно задавать вопросы и обсуждать все свои проблемы, вот к чему я всегда стремлюсь. Конечно у меня нет нимба над головой и я тоже могу и уставать, и какой-то бред ляпнуть, но возвращаемся к пункту, взрослый - взрослый. Взрослый принимает свои ошибки и их исправляет.
Вот именно за таким общением я вас и приглашаю в нашу 🔥 мощную команду февральского потока интеграции. Уже много интересных ребят с разных компаний придёт))
Будет мощно, жарко и всем придётся поработать! Но есть ради чего стараться!
А мы с Андреем постараемся сработать ускорителями вашего профессионального роста
#интеграция #челлендж #топ #клиенты
Please open Telegram to view this post
VIEW IN TELEGRAM
Как выбрать решение по интеграции?
Частый и любимый вопрос от аналитика.
И он понятен! Архитекторы, разработчики закатывают глаза вверх и отвечают, что-то типа дружок не заходи на мою территориюподвинься щенок, не задавай мне такие вопросы
И когда ты раз получил негатив, два получил негатив, уже в следующий раз не будешь спрашивать, но и чувствовать себя на обочине жизни не хочется. Все там в замесе участвуют, я на всё это хозяйство ТЗ пиши, и не должен понимать, а почему выбрали то или иное решение?
Попробуем разобраться вместе.
Какие могут быть варианты:
✅1.По-другому нельзя, у нас нет выбора - у нас интеграция с сервисом на который мы не можем повлиять, сказали SOAP, значит SOAP, и нет тут долгих размышлений и логики принятия решения.
✅2.Среда нас ограничивает - мы такие умные и красивые пришли со своим REST API, микросервисами, а наш партнёр нам говорит - Дорогой ты мой человек! Мы когда в пятницу уходим на выходные, всё отрубаем и сервер тоже. И вообще у нас Марья Ивановна будет работать с вашими данными на винде. Дайте человеку файл на почту, чтобы смогла его открыть, прочитать и ничего не потерялось.
✅3.Политическое решение. Не нужно вам знать почему так! Слишком много задаёшь вопросов, товарищ,подозрительно на которые нет ответов. Как-то на проекте я спросила, почему купили шину IBM, а не ORACLE? Мне сказали, тсссс! Молчи! Нашему инвестору IBM красивую презентацию показали и ужин устроили и ещё то, чего мы не знаем. И не говорим вслух...
✅4.Нет ресурсов - банально, может быть там, что нет разработчиков, кто бы модно, молодёжно смог сделать. Поэтому берут проверенный, рабочий вариант.
✅5.И может быть вариант - да бог его знает, все так делают и ваще Вася наш гений, вот он так и решил, играет в технологии, главное. Всё работает, все довольны!
✅6. А может быть вариант - не знаю, исторически сложилось, или никто не думал, поэтому не задавай вопросы!
Ну и главный фактор - решение принимает человек и он исходит (в лучшем случае) из того, какие у него вводные данные:
📍сроки,
📍требования,
📍безопасность,
📍скорость передачи,
📍объем передачи данных,
📍надёжность,
📍масштабируемость,
📍среда (ограничения среды),
📍ресурсы,
📍поддержка,
📍бюджет,
📍уже что-то пообещали начальству...
И не стоит подходит к вопросу, а как должно быть?
С такой позиции, что мы сейчас делаем раз и навсегда. И интеграция у нас будет вылита в бронзе.
Как-то на одном проекте, у нас интеграция за год поменялась несколько раз:
✅В начале, надо было быстро, сделать point-to-point напрямую, шаблонно, так как уже было api
✅Потом переделали и завернули на шину, сделали центр обмена xml-сообщениями
✅Потом поняли, что нужен брокер, поставили и завернули на очередь.
И при таком раскладе решение везде работало, и прошло эволюцию вместе с айти ландшафтом компании.
Поэтому, мы стараемся разбирать позицию аналитика в связке - требование, ограничение, и влияние на решение. Но аналитик не принимает окончательные решения по разработке, аналитик помогает команде погрузиться в плоскость проблем, требований, ограничений, рисков, как раз задавая неудобные вопросы, которые направляют нашу команду в нужном русле.
👉Именно такой путь мы и будем с вами проходить на курсе интеграции.
👉Будем делиться кейсами из жизни, опытом, знаниями и проходить цепочку проектирования решения от концепции до уровня технологий и паттернов интеграции.
-----------------------
Залетайте к нам в февральский поток! 🚀
#интеграция #челлендж #выборрешения
Частый и любимый вопрос от аналитика.
И он понятен! Архитекторы, разработчики закатывают глаза вверх и отвечают, что-то типа дружок не заходи на мою территорию
И когда ты раз получил негатив, два получил негатив, уже в следующий раз не будешь спрашивать, но и чувствовать себя на обочине жизни не хочется. Все там в замесе участвуют, я на всё это хозяйство ТЗ пиши, и не должен понимать, а почему выбрали то или иное решение?
Попробуем разобраться вместе.
Какие могут быть варианты:
✅1.По-другому нельзя, у нас нет выбора - у нас интеграция с сервисом на который мы не можем повлиять, сказали SOAP, значит SOAP, и нет тут долгих размышлений и логики принятия решения.
✅2.Среда нас ограничивает - мы такие умные и красивые пришли со своим REST API, микросервисами, а наш партнёр нам говорит - Дорогой ты мой человек! Мы когда в пятницу уходим на выходные, всё отрубаем и сервер тоже. И вообще у нас Марья Ивановна будет работать с вашими данными на винде. Дайте человеку файл на почту, чтобы смогла его открыть, прочитать и ничего не потерялось.
✅3.Политическое решение. Не нужно вам знать почему так! Слишком много задаёшь вопросов, товарищ,
✅4.Нет ресурсов - банально, может быть там, что нет разработчиков, кто бы модно, молодёжно смог сделать. Поэтому берут проверенный, рабочий вариант.
✅5.И может быть вариант - да бог его знает, все так делают и ваще Вася наш гений, вот он так и решил, играет в технологии, главное. Всё работает, все довольны!
✅6. А может быть вариант - не знаю, исторически сложилось, или никто не думал, поэтому не задавай вопросы!
Ну и главный фактор - решение принимает человек и он исходит (в лучшем случае) из того, какие у него вводные данные:
📍сроки,
📍требования,
📍безопасность,
📍скорость передачи,
📍объем передачи данных,
📍надёжность,
📍масштабируемость,
📍среда (ограничения среды),
📍ресурсы,
📍поддержка,
📍бюджет,
📍уже что-то пообещали начальству...
И не стоит подходит к вопросу, а как должно быть?
С такой позиции, что мы сейчас делаем раз и навсегда. И интеграция у нас будет вылита в бронзе.
Как-то на одном проекте, у нас интеграция за год поменялась несколько раз:
✅В начале, надо было быстро, сделать point-to-point напрямую, шаблонно, так как уже было api
✅Потом переделали и завернули на шину, сделали центр обмена xml-сообщениями
✅Потом поняли, что нужен брокер, поставили и завернули на очередь.
И при таком раскладе решение везде работало, и прошло эволюцию вместе с айти ландшафтом компании.
Поэтому, мы стараемся разбирать позицию аналитика в связке - требование, ограничение, и влияние на решение. Но аналитик не принимает окончательные решения по разработке, аналитик помогает команде погрузиться в плоскость проблем, требований, ограничений, рисков, как раз задавая неудобные вопросы, которые направляют нашу команду в нужном русле.
👉Именно такой путь мы и будем с вами проходить на курсе интеграции.
👉Будем делиться кейсами из жизни, опытом, знаниями и проходить цепочку проектирования решения от концепции до уровня технологий и паттернов интеграции.
-----------------------
Залетайте к нам в февральский поток! 🚀
#интеграция #челлендж #выборрешения
sup.expert
Курс по интеграции