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

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

Написать мне @tasha_kvitka
Download Telegram
Полномочия, влияние, власть.

#управлениеизменениями #управление #адизес #books #рассуждения #выводы

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

Но я технический человек, мне нужна конкретика! Обычно я всегда так возмущалась) А тут читаю у Азидеса, что нормально чем-то не обладать, и если вам нужны полномочия идите и попросите. Спасибо #капитаночевидность !!!

И вот мы в итоге получаем три варианта управления:
1.Когда у нас есть полномочия, есть влияние и есть власть. И тогда в таких условиях любые наши поручения, задачи реализуются и исполняются. Но такая ситуация может быть только у технического специалиста. Вы знаете какое решение может быть хорошим, как принимать решение, как о них сообщать и как осуществить.
2.Следующий вариант, у вас есть только полномочия, тогда вам нужно быть политиком. Вам нужно создать взаимовыгодные условия, в которых каждый чувствует свою связь с остальными.
3.Если у вас есть только влияние, то вы должны быть психологом-практиком. Вы должны осуществлять коммуникации с людьми на том языке, который им понятен.

Итого получается, что хороший менеджер это:
➡️Техник
➡️Политик
➡️Психолог.

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

___
Другие посты про типы менеджеров, у которых ярко проявлена одна черта менеджера:

😎Одинокая женщина/Одинокий ковбой

🔥Поджигатель/Бешенный креативщик

🥸Интегратор/Политик манипулятор
Please open Telegram to view this post
VIEW IN TELEGRAM
С чего начинать проектирование интеграции? А как продолжить и ничего не забыть?
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)


Мой путь в айти начался, как раз с интеграции, в далёком 2006 году в телекоме, в команде шинной интеграции продукта IBM WebSphere. Интеграция, как красная линия, проходит через весь мой опыт. Практически ни один из проектов, в которых я участвовала, не проходил без интеграции.
Мне знакомы трудности и "подводные камни" на пути системного аналитика.

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

Что поможет?
- фундамент знаний различных дисциплин
- опыт, тут я как #капитаночевидность
- шаблон ТЗ (с любыми шаблонами работать проще)
- знание, применение инструментов проекторования, основа - это sequence диаграмма (Uml) и сценарная техника (Use Cases), но без диаграммы статусов State Machine (Uml) и диаграмм C4 (DFD+Component) тоже не обойтись
- знание технологий SOAP, REST API
- и такие замечательные слова как безопасность, логирование, мониторинг, квотирование, мастер-данные, гарантированная доставка тоже должны быть понятны, как и шина, и брокер)

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

Разберём:
1.Из каких шагов состоит проектирование интеграции
2.Что точно стоит изучить, чтобы стало понятнее и легче
3.Как можно классифицировать интеграцию
4.Часто возникающие подводные камни или #смертныегрехи системного аналитика
5.Кейсы из жизни, их у меня накопилось много)

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

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

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

А прямо сейчас задавайте свои вопросы, которые касаются интеграции 👇
Интеграция - это не только маппинг данных. 😎

Некоторые руководители считают, а что там сложного в интеграции, описали маппинг данных и всё! Вперёд!

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

Да, можно и нужно разбираться в технологиях. Да, REST API, Кафка, микросервисная архитектура это текущий тренд отрасли и все бегут в эту сторону, услышав модные слова (и то уже сделаны выводы, что не так с микросервисами и не везде они нужны).
К задаче интеграции нужно подходить, как к "слоёному пирогу", и снимать слой за слоем уровней требований.
Отсюда и проблема, что аналитики чего-то не знают, где-то есть пробелы, не видят границы и задачу системно. Ходят с курса на курс, читают книги, смотрят вебинары, но это всё не даёт единую картину мира. Это всё прекрасно и нужно, но стоит собирать знания вместе, чтобы оно заработало.

Например, чтобы соединить две системы между собой, сначала нужно понять на бизнес уровне, что соединяется? Зачем? Какой бизнес-процесс в итоге мы выстраиваем. Да, если мы работаем со справочниками тут нет вопросов, тут действительно маппинг данных и регламенты обмена включаются, и вперёд!
Но если у нас сложная интеграция, то нужно понимать, как будет работать бизнес-уровень, какие объекты предметной области участвуют в процессах, как меняются их статусы при интеграции, как сценарии на пользовательском уровне переходят в функциональный, как наше решение вписывается в системный контекст ИТ-ландшафта компаний. И только пройдя несколько уровней абстракции, мы доходим до данных и технологий обмена этими данными. И тут как раз нам и нужны знания по REST API, SOAP, тут дальше можно назвать другие страшные слова.

Я конечно #капитаночевидность будучи системным аналитиком, подходи к задаче системно и будет тебе счастье) Делай нормально и будет нормально))
Но действительно это работает!

Завтра расскажу о системном подходе к интеграции ☝️

А пока делитесь мыслями, какие у вас подходы при проектирование решений интеграции? Что вам помогает?)

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

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

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

Аналитик может цикл за циклом возвращаться к артефактам, и это нормально! Не ждите чистовой версии с первого раза! Ваш перфекционизм нужен только при ловле блох! Получил новую информацию понял, что нужно пойти и что-то изменить, вернулся и изменил. Изменения это нормально. Понял, что слишком большой кусок взял на переваривание, остановился, декомпозировал, разделил и пошёл властвовать с небольшим объёмом. А иногда другая крайность появляется, так много всего, за что хвататься, нужно всё!!! Ааааа!!! Начни с ключевых моментов, в интеграции это сценарии и sequence диаграмма, по этим сценариям. А дальше стройте вокруг них.

Горькая правда состоит в том, что подходы к своей работе, к проектированию вы формируете сами. Работа системного аналитика не так проста, как её продают. И самое ценное это наслоение знаний, на фундамент, и всё это работает в системе и в итоге вам выдает хороший результат.

Я как ментор, тренер создаю реальные условия на курсах, сессиях, от которых бывает участников бомбит "дайте адаптированный вариант!" Но на ваших проектах не будет такой адаптации и вам придётся справляться самим.
Мне же хочется заложить граф связанных инструментов, знаний, навыков, чтобы очертить поле битвы. И подсветить, то чего не хватает аналитику для его работы. Чтобы он в боевых условиях не растерялся и понял, ага, это вот там должно быть, помню, помню этот пазл. Отсюда кстати и уверенность приходит)

Да, я могу показать один из вариантов, а может даже ни один и подходов к решению задачи может быть много. И тут всё зависит от уровня прокачки аналитика. Потому что кому-то не нужны шаблоны, адаптированные задачи и "костыли", а кому-то пока нужно научиться ходить, то есть мыслить))) а потом уже и бегать на скорости! и тут Остапа понесло...

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

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

Завтра продолжим говорить про то, из чего состоит проектирование интеграционных решений 🤓
Please open Telegram to view this post
VIEW IN TELEGRAM
Администрирование интеграции

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

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

Так что принцип "сделать так, чтобы ко мне мало прибегали с вопросами" очень мотивирует.

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

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

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

Какие могут быть параметры настроек?
Например, типичные и часто встречающиеся:
➡️- тайм зона, бизнес любит расширять свои границы на разные регионы, даже если не сразу говорит, но захватить мир все хотят,

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

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

➡️- настройки связанные с обработкой ошибок, нужно ли включать повторные вызовы, если была ошибка, сколько раз, за какой период,

➡️- уровни логирования данных (может быть встроенная функциональность разных платформ, а может быть своя логика),

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


Как-то мне аналитик, сказал, вот ты топишь за настройки, а у нас их было так много, что мы запутались.

⚡️Ну во-первых, можно делать значения по умолчанию, и не трогать ружье, которое висит на стене, но раз в год выстрелит.

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

Конечно, я могла что-то забыть, и полно все детали в пост не впихнуть, но с думаю мой посыл понятен.

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

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

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

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

И я так радовалась, ну вот оно!

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

И на самом деле это очень круто, когда 2-5 человек говорят одни и те же проблемы, их подсвечивают, значит реально их нужно решать. Если не решать, не вносить изменений, то не будет развития. #капитаночевидность

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

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

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

#изменения #новыйсотрудник #мойопыт #онбординг #лидер
Квотирование в интеграции, что это такое и зачем нужно?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Список книг, которые бы хотелось прочитать растёт в геометрической прогрессии. При этом есть над чем работать и есть, что изучить. Это огромный поток под словом "НАДО"! А ещё надо было ещё вчера, хочется остановиться и закричать!

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

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

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

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

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

Достойный, глубокий, структурный, действительно мощный материал порой бывает очень трудно найти. А поверхностный уровень его валом.

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

Есть ли экономия времени? Кажется, что нефига. Потому что так много предложений и я трачу время на их анализ, потому что я аналитик и не всегда могу быстро принять решение)) оно должно созреть. И фильтрую материал, потому что есть дно, которое нафиг не нужно (может тут ИИ бы и помог). И вот отбросив фигню, я нахожу то, что мне действительно нужно и уже это изучаю, читаю.

#подмечено #мирвокруг #саморазвитие #обучение #моемнение

А как вы обучаетесь?
Используете ли искусственный интеллект?
Остаётся ли что-то в голове?)
Требования - это же не rocket science, что тут сложного?

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

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

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

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

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

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

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

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

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

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