Наташа Косинова. Варю айти СУП
2.68K subscribers
66 photos
3 videos
9 files
334 links
Системный аналитик, тимлид, ментор, бизнес-тренер, автор айти курсов. Работаю в айти с 2006 года. Мой канал про айти, без лапши успешного успеха. Варю айти СУП здорового человека)

Мои услуги:
https://nkosinova.taplink.ws

Написать мне @tasha_kvitka
Download Telegram
Через 2 недели стартует, последний в этом году, поток интеграции.
Вас ждёт аналитический марафон в 2 месяца!

-------------------------------
Курс интеграции состоит из 8 блоков и разделён на два этапа:
Первый 🎯 - это проектирование интеграционного решения от концепции до уровня данных (блоки с 1 по 4).
Блок 1 - отвечаем на вопрос, что такое интеграция, строим С4
Блок 2 - use cases, онтологическая модель предметной области, state machine
Блок 3 - sequence, мастер данные, гарантированная доставка, обработка ошибок, валидация данных
Блок 4 - словарь данных, маппинг данных, администрирование, activity

Второй 🎯 - разбор технологий передачи данных, паттернов интеграции, шина и брокеры (блоки с 5 по 8).
Блок 5 - введение в OSI модель сети, REST API, json
Блок 6 - SOAP, xml
Блок 7 - graphQL, gRPC, логирование, мониторинг, квотирование, безопасность
Блок 8 - Паттерны интеграции, шина, брокер

-------------------------------
Кому подойдёт курс?

Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно пройти курс, понять, что входит в интеграцию, увидеть путь рассуждений, которые приводят к результату. Вы приобретёте навыки и уверенность, что позволит брать в работу новые задачи.

Если вы аналитик с опытом от 3 до 5 лет, курс поможет систематизировать знания понять свои пробелы, увидеть эволюцию проектирования, что в конечном итоге позволит вам выйти на новый уровень, составить план развития, а может и сменить работу (такие прецеденты у нас уже есть))).

Если вы ведущий аналитик или тим лид анализа, вы сможете понять, каким путем стоит идти вместе с командой, чтобы повысить качество результата работы аналитиков, посмотрите со стороны на свою работу, артефакты анализа. Будете понимать на что обращать внимание в качестве наставника.

Формат курса - онлайн занятия, приближенные к классической схеме обучения,
в четверг лекция (утром по Москве с 9 до 11),
во вторник семинар - разбор домашних заданий (утром по Москве с 9 до 11).

Наш формат похож на формат групповых менторских сессий, где ведущие общаются с группой и сразу, по ходу, могут обсуждать возникающие вопросы. Мы подстраиваемся под уровень знаний участников и стараемся давать новый блок информации так, чтобы он ложился на текущий фундамент. Мы не являемся огромной школой или площадкой, что позволяет нам создавать уютное, открытое общение и делиться опытом между собой.

Сколько сможете унести знаний зависит только от вас))
Многие ребята пересматривают записи занятий и узнают снова и снова что-то новое.
➡️ Презентации
➡️ Материал
➡️ Видео записи занятий остаются у вас навсегда!


Мы предлагаем разные тарифы обучения:

Можно прийти на тариф "только послушать", участвовать в онлайн формате в обсуждениях, интерактивных практиках.

Если вы хотите разрабатывать учебный проект и выполнять домашние задания по проектированию, для вас подходит тариф "плюс практика", с разбором домашних заданий.

Мы специально проводим занятия в утреннее время в будние, чтобы вы со свежей головой смогли разобраться в сложной системной информации. Учиться и работать одновременно это действительно сложно, поэтому мы стараемся создать условия, чтобы вы успешно прошли весь аналитический марафон вместе с нами)) Каждый новый поток для нас, как новый вызов!

Имея чёткое расписание, просто приходя на занятия, вы точно сможете почерпнуть для себя полезные знания.

Ведущие:
Основные лекции по проектированию провожу я, Косинова Наталья, мой опыт интеграции более 15 лет, восновном шинная интеграция проектов Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.

Мне помогает
Андрей Корниенко, с точки зрения разработчика и архитектора раскрывает тему технологий, архитектуры решений и интеграции с помощью брокеров сообщений. Именно взгляда разработчика часто не хватает аналитику, когда речь идёт о реализации решения.

Чтобы записаться на курс оставьте свою заявку на нашем сайте ➡️https://sup.expert/

Если у вас остались вопросы, пишите в комментариях, я обязательно отвечу 🔽

До встречи на занятиях!
#анонс #курсинтеграции #интеграция #системныйаналитик #системныйанализ #мойопыт
Please open Telegram to view this post
VIEW IN TELEGRAM
Аналитик, догони разработку!

Часто аналитик попадает в ловушку под названием "разработка опережает анализ".

При этом аналитик начинает летать в облаках "вот, вот, я сейчас поднажму и всех догоню!", ага, ага, плавали знаем... Турбо ускорителя у меня нет, да думаю и у вас тоже нет, у меня ни разу не получалось.

А кто-то скажет, а что в этом такого? Пусть разработка опережает, ничего страшного.
При этом мы видим загнанного лошадь аналитика, который уже на грани срыва, где глаза наполняются слезами и он не понимает зачем он нужен, что он тут делает и весь мир тлен.

А ещё к этому добавим ситуацию "я один аналитик на проекте и мне нужно догонять" 😵‍💫 и он превращается в тестировщика, технического писателя, не может раскрыть весь свой потенциал, а может грешным делом думает, что всё в порядке, но тайно вечерами мечтает уволиться.

В такой ситуации аналитик больше похож на уборщицу магазина, которая ходит нонстоп за посетителями и вытирает след от грязных ботинок. Но попросить разуться при входе, не может, так вроде заведено...

Я сама попадала в такие ситуации, при этом мой непосредственный руководитель считал, что всё хорошо.

-------------------------------
Что можно с этим сделать:

первое признать, что что-то не так в процессах и их нужно менять, и продавать эту мысль руководителю (даже если он не верит, можно капать на мозг)

второе, вспомнить зачем нужен анализ и технические задания, зачем нужен аналитик (кто-то скажет, он нам не нужен, хорошо, тогда не нанимайте подобных специалистов и не ждите от них результатов). Аналитик занимается проектированием, а оно в свою очередь нужно перед разработкой программных продуктов, для описания решения на языке требований, чтобы в конечном итоге снизить неопределённость и уменьшить количество переделок.

аналитик помогает ускорить процесс разработки (на моем опыте, команда с хорошим аналитиком начинает "съедать" backlog задач быстрее в 2 раза)

признаться аналитику, что вам нужен тестировщик или технический писатель, а что?)) может правда нужны другие специалисты

и в конце концов поставить анализ перед разработкой, и дать аналитику возможность опережать разработку хотя бы на полспринта, а лучше на целый спринт.

Иногда стоит просто открыть рот и начать говорить, о том, что что-то не так. И просить изменить процесс.

И тогда наш аналитик:
😏- повеселеет (руководство чаще всего думают, что все аналитики вечно в депрессии из-за кислого выражения лица, просто мы знаем чуть больше и нам трудно)))
😎-станет более заряженный, будет действовать в интересах команды и приносить проработанные задачи на обсуждение разработчикам.

А тут, глядишь и оценка сроков станет более чёткой)))

Сплошные плюсы, а всего лишь, всё расставили по своим местам))

#мойопыт #системныйаналитик #системныйанализ #больаналитика #управление #смертныегрехи #догониразработку
Please open Telegram to view this post
VIEW IN TELEGRAM
Квотирование в интеграции, что это такое и зачем нужно?

Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.

Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.

Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.

А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.

Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).

Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.

Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.

#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции

А какие вы встречали кейсы Квотирования в своей практике?

Делитесь в комментариях ниже 👇
Как выбрать паттерн интеграции?

Это любимый вопрос аналитика. И его можно понять, ибо ставя задачу на разработку и не понимая, как принимаются решения, сложно контролировать и принимать результат работы. Чувство не самое приятное, ты в команде, но почему так сделали непонятно.

➡️ Один из ответов, к сожалению, звучит так - потому что так сложилось. 🤷‍♀ Действительно, часто нет логического чёткого объяснения почему так. Потому что наш директор поехал на презентацию, там выпил водки и купил лицензию по шине, а теперь нам с ней работать. Занавес.


➡️ Следующий ответ звучит, как - а мы только так можем, и никак по-другому. Действительно, команда просто по-другому не умеет, и делает так, как привычно. Нет компетенций, опыта, бюджета на новое, на обучение. Всё что угодно. Оно работает? Работает. Тогда не ломай, не трогай.

➡️ Дальше, самый сок, когда ты думаешь, ну вот сейчас будет шина, а вот тут брокер. Но приходит партнёр и говорит - у нас нет разработчиков, и вообще мы, уходя на выходные, выключаем сервер. У нас был такой кейс. И тут кроме интеграции через электронную почту, у нас не было больше никаких других вариантов. Даже с файлами они не хотели работать.

➡️ И если включать здравый смысл и логику, то нужно исходить из бизнес требований, нефункциональных требований, объёма передачи данных, масштабирования, развития компании, ИТ-ландшафта, ограничений бюджета,и конечно сотрудников.

Какие есть Паттерны?
По способу передачи данных:

Обмен данных с помощью
файлов
общей базы данных
- это антипаттерны интеграции, от них лучше уходить.

Те кто хоть раз подобные паттерны пытался поддерживать в продуктиве могут рассказать множество замечательных историй, про седые волосы и бессонные ночи.

И остаётся чаще всего применяемые паттерны -
удалённый вызов процедур
обмен сообщениями (шина, брокер).

Удалённый вызов процедур - по сути онлайн обмен между двух систем, которые соединены напрямую, через API.

Брокер - это работа с абстракцией в виде очереди, которая может быть реализована по-разному (например, на основе протокола AMQP).

Шина - это швейцарский ножик, который вбирает в себя все Паттерны и нюансы управления интеграционным слоем.

Шина с централизованным обменом данных является одним из паттернов SOA архитектуры.

Брокер может быть с очередями частью шины или способом передачи сообщений в микросервисной архитектуре.

В реальности в ИТ-ландшафте компаний можно встретить гибрид из всех паттернов интеграции по способу передачи данных.
И каждый из них имеет свои плюсы и минусы, применимость в конкретных случаях, среде.

И кажется, что в айти всё логично, и есть обоснование всему, что происходит. Но нет. Часто скрытых смыслов и большого пути принятия решений попросту нет.

Подробнее про проектирование интеграционных решений вы можете узнать на нашем курсе, старт потока уже в этот четверг 16 ноября.

Почитать про курс можно вот тут ➡️ sup.expert

#курсинтеграции #курс #системныйанализ #паттерныинтеграции

⚡️Остались вопросы или вы хотите записаться, пишите напрямую мне))
Please open Telegram to view this post
VIEW IN TELEGRAM
Реальные результаты наших участников курса интеграции.

В большинстве своём на курс приходят ребята, кто был у меня на менторстве, оно и понятно, но и не только! У каждого свои цели. И вот немного классифицирую, по грейдам, кто что уносит и использует на практике:
1.Начну с джунов или тех кто хочет стать системным аналитиком. Очень сложно бывает показать, что именно нужно специалисту для прокачки. Курс интеграции, как курс молодого бойца показывает систему знаний, инструментов, подходов и практик. Что хорошо, мы полностью проходим по пирамиде артефактов и доходим до уровня технологий, данных. Я не хочу давать обещания, которые считаю нереальными. Но то, что джун поймёт, куда ему дальше и что такое системный анализ это точно.
2.По результатам курса можно написать свой собственный план развития, и взять за основу те ссылки, те внешние источники, книги которые мы рекомендуем, и на которые опираемся.
3.Миддл аналитики обретают уверенность! Это очень важно. Они могут чего-то не знать, но понимать объем, границы задачи и чувствовать себя увереннее. Понимают, куда смотреть, что делать.
4.Как так уже давно получилось, что я стала для многих "карьерной феей"))) Ребята после работы со мной идут дальше, есть даже те кто вырос в айти директора, кто-то в архитектора, тим лида. И вот по результатам наших даже двух потоков курса, много кто сменил работу! Пошёл выше по грейдам, прибавил в деньгах. Как говорит Андрей Корниенко, у аналитиков открылись глаза и поняли, что именно они должны делать, отсюда уверенность, энергия перемен и попытка дальше себя развивать, для этого меняют среду. Мы ничего специально не делаем, так получается))) А то компании, чего неладное подумают))
5.Многие отмечали такой факт, что стали увереннее на собеседованиях и смогли ответить на каверзные вопросы. Или честно сказать, что они и в каком объёме могут сделать.

Так что не хочу обещать вам успешный успех, скажу лишь только одно - вы сможете унести столько сколько можете на текущий момент. Есть у нас такие прецеденты, когда участник курса пересмотрел его заново в записи, и вынес новое, чего за первый заход в упор не понимал. Это было любопытно и радостно))

Видео запись и материалы остаются навсегда, как и возможность общения со мной и моим компаньоном. Андрей Корниенко помогает мне на курсе в части технологий, взглядом разработчика и архитектора, что очень важно в работе аналитика.

Приглашаю вас присоединиться к группе, старт уже завтра! В новый год вы вступите с новыми знаниями))

#системныйанализ #курс #курсинтеграции #анонс #результатыучастников #интеграция

Остались вопросы, пишите мне‼️
Please open Telegram to view this post
VIEW IN TELEGRAM
Концептуальное проектирование

Есть две вещи, которые простые, очевидные #капитаночевидность поэтому их мало кто делает.

Первая это Концептуальное проектирование (сюда же DFD отнесу), а второе - это блок-схемы, с помощью которых можно и алгоритм описать и процесс, и сделать это хорошо!

Сегодня решила написать про Концептуальное проектирование.

Что может быть проще - в центр поместить систему, которую мы проектируем, вокруг участников информационного обмена, и стрелками показать направление потоков данных, кто, кому, что передаёт.

Но, в чем трудность?
1.Заставить себя мыслить в структуре и разложить по схеме - участники, данные уже не те просто. Скучно, дайте нам сразу строить космический корабль. Чтобы выделить набор данных нужно хорошо понимать, а что мы собственно делаем и промоделировать процессы.
2.Если возьмём DFD - да, есть разные нотации, но суть одна и та же, к наших участникам, и данным, добавляется хранение данных. Откуда и куда уходят данные и где остаются.

DFD, концептуальное проектирование заставляет нас думать структурой. И отбрасывать то, что круче, интереснее, можно помоделировать)))

По сути мы наш концепт раскладываем по следующим пунктам:
1.Источник данных
2.Потребитель данных
3.Обработка, работа, логические функции над данными
4.Потоки данных
5.Хранилища данных

И нам неважно, как будет реализована наша концепция, на начальном этапе. Какие технологии передачи данных будут выбраны. Требования ещё не собрали и до структуры хранилищ не добрались, как и до самого кода.

К DFD мы можем подходить, как в слоёному пирогу, как и с ER диаграммами, по этапам:
1.Описать концепцию - участники и потоки данных
2.Добавить логику обработки - получим логический уровень
3.Добавить хранение данных - физический уровень

Но если вы сделаете хотя бы концепцию решения уже станет лучше))) и будут видны участники, системный контекст, границы решения.

Мне нравится статья по этой теме в школе системного анализа и проектирования.

Рекомендую к применению на проектах)

#интеграция #концепция #dfd #системныйаналитик #системныйанализ #системныйконтекст
Требования - это же не rocket science, что тут сложного?

Когда ко мне на менторство или на курсы приходят аналитики, особенно с опытом, на вопрос умеют ли они собирать требования и их формулировать? Все с большой уверенностью говорят да.

Мы копаем дальше, но в какой-то момент понимаем, что нужно вернуться к базовым вещам, их скорректировать, и ещё раз разобрать работу с требованиями, их классификацию.

Правда, эти требования уже всех задолбали, но сколько можно о них говорить?) Дайте, что-то поинтереснее!

Требования - это ключевая единица результата работы аналитика.

По факту аналитик, даже с опытом, может не видеть нюансы. Это нормально. Я сама такая же, не сразу доходит.

Хотя казалось бы #капитаночевидность, что тут сложного, разложи требования по уровням:
БТ (бизнес),
ПТ (пользователь),
ФТ (функция),
НФТ (ограничения),
СТ (система).

Но чем проще инструмент, тем сложнее с ним работать))) прям #ладайламинг

Суть проблемы, состоит в том, что аналитик не видит разные уровни абстракции, не видит нюансы, какое требование к чему относится. И на выходе получается каша, и не всегда понятно на каком уровне мы сейчас находимся? Бизнес, Пользователь, Функция, или Система?

#работастребованиями #системныйанализ #системныйаналитик #требования

Что с этим делать? Своё мнение расскажу завтра, а пока пишите свои варианты в комментариях 👇
⚡️Сбор требований, это не ядерная физика!

Хуже, когда тебе нужно собрать требования в ядерной физике 🤯

Что же поможет аналитику при работе с требованиями?

Первое, это начать замечать уровни требований. Чтобы заметить проблему, её нужно сначала просто назвать. Тут поможет пирамида артефактов, дополнительные вопросы.

Второе, это инструменты выявления и фиксирования требований, нотации в том числе в помощь. Всё зависит от уровня требований. Если мы находимся на бизнес уровне, так на языке этого уровня и нужно говорить, брать бизнес-модели, орг структуру, бизнес-процессы.

Третье, это абстрактное мышление. До сих пор ведутся споры, что такое мышление, а тут ещё и абстрактное. Но действительно оно есть, способ думать так, чтобы минимально опираться на самое решение, разработку. Это действительно сложно. И подобный навык дают технические вузы, но как любое мышление, абстрактное мышление можно развивать.

Четвёртое, логика и взаимносвязи наших требований. Тут помогут знания по формальной логики, теория по пирамиде Минто, теория графов, математика. Но я бы ещё добавила и философию. Всё в системе даёт результат.

Пятое, банальные вещи, опыт, насмотренность, вопросы старшим коллегам, активность. Да и просто иногда нужно делать, как другие.

Шестое, знания методологий разработки программных продуктов. Всё таки среда очень сильно влияет и необходимо подстроиться под заказчика и команду одновременно.

Седьмое, понимание, когда нужно остановиться. Чем больше требований вы описываете на низком уровне, тем больше падает качество результата.

Восьмое, знание технологий, подходов в программирование. Всё таки аналитик должен иметь знания, не только на уровне бизнеса, но и на уровне информационных систем (я говорю про системного аналитика). Банально, но часто аналитик даже не может сказать заказчику - "такого не существует".

Девятое, soft skills, никто не отменял. Адекватность, умение открыть рот и начать говорить, кажется очень простым навыком, но по факту, это нефига не просто.

#требования #системныйаналитик #работастребованиями #чеклист #системныйанализ #моемнение

А что вам помогает в работе? Пишите в комментариях 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
Я боюсь, что разработчики решат, что я дурачок.

Аналитики перфекционисты, и возмутители спокойствия одновременно.

Часто аналитик находится в ситуации:
- все всё понимают, я не понимаю,
- якобы все знают, что я должен выдать и как, но почему-то мне не говорят и я как сапёр хожу по минированному полю,
- боюсь, сделать неверный шаг в сторону и возмутить спокойствие и будет взрыв негодования.

Что могу сказать...
Пусть будет взрыв!
Пусть назовут дурачком. Вы то знаете о себе правду лучше других 😎

Возможно, это будет сексизм, но иногда разработчики более лояльны к девушкам, "ну что с неё взять, она девушка. Какой-то бред написала. Ну и пусть..."

Но я много раз в свою сторону получала взрыв эмоций под названием "какой мудак это написал!?"

Раньше я переживала, а теперь я понимаю, что такие эмоции это моё оружие. И когда все партизаны вокруг и ничего не говорят, я могу подготовить несколько вариантов диаграммы (а почему бы и не да!).
Сначала показать ту, которая вызовет взрыв эмоций, и на этих эмоциях "всё не так", я получу ответ, а "как надо". Только записывай. А если этот вариант совпадает с тем, что у меня есть в портфеле вариантов, то я как фокусник из рукава достану вариант со словами "а кстати говоря, у меня есть то, о чем вы говорите, так хотели бы? Посмотрим вместе?"

Но надо дождаться, когда вулкан эмоций выльется, и тогда можно показать вариант, а можно и чуть позже показать вариант, дав людям управлять ситуацией.

Хитро? Наверное.
Работа выполнена? Да.
А о способе получения информации уже никто и не вспомнит.

Тут единственное но нужно учиться ставить границы, что этот взрыв эмоций, не потому что я плохой специалист, а потому что я управляю этой ситуацией и использую этот способ выявления требований, подкинув катализатор.

Конечно риски такого способа тоже нужно взвесить, чтобы не влияло на вашу репутацию.
И быть готовым к разному развитию событий.

А вы какие используете катализаторы в работе?

#сбортребований #катализатор #лайфхаки #капитаночевидность #системныйанализ #мойопыт #моемнение #выявлениетребований