#теория #мысливслух #рассуждения #моемнение #мойопыт
На днях снова коснулась темы, что аналитик работает с высокой степенью неопределенности. #капитаночевидность
Но с этой неопределенностью связана работа не только по набору информации для систематизации, структуризации, но ещё и большая часть soft skills.
Не было исследований насчёт того, каким психотипом в основном обладают аналитики, но буду говорить за себя. Я реально параноик, даже в хорошем смысле этого слова))) Мой мозг будет безумно возмущен, если что-то непонятно. Мне нужно прежде всего объяснить себе. Иначе я впадаю в злость, потом в растерянность. И если информацию, в частности на курсах, мне дают не системно, я просто превращаюсь в язву и начинаю всех мочить. Не очень красиво))) Я терплю, но иногда понимаю, что нет смысла терпеть, не идёт, не то. Да, у меня и к себе, и у другим часто завышенные требования.
И тут возникает скилл под названием "всё в порядке", это не я такая тупая, это информации мало, неопределенность очень высокая, что нормально. И тут мы приходим к тому, что аналитик, та самая роль, которая эту #неопределенность должна уменьшить. Знания, нотации, подходы, инструменты всё даёт возможность описать модель реального мира, того самого проекта, над которым нужно работать.
И злиться, беситься, впадать в уныние "мне понятно, что ничего непонятно", но проект мы уже делаем это нормально. Это можно наработать, научится переживать эти стадии.
Можно себя представить мышью, которая поедает сыр, я об этом писала вот тут - https://t.me/start_in_IT/315
Можно и нужно себе рассказать, что предметная область, проекты, и наш реальный мир очень сложный. И как не крути, на сложных проектах нужно пройти стадии обучения, освоения материала. Три месяца не просто так даются на испытательном сроке, не говоря уже об удаленке, где до полугода можно ходить в тумане неопределенности.
Как погружаться в предметную область я писала в постах и серии подкастов:
1.https://t.me/start_in_IT/420
2.https://t.me/start_in_IT/422
3.https://t.me/start_in_IT/425
4.https://t.me/start_in_IT/430
5.https://t.me/start_in_IT/433
Ещё мне нравится #конуснеопределенности, он отлично визуализирует стадии проекта, и возвращаясь к цели анализа - мы снова получаем основу в виде - снижения уровня риска переделок на стадии сдачи проекта. И снова приходим к тому, что с точки зрения психологии нужно учиться управлять эмоциями, хотя бы их называть уже будет круто, сохранять самообладание, не впадать в уныние, работать с самооценкой и возвращать себя в реальность, опираясь на факты.
P. S.
Про конус неопределенности можно посмотреть старое видео Сергея Нужненко - https://vimeo.com/61968936
На днях снова коснулась темы, что аналитик работает с высокой степенью неопределенности. #капитаночевидность
Но с этой неопределенностью связана работа не только по набору информации для систематизации, структуризации, но ещё и большая часть soft skills.
Не было исследований насчёт того, каким психотипом в основном обладают аналитики, но буду говорить за себя. Я реально параноик, даже в хорошем смысле этого слова))) Мой мозг будет безумно возмущен, если что-то непонятно. Мне нужно прежде всего объяснить себе. Иначе я впадаю в злость, потом в растерянность. И если информацию, в частности на курсах, мне дают не системно, я просто превращаюсь в язву и начинаю всех мочить. Не очень красиво))) Я терплю, но иногда понимаю, что нет смысла терпеть, не идёт, не то. Да, у меня и к себе, и у другим часто завышенные требования.
И тут возникает скилл под названием "всё в порядке", это не я такая тупая, это информации мало, неопределенность очень высокая, что нормально. И тут мы приходим к тому, что аналитик, та самая роль, которая эту #неопределенность должна уменьшить. Знания, нотации, подходы, инструменты всё даёт возможность описать модель реального мира, того самого проекта, над которым нужно работать.
И злиться, беситься, впадать в уныние "мне понятно, что ничего непонятно", но проект мы уже делаем это нормально. Это можно наработать, научится переживать эти стадии.
Можно себя представить мышью, которая поедает сыр, я об этом писала вот тут - https://t.me/start_in_IT/315
Можно и нужно себе рассказать, что предметная область, проекты, и наш реальный мир очень сложный. И как не крути, на сложных проектах нужно пройти стадии обучения, освоения материала. Три месяца не просто так даются на испытательном сроке, не говоря уже об удаленке, где до полугода можно ходить в тумане неопределенности.
Как погружаться в предметную область я писала в постах и серии подкастов:
1.https://t.me/start_in_IT/420
2.https://t.me/start_in_IT/422
3.https://t.me/start_in_IT/425
4.https://t.me/start_in_IT/430
5.https://t.me/start_in_IT/433
Ещё мне нравится #конуснеопределенности, он отлично визуализирует стадии проекта, и возвращаясь к цели анализа - мы снова получаем основу в виде - снижения уровня риска переделок на стадии сдачи проекта. И снова приходим к тому, что с точки зрения психологии нужно учиться управлять эмоциями, хотя бы их называть уже будет круто, сохранять самообладание, не впадать в уныние, работать с самооценкой и возвращать себя в реальность, опираясь на факты.
Про конус неопределенности можно посмотреть старое видео Сергея Нужненко -
Telegram
Наталья PRO-Анализ. Записки специалиста
#новаяпредметнаяобласть #капитаночевидность #методсыримышь #бизнесаналитик #системныйаналитик #аналитикIT #мойопыт
За последние дни несколько раз рассказывала про метод поедания сыра мышью.
Не буду говорить за всех, но когда у меня новая среда и ничего…
За последние дни несколько раз рассказывала про метод поедания сыра мышью.
Не буду говорить за всех, но когда у меня новая среда и ничего…
#анонс #китайскаяручка #тренинг #очно #системныйаналитик #требования
После своего долгого молчания возвращаюсь с анонсом!
Решила вспомнить былое и провести очный тренинг "Китайская ручка", по сбору требований!Сейчас Китай это модно, тем более Си++ прилетел в Москву.
Спасибо автору тренинга Сергею Нужненко за информацию и поддержку.
Кому нужен тренинг? Я бы сказала всем. Даже аналитики с опытом делают для себя выводы. Но будем объективными, что тренинг важен прежде всего начинающим аналитикам, и тем кто понимает, что буксует в части сбора, систематизации и анализа требований.
Тренинг будет проходить в виде игры в командах (или будет одна команда). Мы будем имитировать этапы:
✅интервью для сбора требований,
✅создания спецификации с
✅последующем согласованием,
✅изготовление,
✅приёмку результата с заказчиком.
Во второй части, мы затронем подход Agile, описание требований в виде user story, и составления user story mapping. Сравним подходы, посчитаем эффект.
Даты тренинга - 22 марта (среда, часть 1) и 29 марта (среда, часть 2) с 19:00 до 22:00.
Тренинг идёт две среды.
Стоимость 5000 рублей.
Адрес: (предварительно) зал в 5 минутах ходьбы от метро Кузнецкий мост, Москва
Регистрация - пишите сообщение мне в личку @tasha_kvitka
Если остались вопросы, пишите, спрашивайте!
После своего долгого молчания возвращаюсь с анонсом!
Решила вспомнить былое и провести очный тренинг "Китайская ручка", по сбору требований!
Спасибо автору тренинга Сергею Нужненко за информацию и поддержку.
Кому нужен тренинг? Я бы сказала всем. Даже аналитики с опытом делают для себя выводы. Но будем объективными, что тренинг важен прежде всего начинающим аналитикам, и тем кто понимает, что буксует в части сбора, систематизации и анализа требований.
Тренинг будет проходить в виде игры в командах (или будет одна команда). Мы будем имитировать этапы:
✅интервью для сбора требований,
✅создания спецификации с
✅последующем согласованием,
✅изготовление,
✅приёмку результата с заказчиком.
Во второй части, мы затронем подход Agile, описание требований в виде user story, и составления user story mapping. Сравним подходы, посчитаем эффект.
Даты тренинга - 22 марта (среда, часть 1) и 29 марта (среда, часть 2) с 19:00 до 22:00.
Тренинг идёт две среды.
Стоимость 5000 рублей.
Адрес: (предварительно) зал в 5 минутах ходьбы от метро Кузнецкий мост, Москва
Регистрация - пишите сообщение мне в личку @tasha_kvitka
Если остались вопросы, пишите, спрашивайте!
#типичныеошибки #системныйаналитик #сбортребований #капитаночевидность #какненужноделать #мысливслух #мойопыт
Расскажу про частые ошибки аналитиков. Особенно хорошо это видно на менторстве.
1.Номер один это паттерн поведения "я всё знаю и знаю лучше заказчика, что ему нужно". Часто такой Паттерн у руководителей проектов, либо аналитиков, которые пришли в профессию из смежных направлений из разработки, тестирования. И вспоминаем график, джуны часто думают о том, что всё знают и что там делать то.
2.Следующие грабли - это навязывать решение или фичи, которые не нужны заказчику. Но аналитик считает, что оно круто или я это видел у конкурентов. Наш велосипед ещё не едет, но давайте повесим фонарик или ещё лучше наклейки сделаем или счётчик расстояния, спидометр. И из велосипеда сделаем обвешенную погремушку, а в финале поймём, что не едет и надо бы накачать колеса.
3.Нефункциональные требования. Или как их называет Сергей Нужненко "волшебные" требования. Тут просто срабатывает триггер мозга "сложно, не хочу, не буду, неинтересно". В итоге на наш велосипед сможет сесть только ребёнок, потому что средний вес пассажира никто не сказал. Или велосипед просто угнали, а может сделали таких размеров, что он не влезает никуда и вообще стандарты, ГОСТы, ISO это для слабаков и это скучно.
4.Ещё аналитики очень любят рулить всем, стараются залезать в решение, архитектура, сроки, бюджеты и ныть, что всё ужасно. Я сама такая же))) и тут стоит возвращать себе свою роль и границы её, где и за что отвечает аналитик? А нытьё можно превращать в риски и анализировать сценарии, что может пойти не так и реализоваться в будущем.
Как можно научить себя не впадать в решение и развивать абстрактное мышление? Разные игры, теории, модели. Игра в шахматы, головоломки. Ну и конечно тренинги. Я думаю вы поняли к чему я веду?)
У вас есть шанс запрыгнуть в уходящий завтра поезд и поучаствовать в тренинге по сбору требований, где мы будем в том числе совершать типичные ошибки аналитиков, и понимать, как с ними справляться, на что обращать внимание, чтобы в будущих проектах работать эффективнее и стабильнее!🚀
А также будем практироваться в формулирование требований, а том числе и в Agile подходе.✅
Присоединяйтесь, анонс был выше! 😎
Расскажу про частые ошибки аналитиков. Особенно хорошо это видно на менторстве.
1.Номер один это паттерн поведения "я всё знаю и знаю лучше заказчика, что ему нужно". Часто такой Паттерн у руководителей проектов, либо аналитиков, которые пришли в профессию из смежных направлений из разработки, тестирования. И вспоминаем график, джуны часто думают о том, что всё знают и что там делать то.
2.Следующие грабли - это навязывать решение или фичи, которые не нужны заказчику. Но аналитик считает, что оно круто или я это видел у конкурентов. Наш велосипед ещё не едет, но давайте повесим фонарик или ещё лучше наклейки сделаем или счётчик расстояния, спидометр. И из велосипеда сделаем обвешенную погремушку, а в финале поймём, что не едет и надо бы накачать колеса.
3.Нефункциональные требования. Или как их называет Сергей Нужненко "волшебные" требования. Тут просто срабатывает триггер мозга "сложно, не хочу, не буду, неинтересно". В итоге на наш велосипед сможет сесть только ребёнок, потому что средний вес пассажира никто не сказал. Или велосипед просто угнали, а может сделали таких размеров, что он не влезает никуда и вообще стандарты, ГОСТы, ISO это для слабаков и это скучно.
4.Ещё аналитики очень любят рулить всем, стараются залезать в решение, архитектура, сроки, бюджеты и ныть, что всё ужасно. Я сама такая же))) и тут стоит возвращать себе свою роль и границы её, где и за что отвечает аналитик? А нытьё можно превращать в риски и анализировать сценарии, что может пойти не так и реализоваться в будущем.
Как можно научить себя не впадать в решение и развивать абстрактное мышление? Разные игры, теории, модели. Игра в шахматы, головоломки. Ну и конечно тренинги. Я думаю вы поняли к чему я веду?)
У вас есть шанс запрыгнуть в уходящий завтра поезд и поучаствовать в тренинге по сбору требований, где мы будем в том числе совершать типичные ошибки аналитиков, и понимать, как с ними справляться, на что обращать внимание, чтобы в будущих проектах работать эффективнее и стабильнее!🚀
А также будем практироваться в формулирование требований, а том числе и в Agile подходе.✅
Присоединяйтесь, анонс был выше! 😎
Команда считает, что ей не нужен аналитик.
#мысливслух #зачеманалитик #историиизжизни #развитие #чтоделать #мойопыт #ИТаналитик #проект #намненуженаналитик
А ещё можно накинуть - нам не нужна документация, мы итак без неё хорошо жили. Или пусть аналитик документирует то, что уже разработали. Правда что!!! Он же нам не нужен!!!
В каждой подобной фразе отдаётся боль.
Годы идут, но проблемы в отрасли те же самые. На тему "Зачем проекту аналитик?" я уже делала вебинар вместе с Евгением Галактионовым, рекомендую к просмотру, если у вас возникают подобные проблемы с командой, возможно какие-то мысли и инсайты для себя поймаете - https://www.youtube.com/live/sIi1JdB4Iow?feature=share
Но ещё я порассуждаю на эту тему.
Что же делать?
✅ 1.Хочется бежать из такой команды. И отчасти вы будете правы. Во-первых, если команда не работала никогда с аналитиком, а вот его наняли и вы такой красивый пришли и вот сейчас как заживём по-другому! То нет. Люди очень не любят перемены и изменения. С изменениями нужно работать и не всегда опыта, компетенций, да и вообще полномочий хватает аналитику. И часто не задача аналитика заниматься внедрением изменений внутренних процессов, хотя ему её могут поставить, и потом сказать, но ты же не справился.
✅2.Во вторых, не соглашаетесь писать требования после разработки продукта. Восстановить требования можно, но часто руководство воспринимает аналитика, как технического писателя, который "подтирает за командой" или администратора проекта. "Поздно пить боржоми, если почки уже отказали." Смысл работы аналитика теряется, и это первый шаг к выгоранию, делать не свои обязанности. А как быть? Аналитик должен опережать разработку, иначе выгода от его наличия на проекте теряется. Аналитик нужен для минимизации риска переделок на финише, и приближения результата к той проблеме и к тому эффекту, что хочет заказчик. Берите задачи с опережением спирта хотя бы на 0.5 спринта, а лучше на целый спринт вперёд, чтобы на планирование или груминге можно было получить от команды глубокие вопросы и более чёткую оценку по реализации задачи.
✅3."Нам не нужна документация, мы итак же без неё хорошо жили." Рост сложности проекта неизбежен, и вопрос с артефактами появится. Аналитик не технический писатель и он проектирует решение. Документация ради документации никому не нужна, кроме ситуаций с политическими играми в защите проекта. А спроектированные решения, костяк артефактов, и описание требований - это, то что необходимо для выравнивания контекста при общение с заказчиком и командой. Все должны быть в одной плоскости общения, чтобы исследовать проблему, спроектировать решение и приблизить проект к успеху.
✅4.Плюс - если ваша команда на удаленке - вам нужны артефакты, диаграммы, и вики проекта, для постоянного выравнивания общего контекста и коммуникации команды. Команда на удаленке часто получает проблему в коммуникации. Какие артефакты вам нужны и в каком объёме и на каком уровне детальности - решает команда и всё зависит от уровня компетенции участников, критичности и сложности проекта. Про артефакты, примерный их набор можно посмотреть в вебинаре "Пирамида артефактов" - https://www.youtube.com/live/Ua19ythnFvE?feature=share
✅5.Если уж давать, советы, то следующий совет - абстрагироваться от наездов команды и делать своё дело, желательно при этом подкрепляя всю свою деятельность поддержкой руководства (иначе работать с изменениями бесполезно). Всё таки вас зачем-то взяли на проект и поставили задачи? Чаще всего разговоры бесполезны, лучше показать результат своей работы. Вы же новый человек и уважение ещё нужно заслужить делами. Команда может молчать. Я как-то столкнулась с тем, что я зафиксировала решение несколькими диаграммами, спросила команду "Ну как? Что вам было полезно?" Все промолчали, а потом на ретро после спринта в самое хорошее за спринт записали мои диаграммы. Я была удивлена, и сделала вывод, что за молчанием может скрываться, что угодно, не стоит себя раскачивать фантазией.
#мысливслух #зачеманалитик #историиизжизни #развитие #чтоделать #мойопыт #ИТаналитик #проект #намненуженаналитик
А ещё можно накинуть - нам не нужна документация, мы итак без неё хорошо жили. Или пусть аналитик документирует то, что уже разработали. Правда что!!! Он же нам не нужен!!!
В каждой подобной фразе отдаётся боль.
Годы идут, но проблемы в отрасли те же самые. На тему "Зачем проекту аналитик?" я уже делала вебинар вместе с Евгением Галактионовым, рекомендую к просмотру, если у вас возникают подобные проблемы с командой, возможно какие-то мысли и инсайты для себя поймаете - https://www.youtube.com/live/sIi1JdB4Iow?feature=share
Но ещё я порассуждаю на эту тему.
Что же делать?
✅ 1.
✅2.Во вторых, не соглашаетесь писать требования после разработки продукта. Восстановить требования можно, но часто руководство воспринимает аналитика, как технического писателя, который "подтирает за командой" или администратора проекта. "Поздно пить боржоми, если почки уже отказали." Смысл работы аналитика теряется, и это первый шаг к выгоранию, делать не свои обязанности. А как быть? Аналитик должен опережать разработку, иначе выгода от его наличия на проекте теряется. Аналитик нужен для минимизации риска переделок на финише, и приближения результата к той проблеме и к тому эффекту, что хочет заказчик. Берите задачи с опережением спирта хотя бы на 0.5 спринта, а лучше на целый спринт вперёд, чтобы на планирование или груминге можно было получить от команды глубокие вопросы и более чёткую оценку по реализации задачи.
✅3."Нам не нужна документация, мы итак же без неё хорошо жили." Рост сложности проекта неизбежен, и вопрос с артефактами появится. Аналитик не технический писатель и он проектирует решение. Документация ради документации никому не нужна, кроме ситуаций с политическими играми в защите проекта. А спроектированные решения, костяк артефактов, и описание требований - это, то что необходимо для выравнивания контекста при общение с заказчиком и командой. Все должны быть в одной плоскости общения, чтобы исследовать проблему, спроектировать решение и приблизить проект к успеху.
✅4.Плюс - если ваша команда на удаленке - вам нужны артефакты, диаграммы, и вики проекта, для постоянного выравнивания общего контекста и коммуникации команды. Команда на удаленке часто получает проблему в коммуникации. Какие артефакты вам нужны и в каком объёме и на каком уровне детальности - решает команда и всё зависит от уровня компетенции участников, критичности и сложности проекта. Про артефакты, примерный их набор можно посмотреть в вебинаре "Пирамида артефактов" - https://www.youtube.com/live/Ua19ythnFvE?feature=share
✅5.Если уж давать, советы, то следующий совет - абстрагироваться от наездов команды и делать своё дело, желательно при этом подкрепляя всю свою деятельность поддержкой руководства (иначе работать с изменениями бесполезно). Всё таки вас зачем-то взяли на проект и поставили задачи? Чаще всего разговоры бесполезны, лучше показать результат своей работы. Вы же новый человек и уважение ещё нужно заслужить делами. Команда может молчать. Я как-то столкнулась с тем, что я зафиксировала решение несколькими диаграммами, спросила команду "Ну как? Что вам было полезно?" Все промолчали, а потом на ретро после спринта в самое хорошее за спринт записали мои диаграммы. Я была удивлена, и сделала вывод, что за молчанием может скрываться, что угодно, не стоит себя раскачивать фантазией.
YouTube
Зачем проекту аналитик? Наталья Косинова #системныйаналитик #системныйанализ
Обучение на системного аналитика с нуля— интенсивная онлайн-программа переподготовки https://ssa.io/IJOnVV
Вебинар "Зачем проекту аналитик?" покажет на наглядном примере из жизни плюсы и минусы разработки программных продуктов с отдельно выделенной ролью…
Вебинар "Зачем проекту аналитик?" покажет на наглядном примере из жизни плюсы и минусы разработки программных продуктов с отдельно выделенной ролью…
#системныйаналитик #прямойэфир #МарияГришина #переходвайти #проопыт #историиизжизни
Запись вчерашнего прямого эфира с Марией Гришиной)))
Говорили о том, как Маша перешла из бизнеса в айти, что помогло, какие цели ставила перед собой, как себя поддерживала.
Конечно поговорили "за жизнь", о собеседование, выгорание, гармонии между работой и жизнью, о том зачем нужно инженерное образование и о многом другом. Разговор получился живой и продолжительный и кажется, что осталось еще много тем, которые могут быть интересны специалистам)))
Запись видео можно посмотреть на youtube
https://youtu.be/9LYKP9754Ts
Аудиоверсия постом ниже 👇
Запись вчерашнего прямого эфира с Марией Гришиной)))
Говорили о том, как Маша перешла из бизнеса в айти, что помогло, какие цели ставила перед собой, как себя поддерживала.
Конечно поговорили "за жизнь", о собеседование, выгорание, гармонии между работой и жизнью, о том зачем нужно инженерное образование и о многом другом. Разговор получился живой и продолжительный и кажется, что осталось еще много тем, которые могут быть интересны специалистам)))
Запись видео можно посмотреть на youtube
https://youtu.be/9LYKP9754Ts
Аудиоверсия постом ниже 👇
YouTube
Прямой эфир с Марией Гришиной от 06.07.2023 - "Как из бизнеса перейти в айти"
Мария рассказала о себе и о том, что помогло ей перейти в айти, какие для себя цели она ставила.
Мы поговорили не только о переходе в новую сферу, но и "за жизнь", про выгорание, про образование инженера, что собеседования и про жизненный опыт.
Присоединяйтесь…
Мы поговорили не только о переходе в новую сферу, но и "за жизнь", про выгорание, про образование инженера, что собеседования и про жизненный опыт.
Присоединяйтесь…
Вакансия, как чеклист развития аналитика)
#чеклист #планразвития #senior #системныйаналитик
С одной стороны #реклама #вакансия
А с другой стороны описание, которое смело можно превратить для себя в чеклист, как мне стать аналитиком сеньорного уровня?
Описание настолько хорошо, что хочется пообщаться с командой, конечно ещё нужно понимать, что это описание сделал Сергей Нужненко.
Если вас заинтересовала вакансия, смело пишите📝 в личку Сергею @darkboatman
---------------
Ведущий/старший системный аналитик 🥷
Аналитик нужен на проект по построению новой системы авиабилетного агрегатора в качестве старшего/ведущего аналитика по системе чтобы помочь ИТ-команде превращать концепции от бизнеса в ясные и непротиворечивые постановки к задачам разработки.
Что, делать:
- Выявлять, собирать и разрабатывать требования к системе в тесном взаимодействии с бизнес-аналитиком, представителями бизнеса и разработчиками.
- Помогать команде документировать системную архитектуру и системный дизайн.
- Прорабатывать потоки данных между отдельными сервисами, логические схемы данных, эскизы пользовательских интерфейсов, проектировать API вместе с разработкой.
- Помогать в проведении архитектурных сессий разработки с бизнесом для превращения требований в задачи команды.
- Документировать бизнес-процессы, требования, функции, архитектуру, интерфейсы, алгоритмы, структуры данных системы в необходимом разработке и бизнесу объеме вместе с бизнес-аналитиком.
- Разрабатывать детальные постановки к задачам разработки, сопровождать разработку и тестирование ответами на вопросы и недостающими деталями постановок.
- Участвовать в приемке и поддержке пользователей.
Чего мы ждем от кандидата:
- Умение моделировать и описывать деятельность, функции, структуры данных, интерфейсы, алгоритмы.
- Умение работать с требованиями.
- Знакомство с основными концепциями процедурного и объектно-ориентированного программирования.
- Умение моделировать и описывать архитектуру и дизайн систем и программных приложений.
- Готовность изучать и применять инструменты и технологии, выбранные командой для работы.
- Знакомство с концепциями REST API (JSON), SOAP (XML/XSD/WSDL)
- Знакомство с принципами проектрования реляционных БД.
- Грамотный русский язык, умение структурировать текст в документах, письмах, тикетах.
- Навыки деловой коммуникации, проведения интервью, донесения мыслей, подготовки и проведения презентаций, обсуждения решений и конструктивного отстаивания своей позиции.
- Понимание жизненного цикла ИТ-систем, процессов разработки, сопровождения и развития ПО.
Не обязательно, но приветствуется широкий кругозор и наличие знаний и навыков проектирования систем. В том числе:
- Знакомство с формальной логикой.
- Знакомство с классификацией и атрибутами качества требований.
- Опыт работы с системами моделирования, Sparx Systems Enterprise Architecht, Visual Paradigm или другими.
- Отсутствие "аллергии" на высшую математику, в том числе дискретную математику, структуры данных и алгоритмы, реляционную алгебру.
- Знакомство со стандартами, нотациями и практиками моделирования IDEFx, DFD, UML, BPMN, ARIS и др.
- Знакомство с подходами к описанию функций в виде Use Case, User Story, пользовательских сценариев.
- Знакомство с Agile практиками Story mapping, Event storming, CJM, Service Blueprint, 4 context architecture.
- Практики бизнес-анализа, в том числе Busines Canvas, понимание структуры бизнес-плана, умение работать с бизнес-целями, проектированием бизнес-процессов и обоснованием ценности проектов и фич.
- Знакомство с ГОСТ серии 34 и 19 и современными стандартами системной инженерии и управления требованиями.
- Опыт фасилитации групповых рабочих сессий.
- Навыки проектирования баз данных.
- Знакомство с Domain Driven Design, шаблонами интеграции приложений, шаблонами реализации микросервисной архитектуры.
#чеклист #планразвития #senior #системныйаналитик
С одной стороны #реклама #вакансия
А с другой стороны описание, которое смело можно превратить для себя в чеклист, как мне стать аналитиком сеньорного уровня?
Описание настолько хорошо, что хочется пообщаться с командой, конечно ещё нужно понимать, что это описание сделал Сергей Нужненко.
Если вас заинтересовала вакансия, смело пишите
---------------
Ведущий/старший системный аналитик 🥷
Аналитик нужен на проект по построению новой системы авиабилетного агрегатора в качестве старшего/ведущего аналитика по системе чтобы помочь ИТ-команде превращать концепции от бизнеса в ясные и непротиворечивые постановки к задачам разработки.
Что, делать:
- Выявлять, собирать и разрабатывать требования к системе в тесном взаимодействии с бизнес-аналитиком, представителями бизнеса и разработчиками.
- Помогать команде документировать системную архитектуру и системный дизайн.
- Прорабатывать потоки данных между отдельными сервисами, логические схемы данных, эскизы пользовательских интерфейсов, проектировать API вместе с разработкой.
- Помогать в проведении архитектурных сессий разработки с бизнесом для превращения требований в задачи команды.
- Документировать бизнес-процессы, требования, функции, архитектуру, интерфейсы, алгоритмы, структуры данных системы в необходимом разработке и бизнесу объеме вместе с бизнес-аналитиком.
- Разрабатывать детальные постановки к задачам разработки, сопровождать разработку и тестирование ответами на вопросы и недостающими деталями постановок.
- Участвовать в приемке и поддержке пользователей.
Чего мы ждем от кандидата:
- Умение моделировать и описывать деятельность, функции, структуры данных, интерфейсы, алгоритмы.
- Умение работать с требованиями.
- Знакомство с основными концепциями процедурного и объектно-ориентированного программирования.
- Умение моделировать и описывать архитектуру и дизайн систем и программных приложений.
- Готовность изучать и применять инструменты и технологии, выбранные командой для работы.
- Знакомство с концепциями REST API (JSON), SOAP (XML/XSD/WSDL)
- Знакомство с принципами проектрования реляционных БД.
- Грамотный русский язык, умение структурировать текст в документах, письмах, тикетах.
- Навыки деловой коммуникации, проведения интервью, донесения мыслей, подготовки и проведения презентаций, обсуждения решений и конструктивного отстаивания своей позиции.
- Понимание жизненного цикла ИТ-систем, процессов разработки, сопровождения и развития ПО.
Не обязательно, но приветствуется широкий кругозор и наличие знаний и навыков проектирования систем. В том числе:
- Знакомство с формальной логикой.
- Знакомство с классификацией и атрибутами качества требований.
- Опыт работы с системами моделирования, Sparx Systems Enterprise Architecht, Visual Paradigm или другими.
- Отсутствие "аллергии" на высшую математику, в том числе дискретную математику, структуры данных и алгоритмы, реляционную алгебру.
- Знакомство со стандартами, нотациями и практиками моделирования IDEFx, DFD, UML, BPMN, ARIS и др.
- Знакомство с подходами к описанию функций в виде Use Case, User Story, пользовательских сценариев.
- Знакомство с Agile практиками Story mapping, Event storming, CJM, Service Blueprint, 4 context architecture.
- Практики бизнес-анализа, в том числе Busines Canvas, понимание структуры бизнес-плана, умение работать с бизнес-целями, проектированием бизнес-процессов и обоснованием ценности проектов и фич.
- Знакомство с ГОСТ серии 34 и 19 и современными стандартами системной инженерии и управления требованиями.
- Опыт фасилитации групповых рабочих сессий.
- Навыки проектирования баз данных.
- Знакомство с Domain Driven Design, шаблонами интеграции приложений, шаблонами реализации микросервисной архитектуры.
Please open Telegram to view this post
VIEW IN TELEGRAM
Чем сложна интеграция?
#интеграция #курсинтеграции #рассуждения #мойопыт #системныйаналитик #проектирование
Начну с того, что я люблю задачи по интеграции. Так сложились звезды, что свою карьеру я начала в команде шинной интеграции аж в 2006 году и интеграция, как "красная линия" идёт через весь мой опыт. Сейчас айти ландшафты стали сложнее, "развесистее", запутаннее и имеют часто "зоопарк" технологий и систем. И это нормально!
Конечно интеграция - это та самая задача, которая будет всегда актуальна. Интеграция систем конечно упрощается и по шаблонам больше похожа на конструктор, или обыденное действие "вставить вилку в розетку". Но имея всё вышеперечисленное в айти ландшафте, чтобы соединить/перестроить инфообмен систем нужно действительно заняться системным анализом.
И тогда команда проектирования сталкивается со следующими сложностями:
✅1.Первый пункт сложности - это разложить процесс на разные уровни абстракции. С точки зрения бизнеса, часто нет проблем в понимание. Мы соединяем бизнес процессы или соединяем обмен информацией на уровне справочников. Пользовательский уровень часто отсутствует, потому что пользователь далеко, либо наш пользователь это администратор системы. Вместо пользователя появляется уровень организационный, выстраивания информационного обмена между участниками.
✅2.Самое сложное это системный уровень, и чтобы спуститься на этот уровень нужны знания по технологиям передачи данных, устройство сетей, работа с API, понимание протоколов и их нюансов проектирования.
✅3.Как-то один руководитель мне сказал, а что сложного в интеграции? Передали данные, написали их маппинг делов то. Вот тут и кроется засада в виде выстраивания среды вокруг этой передачи данных. Тут появляется логирование, квотирование, мониторинг и те самые НФТ, которые описывают требования к безопасности, отказоустойчивости, масштабированию, доступности. Управления интеграцией! Администрирование! И в интеграции подобные вещи явно видны и критичны.
✅4.Ещё момент, про который почему-то многие аналитики забывают - это работа с ошибками/исключениями и выявление альтернатив с описанием их обработки. Конечно, есть моменты, которые вроде как очевидны разработчикам, но есть альтернативы неочевидные и решение по их обработке и реакции на события должны принимать бизнес-заказчики.
✅5.А теперь "тяжёлая артиллерия", это знание и понимание ООП. Да, да, да системному аналитику в интеграции нужны знания программирования. В основе большинства процессов лежат объекты и действия над ними, в интеграции нужно ещё и нырнуть на уровень проектирования процессов обработки объектов, так, чтобы не нарушить их жизненный цикл, а скорее выстроить в разрезе интеграционного взаимодействия. А в шинной интеграции у нас ещё и БД были, и вот тут тоже включаются компетенции связанные с проектированием реляционных баз данных.
И вот, что мы получаем в итоге? Что интеграция это частный случай проектирования информационных систем. И как бы не хотелось подобную задачу облегчить, и сделать понятной и шаблонной, всё равно мы сталкиваемся с тем, что компетенции аналитика в системном анализе, знаний технологий, основ проектирования информационных систем ООП, БД просто необходимо для адекватного решения задачи. Абы как "по быстрому", можно))) Но это вариант решения, за который сразу придёт немедленная расплата при выкатке на продуктив.
Размышляя на тему интеграции, я снова прихожу к выводу, что
Старт курса мы сдвинули на 21 сентября, и если интеграция для вас открытый, сложный вопрос, то наш курс для вас)
Регистрация по ссылке https://sup.expert/
#интеграция #курсинтеграции #рассуждения #мойопыт #системныйаналитик #проектирование
Начну с того, что я люблю задачи по интеграции. Так сложились звезды, что свою карьеру я начала в команде шинной интеграции аж в 2006 году и интеграция, как "красная линия" идёт через весь мой опыт. Сейчас айти ландшафты стали сложнее, "развесистее", запутаннее и имеют часто "зоопарк" технологий и систем. И это нормально!
Конечно интеграция - это та самая задача, которая будет всегда актуальна. Интеграция систем конечно упрощается и по шаблонам больше похожа на конструктор, или обыденное действие "вставить вилку в розетку". Но имея всё вышеперечисленное в айти ландшафте, чтобы соединить/перестроить инфообмен систем нужно действительно заняться системным анализом.
И тогда команда проектирования сталкивается со следующими сложностями:
✅1.Первый пункт сложности - это разложить процесс на разные уровни абстракции. С точки зрения бизнеса, часто нет проблем в понимание. Мы соединяем бизнес процессы или соединяем обмен информацией на уровне справочников. Пользовательский уровень часто отсутствует, потому что пользователь далеко, либо наш пользователь это администратор системы. Вместо пользователя появляется уровень организационный, выстраивания информационного обмена между участниками.
✅2.Самое сложное это системный уровень, и чтобы спуститься на этот уровень нужны знания по технологиям передачи данных, устройство сетей, работа с API, понимание протоколов и их нюансов проектирования.
✅3.Как-то один руководитель мне сказал, а что сложного в интеграции? Передали данные, написали их маппинг делов то. Вот тут и кроется засада в виде выстраивания среды вокруг этой передачи данных. Тут появляется логирование, квотирование, мониторинг и те самые НФТ, которые описывают требования к безопасности, отказоустойчивости, масштабированию, доступности. Управления интеграцией! Администрирование! И в интеграции подобные вещи явно видны и критичны.
✅4.Ещё момент, про который почему-то многие аналитики забывают - это работа с ошибками/исключениями и выявление альтернатив с описанием их обработки. Конечно, есть моменты, которые вроде как очевидны разработчикам, но есть альтернативы неочевидные и решение по их обработке и реакции на события должны принимать бизнес-заказчики.
✅5.А теперь "тяжёлая артиллерия", это знание и понимание ООП. Да, да, да системному аналитику в интеграции нужны знания программирования. В основе большинства процессов лежат объекты и действия над ними, в интеграции нужно ещё и нырнуть на уровень проектирования процессов обработки объектов, так, чтобы не нарушить их жизненный цикл, а скорее выстроить в разрезе интеграционного взаимодействия. А в шинной интеграции у нас ещё и БД были, и вот тут тоже включаются компетенции связанные с проектированием реляционных баз данных.
И вот, что мы получаем в итоге? Что интеграция это частный случай проектирования информационных систем. И как бы не хотелось подобную задачу облегчить, и сделать понятной и шаблонной, всё равно мы сталкиваемся с тем, что компетенции аналитика в системном анализе, знаний технологий, основ проектирования информационных систем ООП, БД просто необходимо для адекватного решения задачи. Абы как "по быстрому", можно))) Но это вариант решения, за который сразу придёт немедленная расплата при выкатке на продуктив.
Размышляя на тему интеграции, я снова прихожу к выводу, что
курс проектирования интеграции, который мы развиваем с Андреем Корниенко это ещё и курс молодого бойца по проектированию информационных систем. Пока мы не хотим менять формат, наш курс больше похож на менторство, где в онлайн формате с участниками мы проходим основные шаги реализации проекта и разбираем трудности, которые чаще всего появляются. Старт курса мы сдвинули на 21 сентября, и если интеграция для вас открытый, сложный вопрос, то наш курс для вас)
Регистрация по ссылке https://sup.expert/
sup.expert
Курс по интеграции
Чек-лист интеграции.
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских аналитиков, был написан коллективный чек-лист "Интеграции". Попытка как раз хоть как-то себе облегчить жизнь)))
Его и предоставляю вашему вниманию.
💥
--------------------------
1. Определить системы, участвующие в обмене
2. Описать потоки данных
3. Понять наличие гарантированной доставки данных
4. Описать регламент взаимодействия систем:
• передаваемые данные
• частота передачи
• расписание
• система-инициатор обмена
5. Описать формат передачи данных:
• Названия атрибутов
• Тип, длина
• Обязательность
• Кодировка
6. Зафиксировать маппинг данных из формата системы-источника в формат системы-приёмника.
7. Понять в какой системе хранятся мастер-данные по объектам.
8. Выявить необходимость преобразования/проверки на актуальность/обогащения данных.
9. Зафиксировать протоколы обмена данными.
10. Понять ограничения платформы/канала интеграции.
11. Нефункциональные требования:
• Выявить требования к скорости обработки и передачи данных.
• Понять необходимость шифрования данных.
• Оценить объем передаваемых данных.
• Понять наличие ограничений на уровне регулятора (152 ФЗ, PCI DSS).
12. Описать интеграционный сценарий взаимодействия.
13. Понять способ взаимодействия – синхронное/асинхронное.
14. Описать механизм обработки ошибок.
15. Выявить требования к настройкам и администрированию.
--------------------------
Каждый из пунктов мы подробно разбираем на курсе "Проектирование интеграции информационных систем", который я смело уже могу назвать менторским подходом вцелом к проектированию информационных систем с нуля, начиная с концепции, переходя с одного уровня абстракции на другой, добираясь до самого низкоуровневого описания.
✔️ Я и мой компаньон Андрей Корниенко, ведём курс в формате лекций, домашних заданий, обсуждений и менторства, чтобы показать, как именно аналитику нужно думать, чтобы спроектировать интеграцию.
✔️ У нас нет сумасшедших потоков, наше преимущество это работа в долгую, наш курс это аналитический марафон в 2 месяца. Мы специально даём время на освоение материала и его осознание.
✔️ Мы не фабрика, не огромная площадка, нам самим прежде всего интересно передать свои знания и опыт, так чтобы это было системно и структурно. Это даёт нам проявлять гибкость и нестандартно зачитывать материал.
📌 Подробнее о курсе можно прочитать тут https://sup.expert/
старт потока совсем скоро, уже в этот четверг 21 сентября!)
Ждём тех кто ещё размышляет, у вас есть возможность запрыгнуть в уходящий поезд!📣
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских аналитиков, был написан коллективный чек-лист "Интеграции". Попытка как раз хоть как-то себе облегчить жизнь)))
Его и предоставляю вашему вниманию.
--------------------------
1. Определить системы, участвующие в обмене
2. Описать потоки данных
3. Понять наличие гарантированной доставки данных
4. Описать регламент взаимодействия систем:
• передаваемые данные
• частота передачи
• расписание
• система-инициатор обмена
5. Описать формат передачи данных:
• Названия атрибутов
• Тип, длина
• Обязательность
• Кодировка
6. Зафиксировать маппинг данных из формата системы-источника в формат системы-приёмника.
7. Понять в какой системе хранятся мастер-данные по объектам.
8. Выявить необходимость преобразования/проверки на актуальность/обогащения данных.
9. Зафиксировать протоколы обмена данными.
10. Понять ограничения платформы/канала интеграции.
11. Нефункциональные требования:
• Выявить требования к скорости обработки и передачи данных.
• Понять необходимость шифрования данных.
• Оценить объем передаваемых данных.
• Понять наличие ограничений на уровне регулятора (152 ФЗ, PCI DSS).
12. Описать интеграционный сценарий взаимодействия.
13. Понять способ взаимодействия – синхронное/асинхронное.
14. Описать механизм обработки ошибок.
15. Выявить требования к настройкам и администрированию.
--------------------------
Каждый из пунктов мы подробно разбираем на курсе "Проектирование интеграции информационных систем", который я смело уже могу назвать менторским подходом вцелом к проектированию информационных систем с нуля, начиная с концепции, переходя с одного уровня абстракции на другой, добираясь до самого низкоуровневого описания.
старт потока совсем скоро, уже в этот четверг 21 сентября!)
Ждём тех кто ещё размышляет, у вас есть возможность запрыгнуть в уходящий поезд!
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
С чего начинать проектирование интеграции? А как продолжить и ничего не забыть?
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)
Мой путь в айти начался, как раз с интеграции, в далёком 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 диаграмму)