С чего начинать проектирование интеграции? А как продолжить и ничего не забыть?
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)
Мой путь в айти начался, как раз с интеграции, в далёком 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
Наталья Косинова. Как разобраться в предметной области: инструкция по применению
Любой специалист сталкивается с проблемой освоения новой для себя предметной областью. Нужно ли быть сильным экспертом в предметке, чтобы работать на новых проектах? Что делать, как систематизировать знания?
Как быстрее залить в голову информацию и начать…
Как быстрее залить в голову информацию и начать…
Как я проектирую интеграцию.
Расскажу именно свой процесс, да он может быть не последовательный, но я опишу его по шагам (+ см. чек-лист):
✅1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно (вспоминаем эффект Бандуры) .
✅2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения.
✅3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает.
✅4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
✅5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки.
✅6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
✅7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы.
✅8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
✅9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
✅10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет пытаюсь посчитать и согласовать с разработкой.
✅11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
✅12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов (могу и сама на них проверить API, иногда спека отличается от реальной жизни и тогда всё будет насмарку)).
Очень кратко описала процесс, специально опуская детали.
Когда ребята приходят к нам на интеграцию мы проходим по тем шагам, которые помогут действительно спроектировать решение и написать ТЗ. Каждый участник на курс приходит за своим, но то что отмечают многие, это то, что на финише остаётся в голове система, что повышает уверенность в работе, на собеседованиях. А это очень важный момент! Даже каверзные вопросы не ставят в тупик, появляется понимание куда рыть и в какой плоскости лежит решение.
И я действительно как карьерная фея🤩 , понимаю, что уже несколько выпускников наших потоков курса поменяли работу и выросли в грейдах.
Многие смогли понять свои проблемы и написать план собственного развития и мощно обновили свои базы знаний📈
Приходите к нам на интеграцию➡️ https://sup.expert/
#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс
Расскажу именно свой процесс, да он может быть не последовательный, но я опишу его по шагам (+ см. чек-лист):
✅1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно (вспоминаем эффект Бандуры) .
✅2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения.
✅3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает.
✅4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
✅5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки.
✅6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
✅7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы.
✅8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
✅9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
✅10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет пытаюсь посчитать и согласовать с разработкой.
✅11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
✅12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов (могу и сама на них проверить API, иногда спека отличается от реальной жизни и тогда всё будет насмарку)).
Очень кратко описала процесс, специально опуская детали.
Когда ребята приходят к нам на интеграцию мы проходим по тем шагам, которые помогут действительно спроектировать решение и написать ТЗ. Каждый участник на курс приходит за своим, но то что отмечают многие, это то, что на финише остаётся в голове система, что повышает уверенность в работе, на собеседованиях. А это очень важный момент! Даже каверзные вопросы не ставят в тупик, появляется понимание куда рыть и в какой плоскости лежит решение.
И я действительно как карьерная фея
Многие смогли понять свои проблемы и написать план собственного развития и мощно обновили свои базы знаний
Приходите к нам на интеграцию
#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Наташа Косинова. Варю айти СУП
Чек-лист интеграции.
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
Ошибки проектирования сценариев взаимодействия систем при их интеграции.
Честно, сегодня хотела взять реальную sequence диаграмму с проекта или то, что рисуют ученики и разобрать ошибки. Но понимаю, что очень много на это нужно времени. Но идея мне нравится и вы мне в этом можете помочь и прислать свой вариант, и я его разберу))
А сегодня поговорю о частой ошибке, которую совершают аналитики - это нарезка или проектирование use cases. Тема use cases - сценарной техники сложна и проста одновременно.
Если смотреть канонично на сценарий/use case/прецендет, то что Коберн вкладывал в это понятие это то, как пользователь взаимодействует с системой и какие ожидает реакции системы на свои действия. Чтобы составить набор use cases на пользовательском уровне требований, нужно ответить на следующие вопросы:
✅1.Какие роли есть в системе
✅2.Как эти роли между собой связаны (может быть связь через наследование полномочий)
✅3.Что и какая роль ожидает от системы, то есть зачем я как диспетчер лезу в информационную систему, что я хочу от неё получить? Например, отчёт, его распечатать и отдать механику.
И уже на этом уровне возникает проблема, что не очень понятна бизнес цель и аналитик нарезает сценария применяя CRUD (Create, Read, Update, Delete). И у нас получается сценарии: создать отчет, прочитать отчет, редактировать отчет, удалить отчет. Это тоже хорошо, CRUD нам везде в помощь, но цель генерации отчёта для выпуска водителя на линию звучит совсем по-другому. Не правда ли? Я как диспетчер, хочу внести изменения в отчёт, чтобы зафиксировать сколько нужно бензина. Или отправить автомобиль в ремонт, на тех.обслуживание и т.д.
Почувствовали разницу?
А теперь следующая частая ошибка аналитика, он спускается на системный уровень проектирования интеграции, при этом оставаясь на пользовательском уровне абстракции. Но на системном уровне, бизнес цель пользователя превращается в системную цель.
Отвечаем на вопрос:
Что должна сделать система, чтобы помочь пользователю выполнить бизнес-цель?
И мало того, что выполнить, но и в связке с другой системой, в интеграции. И тогда у нас появляются use cases на системном уровне, вот которые мы уже превращаем в sequence диаграммы.
И для нашего диспетчера, чтобы отправить водителя в рейс система А, должна передать в систему В информацию о водителе и автомобиле и получить согласование от врача, механика. И use cases будет про передачу данных с целью обновления, и подтверждения этого обновления.
И вот мы в итоге получаем совсем другую нарезку сценариев для интеграции.
Действительно инструмент use cases прост, но сложен, когда нужно подключать абстрактное мышление и возвращать себя на уровень требований, на котором мы находимся во время проектирования.
И это всё #капитаннеочевидность и не сразу доходишь до понимая, как, где, зачем и почему нужно применять тот или иной инструмент проектирования. И как сеньорного аналитика отличает не только знания "портфеля инструментов", но и целесообразность их применения в том или ином случае.
#интеграция #системныйаналитик #системныйанализ #мойопыт #рассуждения #выводы
P. S. Моё предложение в силе разобрать вашу sequence диаграмму)
Честно, сегодня хотела взять реальную sequence диаграмму с проекта или то, что рисуют ученики и разобрать ошибки. Но понимаю, что очень много на это нужно времени. Но идея мне нравится и вы мне в этом можете помочь и прислать свой вариант, и я его разберу))
А сегодня поговорю о частой ошибке, которую совершают аналитики - это нарезка или проектирование use cases. Тема use cases - сценарной техники сложна и проста одновременно.
Если смотреть канонично на сценарий/use case/прецендет, то что Коберн вкладывал в это понятие это то, как пользователь взаимодействует с системой и какие ожидает реакции системы на свои действия. Чтобы составить набор use cases на пользовательском уровне требований, нужно ответить на следующие вопросы:
✅1.Какие роли есть в системе
✅2.Как эти роли между собой связаны (может быть связь через наследование полномочий)
✅3.Что и какая роль ожидает от системы, то есть зачем я как диспетчер лезу в информационную систему, что я хочу от неё получить? Например, отчёт, его распечатать и отдать механику.
И уже на этом уровне возникает проблема, что не очень понятна бизнес цель и аналитик нарезает сценария применяя CRUD (Create, Read, Update, Delete). И у нас получается сценарии: создать отчет, прочитать отчет, редактировать отчет, удалить отчет. Это тоже хорошо, CRUD нам везде в помощь, но цель генерации отчёта для выпуска водителя на линию звучит совсем по-другому. Не правда ли? Я как диспетчер, хочу внести изменения в отчёт, чтобы зафиксировать сколько нужно бензина. Или отправить автомобиль в ремонт, на тех.обслуживание и т.д.
Почувствовали разницу?
А теперь следующая частая ошибка аналитика, он спускается на системный уровень проектирования интеграции, при этом оставаясь на пользовательском уровне абстракции. Но на системном уровне, бизнес цель пользователя превращается в системную цель.
Отвечаем на вопрос:
Что должна сделать система, чтобы помочь пользователю выполнить бизнес-цель?
И мало того, что выполнить, но и в связке с другой системой, в интеграции. И тогда у нас появляются use cases на системном уровне, вот которые мы уже превращаем в sequence диаграммы.
И для нашего диспетчера, чтобы отправить водителя в рейс система А, должна передать в систему В информацию о водителе и автомобиле и получить согласование от врача, механика. И use cases будет про передачу данных с целью обновления, и подтверждения этого обновления.
И вот мы в итоге получаем совсем другую нарезку сценариев для интеграции.
Действительно инструмент use cases прост, но сложен, когда нужно подключать абстрактное мышление и возвращать себя на уровень требований, на котором мы находимся во время проектирования.
И это всё #капитаннеочевидность и не сразу доходишь до понимая, как, где, зачем и почему нужно применять тот или иной инструмент проектирования. И как сеньорного аналитика отличает не только знания "портфеля инструментов", но и целесообразность их применения в том или ином случае.
#интеграция #системныйаналитик #системныйанализ #мойопыт #рассуждения #выводы
P. S. Моё предложение в силе разобрать вашу sequence диаграмму)
История Искусств или ТРИЗ?)
Одно из моих хобби - это рисование. У меня в этом направление есть наставник, это Евгения (#нереклама, посмотреть работы). И вот мы на днях вместе ходили в Третьяковку.
Евгения архитектор, и мне нравится её системность и глубина знаний. Вот ты ходишь, смотришь картины. Ну да красиво, сейчас я уже могу оценить то, как детально проработано. Но почему картина шедевр, узнаешь только тогда, когда добавляешь знаний про историю её создания. И вот тут История Искусств для меня становится очень важным примером необходимости подобных знаний. Так и теория решения инженерных задач (ТРИЗ), показывает важные закономерности в создание инженерных изобретений.
И кстати, ТРИЗ помогает аналитику в проектирование интерфейсов.
Проектируя информационную систему, мы увидим результатв лучшем случае виде диаграммы. Но почему так? Часто остаётся открытым вопросом.
Я вижу, как аналитики бегут за знаниями технологий, языков программирования, не задавая вопрос, а что лежит в основе? В чем фундамент? Почему так?
Мы видим результат эволюции и развития инноваций, забывая про то, что опыт пройденного пути нам важен, чтобы решать свои задачи.
Поэтому, да, сложно, да больно, но чтобы спроектировать интеграцию нужно понимать, какой путь нужно пройти, откуда ноги растут тех или иных принятых решений, в чем фундамент? Каков путь? И пройти этот путь по разным уровням требований, начиная с бизнеса, заканчивая технологиями передачи данных можно вместе с нами на курсе интеграции, старт совсем скоро 16 ноября!
#системныйанализ #интеграция #анонс #курсинтеграции #системныйаналитик #курс
Одно из моих хобби - это рисование. У меня в этом направление есть наставник, это Евгения (#нереклама, посмотреть работы). И вот мы на днях вместе ходили в Третьяковку.
Евгения архитектор, и мне нравится её системность и глубина знаний. Вот ты ходишь, смотришь картины. Ну да красиво, сейчас я уже могу оценить то, как детально проработано. Но почему картина шедевр, узнаешь только тогда, когда добавляешь знаний про историю её создания. И вот тут История Искусств для меня становится очень важным примером необходимости подобных знаний. Так и теория решения инженерных задач (ТРИЗ), показывает важные закономерности в создание инженерных изобретений.
И кстати, ТРИЗ помогает аналитику в проектирование интерфейсов.
Проектируя информационную систему, мы увидим результат
Я вижу, как аналитики бегут за знаниями технологий, языков программирования, не задавая вопрос, а что лежит в основе? В чем фундамент? Почему так?
Мы видим результат эволюции и развития инноваций, забывая про то, что опыт пройденного пути нам важен, чтобы решать свои задачи.
Поэтому, да, сложно, да больно, но чтобы спроектировать интеграцию нужно понимать, какой путь нужно пройти, откуда ноги растут тех или иных принятых решений, в чем фундамент? Каков путь? И пройти этот путь по разным уровням требований, начиная с бизнеса, заканчивая технологиями передачи данных можно вместе с нами на курсе интеграции, старт совсем скоро 16 ноября!
#системныйанализ #интеграция #анонс #курсинтеграции #системныйаналитик #курс
Через 2 недели стартует, последний в этом году, поток интеграции.
Вас ждёт аналитический марафон в 2 месяца! ✅
-------------------------------
Курс интеграции состоит из 8 блоков и разделён на два этапа:
Первый 🎯 - это проектирование интеграционного решения от концепции до уровня данных (блоки с 1 по 4).
Блок 1 - отвечаем на вопрос, что такое интеграция, строим С4
Блок 2 - use cases, онтологическая модель предметной области, state machine
Блок 3 - sequence, мастер данные, гарантированная доставка, обработка ошибок, валидация данных
Блок 4 - словарь данных, маппинг данных, администрирование, activity
Второй 🎯 - разбор технологий передачи данных, паттернов интеграции, шина и брокеры (блоки с 5 по 8).
Блок 5 - введение в OSI модель сети, REST API, json
Блок 6 - SOAP, xml
Блок 7 - graphQL, gRPC, логирование, мониторинг, квотирование, безопасность
Блок 8 - Паттерны интеграции, шина, брокер
-------------------------------
Кому подойдёт курс?
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно пройти курс, понять, что входит в интеграцию, увидеть путь рассуждений, которые приводят к результату. Вы приобретёте навыки и уверенность, что позволит брать в работу новые задачи.
Если вы аналитик с опытом от 3 до 5 лет, курс поможет систематизировать знания понять свои пробелы, увидеть эволюцию проектирования, что в конечном итоге позволит вам выйти на новый уровень, составить план развития, а может и сменить работу (такие прецеденты у нас уже есть))).
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, каким путем стоит идти вместе с командой, чтобы повысить качество результата работы аналитиков, посмотрите со стороны на свою работу, артефакты анализа. Будете понимать на что обращать внимание в качестве наставника.
Формат курса - онлайн занятия, приближенные к классической схеме обучения,
✅в четверг лекция (утром по Москве с 9 до 11),
✅во вторник семинар - разбор домашних заданий (утром по Москве с 9 до 11).
Наш формат похож на формат групповых менторских сессий, где ведущие общаются с группой и сразу, по ходу, могут обсуждать возникающие вопросы. Мы подстраиваемся под уровень знаний участников и стараемся давать новый блок информации так, чтобы он ложился на текущий фундамент. Мы не являемся огромной школой или площадкой, что позволяет нам создавать уютное, открытое общение и делиться опытом между собой.
Сколько сможете унести знаний зависит только от вас))
Многие ребята пересматривают записи занятий и узнают снова и снова что-то новое.
➡️ Презентации
➡️ Материал
➡️ Видео записи занятий остаются у вас навсегда!
Мы предлагаем разные тарифы обучения:
Можно прийти на тариф "только послушать", участвовать в онлайн формате в обсуждениях, интерактивных практиках.
Если вы хотите разрабатывать учебный проект и выполнять домашние задания по проектированию, для вас подходит тариф "плюс практика", с разбором домашних заданий.
Мы специально проводим занятия в утреннее время в будние, чтобы вы со свежей головой смогли разобраться в сложной системной информации. Учиться и работать одновременно это действительно сложно, поэтому мы стараемся создать условия, чтобы вы успешно прошли весь аналитический марафон вместе с нами)) Каждый новый поток для нас, как новый вызов!
Имея чёткое расписание, просто приходя на занятия, вы точно сможете почерпнуть для себя полезные знания.
Ведущие:
Основные лекции по проектированию провожу я, Косинова Наталья, мой опыт интеграции более 15 лет, восновном шинная интеграция проектов Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.
Мне помогает
Андрей Корниенко, с точки зрения разработчика и архитектора раскрывает тему технологий, архитектуры решений и интеграции с помощью брокеров сообщений. Именно взгляда разработчика часто не хватает аналитику, когда речь идёт о реализации решения.
Чтобы записаться на курс оставьте свою заявку на нашем сайте➡️ https://sup.expert/
Если у вас остались вопросы, пишите в комментариях, я обязательно отвечу🔽
До встречи на занятиях!
#анонс #курсинтеграции #интеграция #системныйаналитик #системныйанализ #мойопыт
Вас ждёт аналитический марафон в 2 месяца! ✅
-------------------------------
Курс интеграции состоит из 8 блоков и разделён на два этапа:
Первый 🎯 - это проектирование интеграционного решения от концепции до уровня данных (блоки с 1 по 4).
Блок 1 - отвечаем на вопрос, что такое интеграция, строим С4
Блок 2 - use cases, онтологическая модель предметной области, state machine
Блок 3 - sequence, мастер данные, гарантированная доставка, обработка ошибок, валидация данных
Блок 4 - словарь данных, маппинг данных, администрирование, activity
Второй 🎯 - разбор технологий передачи данных, паттернов интеграции, шина и брокеры (блоки с 5 по 8).
Блок 5 - введение в OSI модель сети, REST API, json
Блок 6 - SOAP, xml
Блок 7 - graphQL, gRPC, логирование, мониторинг, квотирование, безопасность
Блок 8 - Паттерны интеграции, шина, брокер
-------------------------------
Кому подойдёт курс?
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно пройти курс, понять, что входит в интеграцию, увидеть путь рассуждений, которые приводят к результату. Вы приобретёте навыки и уверенность, что позволит брать в работу новые задачи.
Если вы аналитик с опытом от 3 до 5 лет, курс поможет систематизировать знания понять свои пробелы, увидеть эволюцию проектирования, что в конечном итоге позволит вам выйти на новый уровень, составить план развития, а может и сменить работу (такие прецеденты у нас уже есть))).
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, каким путем стоит идти вместе с командой, чтобы повысить качество результата работы аналитиков, посмотрите со стороны на свою работу, артефакты анализа. Будете понимать на что обращать внимание в качестве наставника.
Формат курса - онлайн занятия, приближенные к классической схеме обучения,
✅в четверг лекция (утром по Москве с 9 до 11),
✅во вторник семинар - разбор домашних заданий (утром по Москве с 9 до 11).
Наш формат похож на формат групповых менторских сессий, где ведущие общаются с группой и сразу, по ходу, могут обсуждать возникающие вопросы. Мы подстраиваемся под уровень знаний участников и стараемся давать новый блок информации так, чтобы он ложился на текущий фундамент. Мы не являемся огромной школой или площадкой, что позволяет нам создавать уютное, открытое общение и делиться опытом между собой.
Сколько сможете унести знаний зависит только от вас))
Многие ребята пересматривают записи занятий и узнают снова и снова что-то новое.
➡️ Презентации
➡️ Материал
➡️ Видео записи занятий остаются у вас навсегда!
Мы предлагаем разные тарифы обучения:
Можно прийти на тариф "только послушать", участвовать в онлайн формате в обсуждениях, интерактивных практиках.
Если вы хотите разрабатывать учебный проект и выполнять домашние задания по проектированию, для вас подходит тариф "плюс практика", с разбором домашних заданий.
Мы специально проводим занятия в утреннее время в будние, чтобы вы со свежей головой смогли разобраться в сложной системной информации. Учиться и работать одновременно это действительно сложно, поэтому мы стараемся создать условия, чтобы вы успешно прошли весь аналитический марафон вместе с нами)) Каждый новый поток для нас, как новый вызов!
Имея чёткое расписание, просто приходя на занятия, вы точно сможете почерпнуть для себя полезные знания.
Ведущие:
Основные лекции по проектированию провожу я, Косинова Наталья, мой опыт интеграции более 15 лет, восновном шинная интеграция проектов Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.
Мне помогает
Андрей Корниенко, с точки зрения разработчика и архитектора раскрывает тему технологий, архитектуры решений и интеграции с помощью брокеров сообщений. Именно взгляда разработчика часто не хватает аналитику, когда речь идёт о реализации решения.
Чтобы записаться на курс оставьте свою заявку на нашем сайте
Если у вас остались вопросы, пишите в комментариях, я обязательно отвечу
До встречи на занятиях!
#анонс #курсинтеграции #интеграция #системныйаналитик #системныйанализ #мойопыт
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
Аналитик, догони разработку!
Часто аналитик попадает в ловушку под названием "разработка опережает анализ".
При этом аналитик начинает летать в облаках "вот, вот, я сейчас поднажму и всех догоню!", ага, ага, плавали знаем... Турбо ускорителя у меня нет, да думаю и у вас тоже нет, у меня ни разу не получалось.
А кто-то скажет, а что в этом такого? Пусть разработка опережает, ничего страшного.
При этом мы видим загнанноголошадь аналитика, который уже на грани срыва, где глаза наполняются слезами и он не понимает зачем он нужен, что он тут делает и весь мир тлен.
А ещё к этому добавим ситуацию "я один аналитик на проекте и мне нужно догонять"😵💫 и он превращается в тестировщика, технического писателя, не может раскрыть весь свой потенциал, а может грешным делом думает, что всё в порядке, но тайно вечерами мечтает уволиться.
В такой ситуации аналитик больше похож на уборщицу магазина, которая ходит нонстоп за посетителями и вытирает след от грязных ботинок. Но попросить разуться при входе, не может, так вроде заведено...
Я сама попадала в такие ситуации, при этом мой непосредственный руководитель считал, что всё хорошо.
-------------------------------
Что можно с этим сделать:
✅ первое признать, что что-то не так в процессах и их нужно менять, и продавать эту мысль руководителю (даже если он не верит, можно капать на мозг)
✅ второе, вспомнить зачем нужен анализ и технические задания, зачем нужен аналитик (кто-то скажет, он нам не нужен, хорошо, тогда не нанимайте подобных специалистов и не ждите от них результатов ). Аналитик занимается проектированием, а оно в свою очередь нужно перед разработкой программных продуктов, для описания решения на языке требований, чтобы в конечном итоге снизить неопределённость и уменьшить количество переделок.
✅ аналитик помогает ускорить процесс разработки (на моем опыте, команда с хорошим аналитиком начинает "съедать" backlog задач быстрее в 2 раза)
✅ признаться аналитику, что вам нужен тестировщик или технический писатель, а что?)) может правда нужны другие специалисты
✅ и в конце концов поставить анализ перед разработкой, и дать аналитику возможность опережать разработку хотя бы на полспринта, а лучше на целый спринт.
Иногда стоит просто открыть рот и начать говорить, о том, что что-то не так. И просить изменить процесс.
И тогда наш аналитик:
😏 - повеселеет (руководство чаще всего думают, что все аналитики вечно в депрессии из-за кислого выражения лица, просто мы знаем чуть больше и нам трудно)))
😎 -станет более заряженный, будет действовать в интересах команды и приносить проработанные задачи на обсуждение разработчикам.
А тут, глядишь и оценка сроков станет более чёткой)))
Сплошные плюсы, а всего лишь, всё расставили по своим местам))
#мойопыт #системныйаналитик #системныйанализ #больаналитика #управление #смертныегрехи #догониразработку
Часто аналитик попадает в ловушку под названием "разработка опережает анализ".
При этом аналитик начинает летать в облаках "вот, вот, я сейчас поднажму и всех догоню!", ага, ага, плавали знаем... Турбо ускорителя у меня нет, да думаю и у вас тоже нет, у меня ни разу не получалось.
А кто-то скажет, а что в этом такого? Пусть разработка опережает, ничего страшного.
При этом мы видим загнанного
А ещё к этому добавим ситуацию "я один аналитик на проекте и мне нужно догонять"
В такой ситуации аналитик больше похож на уборщицу магазина, которая ходит нонстоп за посетителями и вытирает след от грязных ботинок. Но попросить разуться при входе, не может, так вроде заведено...
Я сама попадала в такие ситуации, при этом мой непосредственный руководитель считал, что всё хорошо.
-------------------------------
Что можно с этим сделать:
✅ первое признать, что что-то не так в процессах и их нужно менять, и продавать эту мысль руководителю (даже если он не верит, можно капать на мозг)
✅ второе, вспомнить зачем нужен анализ и технические задания, зачем нужен аналитик (
✅ аналитик помогает ускорить процесс разработки (на моем опыте, команда с хорошим аналитиком начинает "съедать" backlog задач быстрее в 2 раза)
✅ признаться аналитику, что вам нужен тестировщик или технический писатель, а что?)) может правда нужны другие специалисты
✅ и в конце концов поставить анализ перед разработкой, и дать аналитику возможность опережать разработку хотя бы на полспринта, а лучше на целый спринт.
Иногда стоит просто открыть рот и начать говорить, о том, что что-то не так. И просить изменить процесс.
И тогда наш аналитик:
А тут, глядишь и оценка сроков станет более чёткой)))
Сплошные плюсы, а всего лишь, всё расставили по своим местам))
#мойопыт #системныйаналитик #системныйанализ #больаналитика #управление #смертныегрехи #догониразработку
Please open Telegram to view this post
VIEW IN TELEGRAM
Квотирование в интеграции, что это такое и зачем нужно?
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Как выбрать паттерн интеграции?
Это любимый вопрос аналитика. И его можно понять, ибо ставя задачу на разработку и не понимая, как принимаются решения, сложно контролировать и принимать результат работы. Чувство не самое приятное, ты в команде, но почему так сделали непонятно.
➡️ Один из ответов, к сожалению, звучит так - потому что так сложилось. 🤷♀ Действительно, часто нет логического чёткого объяснения почему так.Потому что наш директор поехал на презентацию, там выпил водки и купил лицензию по шине, а теперь нам с ней работать. Занавес.
➡️ Следующий ответ звучит, как - а мы только так можем, и никак по-другому. Действительно, команда просто по-другому не умеет, и делает так, как привычно. Нет компетенций, опыта, бюджета на новое, на обучение. Всё что угодно. Оно работает? Работает. Тогда не ломай, не трогай.
➡️ Дальше, самый сок, когда ты думаешь, ну вот сейчас будет шина, а вот тут брокер. Но приходит партнёр и говорит - у нас нет разработчиков, и вообще мы, уходя на выходные, выключаем сервер. У нас был такой кейс. И тут кроме интеграции через электронную почту, у нас не было больше никаких других вариантов. Даже с файлами они не хотели работать.
➡️ И если включать здравый смысл и логику, то нужно исходить из бизнес требований, нефункциональных требований, объёма передачи данных, масштабирования, развития компании, ИТ-ландшафта, ограничений бюджета,и конечно сотрудников.
Какие есть Паттерны?
По способу передачи данных:
Обмен данных с помощью
✅ файлов
✅ общей базы данных - это антипаттерны интеграции, от них лучше уходить.
Те кто хоть раз подобные паттерны пытался поддерживать в продуктиве могут рассказать множество замечательных историй, про седые волосы и бессонные ночи.
И остаётся чаще всего применяемые паттерны -
✅ удалённый вызов процедур
✅ обмен сообщениями (шина, брокер).
Удалённый вызов процедур - по сути онлайн обмен между двух систем, которые соединены напрямую, через API.
Брокер - это работа с абстракцией в виде очереди, которая может быть реализована по-разному (например, на основе протокола AMQP).
Шина - это швейцарский ножик, который вбирает в себя все Паттерны и нюансы управления интеграционным слоем.
Шина с централизованным обменом данных является одним из паттернов SOA архитектуры.
Брокер может быть с очередями частью шины или способом передачи сообщений в микросервисной архитектуре.
В реальности в ИТ-ландшафте компаний можно встретить гибрид из всех паттернов интеграции по способу передачи данных.
И каждый из них имеет свои плюсы и минусы, применимость в конкретных случаях, среде.
И кажется, что в айти всё логично, и есть обоснование всему, что происходит. Но нет. Часто скрытых смыслов и большого пути принятия решений попросту нет.
Подробнее про проектирование интеграционных решений вы можете узнать на нашем курсе, старт потока уже в этот четверг 16 ноября.
Почитать про курс можно вот тут➡️ sup.expert
#курсинтеграции #курс #системныйанализ #паттерныинтеграции
⚡️ Остались вопросы или вы хотите записаться, пишите напрямую мне))
Это любимый вопрос аналитика. И его можно понять, ибо ставя задачу на разработку и не понимая, как принимаются решения, сложно контролировать и принимать результат работы. Чувство не самое приятное, ты в команде, но почему так сделали непонятно.
➡️ Один из ответов, к сожалению, звучит так - потому что так сложилось. 🤷♀ Действительно, часто нет логического чёткого объяснения почему так.
➡️ Следующий ответ звучит, как - а мы только так можем, и никак по-другому. Действительно, команда просто по-другому не умеет, и делает так, как привычно. Нет компетенций, опыта, бюджета на новое, на обучение. Всё что угодно. Оно работает? Работает. Тогда не ломай, не трогай.
➡️ Дальше, самый сок, когда ты думаешь, ну вот сейчас будет шина, а вот тут брокер. Но приходит партнёр и говорит - у нас нет разработчиков, и вообще мы, уходя на выходные, выключаем сервер. У нас был такой кейс. И тут кроме интеграции через электронную почту, у нас не было больше никаких других вариантов. Даже с файлами они не хотели работать.
➡️ И если включать здравый смысл и логику, то нужно исходить из бизнес требований, нефункциональных требований, объёма передачи данных, масштабирования, развития компании, ИТ-ландшафта, ограничений бюджета,и конечно сотрудников.
Какие есть Паттерны?
По способу передачи данных:
Обмен данных с помощью
✅ файлов
✅ общей базы данных - это антипаттерны интеграции, от них лучше уходить.
Те кто хоть раз подобные паттерны пытался поддерживать в продуктиве могут рассказать множество замечательных историй, про седые волосы и бессонные ночи.
И остаётся чаще всего применяемые паттерны -
✅ удалённый вызов процедур
✅ обмен сообщениями (шина, брокер).
Удалённый вызов процедур - по сути онлайн обмен между двух систем, которые соединены напрямую, через API.
Брокер - это работа с абстракцией в виде очереди, которая может быть реализована по-разному (например, на основе протокола AMQP).
Шина - это швейцарский ножик, который вбирает в себя все Паттерны и нюансы управления интеграционным слоем.
Шина с централизованным обменом данных является одним из паттернов SOA архитектуры.
Брокер может быть с очередями частью шины или способом передачи сообщений в микросервисной архитектуре.
В реальности в ИТ-ландшафте компаний можно встретить гибрид из всех паттернов интеграции по способу передачи данных.
И каждый из них имеет свои плюсы и минусы, применимость в конкретных случаях, среде.
И кажется, что в айти всё логично, и есть обоснование всему, что происходит. Но нет. Часто скрытых смыслов и большого пути принятия решений попросту нет.
Подробнее про проектирование интеграционных решений вы можете узнать на нашем курсе, старт потока уже в этот четверг 16 ноября.
Почитать про курс можно вот тут
#курсинтеграции #курс #системныйанализ #паттерныинтеграции
Please open Telegram to view this post
VIEW IN TELEGRAM
Реальные результаты наших участников курса интеграции.
В большинстве своём на курс приходят ребята, кто был у меня на менторстве, оно и понятно, но и не только! У каждого свои цели. И вот немного классифицирую, по грейдам, кто что уносит и использует на практике:
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
Хотите, чтобы…
Требования - это же не rocket science, что тут сложного?
Когда ко мне на менторство или на курсы приходят аналитики, особенно с опытом, на вопрос умеют ли они собирать требования и их формулировать? Все с большой уверенностью говорят да.
Мы копаем дальше, но в какой-то момент понимаем, что нужно вернуться к базовым вещам, их скорректировать, и ещё раз разобрать работу с требованиями, их классификацию.
Правда, эти требования уже всех задолбали, но сколько можно о них говорить?) Дайте, что-то поинтереснее!
✅ Требования - это ключевая единица результата работы аналитика.
По факту аналитик, даже с опытом, может не видеть нюансы. Это нормально. Я сама такая же, не сразу доходит.
Хотя казалось бы #капитаночевидность, что тут сложного, разложи требования по уровням:
БТ (бизнес),
ПТ (пользователь),
ФТ (функция),
НФТ (ограничения),
СТ (система).
Но чем проще инструмент, тем сложнее с ним работать))) прям #ладайламинг
Суть проблемы, состоит в том, что аналитик не видит разные уровни абстракции, не видит нюансы, какое требование к чему относится. И на выходе получается каша, и не всегда понятно на каком уровне мы сейчас находимся? Бизнес, Пользователь, Функция, или Система?
#работастребованиями #системныйанализ #системныйаналитик #требования
Что с этим делать? Своё мнение расскажу завтра, а пока пишите свои варианты в комментариях 👇
Когда ко мне на менторство или на курсы приходят аналитики, особенно с опытом, на вопрос умеют ли они собирать требования и их формулировать? Все с большой уверенностью говорят да.
Мы копаем дальше, но в какой-то момент понимаем, что нужно вернуться к базовым вещам, их скорректировать, и ещё раз разобрать работу с требованиями, их классификацию.
✅ Требования - это ключевая единица результата работы аналитика.
По факту аналитик, даже с опытом, может не видеть нюансы. Это нормально. Я сама такая же, не сразу доходит.
Хотя казалось бы #капитаночевидность, что тут сложного, разложи требования по уровням:
БТ (бизнес),
ПТ (пользователь),
ФТ (функция),
НФТ (ограничения),
СТ (система).
Но чем проще инструмент, тем сложнее с ним работать))) прям #ладайламинг
Суть проблемы, состоит в том, что аналитик не видит разные уровни абстракции, не видит нюансы, какое требование к чему относится. И на выходе получается каша, и не всегда понятно на каком уровне мы сейчас находимся? Бизнес, Пользователь, Функция, или Система?
#работастребованиями #системныйанализ #системныйаналитик #требования
Что с этим делать? Своё мнение расскажу завтра, а пока пишите свои варианты в комментариях 👇
Что же поможет аналитику при работе с требованиями?
✅Первое, это начать замечать уровни требований. Чтобы заметить проблему, её нужно сначала просто назвать. Тут поможет пирамида артефактов, дополнительные вопросы.
✅Второе, это инструменты выявления и фиксирования требований, нотации в том числе в помощь. Всё зависит от уровня требований. Если мы находимся на бизнес уровне, так на языке этого уровня и нужно говорить, брать бизнес-модели, орг структуру, бизнес-процессы.
✅Третье, это абстрактное мышление. До сих пор ведутся споры, что такое мышление, а тут ещё и абстрактное. Но действительно оно есть, способ думать так, чтобы минимально опираться на самое решение, разработку. Это действительно сложно. И подобный навык дают технические вузы, но как любое мышление, абстрактное мышление можно развивать.
✅Четвёртое, логика и взаимносвязи наших требований. Тут помогут знания по формальной логики, теория по пирамиде Минто, теория графов, математика. Но я бы ещё добавила и философию. Всё в системе даёт результат.
✅Пятое, банальные вещи, опыт, насмотренность, вопросы старшим коллегам, активность. Да и просто иногда нужно делать, как другие.
✅Шестое, знания методологий разработки программных продуктов. Всё таки среда очень сильно влияет и необходимо подстроиться под заказчика и команду одновременно.
✅Седьмое, понимание, когда нужно остановиться. Чем больше требований вы описываете на низком уровне, тем больше падает качество результата.
✅Восьмое, знание технологий, подходов в программирование. Всё таки аналитик должен иметь знания, не только на уровне бизнеса, но и на уровне информационных систем (я говорю про системного аналитика). Банально, но часто аналитик даже не может сказать заказчику - "такого не существует".
✅Девятое, soft skills, никто не отменял. Адекватность, умение открыть рот и начать говорить, кажется очень простым навыком, но по факту, это нефига не просто.
#требования #системныйаналитик #работастребованиями #чеклист #системныйанализ #моемнение
А что вам помогает в работе? Пишите в комментариях 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
Я боюсь, что разработчики решат, что я дурачок.
Аналитики перфекционисты, и возмутители спокойствия одновременно.
Часто аналитик находится в ситуации:
✅- все всё понимают, я не понимаю,
✅- якобы все знают, что я должен выдать и как, но почему-то мне не говорят и я как сапёр хожу по минированному полю,
✅- боюсь, сделать неверный шаг в сторону и возмутить спокойствие и будет взрыв негодования.
Что могу сказать...
Пусть будет взрыв!
Пусть назовут дурачком. Вы то знаете о себе правду лучше других 😎
Возможно, это будет сексизм, но иногда разработчики более лояльны к девушкам, "ну что с неё взять, она девушка. Какой-то бред написала. Ну и пусть..."
Но я много раз в свою сторону получала взрыв эмоций под названием "какой мудак это написал!?"
Раньше я переживала, а теперь я понимаю, что такие эмоции это моё оружие. И когда все партизаны вокруг и ничего не говорят, я могу подготовить несколько вариантов диаграммы (а почему бы и не да!).
Сначала показать ту, которая вызовет взрыв эмоций, и на этих эмоциях "всё не так", я получу ответ, а "как надо". Только записывай. А если этот вариант совпадает с тем, что у меня есть в портфеле вариантов, то я как фокусник из рукава достану вариант со словами "а кстати говоря, у меня есть то, о чем вы говорите, так хотели бы? Посмотрим вместе?"
Но надо дождаться, когда вулкан эмоций выльется, и тогда можно показать вариант, а можно и чуть позже показать вариант, дав людям управлять ситуацией.
Хитро? Наверное.
Работа выполнена? Да.
А о способе получения информации уже никто и не вспомнит.
Тут единственное но нужно учиться ставить границы, что этот взрыв эмоций, не потому что я плохой специалист, а потому что я управляю этой ситуацией и использую этот способ выявления требований, подкинув катализатор.
Конечно риски такого способа тоже нужно взвесить, чтобы не влияло на вашу репутацию.
И быть готовым к разному развитию событий.
А вы какие используете катализаторы в работе?
#сбортребований #катализатор #лайфхаки #капитаночевидность #системныйанализ #мойопыт #моемнение #выявлениетребований
Аналитики перфекционисты, и возмутители спокойствия одновременно.
Часто аналитик находится в ситуации:
✅- все всё понимают, я не понимаю,
✅- якобы все знают, что я должен выдать и как, но почему-то мне не говорят и я как сапёр хожу по минированному полю,
✅- боюсь, сделать неверный шаг в сторону и возмутить спокойствие и будет взрыв негодования.
Что могу сказать...
Пусть будет взрыв!
Пусть назовут дурачком. Вы то знаете о себе правду лучше других 😎
Возможно, это будет сексизм, но иногда разработчики более лояльны к девушкам, "ну что с неё взять, она девушка. Какой-то бред написала. Ну и пусть..."
Но я много раз в свою сторону получала взрыв эмоций под названием "какой мудак это написал!?"
Раньше я переживала, а теперь я понимаю, что такие эмоции это моё оружие. И когда все партизаны вокруг и ничего не говорят, я могу подготовить несколько вариантов диаграммы (а почему бы и не да!).
Сначала показать ту, которая вызовет взрыв эмоций, и на этих эмоциях "всё не так", я получу ответ, а "как надо". Только записывай. А если этот вариант совпадает с тем, что у меня есть в портфеле вариантов, то я как фокусник из рукава достану вариант со словами "а кстати говоря, у меня есть то, о чем вы говорите, так хотели бы? Посмотрим вместе?"
Но надо дождаться, когда вулкан эмоций выльется, и тогда можно показать вариант, а можно и чуть позже показать вариант, дав людям управлять ситуацией.
Хитро? Наверное.
Работа выполнена? Да.
А о способе получения информации уже никто и не вспомнит.
Тут единственное но нужно учиться ставить границы, что этот взрыв эмоций, не потому что я плохой специалист, а потому что я управляю этой ситуацией и использую этот способ выявления требований, подкинув катализатор.
Конечно риски такого способа тоже нужно взвесить, чтобы не влияло на вашу репутацию.
И быть готовым к разному развитию событий.
А вы какие используете катализаторы в работе?
#сбортребований #катализатор #лайфхаки #капитаночевидность #системныйанализ #мойопыт #моемнение #выявлениетребований