С чего начинать проектирование интеграции? А как продолжить и ничего не забыть?
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)
Мой путь в айти начался, как раз с интеграции, в далёком 2006 году в телекоме, в команде шинной интеграции продукта IBM WebSphere. Интеграция, как красная линия, проходит через весь мой опыт. Практически ни один из проектов, в которых я участвовала, не проходил без интеграции.
Мне знакомы трудности и "подводные камни" на пути системного аналитика.
Что самое сложное в интеграции?
Интеграция включает в себя все аспекты и нюансы работы системного аналитика. Чтобы спроектировать интеграционное решение приходится знать и понимать многие дисциплины системной инженерии, плюс хорошо разбираться в технологиях и добавлять, развивать абстрактное мышление, чтобы картину взаимодействия систем уложить у себя в голове. Другими словами - приходится действительно заниматься системным анализом))
Что поможет?
- фундамент знаний различных дисциплин
- опыт, тут я как #капитаночевидность
- шаблон ТЗ (с любыми шаблонами работать проще)
- знание, применение инструментов проекторования, основа - это sequence диаграмма (Uml) и сценарная техника (Use Cases), но без диаграммы статусов State Machine (Uml) и диаграмм C4 (DFD+Component) тоже не обойтись
- знание технологий SOAP, REST API
- и такие замечательные слова как безопасность, логирование, мониторинг, квотирование, мастер-данные, гарантированная доставка тоже должны быть понятны, как и шина, и брокер)
Предлагаю в ближайшие недели обсудить часто возникающие проблемы в работе интеграционного аналитика.
Разберём:
1.Из каких шагов состоит проектирование интеграции
2.Что точно стоит изучить, чтобы стало понятнее и легче
3.Как можно классифицировать интеграцию
4.Часто возникающие подводные камни или #смертныегрехи системного аналитика
5.Кейсы из жизни, их у меня накопилось много)
Серия постов по интеграции будет полезна системным аналитикам с разным опытом работы, которые вдумчиво решают свои рабочие задачи и хотят повысить качество своей работы.
Мы получим с вами выжимку по теме интеграции, которая в том числе, поможет вам понять свои белые пятна и смело добавить новые пункты в план своего развития.
#интеграция #мойопыт #анонс #системныйаналитик #системныйанализ
А прямо сейчас задавайте свои вопросы, которые касаются интеграции 👇
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)
Мой путь в айти начался, как раз с интеграции, в далёком 2006 году в телекоме, в команде шинной интеграции продукта IBM WebSphere. Интеграция, как красная линия, проходит через весь мой опыт. Практически ни один из проектов, в которых я участвовала, не проходил без интеграции.
Мне знакомы трудности и "подводные камни" на пути системного аналитика.
Что самое сложное в интеграции?
Интеграция включает в себя все аспекты и нюансы работы системного аналитика. Чтобы спроектировать интеграционное решение приходится знать и понимать многие дисциплины системной инженерии, плюс хорошо разбираться в технологиях и добавлять, развивать абстрактное мышление, чтобы картину взаимодействия систем уложить у себя в голове. Другими словами - приходится действительно заниматься системным анализом))
Что поможет?
- фундамент знаний различных дисциплин
- опыт, тут я как #капитаночевидность
- шаблон ТЗ (с любыми шаблонами работать проще)
- знание, применение инструментов проекторования, основа - это sequence диаграмма (Uml) и сценарная техника (Use Cases), но без диаграммы статусов State Machine (Uml) и диаграмм C4 (DFD+Component) тоже не обойтись
- знание технологий SOAP, REST API
- и такие замечательные слова как безопасность, логирование, мониторинг, квотирование, мастер-данные, гарантированная доставка тоже должны быть понятны, как и шина, и брокер)
Предлагаю в ближайшие недели обсудить часто возникающие проблемы в работе интеграционного аналитика.
Разберём:
1.Из каких шагов состоит проектирование интеграции
2.Что точно стоит изучить, чтобы стало понятнее и легче
3.Как можно классифицировать интеграцию
4.Часто возникающие подводные камни или #смертныегрехи системного аналитика
5.Кейсы из жизни, их у меня накопилось много)
Серия постов по интеграции будет полезна системным аналитикам с разным опытом работы, которые вдумчиво решают свои рабочие задачи и хотят повысить качество своей работы.
Мы получим с вами выжимку по теме интеграции, которая в том числе, поможет вам понять свои белые пятна и смело добавить новые пункты в план своего развития.
#интеграция #мойопыт #анонс #системныйаналитик #системныйанализ
А прямо сейчас задавайте свои вопросы, которые касаются интеграции 👇
Интеграция - это не только маппинг данных. 😎
Некоторые руководители считают, а что там сложного в интеграции, описали маппинг данных и всё! Вперёд!
Проблема интеграции состоит в том, что она затрагивает все аспекты области проектирования информационных систем. И к решению подобной задачи нужно подходить системно.
Да, можно и нужно разбираться в технологиях. Да, REST API, Кафка, микросервисная архитектура это текущий тренд отрасли и все бегут в эту сторону, услышав модные слова (и то уже сделаны выводы, что не так с микросервисами и не везде они нужны).
К задаче интеграции нужно подходить, как к "слоёному пирогу", и снимать слой за слоем уровней требований.
Отсюда и проблема, что аналитики чего-то не знают, где-то есть пробелы, не видят границы и задачу системно. Ходят с курса на курс, читают книги, смотрят вебинары, но это всё не даёт единую картину мира. Это всё прекрасно и нужно, но стоит собирать знания вместе, чтобы оно заработало.
Например, чтобы соединить две системы между собой, сначала нужно понять на бизнес уровне, что соединяется? Зачем? Какой бизнес-процесс в итоге мы выстраиваем. Да, если мы работаем со справочниками тут нет вопросов, тут действительно маппинг данных и регламенты обмена включаются, и вперёд!
Но если у нас сложная интеграция, то нужно понимать, как будет работать бизнес-уровень, какие объекты предметной области участвуют в процессах, как меняются их статусы при интеграции, как сценарии на пользовательском уровне переходят в функциональный, как наше решение вписывается в системный контекст ИТ-ландшафта компаний. И только пройдя несколько уровней абстракции, мы доходим до данных и технологий обмена этими данными. И тут как раз нам и нужны знания по REST API, SOAP,тут дальше можно назвать другие страшные слова.
Я конечно #капитаночевидность будучи системным аналитиком, подходи к задаче системно и будет тебе счастье) Делай нормально и будет нормально))
Но действительно это работает!
Завтра расскажу о системном подходе к интеграции☝️
А пока делитесь мыслями, какие у вас подходы при проектирование решений интеграции? Что вам помогает?)
#интеграция #системныйаналитик #системныйанализ #мойопыт #капитаночевидность #выводы #рассуждения
Некоторые руководители считают, а что там сложного в интеграции, описали маппинг данных и всё! Вперёд!
Проблема интеграции состоит в том, что она затрагивает все аспекты области проектирования информационных систем. И к решению подобной задачи нужно подходить системно.
Да, можно и нужно разбираться в технологиях. Да, REST API, Кафка, микросервисная архитектура это текущий тренд отрасли и все бегут в эту сторону, услышав модные слова (и то уже сделаны выводы, что не так с микросервисами и не везде они нужны).
К задаче интеграции нужно подходить, как к "слоёному пирогу", и снимать слой за слоем уровней требований.
Отсюда и проблема, что аналитики чего-то не знают, где-то есть пробелы, не видят границы и задачу системно. Ходят с курса на курс, читают книги, смотрят вебинары, но это всё не даёт единую картину мира. Это всё прекрасно и нужно, но стоит собирать знания вместе, чтобы оно заработало.
Например, чтобы соединить две системы между собой, сначала нужно понять на бизнес уровне, что соединяется? Зачем? Какой бизнес-процесс в итоге мы выстраиваем. Да, если мы работаем со справочниками тут нет вопросов, тут действительно маппинг данных и регламенты обмена включаются, и вперёд!
Но если у нас сложная интеграция, то нужно понимать, как будет работать бизнес-уровень, какие объекты предметной области участвуют в процессах, как меняются их статусы при интеграции, как сценарии на пользовательском уровне переходят в функциональный, как наше решение вписывается в системный контекст ИТ-ландшафта компаний. И только пройдя несколько уровней абстракции, мы доходим до данных и технологий обмена этими данными. И тут как раз нам и нужны знания по REST API, SOAP,
Я конечно #капитаночевидность будучи системным аналитиком, подходи к задаче системно и будет тебе счастье) Делай нормально и будет нормально))
Но действительно это работает!
Завтра расскажу о системном подходе к интеграции
А пока делитесь мыслями, какие у вас подходы при проектирование решений интеграции? Что вам помогает?)
#интеграция #системныйаналитик #системныйанализ #мойопыт #капитаночевидность #выводы #рассуждения
Please open Telegram to view this post
VIEW IN TELEGRAM
Готовых, чётких, пошаговых инструкций в проектирование интеграционных решений нет.
Все люди, а аналитики тоже люди)) любят готовые решения, как пошагово что-то делать и будет счастье. Что в вебинаре про погружение в предметку (смотрите), что на курсе интеграции я часто слышу разочарование, а какие должны быть шаги, дайте чёткую инструкцию?
Когда я говорю, что да, наш с вами курс или вебинар, выстроен так, что мы идём последовательно, но в ваших проектах не так. Нет инструкций для вашей ситуации, вы сами должны её придумать, сами пройти путь проектирования. Происходит разочарование. При этом иногда очень сложно объяснить, как я пришла к тому или иному решению, потому что путь не линейный.
Аналитик может цикл за циклом возвращаться к артефактам, и это нормально! Не ждите чистовой версии с первого раза! Ваш перфекционизм нужен только при ловле блох! Получил новую информацию понял, что нужно пойти и что-то изменить, вернулся и изменил. Изменения это нормально. Понял, что слишком большой кусок взял на переваривание, остановился, декомпозировал, разделил и пошёл властвовать с небольшим объёмом. А иногда другая крайность появляется, так много всего, за что хвататься, нужно всё!!! Ааааа!!! Начни с ключевых моментов, в интеграции это сценарии и sequence диаграмма, по этим сценариям. А дальше стройте вокруг них.
Горькая правда состоит в том, что подходы к своей работе, к проектированию вы формируете сами. Работа системного аналитика не так проста, как её продают. И самое ценное это наслоение знаний, на фундамент, и всё это работает в системе и в итоге вам выдает хороший результат.
Я как ментор, тренер создаю реальные условия на курсах, сессиях, от которых бывает участников бомбит "дайте адаптированный вариант!" Но на ваших проектах не будет такой адаптации и вам придётся справляться самим.
Мне же хочется заложить граф связанных инструментов, знаний, навыков, чтобы очертить поле битвы. И подсветить, то чего не хватает аналитику для его работы. Чтобы он в боевых условиях не растерялся и понял, ага, это вот там должно быть, помню, помню этот пазл. Отсюда кстати и уверенность приходит)
Да, я могу показать один из вариантов, а может даже ни один и подходов к решению задачи может быть много. И тут всё зависит от уровня прокачки аналитика. Потому что кому-то не нужны шаблоны, адаптированные задачи и "костыли", а кому-то пока нужно научиться ходить, то есть мыслить))) а потом уже и бегать на скорости!и тут Остапа понесло...
Поэтому я и топлю всегда за интерактивные занятия, за менторский подход в долгую, когда чувствуешь группу и сразу можешь менять направление информации или отходить в сторону, чтобы сразу закрыть пробелы по ходу курса. И понимаешь, что есть время и можно успеть разложить всё по плану, потому что этим временем я управляю сама))
#выводы #рассуждения #капитаночевидность #мойопыт #системныйанализ #системныйаналитик #интеграция
Завтра продолжим говорить про то, из чего состоит проектирование интеграционных решений🤓
Все люди, а аналитики тоже люди)) любят готовые решения, как пошагово что-то делать и будет счастье. Что в вебинаре про погружение в предметку (смотрите), что на курсе интеграции я часто слышу разочарование, а какие должны быть шаги, дайте чёткую инструкцию?
Когда я говорю, что да, наш с вами курс или вебинар, выстроен так, что мы идём последовательно, но в ваших проектах не так. Нет инструкций для вашей ситуации, вы сами должны её придумать, сами пройти путь проектирования. Происходит разочарование. При этом иногда очень сложно объяснить, как я пришла к тому или иному решению, потому что путь не линейный.
Аналитик может цикл за циклом возвращаться к артефактам, и это нормально! Не ждите чистовой версии с первого раза! Ваш перфекционизм нужен только при ловле блох! Получил новую информацию понял, что нужно пойти и что-то изменить, вернулся и изменил. Изменения это нормально. Понял, что слишком большой кусок взял на переваривание, остановился, декомпозировал, разделил и пошёл властвовать с небольшим объёмом. А иногда другая крайность появляется, так много всего, за что хвататься, нужно всё!!! Ааааа!!! Начни с ключевых моментов, в интеграции это сценарии и sequence диаграмма, по этим сценариям. А дальше стройте вокруг них.
Горькая правда состоит в том, что подходы к своей работе, к проектированию вы формируете сами. Работа системного аналитика не так проста, как её продают. И самое ценное это наслоение знаний, на фундамент, и всё это работает в системе и в итоге вам выдает хороший результат.
Я как ментор, тренер создаю реальные условия на курсах, сессиях, от которых бывает участников бомбит "дайте адаптированный вариант!" Но на ваших проектах не будет такой адаптации и вам придётся справляться самим.
Мне же хочется заложить граф связанных инструментов, знаний, навыков, чтобы очертить поле битвы. И подсветить, то чего не хватает аналитику для его работы. Чтобы он в боевых условиях не растерялся и понял, ага, это вот там должно быть, помню, помню этот пазл. Отсюда кстати и уверенность приходит)
Да, я могу показать один из вариантов, а может даже ни один и подходов к решению задачи может быть много. И тут всё зависит от уровня прокачки аналитика. Потому что кому-то не нужны шаблоны, адаптированные задачи и "костыли", а кому-то пока нужно научиться ходить, то есть мыслить))) а потом уже и бегать на скорости!
Поэтому я и топлю всегда за интерактивные занятия, за менторский подход в долгую, когда чувствуешь группу и сразу можешь менять направление информации или отходить в сторону, чтобы сразу закрыть пробелы по ходу курса. И понимаешь, что есть время и можно успеть разложить всё по плану, потому что этим временем я управляю сама))
#выводы #рассуждения #капитаночевидность #мойопыт #системныйанализ #системныйаналитик #интеграция
Завтра продолжим говорить про то, из чего состоит проектирование интеграционных решений
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Наталья Косинова. Как разобраться в предметной области: инструкция по применению
Любой специалист сталкивается с проблемой освоения новой для себя предметной областью. Нужно ли быть сильным экспертом в предметке, чтобы работать на новых проектах? Что делать, как систематизировать знания?
Как быстрее залить в голову информацию и начать…
Как быстрее залить в голову информацию и начать…
Администрирование интеграции
Не совсем #капитаночевидность что интеграцией нужно управлять и после выкатки на продуктив, она становится узким горлышком.
Часто и разработка, и аналитик забывают о том, что нужна возможность изменения настроек. И тогда разработчик становится частью своего продукта. Но и аналитик тоже может стать "частью команды, частью корабля". У нас был такой случай, мы узнали, что интеграция работает только в купе с аналитиком, тогда, когда он ушёл в отпуск и всё упало.
Так что принцип "сделать так, чтобы ко мне мало прибегали с вопросами" очень мотивирует.
Тех поддержка в таких случаях разводит руками. Потому что им не сделали инструменты управления. Не сделали, вот мы и не можем передать целые куски в поддержку.
Что делать?
✅ Рассматривать тех поддержку, администраторов системы, как полноценных заказчиков. Им поддерживать решение и они должны получать конкретные инструкции. И в интересах команды, всё сделать так, чтобы к ним не бегали по каждому чиху.
✅ Аналитик может просчитать на несколько шагов вперёд, как будет развиваться бизнес. И именно эти точки развития заложить в реализацию.
Какие могут быть параметры настроек?
Например, типичные и часто встречающиеся:
➡️ - тайм зона, бизнес любит расширять свои границы на разные регионы, даже если не сразу говорит, но захватить мир все хотят,
➡️ - включение, отключение целых блоков бизнес-процессов, есть такие моменты, что вот мы сомневаемся, сегодня надо, а завтра нет, лучше добавить и сделать возможность отключения по настройкам,
➡️ - разные форматы данных, например, что-то нужно настроить по умолчанию, или правила валидации, регулярные выражения, шаблоны вывода и т.п.
➡️ - настройки связанные с обработкой ошибок, нужно ли включать повторные вызовы, если была ошибка, сколько раз, за какой период,
➡️ - уровни логирования данных (может быть встроенная функциональность разных платформ, а может быть своя логика),
➡️ - квотирование, есть платные сервисы и каждый их вызов это деньги, а если вы ещё делаете механизм повторных отправок, можно попасть на бабло, так что лучше сразу задуматься как этим управлять и, например, переключать функционал с платного на бесплатный, некоторые государственные сервисы не очень любят, когда их бомбят запросами и тоже могут ввести квоту на количество обращений в день.
Как-то мне аналитик, сказал, вот ты топишь за настройки, а у нас их было так много, что мы запутались.
⚡️ Ну во-первых, можно делать значения по умолчанию, и не трогать ружье, которое висит на стене, но раз в год выстрелит.
⚡️ А во вторых, можно сделать нормальные человекочитаемые названия, и внятное описание и согласовать с администраторами и тех поддержкой, и дать инструкцию, продумать использование этих самых настроек.
Конечно, я могла что-то забыть, и полно все детали в пост не впихнуть, но с думаю мой посыл понятен.
В интеграции много подобных не очевидных нюансов, если хочется глубже в них разбираться приходи на наш курс интеграции, совсем скоро старт потока (16 ноября), и что-то мне подсказывает, что с нового года будет повышение цены.
Запрыгнуть в нашу уютную группу можно оставив заявку на сайте➡️ https://sup.expert/
#интеграция #администрирование #настройки #выводы
Не совсем #капитаночевидность что интеграцией нужно управлять и после выкатки на продуктив, она становится узким горлышком.
Часто и разработка, и аналитик забывают о том, что нужна возможность изменения настроек. И тогда разработчик становится частью своего продукта. Но и аналитик тоже может стать "частью команды, частью корабля". У нас был такой случай, мы узнали, что интеграция работает только в купе с аналитиком, тогда, когда он ушёл в отпуск и всё упало.
Так что принцип "сделать так, чтобы ко мне мало прибегали с вопросами" очень мотивирует.
Тех поддержка в таких случаях разводит руками. Потому что им не сделали инструменты управления. Не сделали, вот мы и не можем передать целые куски в поддержку.
Что делать?
✅ Рассматривать тех поддержку, администраторов системы, как полноценных заказчиков. Им поддерживать решение и они должны получать конкретные инструкции. И в интересах команды, всё сделать так, чтобы к ним не бегали по каждому чиху.
✅ Аналитик может просчитать на несколько шагов вперёд, как будет развиваться бизнес. И именно эти точки развития заложить в реализацию.
Какие могут быть параметры настроек?
Например, типичные и часто встречающиеся:
Как-то мне аналитик, сказал, вот ты топишь за настройки, а у нас их было так много, что мы запутались.
Конечно, я могла что-то забыть, и полно все детали в пост не впихнуть, но с думаю мой посыл понятен.
В интеграции много подобных не очевидных нюансов, если хочется глубже в них разбираться приходи на наш курс интеграции, совсем скоро старт потока (16 ноября), и что-то мне подсказывает, что с нового года будет повышение цены.
Запрыгнуть в нашу уютную группу можно оставив заявку на сайте
#интеграция #администрирование #настройки #выводы
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
Новому человеку в команде виднее, что не так в процессах.
Когда-то я набирала большой отдел и с каждым новым аналитиком проходила процесс онбординга. Я ждала того момента, когда аналитик начинал видеть внутреннюю кухню и сравнивать со своим опытом и понимал, что чёт не так, и чёт оно не очень хорошо работает))) А так как процесс усовершенствования бесконечный, примерно со всеми аналитиками была, одна и та же история под названием "Наташа, я вот там посмотрел документацию, процесс, давай изменим".
И я так радовалась, ну вот оно!
Вцелом я сама также всегда поступала в новых командах. Это как хозяйка приходит в новый дом и решает, что надо бы прибраться. Кого-то это бесило, не лезь! Кто-то, как истинный руководитель говорил - делай! Тут главное не наступить на грабли с надписью на них "нереально изменить".
И на самом деле это очень круто, когда 2-5 человек говорят одни и те же проблемы, их подсвечивают, значит реально их нужно решать. Если не решать, не вносить изменений, то не будет развития. #капитаночевидность
Как там говорят, только в болоте не течёт вода, и только на кладбище всё без изменений, в жизни всё постоянно меняется. В нашей с вами жизни всё меняется ещё быстрее!
Для меня от нового человека получить список проблем, это равносильно анализу текущего состояния дел. Какая проблема исчезла, мы её закрыли, что нового решение породило в плане новых проблем. А для меня, как для сотрудника компании, это тоже показатель, что меня слушают, со мной ведут диалог, и я могу привнести новую практику. И это тоже некий показатель адекватности.
Изменениями нужно управлять, не всё так просто внедряется, что-то через сопротивление и боль. Главное, чтобы потом было лучше)))
#изменения #новыйсотрудник #мойопыт #онбординг #лидер
Когда-то я набирала большой отдел и с каждым новым аналитиком проходила процесс онбординга. Я ждала того момента, когда аналитик начинал видеть внутреннюю кухню и сравнивать со своим опытом и понимал, что чёт не так, и чёт оно не очень хорошо работает))) А так как процесс усовершенствования бесконечный, примерно со всеми аналитиками была, одна и та же история под названием "Наташа, я вот там посмотрел документацию, процесс, давай изменим".
И я так радовалась, ну вот оно!
Вцелом я сама также всегда поступала в новых командах. Это как хозяйка приходит в новый дом и решает, что надо бы прибраться. Кого-то это бесило, не лезь! Кто-то, как истинный руководитель говорил - делай! Тут главное не наступить на грабли с надписью на них "нереально изменить".
И на самом деле это очень круто, когда 2-5 человек говорят одни и те же проблемы, их подсвечивают, значит реально их нужно решать. Если не решать, не вносить изменений, то не будет развития. #капитаночевидность
Как там говорят, только в болоте не течёт вода, и только на кладбище всё без изменений, в жизни всё постоянно меняется. В нашей с вами жизни всё меняется ещё быстрее!
Для меня от нового человека получить список проблем, это равносильно анализу текущего состояния дел. Какая проблема исчезла, мы её закрыли, что нового решение породило в плане новых проблем. А для меня, как для сотрудника компании, это тоже показатель, что меня слушают, со мной ведут диалог, и я могу привнести новую практику. И это тоже некий показатель адекватности.
Изменениями нужно управлять, не всё так просто внедряется, что-то через сопротивление и боль. Главное, чтобы потом было лучше)))
#изменения #новыйсотрудник #мойопыт #онбординг #лидер
Квотирование в интеграции, что это такое и зачем нужно?
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Концептуальное проектирование
Есть две вещи, которые простые, очевидные #капитаночевидность поэтому их мало кто делает.
Первая это Концептуальное проектирование(сюда же 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 #системныйаналитик #системныйанализ #системныйконтекст
Адаптация под изучение нового.
Список книг, которые бы хотелось прочитать растёт в геометрической прогрессии. При этом есть над чем работать и есть, что изучить. Это огромный поток под словом "НАДО"! А ещё надо было ещё вчера, хочется остановиться и закричать!
✅Как я раньше училась. В институте у меня было правило "не пропускать лекции". Да, я тот ещё душнила и задрот, но я понимала, что тут важен режим и даже если преподаватель и его материал прям тяжело шли, я всё равно приходила на лекцию, брала ручку и писала.
Навык записывать главное из того, что мне начитывают развит у меня отлично.
И я била по всем органам восприятия: слух, визуал, письмо. Это сложно, но то что я записывала или структурировала на бумаге уже на проектах, записывалось мне на подкорку. Я могла потом не перечитывать и не открывать больше, но % запоминания давал рост.
✅Как я сейчас учусь?
Я начинаю внутренний диалог, что мол нужно сесть, взять ручку, открыть тетрадку и начать писать. Что по факту получается? Если лекция не онлайн, то я откладываю. Если онлайн, реально могу сидеть с ручкой и тетрадкой и писать.
Контента много. И я говорю, что минимум - хотя бы прослушать. И я заметила такою штуку, что я чаще стала слушать записи лекций, чтобы понять, тот или иной материал. Да, иногда я всё таки целенаправленно читаю.
И заметила, что я совмещаю прогулку и прослушивание лекции или подкаста. Иииииии - тут прям вывод #капитаночевидность или #капитанНЕочевидность я делаю вывод и понимаю нужно оно мне или нет. Если нет, отбрасываю.
Достойный, глубокий, структурный, действительно мощный материал порой бывает очень трудно найти. А поверхностный уровень его валом.
И получается, что у меня есть развитые навыки обучения, но они подстроились под среду.
Есть ли экономия времени? Кажется, что нефига. Потому что так много предложений и я трачу время на их анализ, потому что я аналитик и не всегда могу быстро принять решение)) оно должно созреть. И фильтрую материал, потому что есть дно, которое нафиг не нужно (может тут ИИ бы и помог). И вот отбросив фигню, я нахожу то, что мне действительно нужно и уже это изучаю, читаю.
#подмечено #мирвокруг #саморазвитие #обучение #моемнение
А как вы обучаетесь?
Используете ли искусственный интеллект?
Остаётся ли что-то в голове?)
Список книг, которые бы хотелось прочитать растёт в геометрической прогрессии. При этом есть над чем работать и есть, что изучить. Это огромный поток под словом "НАДО"! А ещё надо было ещё вчера, хочется остановиться и закричать!
✅Как я раньше училась. В институте у меня было правило "не пропускать лекции". Да, я тот ещё душнила и задрот, но я понимала, что тут важен режим и даже если преподаватель и его материал прям тяжело шли, я всё равно приходила на лекцию, брала ручку и писала.
Навык записывать главное из того, что мне начитывают развит у меня отлично.
И я била по всем органам восприятия: слух, визуал, письмо. Это сложно, но то что я записывала или структурировала на бумаге уже на проектах, записывалось мне на подкорку. Я могла потом не перечитывать и не открывать больше, но % запоминания давал рост.
✅Как я сейчас учусь?
Я начинаю внутренний диалог, что мол нужно сесть, взять ручку, открыть тетрадку и начать писать. Что по факту получается? Если лекция не онлайн, то я откладываю. Если онлайн, реально могу сидеть с ручкой и тетрадкой и писать.
Контента много. И я говорю, что минимум - хотя бы прослушать. И я заметила такою штуку, что я чаще стала слушать записи лекций, чтобы понять, тот или иной материал. Да, иногда я всё таки целенаправленно читаю.
И заметила, что я совмещаю прогулку и прослушивание лекции или подкаста. Иииииии - тут прям вывод #капитаночевидность или #капитанНЕочевидность я делаю вывод и понимаю нужно оно мне или нет. Если нет, отбрасываю.
Достойный, глубокий, структурный, действительно мощный материал порой бывает очень трудно найти. А поверхностный уровень его валом.
И получается, что у меня есть развитые навыки обучения, но они подстроились под среду.
Есть ли экономия времени? Кажется, что нефига. Потому что так много предложений и я трачу время на их анализ, потому что я аналитик и не всегда могу быстро принять решение)) оно должно созреть. И фильтрую материал, потому что есть дно, которое нафиг не нужно (может тут ИИ бы и помог). И вот отбросив фигню, я нахожу то, что мне действительно нужно и уже это изучаю, читаю.
#подмечено #мирвокруг #саморазвитие #обучение #моемнение
А как вы обучаетесь?
Используете ли искусственный интеллект?
Остаётся ли что-то в голове?)
Требования - это же не rocket science, что тут сложного?
Когда ко мне на менторство или на курсы приходят аналитики, особенно с опытом, на вопрос умеют ли они собирать требования и их формулировать? Все с большой уверенностью говорят да.
Мы копаем дальше, но в какой-то момент понимаем, что нужно вернуться к базовым вещам, их скорректировать, и ещё раз разобрать работу с требованиями, их классификацию.
Правда, эти требования уже всех задолбали, но сколько можно о них говорить?) Дайте, что-то поинтереснее!
✅ Требования - это ключевая единица результата работы аналитика.
По факту аналитик, даже с опытом, может не видеть нюансы. Это нормально. Я сама такая же, не сразу доходит.
Хотя казалось бы #капитаночевидность, что тут сложного, разложи требования по уровням:
БТ (бизнес),
ПТ (пользователь),
ФТ (функция),
НФТ (ограничения),
СТ (система).
Но чем проще инструмент, тем сложнее с ним работать))) прям #ладайламинг
Суть проблемы, состоит в том, что аналитик не видит разные уровни абстракции, не видит нюансы, какое требование к чему относится. И на выходе получается каша, и не всегда понятно на каком уровне мы сейчас находимся? Бизнес, Пользователь, Функция, или Система?
#работастребованиями #системныйанализ #системныйаналитик #требования
Что с этим делать? Своё мнение расскажу завтра, а пока пишите свои варианты в комментариях 👇
Когда ко мне на менторство или на курсы приходят аналитики, особенно с опытом, на вопрос умеют ли они собирать требования и их формулировать? Все с большой уверенностью говорят да.
Мы копаем дальше, но в какой-то момент понимаем, что нужно вернуться к базовым вещам, их скорректировать, и ещё раз разобрать работу с требованиями, их классификацию.
✅ Требования - это ключевая единица результата работы аналитика.
По факту аналитик, даже с опытом, может не видеть нюансы. Это нормально. Я сама такая же, не сразу доходит.
Хотя казалось бы #капитаночевидность, что тут сложного, разложи требования по уровням:
БТ (бизнес),
ПТ (пользователь),
ФТ (функция),
НФТ (ограничения),
СТ (система).
Но чем проще инструмент, тем сложнее с ним работать))) прям #ладайламинг
Суть проблемы, состоит в том, что аналитик не видит разные уровни абстракции, не видит нюансы, какое требование к чему относится. И на выходе получается каша, и не всегда понятно на каком уровне мы сейчас находимся? Бизнес, Пользователь, Функция, или Система?
#работастребованиями #системныйанализ #системныйаналитик #требования
Что с этим делать? Своё мнение расскажу завтра, а пока пишите свои варианты в комментариях 👇
Кому нужны эти НФТ? Бред какой-то, это уже немодно.
НФТ оказывают влияние на конечный результат и влияют на общую стоимость решения. Качество, это то, что ожидают от продукта, но не всегда говорят или не понимают, как измерить. А раз оно непонятно, то лучше вообще не делать, не писать и туда не лезть.
Есть ещё такой момент, что требования это вроде как вотчина аналитика. Но аналитик структурирует, перерабатывает информацию, проектируют решение на языке требований. И вот тебе тут НФТ, писать о железе? О масштабирование, архитектуре? Это что реально моё? И странно и сложно. И тут аналитик становится техническим писателем, опроси всех, собери информацию, зафиксируй. Но эта часть непонятная, а я вроде как за неё должен отвечать, но не знаю! Конечно не хочется браться за эфемерную штуку.
Что делать?🤓
✅Первое, что хочется сказать, это всё таки объяснить себе место нефункциональных требований и что они необходимы. Название не очень удачное, и не всегда отражает суть.
Помните в икеа в магазине стояло кресло и его сразу же при нас тестировали на нагрузку? Выглядело эффектно. Нужно это было? Я думаю тут бесспорно.
✅Второе, за что реально может отвечать аналитик и что увидеть?
Тут также как в икеа, со стороны пользователя мы можем описать сценарий использования, где наши волшебные требования себя будут проявлять. И указать условия выполнения, ограничения, понятность шагов. Что например, по регламенту 30 минут на согласование документа, проверяем на группе испытуемых, засекаем время, смотрим результат. Что без инструкций новый пользователь сможет освоить функционал за 5 или 10 минут.
✅Третье, администрирование, настройки, управление продуктом. Хороший аналитик видит развитие бизнеса, может предсказать расширение на несколько шагов вперёд и эти точки масштабирования описать, донести до команды.
✅Четвёртое, что я всегда говорю аналитикам, что аналитик это звено, которое задаёт неудобные вопросы и этими неудобными вопросами погружает команду в плоскость принятия решения. Соответственно в части НФТ, даже если непонятно, что там с железом, можно задать вопросы, взять стандарты, ISO, ГОСТ, и опираться на них в части количественных показателей.
✅Пятое, источником НФТ может быть сама команда. Какие технологии используем, какая архитектура, что зависло, что мешает достижению показателей?
✅Шестое, законы, правила регулятора. Это разряд #капитаночевидность но все про него забывают. Какие отчёты требует регулятор, что будет вносить в законы в ближайшее время, как среда влияет на наше решение, какой язык, локализация и т. п. Например, развивая платёжную систему в России мы сталкивались не только с законом хранения обезличенных персональных данных, стандартом проведения платежа, но и законами на уровне субъекта нашей необъятной родины. Потому что губернатор на уровне своей губернии мог ввести какой-то свой закон по расчёту и оплаты жкх и взятия комиссии за проведение платежа.
А система честный знак, вводит этапами продажу товаров через них, и мы тоже должны учитывать подобные вещи в своих планах разработки.
А ещё есть очень жёсткий момент, что НФТ стоит брать из реальных показателей. Не описывать сферического коня в вакууме, а приземлить на то, что есть и доступно нам уже сейчас. Нет смысла фиксировать показатели, если мы не знаем, достигнем их или нет, есть такие технологии или нет?
Подводя итог, скажу, что НФТ хоть и вызывает негатив, я сама их не очень люблю)) но они важная часть работы с требованиями и тут аналитик, как юрист, должен понимать, что одна его фраза может как добавить работы команде, так и убавить и подложить ломки, там где можно упасть.
Основы работы с требованиями, в том числе и НФТ будем разбирать уже в эти выходные на онлайн игре "Китайская ручка", приходите!)
Регистрация по ссылке➡️ https://sup.expert/pen
НФТ оказывают влияние на конечный результат и влияют на общую стоимость решения. Качество, это то, что ожидают от продукта, но не всегда говорят или не понимают, как измерить. А раз оно непонятно, то лучше вообще не делать, не писать и туда не лезть.
Есть ещё такой момент, что требования это вроде как вотчина аналитика. Но аналитик структурирует, перерабатывает информацию, проектируют решение на языке требований. И вот тебе тут НФТ, писать о железе? О масштабирование, архитектуре? Это что реально моё? И странно и сложно. И тут аналитик становится техническим писателем, опроси всех, собери информацию, зафиксируй. Но эта часть непонятная, а я вроде как за неё должен отвечать, но не знаю! Конечно не хочется браться за эфемерную штуку.
Что делать?
✅Первое, что хочется сказать, это всё таки объяснить себе место нефункциональных требований и что они необходимы. Название не очень удачное, и не всегда отражает суть.
Помните в икеа в магазине стояло кресло и его сразу же при нас тестировали на нагрузку? Выглядело эффектно. Нужно это было? Я думаю тут бесспорно.
✅Второе, за что реально может отвечать аналитик и что увидеть?
Тут также как в икеа, со стороны пользователя мы можем описать сценарий использования, где наши волшебные требования себя будут проявлять. И указать условия выполнения, ограничения, понятность шагов. Что например, по регламенту 30 минут на согласование документа, проверяем на группе испытуемых, засекаем время, смотрим результат. Что без инструкций новый пользователь сможет освоить функционал за 5 или 10 минут.
✅Третье, администрирование, настройки, управление продуктом. Хороший аналитик видит развитие бизнеса, может предсказать расширение на несколько шагов вперёд и эти точки масштабирования описать, донести до команды.
✅Четвёртое, что я всегда говорю аналитикам, что аналитик это звено, которое задаёт неудобные вопросы и этими неудобными вопросами погружает команду в плоскость принятия решения. Соответственно в части НФТ, даже если непонятно, что там с железом, можно задать вопросы, взять стандарты, ISO, ГОСТ, и опираться на них в части количественных показателей.
✅Пятое, источником НФТ может быть сама команда. Какие технологии используем, какая архитектура, что зависло, что мешает достижению показателей?
✅Шестое, законы, правила регулятора. Это разряд #капитаночевидность но все про него забывают. Какие отчёты требует регулятор, что будет вносить в законы в ближайшее время, как среда влияет на наше решение, какой язык, локализация и т. п. Например, развивая платёжную систему в России мы сталкивались не только с законом хранения обезличенных персональных данных, стандартом проведения платежа, но и законами на уровне субъекта нашей необъятной родины. Потому что губернатор на уровне своей губернии мог ввести какой-то свой закон по расчёту и оплаты жкх и взятия комиссии за проведение платежа.
А система честный знак, вводит этапами продажу товаров через них, и мы тоже должны учитывать подобные вещи в своих планах разработки.
А ещё есть очень жёсткий момент, что НФТ стоит брать из реальных показателей. Не описывать сферического коня в вакууме, а приземлить на то, что есть и доступно нам уже сейчас. Нет смысла фиксировать показатели, если мы не знаем, достигнем их или нет, есть такие технологии или нет?
Подводя итог, скажу, что НФТ хоть и вызывает негатив, я сама их не очень люблю)) но они важная часть работы с требованиями и тут аналитик, как юрист, должен понимать, что одна его фраза может как добавить работы команде, так и убавить и подложить ломки, там где можно упасть.
Основы работы с требованиями, в том числе и НФТ будем разбирать уже в эти выходные на онлайн игре "Китайская ручка", приходите!)
Регистрация по ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
"Китайская ручка"