Старт 2024 с тренинга "Китайская ручка" ⭐️
Ох, вот и прошла первая рабочая неделя под лозунгом страдания, по крайней мере у меня так точно. Очень надеюсь, что у вас по-другому)
Процитирую своего коуча "праздники – для того чтобы отдыхать… а послепраздников - для чувства вины как раз".
Так что всё на своих местах)))
Вот с такими разными чувствами и отдохняком потихоньку возвращаюсь в строй!
И внезапно уже набирается мини группа на тренинг по сбору требований к ПО "Китайская ручка!".
Присоединяйтесь!
Анонсирую даты потока:
20 и 21 января с 10 до 14 по Москве, формат онлайн.
Для тех кто размышляет нужно оно или нет, представляю несколько пунктов выводов о тренинге:
✅Во-первых, тренинг и это доработанная, классическая задача собеседований системных аналитиков. Именно с помощью такой игры уже много лет в айти-сфере нанимают аналитиков.
✅Во-вторых, тренинг показывает минимальный необходимый набор знаний аналитика при работе с требованиями. То, без чего не может обойтись ни один аналитик.
✅В третьих, на тренинге разбираются базовые принципы работы с требованиями в том числе мы говорит о том, как корректно формулировать требования.
Подход - "у меня есть руки, я могу писать требования" - ошибочный.
✅В четвёртых, тренинг направлен на приобретение, укрепление навыков, которые аналитик неосознанно использует в своей основной работе.
✅В пятых, мы рассматриваем best practices, чек-листы, шаблоны, практики. Их структура позволяет создавать систему по работе с требованиями на проектах.
В заключение скажу, что сам формат тренинга ценен тем, что есть возможность общаться, делиться опытом и знаниями с коллегами. Именно за счёт групповой работы происходит рост специалистов.
#анонс #тренинг #китайскаяручка #требования
Прочитать подробнее о тренинге и оставить заявку можно на сайте➡️ https://sup.expert/pen
Ох, вот и прошла первая рабочая неделя под лозунгом страдания, по крайней мере у меня так точно. Очень надеюсь, что у вас по-другому)
Процитирую своего коуча "праздники – для того чтобы отдыхать… а послепраздников - для чувства вины как раз".
Так что всё на своих местах)))
Вот с такими разными чувствами и отдохняком потихоньку возвращаюсь в строй!
И внезапно уже набирается мини группа на тренинг по сбору требований к ПО "Китайская ручка!".
Присоединяйтесь!
Анонсирую даты потока:
20 и 21 января с 10 до 14 по Москве, формат онлайн.
Для тех кто размышляет нужно оно или нет, представляю несколько пунктов выводов о тренинге:
✅Во-первых, тренинг и это доработанная, классическая задача собеседований системных аналитиков. Именно с помощью такой игры уже много лет в айти-сфере нанимают аналитиков.
✅Во-вторых, тренинг показывает минимальный необходимый набор знаний аналитика при работе с требованиями. То, без чего не может обойтись ни один аналитик.
✅В третьих, на тренинге разбираются базовые принципы работы с требованиями в том числе мы говорит о том, как корректно формулировать требования.
Подход - "у меня есть руки, я могу писать требования" - ошибочный.
✅В четвёртых, тренинг направлен на приобретение, укрепление навыков, которые аналитик неосознанно использует в своей основной работе.
✅В пятых, мы рассматриваем best practices, чек-листы, шаблоны, практики. Их структура позволяет создавать систему по работе с требованиями на проектах.
В заключение скажу, что сам формат тренинга ценен тем, что есть возможность общаться, делиться опытом и знаниями с коллегами. Именно за счёт групповой работы происходит рост специалистов.
#анонс #тренинг #китайскаяручка #требования
Прочитать подробнее о тренинге и оставить заявку можно на сайте
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
"Китайская ручка"
Пирамида артефактов & абстрактное мышление
Уже несколько раз, за эти дни, я получила порцию благодарности на вебинар "Пирамида артефактов ИТ-проекта". ❤️
Мне очень приятно, что результат живёт и ходит по рукам. И ещё раз спасибо наставнику моих вебинаров Евгению Галактионову.
Решила, что пора напомнить вам о вебинаре, так как у меня много новых подписчиков пришло за последние полгода)
И сегодняшняя моя мысль - это то, что аналитику, техническому айти специалисту необходимо абстрактное мышление.
Проводя курсы, менторство, понимаю, что есть такие вещи, которые сложно потрогать. А если сложно потрогать нам нужно развивать представление о предмете. Наш мозг, и вцелом наш организм, это очень гибкая система, которую мы можем постоянно прокачивать, как и любую мышцу, наш мозг это тоже мышца.
Как увидеть или померить мышление, я не знаю, и с удовольствием бы поговорила на эту тему с нейро-экспертами.
Но аналитик часто работает с тем, что невозможно потрогать. Айти часто это то, что не увидеть, конечно можно открыть код и прочитать, но говоря на языке требований, моделей, образов приходится представлять себе эти абстракции. И моё мнение именно такое, что техническое образование формирует так необходимое мышление для работы в айти отрасли. Безусловно физики, химики работают тоже с абстрактными моделями, отлично делают расчёты и показывают хорошие когнитивные способности в айти разработке.
Но инженер, изначально некий маг, который из говна и палок может сделать колесо. И его мозг заточен так, чтобы соорудить решение в среде жёстких ограничений, используя свои знания.
Уровни абстракции, о которых говорят многих эксперты по проектированию айти решений, требуют как раз прокачки мышцы, чтобы представить этот уровень, выстроить в голове классификацию и на кончиках пальцев понимать, где я сейчас нахожусь, и как мне перейти с одного уровня на другой.
Как раз вебинар рассказывает о том, как эти уровни требований могут быть представлены. Это один из примеров, подходов к тому, как можно организовать работу команды с артефактами и действительно начать проектировать!)
➡️ Ссылка на вебинар
🟢 Ссылка на презентацию
🟢 Канал Евгения Галактионова
#пирамида #вебинар #абстрация #вспомнимважное #мойопыт #капитаночевидность
Уже несколько раз, за эти дни, я получила порцию благодарности на вебинар "Пирамида артефактов ИТ-проекта". ❤️
Мне очень приятно, что результат живёт и ходит по рукам. И ещё раз спасибо наставнику моих вебинаров Евгению Галактионову.
Решила, что пора напомнить вам о вебинаре, так как у меня много новых подписчиков пришло за последние полгода)
И сегодняшняя моя мысль - это то, что аналитику, техническому айти специалисту необходимо абстрактное мышление.
Проводя курсы, менторство, понимаю, что есть такие вещи, которые сложно потрогать. А если сложно потрогать нам нужно развивать представление о предмете. Наш мозг, и вцелом наш организм, это очень гибкая система, которую мы можем постоянно прокачивать, как и любую мышцу, наш мозг это тоже мышца.
Как увидеть или померить мышление, я не знаю, и с удовольствием бы поговорила на эту тему с нейро-экспертами.
Но аналитик часто работает с тем, что невозможно потрогать. Айти часто это то, что не увидеть, конечно можно открыть код и прочитать, но говоря на языке требований, моделей, образов приходится представлять себе эти абстракции. И моё мнение именно такое, что техническое образование формирует так необходимое мышление для работы в айти отрасли. Безусловно физики, химики работают тоже с абстрактными моделями, отлично делают расчёты и показывают хорошие когнитивные способности в айти разработке.
Но инженер, изначально некий маг, который из говна и палок может сделать колесо. И его мозг заточен так, чтобы соорудить решение в среде жёстких ограничений, используя свои знания.
Уровни абстракции, о которых говорят многих эксперты по проектированию айти решений, требуют как раз прокачки мышцы, чтобы представить этот уровень, выстроить в голове классификацию и на кончиках пальцев понимать, где я сейчас нахожусь, и как мне перейти с одного уровня на другой.
Как раз вебинар рассказывает о том, как эти уровни требований могут быть представлены. Это один из примеров, подходов к тому, как можно организовать работу команды с артефактами и действительно начать проектировать!)
#пирамида #вебинар #абстрация #вспомнимважное #мойопыт #капитаночевидность
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Наталья Косинова. Пирамида артефактов для ИТ-проекта: анализ и проектирование
Создавать полную документацию на проекте трудоемкий, долгий и местами нудный процесс, при этом документация ради документации или документация «в стол» никому не нужна.
Артефакты, созданные аналитиком, должны работать на благо команды разработки.
Если аналитик…
Артефакты, созданные аналитиком, должны работать на благо команды разработки.
Если аналитик…
У вас ещё есть шанс присоединиться к нашей уютной группе на тренинг "Китайская ручка")
Работаем 2 дня,🔥 старт уже завтра, по 4 часа, активно в мини группах. С 10:30 до 14:30 по Москве.
Разберем классические ошибки и паттерны поведения аналитиков и заказчиков, такие как:
✅1.Заказчик часто говорит о решение, но не о проблеме, которую необходимо решить.
✅2.Аналитик и Заказчик находятся в разных контекстах, обсуждая требования.
✅3.Необходимо помнить про падение качества требований. Стараться повышать уровень требований с уровня архитектуры, системного уровня, на бизнес, пользовательский.
✅4.В гибкой среде разработки делать ставку на продукт, который должен приносить эффект заказчику, а не пытаться описать весь объем требований.
Неважно какой у вас опыт работы аналитиком, вы только начинаете или уже работаете тим лидом, тренинг будет полезен всем, и покажет систему подходов/инструментов, как стоит подходить к основной работе аналитика - сбору и фиксированию требований.
Каждый забирает и находит свои ответы на вопросы)
Залетайте к нам в группу!
Регистрация по ссылке
➡️ https://sup.expert/pen
Работаем 2 дня,
Разберем классические ошибки и паттерны поведения аналитиков и заказчиков, такие как:
✅1.Заказчик часто говорит о решение, но не о проблеме, которую необходимо решить.
✅2.Аналитик и Заказчик находятся в разных контекстах, обсуждая требования.
✅3.Необходимо помнить про падение качества требований. Стараться повышать уровень требований с уровня архитектуры, системного уровня, на бизнес, пользовательский.
✅4.В гибкой среде разработки делать ставку на продукт, который должен приносить эффект заказчику, а не пытаться описать весь объем требований.
Неважно какой у вас опыт работы аналитиком, вы только начинаете или уже работаете тим лидом, тренинг будет полезен всем, и покажет систему подходов/инструментов, как стоит подходить к основной работе аналитика - сбору и фиксированию требований.
Каждый забирает и находит свои ответы на вопросы)
Залетайте к нам в группу!
Регистрация по ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
"Китайская ручка"
Мне нравится формат тренинга и появились мысли, как и что можно изменить.
✅При этом, уже который раз, замечаю, что формат тренинга хорош тем, что можно вне своей рутины вырваться и пообщаться с коллегами из разных городов, а теперь уже и стран. Сибирь, Москва, Питер, тёплые наши и не наши края))) За это можно сказать спасибо интернету!
✅И ручка, это не только тренинг, который запускает в голове мысли, даёт инсайты, но и способ запустить рефлексию, посмотреть со стороны на свои задачи, проблемы проектов и перегрузиться.
✅Ручка специально выбрана, как такой психологический момент, что мы говорим о том, что все знают и используют. Это как в психологии, чтобы выявить закрытые блоки человеку предлагается посмотреть на проблему, через персонажа. Что это не я, и таким способом человек начинает говорить и проявлять, то что скрыто.
❤️В очередной раз восхищаюсь подписчиками, и аналитиками, настолько прекрасные специалисты и люди, что я очень рада, что у меня есть возможность объединять наше профессиональное сообщество. Слушаю коллег, улыбаюсь и думаю, ну какие же клёвые все
Сегодня настолько была вовлечена в процесс, что рядом поставила кружку с кофе и за 4,5 часа не сделала ни одного глотка)
Хочу проводить ручку раз в месяц, те кто хочет участвовать пишите, оставляйте заявки, соберём группу и сразу же запустим поток, теперь уже в феврале)
➡️ https://sup.expert/pen
Please open Telegram to view this post
VIEW IN TELEGRAM
Зрелость команды
У меня есть прекрасные друзья, которые работают в театрах. И я им благодарна за то, что они привили мне любовь к театру.
Один из моих любимых театров это РАМТ в Москве.
Художественный руководитель театра Алексей Бородин. Список его регалий настолько большой, что даже не буду пробовать их перечислять.
Если вы посмотрите на репертуар театра, то увидите очень разные спектакли, где тот или иной сложный для общества вопрос рассказывается простыми словами.
Есть спектакли, которые Алексей вынашивал годами даже десятилетиями. И как-то в одном интервью он сказал, что настало время, когда трупа театра доросла и готова для спектакля.
Эта мысль мне понравилась. Если послушать тренеров разных спортивных команд, они тоже могут сказать, или даже предсказать, что вот эта команда мировые лидеры или будут через пару лет.
К чему это я всё? А к тому, что командообразование в любом деле очень важная часть становления. И может быть так, что команда просто не готова к тем задачам, которые стоят перед ней.Другой вопрос, что команду никто не спрашивает. И мне иногда странно, что менеджеры или тим лиды это не видят, или не задаются этим вопросом.
У нас никто не говорит о том, что вот у меня 4 года до олимпиады и мне нужно собрать команду чемпионов. Или я хочу поставить сложный спектакль и мне нужны такие актёры, кто сможет показать, то что я хочу.
И действительно, годами, даже десятилетиями к этому идут.
А у нас к сожалению, когда такие лидеры появляются, показывают крутые результаты за несколько лет, и потом исчезают, или их съедает политика. Я считаю, что это отдельное искусство лидера, видеть, а на что способна команда, как наработать, тот опыт, знания, компетенции, чтобы поставить на сцене, что-то действительно серьёзное.
Чуда не бывает, бывает путь, опыт и вложенные средства, силы в желаемый результат. Одно время именно команды с лидером стали ценны, дримтим. Если я не права, то расскажите о своём опыте, но на моём опыте, мало кто смотрит именно на то, чтобы сохранить команду. Важнее бизнес цель от менеджера, который хочет показать результат руководству, а кто и как это будет делать...
#мысливслух #командообразование #зрелость #мирвокруг #замечено
У меня есть прекрасные друзья, которые работают в театрах. И я им благодарна за то, что они привили мне любовь к театру.
Один из моих любимых театров это РАМТ в Москве.
Художественный руководитель театра Алексей Бородин. Список его регалий настолько большой, что даже не буду пробовать их перечислять.
Если вы посмотрите на репертуар театра, то увидите очень разные спектакли, где тот или иной сложный для общества вопрос рассказывается простыми словами.
Есть спектакли, которые Алексей вынашивал годами даже десятилетиями. И как-то в одном интервью он сказал, что настало время, когда трупа театра доросла и готова для спектакля.
Эта мысль мне понравилась. Если послушать тренеров разных спортивных команд, они тоже могут сказать, или даже предсказать, что вот эта команда мировые лидеры или будут через пару лет.
К чему это я всё? А к тому, что командообразование в любом деле очень важная часть становления. И может быть так, что команда просто не готова к тем задачам, которые стоят перед ней.
У нас никто не говорит о том, что вот у меня 4 года до олимпиады и мне нужно собрать команду чемпионов. Или я хочу поставить сложный спектакль и мне нужны такие актёры, кто сможет показать, то что я хочу.
И действительно, годами, даже десятилетиями к этому идут.
А у нас к сожалению, когда такие лидеры появляются, показывают крутые результаты за несколько лет, и потом исчезают, или их съедает политика. Я считаю, что это отдельное искусство лидера, видеть, а на что способна команда, как наработать, тот опыт, знания, компетенции, чтобы поставить на сцене, что-то действительно серьёзное.
Чуда не бывает, бывает путь, опыт и вложенные средства, силы в желаемый результат. Одно время именно команды с лидером стали ценны, дримтим. Если я не права, то расскажите о своём опыте, но на моём опыте, мало кто смотрит именно на то, чтобы сохранить команду. Важнее бизнес цель от менеджера, который хочет показать результат руководству, а кто и как это будет делать...
#мысливслух #командообразование #зрелость #мирвокруг #замечено
Чем темнее времена, тем теплее в лесу ❤️
Я одно время была в Горном турклубе МГУ, и Турклубе МАИ.
В какой-то момент горы стали моим местом силы, куда постоянно хочется возвращаться. Я водила небольшие группы друзей в походы, что было для меня очень тяжёлым испытанием.
Я как-то писала о том, что ГТ МГУ меня многому научил. У нас были крутые лекции, особенно лекции по командообразованию. Именно любовь к диким местам и походным условиям у меня взростила вопрос к себе на собеседование - "а взяла бы я этого человека в поход или нет?" 🤔
Разные практики из походной среды мне помогают и в работе, в том числе в сборе дримтим аналитиков.
В айти много ребят, кто увлекается походами, сплавами, горами и другими видами спорта на природе. И именно в этом направлении работает туроператор "Страна ветров".
Честно говоря зашла к ним на сайт и просто пропала в интересных предложениях🔥
Если вы также увлечены активным отдыхом, рекомендую подписаться на канал "Страны ветров" 🏕
➡️ https://t.me/+mUnQZuPhCfphY2Ni
Я одно время была в Горном турклубе МГУ, и Турклубе МАИ.
В какой-то момент горы стали моим местом силы, куда постоянно хочется возвращаться. Я водила небольшие группы друзей в походы, что было для меня очень тяжёлым испытанием.
Я как-то писала о том, что ГТ МГУ меня многому научил. У нас были крутые лекции, особенно лекции по командообразованию. Именно любовь к диким местам и походным условиям у меня взростила вопрос к себе на собеседование - "а взяла бы я этого человека в поход или нет?" 🤔
Разные практики из походной среды мне помогают и в работе, в том числе в сборе дримтим аналитиков.
В айти много ребят, кто увлекается походами, сплавами, горами и другими видами спорта на природе. И именно в этом направлении работает туроператор "Страна ветров".
Честно говоря зашла к ним на сайт и просто пропала в интересных предложениях
Если вы также увлечены активным отдыхом, рекомендую подписаться на канал "Страны ветров" 🏕
Please open Telegram to view this post
VIEW IN TELEGRAM
Сначала вы работаете на интеграцию, потом интеграция работает на вас.
Забавно, то, что моя карьера системного аналитика в 2006 году началась с интеграции, и кто бы мог подумать, что я буду учить проектированию интеграций) И интеграции никуда не исчезает за эти годы!
Уже много мной накоплено опыта, и кажется, что про интеграцию сказано всё!
Но так ли оно?
----------------
Поэтому на ближайшие две недели, в рамках своего блога, я объявляю себе челлендж по мини-интеграции, чтобы:
♟Получить чёткий roadmap, как действовать, когда прилетела задача на интеграцию и нужно сесть и написать ТЗ.
♟ Поискать инсайты и новую информацию, чего возможно я, как тренер, ментор, упускаю в системном подходе к проектированию интеграции. И довыявить точки расширения roadmap.
----------------
Не знаю, к чему меня приведёт этот челлендж, но мне интересно, снова систематизировать подходы к проектированию.
Некоторые наши ученики-аналитики говорят, что мы с Андреем Корниенко учим не просто интеграции, а системному анализу через интеграцию.
И нам хочется создать новый продукт, который был бы доступен всем и имел сжатый формат, который бы отвечал аналитику на комплекс его основных вопросов.
----------------
У каждого аналитика могут быть свои цели, например (как их вижу я):
Junior - хочет получить волшебную таблетку, чтобы дали готовые шаблоны, чек-листы, roadmap, чтобы увереннее действовать и решать поставленные задачи.
Middle - хочет расширить свои знания, навыки и опыт, чтобы брать в работу сложные задачи, с запутанной логикой.
Senior - хочет систематизировать свои знания и понять, что не видно, о чем забыл и на что стоит обратить внимание, чтобы повысить свою компетенцию.
Team Lead - хочет грамотно делегировать задачи их декомпозировать, отдавать команде и получать сисиемный хороший результат.
----------------
Вы можете мне дописать свои цели ниже в комментариях, которые вы ждёте от интеграции, и в какую область мне ещё посмотреть.
Ух, ну что ж! Погнали! 🚀
#интеграция #челлендж #проектирование #боли #миниинтеграция
Забавно, то, что моя карьера системного аналитика в 2006 году началась с интеграции, и кто бы мог подумать, что я буду учить проектированию интеграций) И интеграции никуда не исчезает за эти годы!
Уже много мной накоплено опыта, и кажется, что про интеграцию сказано всё!
Но так ли оно?
----------------
Поэтому на ближайшие две недели, в рамках своего блога, я объявляю себе челлендж по мини-интеграции, чтобы:
♟Получить чёткий roadmap, как действовать, когда прилетела задача на интеграцию и нужно сесть и написать ТЗ.
----------------
Не знаю, к чему меня приведёт этот челлендж, но мне интересно, снова систематизировать подходы к проектированию.
Некоторые наши ученики-аналитики говорят, что мы с Андреем Корниенко учим не просто интеграции, а системному анализу через интеграцию.
И нам хочется создать новый продукт, который был бы доступен всем и имел сжатый формат, который бы отвечал аналитику на комплекс его основных вопросов.
----------------
У каждого аналитика могут быть свои цели, например (как их вижу я):
Junior - хочет получить волшебную таблетку, чтобы дали готовые шаблоны, чек-листы, roadmap, чтобы увереннее действовать и решать поставленные задачи.
Middle - хочет расширить свои знания, навыки и опыт, чтобы брать в работу сложные задачи, с запутанной логикой.
Senior - хочет систематизировать свои знания и понять, что не видно, о чем забыл и на что стоит обратить внимание, чтобы повысить свою компетенцию.
Team Lead - хочет грамотно делегировать задачи их декомпозировать, отдавать команде и получать сисиемный хороший результат.
----------------
Вы можете мне дописать свои цели ниже в комментариях, которые вы ждёте от интеграции, и в какую область мне ещё посмотреть.
Ух, ну что ж! Погнали! 🚀
#интеграция #челлендж #проектирование #боли #миниинтеграция
Please open Telegram to view this post
VIEW IN TELEGRAM
Моё лицо выглядит примерно вот так, когда мне говорят - нам нужно ТЗ на интеграцию!
Блин это долго, тяжело, и хочется закричать - не хочу!! Не надо!
А всё потому что на старте, у нас высокая неопределённость. А аналитик думает категорией - "завтра в бой, так, мне нужно sequence, rest api, безопасность, нфт... Блин ещё swagger руками потрогать... А вдруг я что-то забуду?" 🤯
А ещё лучше, когда что-то прилетает, из серии - "я это не знаю"!
И вот я уже вижу, как потихоньку, легко, но верно, я начинаю падать в грязь лицом...
А ещё сверху приправим соусом "ты же специалист, тебе виднее, мы знаем, что ты можешь... ждём ТЗ..."
Вот в такой ситуации, я могу говорить, ребята, возьмите С4, или Uml и ещё 100500 разных подходов. Но лучше выдохнуть, сделать шаг назад, и начать с любой схемы! Нет вы не ослышались, любая диаграмма, картинка, визуализация подойдёт. Упрощайте!
Не нужно мучить себя нотациями, правилами, инструментами, вам нужно понять, а что собственно происходит?
Нарисуйте всё что знаете по задаче, даже если это будут 2 квадратика и стрелочка между ними со словом интеграция.
На днях на менторской сессии, я открыла диаграмму с одного своего проекта, и поняла, что это смесь DFD, Component и даже Deployment diagram. А цель моя была понять объем задачи, получилось? Да! Все красные стрелочки - это объем.
Я часто рассказываю, что когда мне присылают описание API, я просто схематично рисую диаграмму и называю "точки интеграции", визуализирую вызовы, их набор, направление, логику, последовательность.
А самое сокровенное, что я хочу сказать, прикиньте эту диаграмму можно никому не показывать)))
Так что, получая новую задачу по интеграции:
✅Не требуйте от себя быстрого крутого, финального результата
✅Рисуйте визуализацию задачи
✅Начинайте с концептуального или бизнес-уровня
✅Если вы перечислите, хотя бы участников и красными стрелочками покажите, то что нужно разработать, это уже круто!
✅Просто начните, вы уже можете объяснить себе, о чем идёт речь?)
#капитаночевидность
#интеграция #челлендж #мойопыт
Блин это долго, тяжело, и хочется закричать - не хочу!! Не надо!
А всё потому что на старте, у нас высокая неопределённость. А аналитик думает категорией - "завтра в бой, так, мне нужно sequence, rest api, безопасность, нфт... Блин ещё swagger руками потрогать... А вдруг я что-то забуду?" 🤯
А ещё лучше, когда что-то прилетает, из серии - "я это не знаю"!
И вот я уже вижу, как потихоньку, легко, но верно, я начинаю падать в грязь лицом...
А ещё сверху приправим соусом "ты же специалист, тебе виднее, мы знаем, что ты можешь... ждём ТЗ..."
Вот в такой ситуации, я могу говорить, ребята, возьмите С4, или Uml и ещё 100500 разных подходов. Но лучше выдохнуть, сделать шаг назад, и начать с любой схемы! Нет вы не ослышались, любая диаграмма, картинка, визуализация подойдёт. Упрощайте!
Не нужно мучить себя нотациями, правилами, инструментами, вам нужно понять, а что собственно происходит?
Нарисуйте всё что знаете по задаче, даже если это будут 2 квадратика и стрелочка между ними со словом интеграция.
На днях на менторской сессии, я открыла диаграмму с одного своего проекта, и поняла, что это смесь DFD, Component и даже Deployment diagram. А цель моя была понять объем задачи, получилось? Да! Все красные стрелочки - это объем.
Я часто рассказываю, что когда мне присылают описание API, я просто схематично рисую диаграмму и называю "точки интеграции", визуализирую вызовы, их набор, направление, логику, последовательность.
А самое сокровенное, что я хочу сказать, прикиньте эту диаграмму можно никому не показывать)))
Так что, получая новую задачу по интеграции:
✅Не требуйте от себя быстрого крутого, финального результата
✅Рисуйте визуализацию задачи
✅Начинайте с концептуального или бизнес-уровня
✅Если вы перечислите, хотя бы участников и красными стрелочками покажите, то что нужно разработать, это уже круто!
✅Просто начните, вы уже можете объяснить себе, о чем идёт речь?)
#капитаночевидность
#интеграция #челлендж #мойопыт
Как оценить задачу?
Можно смотреть на формулы, уходить в глубину и сложность задачи. Но когда это всё недоступно, или нет опыта, а ответ нужен здесь и сейчас. Просто делаю задачу-шаблон, считаю время и получается некий эталон, на который можно уже накинуть погрешность в несколько дней и дать оценку.
Когда-то так и произошло.
Типичный бизнес любит находу принять решение и щёлкнуть пальцами. Хочу!! Вчера!!
И вот прибегает ко мне чайка менеджер и говорит - срочно нужна интеграция с регионом! Задача первого, высшего, максимального приоритета! Ааааа! Сколько, сколько, сколько? Тебе нужно времени?
Когда меня спрашивают сколько нужно на разработку большой системы с нуля, я всегда говорю полгода. Руководство конечно возмущается, много! Скашивает до 3 месяцев, а в результате полгода...
Но тут была другая история.
Сразу скажу про исходные данные:
✅ Я хорошо знала бизнес.
✅ Я глубоко понимала как работает сфера.
✅ У меня уже был опыт подобных интеграций.
Я сказала месяц.
Отдать должное менеджеру, он сказал времени нет, ТЗ нужно срочно. И что можно сделать для ускорения? Ай зараза....
Я перечислила:
👉получить актуальное описание,
👉тестовый стенд,
👉тестовые данные,
👉контактное лицо, кто ответит на все мои вопросы,
👉понять кто принимает решение на доработку с их стороны, чтобы не тормозили.
И мы решили, что поедем в командировку к нашему партнёру. Нам нужно реализовать использование SOAP API у себя, и понять, все ли данные нужные нам есть, а что должен разработать компаньон.
И вот мы сели в поезд. В гостинице я распечатала описание, вечерком выделила фломастером, всё что мне было непонятно, написала список вопросов. И даже какие-то первые черновые варианты интеграции прикинула.
На следующий день у нас произошла встреча с командой партнёра, я смогла оперативно задать все вопросы, соединить наших разработчиков и разработчиков партнёра. Айти директор компании партнёра посмотрел на нас, обсудили договор, пришли к согласию. Переговоры сначала шли тяжело, но потом пошли в сторону поиска точек соприкосновения. И в итоге мы чётко зафиксировали, что делаем мы, что они и что нам нужно. Я написала отчёт о встрече! Не принебрегайте им!
Все довольны, мы устали часов 6 переговоров... Временами жёстких...
И вот мы уже вечером сидим в поезде обратно в Москву, и молчим...
По приезду, я запираюсь в комнате, ни с кем не общаюсь и с утра до вечера пишу ТЗ.
Забег с командировкой и написанием низкогоуровневого ТЗ с объёмом на 5-6 интеграционных сценариев у меня занял 4 дня.
4 дня это эталон надрывной работы над задачей.
Больше мне не хотелось такого надрыва, да и не всегда партнёр действительно может оперативно принять решения.
После этой истории, на вопрос, сколько тебе нужно времени на ТЗ по интеграции я всегда говорила - месяц!)))
#челлендж #интеграция #оценкаинтеграции #мойопыт
Можно смотреть на формулы, уходить в глубину и сложность задачи. Но когда это всё недоступно, или нет опыта, а ответ нужен здесь и сейчас. Просто делаю задачу-шаблон, считаю время и получается некий эталон, на который можно уже накинуть погрешность в несколько дней и дать оценку.
Когда-то так и произошло.
Типичный бизнес любит находу принять решение и щёлкнуть пальцами. Хочу!! Вчера!!
И вот прибегает ко мне чайка менеджер и говорит - срочно нужна интеграция с регионом! Задача первого, высшего, максимального приоритета! Ааааа! Сколько, сколько, сколько? Тебе нужно времени?
Когда меня спрашивают сколько нужно на разработку большой системы с нуля, я всегда говорю полгода. Руководство конечно возмущается, много! Скашивает до 3 месяцев, а в результате полгода...
Но тут была другая история.
Сразу скажу про исходные данные:
✅ Я хорошо знала бизнес.
✅ Я глубоко понимала как работает сфера.
✅ У меня уже был опыт подобных интеграций.
Я сказала месяц.
Отдать должное менеджеру, он сказал времени нет, ТЗ нужно срочно. И что можно сделать для ускорения? Ай зараза....
Я перечислила:
👉получить актуальное описание,
👉тестовый стенд,
👉тестовые данные,
👉контактное лицо, кто ответит на все мои вопросы,
👉понять кто принимает решение на доработку с их стороны, чтобы не тормозили.
И мы решили, что поедем в командировку к нашему партнёру. Нам нужно реализовать использование SOAP API у себя, и понять, все ли данные нужные нам есть, а что должен разработать компаньон.
И вот мы сели в поезд. В гостинице я распечатала описание, вечерком выделила фломастером, всё что мне было непонятно, написала список вопросов. И даже какие-то первые черновые варианты интеграции прикинула.
На следующий день у нас произошла встреча с командой партнёра, я смогла оперативно задать все вопросы, соединить наших разработчиков и разработчиков партнёра. Айти директор компании партнёра посмотрел на нас, обсудили договор, пришли к согласию. Переговоры сначала шли тяжело, но потом пошли в сторону поиска точек соприкосновения. И в итоге мы чётко зафиксировали, что делаем мы, что они и что нам нужно. Я написала отчёт о встрече! Не принебрегайте им!
Все довольны, мы устали часов 6 переговоров... Временами жёстких...
И вот мы уже вечером сидим в поезде обратно в Москву, и молчим...
По приезду, я запираюсь в комнате, ни с кем не общаюсь и с утра до вечера пишу ТЗ.
Забег с командировкой и написанием низкогоуровневого ТЗ с объёмом на 5-6 интеграционных сценариев у меня занял 4 дня.
4 дня это эталон надрывной работы над задачей.
Больше мне не хотелось такого надрыва, да и не всегда партнёр действительно может оперативно принять решения.
После этой истории, на вопрос, сколько тебе нужно времени на ТЗ по интеграции я всегда говорила - месяц!)))
#челлендж #интеграция #оценкаинтеграции #мойопыт
Сценарии в интеграции
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
ООП - объектно-ориентированный подход к программированию.
Я часто говорю о том, что ООП аналитику нужно знать, ибо именно при таком подходе в разработке, часто и нужен аналитик. Чтобы спроектировать решение.
Возвращаясь к теме интеграции, скажу, что ООП ключевая вещь.
✅Аналитику нужно понимать, какая предметная область лежит в основе решения.
✅Какие объекты предметной области участвуют в процессах (в интеграционных сценариях).
✅И как собственно интеграция влияет на жизненный путь объекта. Как из одного статуса объект переходит в другой, и что при этом происходит.
Например, у нас есть с вами предметная область - ритейл. То есть создаётся корзина, в соответствии с ней заказ, заказ оплачивается, и после оплаты происходит его сборка на складе и отгрузка в доставку.
Рассказывая, что происходит и над какими объектами, мы с вами можем выделить как раз ключевые бизнес объекты, и их статусы.
И как часто бывает, если потянуть за веревочку, мы целый клубок всего находим, где нам нужно понимание ООП:
♟1.Объекты предметной области и связи между ними
♟2.Структура объектов, иерархия данных
♟3.Жизненный цикл ключевых объектов предметной области
♟4.Операции над объектами (основа для API).
И в итоге мы с вами получаем целый пласт информации, которая нам необходима, чтобы в конечном приближение указать детали - доступные операции над структурой объектов, выполняя которые, объекты меняют статусы в соответствии со своим жизненным циклом.
И мы с вами по статусу объекта сможем понять, на каком этапе обработки он находится. Например, заказ собран уже на складе и готов к отгрузке на доставку.
Очень часто, аналитики в задачах интеграции принебрегают анализом таких артефактов, как онтологическая модель предметной области (можно также брать ER - диаграмму или диаграмму классов), диаграмма статусов (state machine) + правила перехода из статуса статус.
Не стоит забывать, что ООП - это один из способов упрощения работы с данными. Когда сложные структуры мы укладываем в объекты, и определяем связи между объектами, и описываем операции над ними, исходя из процессов, в которых участвуют объекты.
По сути ООП - это способ представления нашего реального мира в виртуальном, мы делаем проекцию, таким способом автоматизирую сложные операции реальных процессов.
#челлендж #интеграция #ооп
Так что не стоит забывать про платформу знаний, которая вам необходима, чтобы написать идеальное ТЗ на интеграцию - это ООП.
Я часто говорю о том, что ООП аналитику нужно знать, ибо именно при таком подходе в разработке, часто и нужен аналитик. Чтобы спроектировать решение.
Возвращаясь к теме интеграции, скажу, что ООП ключевая вещь.
✅Аналитику нужно понимать, какая предметная область лежит в основе решения.
✅Какие объекты предметной области участвуют в процессах (в интеграционных сценариях).
✅И как собственно интеграция влияет на жизненный путь объекта. Как из одного статуса объект переходит в другой, и что при этом происходит.
Например, у нас есть с вами предметная область - ритейл. То есть создаётся корзина, в соответствии с ней заказ, заказ оплачивается, и после оплаты происходит его сборка на складе и отгрузка в доставку.
Рассказывая, что происходит и над какими объектами, мы с вами можем выделить как раз ключевые бизнес объекты, и их статусы.
И как часто бывает, если потянуть за веревочку, мы целый клубок всего находим, где нам нужно понимание ООП:
♟1.Объекты предметной области и связи между ними
♟2.Структура объектов, иерархия данных
♟3.Жизненный цикл ключевых объектов предметной области
♟4.Операции над объектами (основа для API).
И в итоге мы с вами получаем целый пласт информации, которая нам необходима, чтобы в конечном приближение указать детали - доступные операции над структурой объектов, выполняя которые, объекты меняют статусы в соответствии со своим жизненным циклом.
И мы с вами по статусу объекта сможем понять, на каком этапе обработки он находится. Например, заказ собран уже на складе и готов к отгрузке на доставку.
Очень часто, аналитики в задачах интеграции принебрегают анализом таких артефактов, как онтологическая модель предметной области (можно также брать ER - диаграмму или диаграмму классов), диаграмма статусов (state machine) + правила перехода из статуса статус.
Не стоит забывать, что ООП - это один из способов упрощения работы с данными. Когда сложные структуры мы укладываем в объекты, и определяем связи между объектами, и описываем операции над ними, исходя из процессов, в которых участвуют объекты.
По сути ООП - это способ представления нашего реального мира в виртуальном, мы делаем проекцию, таким способом автоматизирую сложные операции реальных процессов.
#челлендж #интеграция #ооп
Так что не стоит забывать про платформу знаний, которая вам необходима, чтобы написать идеальное ТЗ на интеграцию - это ООП.
Паттерны интеграций (технологии передачи данных)
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии
Проектирование интеграции = частный случай системного анализа.
Действительно, в чем же сложность проектирования интеграции? Да, в том, что приходиться все знания, на разных уровнях собирать в систему и выдавать результат. Быть реально системным аналитиком))) и уметь переключать контексты.
Предыдущие потоки курса интеграции нам показали, что мы учим не только проектированию, но и подходу к задачам аналитика. Показываем системный анализ через интеграцию. Создаём систему знаний, навыков, что на выходе расширяет границы у аналитика.
Надеюсь всё таки границы знаний, а не сознания))) А когда ты видишь картину целиком, ты становишься более уверенным и хочется брать больше крутых задач.
Что и происходит с нашими учениками) Многие меняют проекты, меняют работу. И иногда меня не только карьерной феей называют, но и айти ведьмой)
На прошлом потоке, я забеспокоилась куда пропала участница, а оказалось, что в середине курса она уже поменяла работу. Вот так оно работает)))
Также есть те, кто только начинает свой путь в системном анализе и хочет понять надо оно или нет, куда дальше расти, что изучать. И тоже находят ответы на свои вопросы.
Есть те кто решил, что не надо мне всё это, но до конца курса всё таки дошли. И выбрали бизнес направление.
Каждый получил свой результат, и заберёт столько сколько сможет (все презентации, материалы и записи остаются в доступе навсегда).
Мне хочется, чтобы на проектах работали специалисты, которые могут проектировать качественные решения и делать наш мир лучше. А я смогу пользоваться более качественными сервисами)))
Что же нужно сделать, чтобы спроектировать интеграцию?
Если читали посты выше, то уже знаете:
✅1. Разобраться в том, для чего и зачем нужна интеграция. В каких процессах участвует. Спроектировать интеграционные сценарии на пользовательском уровне, их превратить в системный уровень. И зафиксировать организацию обмена данными под процессы.
✅2. Подключить знания по ООП. Взять предметку, выделить бизнес-объекты, понять их жизненный цикл. И выявить то как интеграция влияет на жизненный цикл объекта, как переключает статус, и как этот статус влияет на другие объекты и процессы.
✅3. Спуститься на уровень технологий и данных. И понять, как именно будут передаваться данные, как обрабатывать ошибки, какой паттерн интеграции будет. И описать маппинг данных нашего объекта при передачи от системы источник и систему приёмник.
Вроде бы всё понятно.
Но знать и кивать головой — это одно. А когда приступаешь к реализации — вот тут начинаются танцы с бубнами...
С какой стороны подходить?
Где знаю, а где нет, а может всё знаю?
А что должен делать я, а что нет?
Тратишь кучу времени и сил... Книги это хорошо, но свой опыт и опыт коллег ещё лучше.
У нас для вас хорошая новость))
Мы готовы делиться с вами своим опытом интеграционных проектов!
Запускаем 🚀набор на поток курса интеграции.
И я бы его уже переименовала в🔄 системный анализ в интеграции.
🔥 Старт 15 февраля!
(Для тех кто не успевает на этот поток, скажу, что на весну мы планируем ещё поток).
-------------------------------
Курс интеграции состоит из 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 - Паттерны интеграции, шина, брокер
-------------------------------
Запись на курс
➡️ https://sup.expert/
Для тех кто приходил ко мне на менторство, на китайскую ручку, для вас действует скидка 10%
Действительно, в чем же сложность проектирования интеграции? Да, в том, что приходиться все знания, на разных уровнях собирать в систему и выдавать результат. Быть реально системным аналитиком))) и уметь переключать контексты.
Предыдущие потоки курса интеграции нам показали, что мы учим не только проектированию, но и подходу к задачам аналитика. Показываем системный анализ через интеграцию. Создаём систему знаний, навыков, что на выходе расширяет границы у аналитика.
Что и происходит с нашими учениками) Многие меняют проекты, меняют работу. И иногда меня не только карьерной феей называют, но и айти ведьмой)
На прошлом потоке, я забеспокоилась куда пропала участница, а оказалось, что в середине курса она уже поменяла работу. Вот так оно работает)))
Также есть те, кто только начинает свой путь в системном анализе и хочет понять надо оно или нет, куда дальше расти, что изучать. И тоже находят ответы на свои вопросы.
Есть те кто решил, что не надо мне всё это, но до конца курса всё таки дошли. И выбрали бизнес направление.
Каждый получил свой результат, и заберёт столько сколько сможет (все презентации, материалы и записи остаются в доступе навсегда).
Мне хочется, чтобы на проектах работали специалисты, которые могут проектировать качественные решения и делать наш мир лучше. А я смогу пользоваться более качественными сервисами)))
Что же нужно сделать, чтобы спроектировать интеграцию?
Если читали посты выше, то уже знаете:
✅1. Разобраться в том, для чего и зачем нужна интеграция. В каких процессах участвует. Спроектировать интеграционные сценарии на пользовательском уровне, их превратить в системный уровень. И зафиксировать организацию обмена данными под процессы.
✅2. Подключить знания по ООП. Взять предметку, выделить бизнес-объекты, понять их жизненный цикл. И выявить то как интеграция влияет на жизненный цикл объекта, как переключает статус, и как этот статус влияет на другие объекты и процессы.
✅3. Спуститься на уровень технологий и данных. И понять, как именно будут передаваться данные, как обрабатывать ошибки, какой паттерн интеграции будет. И описать маппинг данных нашего объекта при передачи от системы источник и систему приёмник.
Вроде бы всё понятно.
Но знать и кивать головой — это одно. А когда приступаешь к реализации — вот тут начинаются танцы с бубнами...
С какой стороны подходить?
Где знаю, а где нет, а может всё знаю?
А что должен делать я, а что нет?
Тратишь кучу времени и сил... Книги это хорошо, но свой опыт и опыт коллег ещё лучше.
У нас для вас хорошая новость))
Мы готовы делиться с вами своим опытом интеграционных проектов!
Запускаем 🚀набор на поток курса интеграции.
И я бы его уже переименовала в
(Для тех кто не успевает на этот поток, скажу, что на весну мы планируем ещё поток).
-------------------------------
Курс интеграции состоит из 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 - Паттерны интеграции, шина, брокер
-------------------------------
Запись на курс
Для тех кто приходил ко мне на менторство, на китайскую ручку, для вас действует скидка 10%
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
Наташа Косинова. Варю айти СУП pinned «Проектирование интеграции = частный случай системного анализа. Действительно, в чем же сложность проектирования интеграции? Да, в том, что приходиться все знания, на разных уровнях собирать в систему и выдавать результат. Быть реально системным аналитиком)))…»
Обожаю работать с аналитиками))
Мало того, что аналитик это специалист, который постоянно ищет противоречия, выстраивает логику, делает выводы, но ещё и обладает профессиональным чутьем, где собака зарыта.
От аналитиков всегда прилетают глубокие вопросы. И это действительно здорово!) Потому что не всё видно с первого раза. Плюс я сама расту за счёт такой обратной связи, и мотивация есть двигаться дальше.
-----------------------
За годы работы в качестве тренера, ментора, преподавателя, у меня сложился свой🔝 правил, которые помогают мне определить идеального клиента-аналитика:
⏺ Я не люблю слово преподаватель, потому что оно сразу показывает некую позицию, я вам сейчас преподам. Я люблю работать с аналитиками с позицией "на равных", взрослый - взрослый. Менторская позиция. Мы одинаковые, я просто расскажу своё мнение и способ, как я вижу можно решить твой запрос. Но за тобой всегда своё собственное мнение, что и как делать. Прислушиваться или нет. Именно взрослый человек принимает свои решения и управляет своей жизнью.
⏺ Также я стараюсь выстраивать общение с позиции "со мной всё в порядке", "с тобой всё в порядке". Если человек пришёл учиться или получить от меня комментарии, то это уже стрессовая позиция, не вижу смысла её усугублять и пытаться потешить своё эго.Мест для выпендивания можно найти дофига других)))
⏺ Также не работаю по принципу no pain, no gain. Так много этого надрыва вокруг, критики и давления, что не вижу в таком подходе ничего хорошего, особенно когда говорим про игру вдолгую.
⏺ Конечно круто, когда человек приходит с чётким запросом, знает чего хочет и понимает адекватность своего запроса.Сделай с нуля из меня тим лида, чтобы я зарабатывал полляма и ничего не делал, это не ко мне))
⏺ Умеет и готов работать, плюс создаёт для себя условия успеха, в виде регулярности, дисциплины. Причём дисциплина тут это не хлыст сверху, а неотъемлемая часть жизни. Потому что рутина даёт результат. Но и совсем уж расслабиться и ничего не делать это не про аналитиков))) Ребята аналитики выстраивают себе систему и именно эта система, регулярность, целенаправленность и даёт результат. Я некоторые ещё те ломовые лошади!)
⏺ Конечно приятно работать с людьми с опытом, в том числе и жизненным. Потому что я скорее работаю, как ускоритель той базы которая уже есть. Создавать базу с нуля сложно, и пока я за такое не берусь.
⏺ Взаимодействие строиться на доверие. Ибо нет смысла идти к специалисту, который тебе не нравится, ментально в том числе. Искать когда будет провал или какой либо подвох.
⏺ Границы ответственности. Мне не интересно делать за кого-то его работу, мне интересно видеть прогресс. Переложить с больной головы на здоровую прекрасно, но вам то, что с этого?
-----------------------
Есть такое понятие сложный клиент, вот я бы скорее сказала, что клиент есть клиент, и он может быть не ваш, либо вы не можете найти подход и общий язык. Да, есть и такие, кто будет хлопать дверью, кричать. Это нормально, все мы разные и хотим разного)))
Комфортное открытое пространство общения, где можно задавать вопросы и обсуждать все свои проблемы, вот к чему я всегда стремлюсь. Конечно у меня нет нимба над головой и я тоже могу и уставать, и какой-то бред ляпнуть, но возвращаемся к пункту, взрослый - взрослый. Взрослый принимает свои ошибки и их исправляет.
Вот именно за таким общением я вас и приглашаю в нашу 🔥 мощную команду февральского потока интеграции. Уже много интересных ребят с разных компаний придёт))
Будет мощно, жарко и всем придётся поработать! Но есть ради чего стараться!
А мы с Андреем постараемся сработать ускорителями вашего профессионального роста😎
#интеграция #челлендж #топ #клиенты
Мало того, что аналитик это специалист, который постоянно ищет противоречия, выстраивает логику, делает выводы, но ещё и обладает профессиональным чутьем, где собака зарыта.
От аналитиков всегда прилетают глубокие вопросы. И это действительно здорово!) Потому что не всё видно с первого раза. Плюс я сама расту за счёт такой обратной связи, и мотивация есть двигаться дальше.
-----------------------
За годы работы в качестве тренера, ментора, преподавателя, у меня сложился свой
⏺ Я не люблю слово преподаватель, потому что оно сразу показывает некую позицию, я вам сейчас преподам. Я люблю работать с аналитиками с позицией "на равных", взрослый - взрослый. Менторская позиция. Мы одинаковые, я просто расскажу своё мнение и способ, как я вижу можно решить твой запрос. Но за тобой всегда своё собственное мнение, что и как делать. Прислушиваться или нет. Именно взрослый человек принимает свои решения и управляет своей жизнью.
⏺ Также я стараюсь выстраивать общение с позиции "со мной всё в порядке", "с тобой всё в порядке". Если человек пришёл учиться или получить от меня комментарии, то это уже стрессовая позиция, не вижу смысла её усугублять и пытаться потешить своё эго.
⏺ Также не работаю по принципу no pain, no gain. Так много этого надрыва вокруг, критики и давления, что не вижу в таком подходе ничего хорошего, особенно когда говорим про игру вдолгую.
⏺ Конечно круто, когда человек приходит с чётким запросом, знает чего хочет и понимает адекватность своего запроса.
⏺ Умеет и готов работать, плюс создаёт для себя условия успеха, в виде регулярности, дисциплины. Причём дисциплина тут это не хлыст сверху, а неотъемлемая часть жизни. Потому что рутина даёт результат. Но и совсем уж расслабиться и ничего не делать это не про аналитиков))) Ребята аналитики выстраивают себе систему и именно эта система, регулярность, целенаправленность и даёт результат. Я некоторые ещё те ломовые лошади!)
⏺ Конечно приятно работать с людьми с опытом, в том числе и жизненным. Потому что я скорее работаю, как ускоритель той базы которая уже есть. Создавать базу с нуля сложно, и пока я за такое не берусь.
⏺ Взаимодействие строиться на доверие. Ибо нет смысла идти к специалисту, который тебе не нравится, ментально в том числе. Искать когда будет провал или какой либо подвох.
⏺ Границы ответственности. Мне не интересно делать за кого-то его работу, мне интересно видеть прогресс. Переложить с больной головы на здоровую прекрасно, но вам то, что с этого?
-----------------------
Есть такое понятие сложный клиент, вот я бы скорее сказала, что клиент есть клиент, и он может быть не ваш, либо вы не можете найти подход и общий язык. Да, есть и такие, кто будет хлопать дверью, кричать. Это нормально, все мы разные и хотим разного)))
Комфортное открытое пространство общения, где можно задавать вопросы и обсуждать все свои проблемы, вот к чему я всегда стремлюсь. Конечно у меня нет нимба над головой и я тоже могу и уставать, и какой-то бред ляпнуть, но возвращаемся к пункту, взрослый - взрослый. Взрослый принимает свои ошибки и их исправляет.
Вот именно за таким общением я вас и приглашаю в нашу 🔥 мощную команду февральского потока интеграции. Уже много интересных ребят с разных компаний придёт))
Будет мощно, жарко и всем придётся поработать! Но есть ради чего стараться!
А мы с Андреем постараемся сработать ускорителями вашего профессионального роста
#интеграция #челлендж #топ #клиенты
Please open Telegram to view this post
VIEW IN TELEGRAM
Как выбрать решение по интеграции?
Частый и любимый вопрос от аналитика.
И он понятен! Архитекторы, разработчики закатывают глаза вверх и отвечают, что-то типа дружок не заходи на мою территориюподвинься щенок, не задавай мне такие вопросы
И когда ты раз получил негатив, два получил негатив, уже в следующий раз не будешь спрашивать, но и чувствовать себя на обочине жизни не хочется. Все там в замесе участвуют, я на всё это хозяйство ТЗ пиши, и не должен понимать, а почему выбрали то или иное решение?
Попробуем разобраться вместе.
Какие могут быть варианты:
✅1.По-другому нельзя, у нас нет выбора - у нас интеграция с сервисом на который мы не можем повлиять, сказали SOAP, значит SOAP, и нет тут долгих размышлений и логики принятия решения.
✅2.Среда нас ограничивает - мы такие умные и красивые пришли со своим REST API, микросервисами, а наш партнёр нам говорит - Дорогой ты мой человек! Мы когда в пятницу уходим на выходные, всё отрубаем и сервер тоже. И вообще у нас Марья Ивановна будет работать с вашими данными на винде. Дайте человеку файл на почту, чтобы смогла его открыть, прочитать и ничего не потерялось.
✅3.Политическое решение. Не нужно вам знать почему так! Слишком много задаёшь вопросов, товарищ,подозрительно на которые нет ответов. Как-то на проекте я спросила, почему купили шину IBM, а не ORACLE? Мне сказали, тсссс! Молчи! Нашему инвестору IBM красивую презентацию показали и ужин устроили и ещё то, чего мы не знаем. И не говорим вслух...
✅4.Нет ресурсов - банально, может быть там, что нет разработчиков, кто бы модно, молодёжно смог сделать. Поэтому берут проверенный, рабочий вариант.
✅5.И может быть вариант - да бог его знает, все так делают и ваще Вася наш гений, вот он так и решил, играет в технологии, главное. Всё работает, все довольны!
✅6. А может быть вариант - не знаю, исторически сложилось, или никто не думал, поэтому не задавай вопросы!
Ну и главный фактор - решение принимает человек и он исходит (в лучшем случае) из того, какие у него вводные данные:
📍сроки,
📍требования,
📍безопасность,
📍скорость передачи,
📍объем передачи данных,
📍надёжность,
📍масштабируемость,
📍среда (ограничения среды),
📍ресурсы,
📍поддержка,
📍бюджет,
📍уже что-то пообещали начальству...
И не стоит подходит к вопросу, а как должно быть?
С такой позиции, что мы сейчас делаем раз и навсегда. И интеграция у нас будет вылита в бронзе.
Как-то на одном проекте, у нас интеграция за год поменялась несколько раз:
✅В начале, надо было быстро, сделать point-to-point напрямую, шаблонно, так как уже было api
✅Потом переделали и завернули на шину, сделали центр обмена xml-сообщениями
✅Потом поняли, что нужен брокер, поставили и завернули на очередь.
И при таком раскладе решение везде работало, и прошло эволюцию вместе с айти ландшафтом компании.
Поэтому, мы стараемся разбирать позицию аналитика в связке - требование, ограничение, и влияние на решение. Но аналитик не принимает окончательные решения по разработке, аналитик помогает команде погрузиться в плоскость проблем, требований, ограничений, рисков, как раз задавая неудобные вопросы, которые направляют нашу команду в нужном русле.
👉Именно такой путь мы и будем с вами проходить на курсе интеграции.
👉Будем делиться кейсами из жизни, опытом, знаниями и проходить цепочку проектирования решения от концепции до уровня технологий и паттернов интеграции.
-----------------------
Залетайте к нам в февральский поток! 🚀
#интеграция #челлендж #выборрешения
Частый и любимый вопрос от аналитика.
И он понятен! Архитекторы, разработчики закатывают глаза вверх и отвечают, что-то типа дружок не заходи на мою территорию
И когда ты раз получил негатив, два получил негатив, уже в следующий раз не будешь спрашивать, но и чувствовать себя на обочине жизни не хочется. Все там в замесе участвуют, я на всё это хозяйство ТЗ пиши, и не должен понимать, а почему выбрали то или иное решение?
Попробуем разобраться вместе.
Какие могут быть варианты:
✅1.По-другому нельзя, у нас нет выбора - у нас интеграция с сервисом на который мы не можем повлиять, сказали SOAP, значит SOAP, и нет тут долгих размышлений и логики принятия решения.
✅2.Среда нас ограничивает - мы такие умные и красивые пришли со своим REST API, микросервисами, а наш партнёр нам говорит - Дорогой ты мой человек! Мы когда в пятницу уходим на выходные, всё отрубаем и сервер тоже. И вообще у нас Марья Ивановна будет работать с вашими данными на винде. Дайте человеку файл на почту, чтобы смогла его открыть, прочитать и ничего не потерялось.
✅3.Политическое решение. Не нужно вам знать почему так! Слишком много задаёшь вопросов, товарищ,
✅4.Нет ресурсов - банально, может быть там, что нет разработчиков, кто бы модно, молодёжно смог сделать. Поэтому берут проверенный, рабочий вариант.
✅5.И может быть вариант - да бог его знает, все так делают и ваще Вася наш гений, вот он так и решил, играет в технологии, главное. Всё работает, все довольны!
✅6. А может быть вариант - не знаю, исторически сложилось, или никто не думал, поэтому не задавай вопросы!
Ну и главный фактор - решение принимает человек и он исходит (в лучшем случае) из того, какие у него вводные данные:
📍сроки,
📍требования,
📍безопасность,
📍скорость передачи,
📍объем передачи данных,
📍надёжность,
📍масштабируемость,
📍среда (ограничения среды),
📍ресурсы,
📍поддержка,
📍бюджет,
📍уже что-то пообещали начальству...
И не стоит подходит к вопросу, а как должно быть?
С такой позиции, что мы сейчас делаем раз и навсегда. И интеграция у нас будет вылита в бронзе.
Как-то на одном проекте, у нас интеграция за год поменялась несколько раз:
✅В начале, надо было быстро, сделать point-to-point напрямую, шаблонно, так как уже было api
✅Потом переделали и завернули на шину, сделали центр обмена xml-сообщениями
✅Потом поняли, что нужен брокер, поставили и завернули на очередь.
И при таком раскладе решение везде работало, и прошло эволюцию вместе с айти ландшафтом компании.
Поэтому, мы стараемся разбирать позицию аналитика в связке - требование, ограничение, и влияние на решение. Но аналитик не принимает окончательные решения по разработке, аналитик помогает команде погрузиться в плоскость проблем, требований, ограничений, рисков, как раз задавая неудобные вопросы, которые направляют нашу команду в нужном русле.
👉Именно такой путь мы и будем с вами проходить на курсе интеграции.
👉Будем делиться кейсами из жизни, опытом, знаниями и проходить цепочку проектирования решения от концепции до уровня технологий и паттернов интеграции.
-----------------------
Залетайте к нам в февральский поток! 🚀
#интеграция #челлендж #выборрешения
sup.expert
Курс по интеграции
Я тут пришла к выводу, что самые крутые инструменты начинаешь ценить за их простоту, только спустя годы работы)))
Блок-схема, ну фу, какое-то тупое название из 90-х, а DFD чет так просто, фу для детей.
Но в этой простоте гениальность💔
Блок-схема, ну фу, какое-то тупое название из 90-х, а DFD чет так просто, фу для детей.
Но в этой простоте гениальность
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 Телеграм для Системного/Бизнес аналитика
Подписывайся на канал и забирай материалы по проектированию, здоровому развитию себя как айти - аналитика, от эксперта с опытом более 17 лет, прошедшего путь от джуна до тим лида системного анализа, ментора, тренера команд.
Специально для вас сделала подборку материала, изучив которую, вы сможете найти ответы на часто возникающие вопросы‼️:
Проектирование интеграций:
✅Чек-лист интеграции - проверь себя
✅Интеграционные сценарии - ключевой артефакт интеграции
✅ООП - основа проектирования
✅Паттерны интеграции - по типу передачи данных
Хочется больше знать и уметь в теме интеграции приходи на курс - https://sup.expert/ (следующий поток с 25 апреля)
------------
Для тех кто только начинает карьеру, и не знает, что делать, как себя позиционировать и выбрать нужное направление?
✅Поможет статья какие есть виды аналитиков?
✅И видео запись менторской сессии - про направления в айти.
✅Чем продукт отличается от проекта?
-----------------------------
Для тех кто сталкивается с новым проектом и не знает с чего начать?
✅Вебинар погружение в предметную область.
Кто давно в отрасли, но не понимает, как организовать базу знаний и выбрать нужные, именно вам артефакты анализа, инструменты, подходы - ответит вебинар "Пирамида артефактов анализа для IT-проекта".
Если вы менеджер продукта/проекта и не понимаете нужен ли вам аналитик? Или же вы аналитик, которому нужно "продать" команде свою роль - то ознакомьтесь с
✅вебинаром "Зачем аналитик проекту?"
------------
Также раз в месяц провожу тренинг по основам разработки требований "Китайская ручка"
О чем тренинг можно ознакомиться в посте.
Регистрация по ссылке - https://sup.expert/pen
Если у вас остались вопросы, есть предложения, или вам нужен тренинг для команда анализа, то ➡️
пишите мне напрямую и приходите на менторство)
Подписывайся на канал и забирай материалы по проектированию, здоровому развитию себя как айти - аналитика, от эксперта с опытом более 17 лет, прошедшего путь от джуна до тим лида системного анализа, ментора, тренера команд.
Специально для вас сделала подборку материала, изучив которую, вы сможете найти ответы на часто возникающие вопросы‼️:
Проектирование интеграций:
✅Чек-лист интеграции - проверь себя
✅Интеграционные сценарии - ключевой артефакт интеграции
✅ООП - основа проектирования
✅Паттерны интеграции - по типу передачи данных
Хочется больше знать и уметь в теме интеграции приходи на курс - https://sup.expert/ (следующий поток с 25 апреля)
------------
Для тех кто только начинает карьеру, и не знает, что делать, как себя позиционировать и выбрать нужное направление?
✅Поможет статья какие есть виды аналитиков?
✅И видео запись менторской сессии - про направления в айти.
✅Чем продукт отличается от проекта?
-----------------------------
Для тех кто сталкивается с новым проектом и не знает с чего начать?
✅Вебинар погружение в предметную область.
Кто давно в отрасли, но не понимает, как организовать базу знаний и выбрать нужные, именно вам артефакты анализа, инструменты, подходы - ответит вебинар "Пирамида артефактов анализа для IT-проекта".
Если вы менеджер продукта/проекта и не понимаете нужен ли вам аналитик? Или же вы аналитик, которому нужно "продать" команде свою роль - то ознакомьтесь с
✅вебинаром "Зачем аналитик проекту?"
------------
Также раз в месяц провожу тренинг по основам разработки требований "Китайская ручка"
О чем тренинг можно ознакомиться в посте.
Регистрация по ссылке - https://sup.expert/pen
Если у вас остались вопросы, есть предложения, или вам нужен тренинг для команда анализа, то ➡️
пишите мне напрямую и приходите на менторство)
sup.expert
Курс по интеграции
Наташа Косинова. Варю айти СУП pinned «🔥 Телеграм для Системного/Бизнес аналитика Подписывайся на канал и забирай материалы по проектированию, здоровому развитию себя как айти - аналитика, от эксперта с опытом более 17 лет, прошедшего путь от джуна до тим лида системного анализа, ментора, тренера…»
Я чувствую себя ненужным, лишним.
Непонятно зачем я команде?
Я пыталась вспомнить в какой момент моей трудовой деятельности посетило меня такое чувство. Пришла к выводу, что в самом начале, как пришла на проект, так и прилетел у меня вопрос - а что я тут делаю? Я же никому не нужна.
Когда уровень стал выше и смелость, и опыт, дали возможность сразу сходу говорить о том, что не так, стало легче.
Но когда ты приходишь в новую команду - ощущение ненужности, это прям как холодный душ. Бодрит!
Что с этим делать?
Во первых, если вы так чувствуете, значит это действительно так! И все эти разговоры - да ну че ты, всё пройдёт... И т.д. просто откладывание проблемы.
✅Так что первое признаем ситуацию.
✅Второе ищем причины, почему аналитик не нужен команде.
Предположим, что реально не нужен. Тогда вопрос к руководству - зачем мучаете специалиста?
Если нужен, в чем могут быть причины:
✔️ 1.Команда никогда не работала с аналитиком
✔️ 2.Команда не доверяет аналитику (прошлый негативный опыт мешает, сходил я тут к стоматологу, не понравилось, больше не пойду... Ну камон ...)
✔️ 3.Руководство не понимает зачем нужен аналитик (ну нам сказали, мы взяли)
✔️ 4.Все привыкли работать по процессам, которые не подразумевают анализ. И в итоге аналитик, где-то в конце подключается к процессу разработки.
✔️ 5.Аналитику дают не его задачи. Всё что угодно. Менеджерские, тех поддержка, тех писательство, тестирование, дизайн, а ещё я крестиком вышивать могу и борщ готовить))
✔️ 6.Аналитику часто меняют задачу. Вот на тебе, она уже просрочена. Упс, не успел. На другую, она тоже просрочена. Ай, ну что ж ты. Надо как-то быстрее переключаться с задачи на задачу. Контекст разный? Ну что ж ты нерасторопный такой, ты же профессионал, переключайся быстрее, мы тебе много деняг платим. Итог - нет видимого результата, как челночный бег, стоишь на месте, при этом жутко устал.
✔️ 7.Аналитик один, грустит и превращается в депрессивного странного чувака.
✔️ 8.Аналитик "не пришей кобыле хвост", пришёл к заказчику, тот его послал, он послался. Пришёл к команде, его послали, он послался. Пришёл к руководству, руководство сказало - не ной, не до тебя сейчас, иди найди оружие в бою. Ты сильный, я в тебя верю. Но потом спрошу!
Список можно пополнить своей историей в комментариях 👇
Дальше торг, депрессия, принятие, заявление об увольнение...
Что можно с этим сделать?
📍1.Начать говорить о проблеме и о том, что не так. Фиксировать все договорённости отчётами, датами, указывая имена.
📍2.Заручиться поддержкой руководства. Если вас взяли в команду, значит компания уже потратила время, деньги и ресурсы сотрудников, и вы нужны. Если не нужны, то это другой разговор.
📍3.Просить не менять контекст, не перекидывать с задачи на задачу. Дать шанс показать результат.
📍4.Общаться, и ещё раз общаться.
📍5. Своим результатом продавать заказчику, команде, руководству анализ. К сожалению это так. И только конкретным результатом, это можно показать. Тем более сейчас уровень компетенции падает и у многих разработчиков аллергия на аналитиков.
📍6.Выстраивать процесс так, чтобы аналитик опережал разработку на спринт, или хотя бы на половину спринта. Иначе он не аналитик, а техпис или ещё кто-то. Занять своё место в общем процессе.
📍7.Действительно заниматься своим делом. На стартапах все делают всё. И это чревато тем, что своими обязанностями вы не будете заниматься. И всем будет удобно, кроме вас. Закроете тестера, тех поддержку, секретаря, дизайнера. Если выхода нет. Можно наглядно показать, посчитав сколько времени вы тратите на другие направления. Я как-то посчитала сколько я работаю как HR, и как тим лид анализа. И я такой дорогой HR выхожу. Смысл тогда меня, как тим лида в компании? Когда переводишь разговор в русло денег, времени, ресурса, всё становится по местам и быстро с меня сняли работу HR и нашли спеца))
Непонятно зачем я команде?
Я пыталась вспомнить в какой момент моей трудовой деятельности посетило меня такое чувство. Пришла к выводу, что в самом начале, как пришла на проект, так и прилетел у меня вопрос - а что я тут делаю? Я же никому не нужна.
Когда уровень стал выше и смелость, и опыт, дали возможность сразу сходу говорить о том, что не так, стало легче.
Но когда ты приходишь в новую команду - ощущение ненужности, это прям как холодный душ. Бодрит!
Что с этим делать?
Во первых, если вы так чувствуете, значит это действительно так! И все эти разговоры - да ну че ты, всё пройдёт... И т.д. просто откладывание проблемы.
✅Так что первое признаем ситуацию.
✅Второе ищем причины, почему аналитик не нужен команде.
Предположим, что реально не нужен. Тогда вопрос к руководству - зачем мучаете специалиста?
Если нужен, в чем могут быть причины:
Список можно пополнить своей историей в комментариях 👇
Дальше торг, депрессия, принятие, заявление об увольнение...
Что можно с этим сделать?
📍1.Начать говорить о проблеме и о том, что не так. Фиксировать все договорённости отчётами, датами, указывая имена.
📍2.Заручиться поддержкой руководства. Если вас взяли в команду, значит компания уже потратила время, деньги и ресурсы сотрудников, и вы нужны. Если не нужны, то это другой разговор.
📍3.Просить не менять контекст, не перекидывать с задачи на задачу. Дать шанс показать результат.
📍4.Общаться, и ещё раз общаться.
📍5. Своим результатом продавать заказчику, команде, руководству анализ. К сожалению это так. И только конкретным результатом, это можно показать. Тем более сейчас уровень компетенции падает и у многих разработчиков аллергия на аналитиков.
📍6.Выстраивать процесс так, чтобы аналитик опережал разработку на спринт, или хотя бы на половину спринта. Иначе он не аналитик, а техпис или ещё кто-то. Занять своё место в общем процессе.
📍7.Действительно заниматься своим делом. На стартапах все делают всё. И это чревато тем, что своими обязанностями вы не будете заниматься. И всем будет удобно, кроме вас. Закроете тестера, тех поддержку, секретаря, дизайнера. Если выхода нет. Можно наглядно показать, посчитав сколько времени вы тратите на другие направления. Я как-то посчитала сколько я работаю как HR, и как тим лид анализа. И я такой дорогой HR выхожу. Смысл тогда меня, как тим лида в компании? Когда переводишь разговор в русло денег, времени, ресурса, всё становится по местам и быстро с меня сняли работу HR и нашли спеца))
Please open Telegram to view this post
VIEW IN TELEGRAM