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

Курс интеграции:
https://sup.expert/

Написать мне @tasha_kvitka
Download Telegram
Вакансия, как чеклист развития аналитика)

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

С одной стороны #реклама #вакансия
А с другой стороны описание, которое смело можно превратить для себя в чеклист, как мне стать аналитиком сеньорного уровня?

Описание настолько хорошо, что хочется пообщаться с командой, конечно ещё нужно понимать, что это описание сделал Сергей Нужненко.

Если вас заинтересовала вакансия, смело пишите 📝 в личку Сергею @darkboatman

---------------
Ведущий/старший системный аналитик 🥷

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

Что, делать:
- Выявлять, собирать и разрабатывать требования к системе в тесном взаимодействии с бизнес-аналитиком, представителями бизнеса и разработчиками.
- Помогать команде документировать системную архитектуру и системный дизайн.
- Прорабатывать потоки данных между отдельными сервисами, логические схемы данных, эскизы пользовательских интерфейсов, проектировать API вместе с разработкой.
- Помогать в проведении архитектурных сессий разработки с бизнесом для превращения требований в задачи команды.
- Документировать бизнес-процессы, требования, функции, архитектуру, интерфейсы, алгоритмы, структуры данных системы в необходимом разработке и бизнесу объеме вместе с бизнес-аналитиком.
- Разрабатывать детальные постановки к задачам разработки, сопровождать разработку и тестирование ответами на вопросы и недостающими деталями постановок.
- Участвовать в приемке и поддержке пользователей.

Чего мы ждем от кандидата:
- Умение моделировать и описывать деятельность, функции, структуры данных, интерфейсы, алгоритмы.
- Умение работать с требованиями.
- Знакомство с основными концепциями процедурного и объектно-ориентированного программирования.
- Умение моделировать и описывать архитектуру и дизайн систем и программных приложений.
- Готовность изучать и применять инструменты и технологии, выбранные командой для работы.
- Знакомство с концепциями REST API (JSON), SOAP (XML/XSD/WSDL)
- Знакомство с принципами проектрования реляционных БД.
- Грамотный русский язык, умение структурировать текст в документах, письмах, тикетах.
- Навыки деловой коммуникации, проведения интервью, донесения мыслей, подготовки и проведения презентаций, обсуждения решений и конструктивного отстаивания своей позиции.
- Понимание жизненного цикла ИТ-систем, процессов разработки, сопровождения и развития ПО.

Не обязательно, но приветствуется широкий кругозор и наличие знаний и навыков проектирования систем. В том числе:
- Знакомство с формальной логикой.
- Знакомство с классификацией и атрибутами качества требований.
- Опыт работы с системами моделирования, Sparx Systems Enterprise Architecht, Visual Paradigm или другими.
- Отсутствие "аллергии" на высшую математику, в том числе дискретную математику, структуры данных и алгоритмы, реляционную алгебру.
- Знакомство со стандартами, нотациями и практиками моделирования IDEFx, DFD, UML, BPMN, ARIS и др.
- Знакомство с подходами к описанию функций в виде Use Case, User Story, пользовательских сценариев.
- Знакомство с Agile практиками Story mapping, Event storming, CJM, Service Blueprint, 4 context architecture.
- Практики бизнес-анализа, в том числе Busines Canvas, понимание структуры бизнес-плана, умение работать с бизнес-целями, проектированием бизнес-процессов и обоснованием ценности проектов и фич.
- Знакомство с ГОСТ серии 34 и 19 и современными стандартами системной инженерии и управления требованиями.
- Опыт фасилитации групповых рабочих сессий.
- Навыки проектирования баз данных.
- Знакомство с Domain Driven Design, шаблонами интеграции приложений, шаблонами реализации микросервисной архитектуры.
Please open Telegram to view this post
VIEW IN TELEGRAM
Чек-лист интеграции.

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

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

Много лет назад на одном из митапов московских аналитиков, был написан коллективный чек-лист "Интеграции". Попытка как раз хоть как-то себе облегчить жизнь)))

Его и предоставляю вашему вниманию.
💥

--------------------------
1.  Определить системы, участвующие в обмене
2.  Описать потоки данных
3.  Понять наличие гарантированной доставки данных
4.  Описать регламент взаимодействия систем:
•  передаваемые данные
•  частота передачи
•  расписание
•  система-инициатор обмена
5.  Описать формат передачи данных:
•  Названия атрибутов
•  Тип, длина
•  Обязательность
•  Кодировка
6.  Зафиксировать маппинг данных из формата системы-источника в формат системы-приёмника.
7.  Понять в какой системе хранятся мастер-данные по объектам.
8.  Выявить необходимость преобразования/проверки на актуальность/обогащения данных.
9.  Зафиксировать протоколы обмена данными.
10.  Понять ограничения платформы/канала интеграции.
11.  Нефункциональные требования:
•  Выявить требования к скорости обработки и передачи данных.
•  Понять необходимость шифрования данных.
•  Оценить объем передаваемых данных.
•  Понять наличие ограничений на уровне регулятора (152 ФЗ, PCI DSS).
12.  Описать интеграционный сценарий взаимодействия.
13.  Понять способ взаимодействия – синхронное/асинхронное.
14.  Описать механизм обработки ошибок.
15.  Выявить требования к настройкам и администрированию.
--------------------------

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

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

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

✔️Мы не фабрика, не огромная площадка, нам самим прежде всего интересно передать свои знания и опыт, так чтобы это было системно и структурно. Это даёт нам проявлять гибкость и нестандартно зачитывать материал.

📌Подробнее о курсе можно прочитать тут https://sup.expert/

старт потока совсем скоро, уже в этот четверг 21 сентября!)

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

Расскажу именно свой процесс, да он может быть не последовательный, но я опишу его по шагам (+ см. чек-лист):

1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно (вспоминаем эффект Бандуры) .
2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения.
3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает.
4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки.
6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы.
8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет пытаюсь посчитать и согласовать с разработкой.
11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов (могу и сама на них проверить API, иногда спека отличается от реальной жизни и тогда всё будет насмарку)).

Очень кратко описала процесс, специально опуская детали.

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

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

Многие смогли понять свои проблемы и написать план собственного развития и мощно обновили свои базы знаний 📈

Приходите к нам на интеграцию ➡️ https://sup.expert/

#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡️Сбор требований, это не ядерная физика!

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

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

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

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

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

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

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

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

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

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

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

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

А что вам помогает в работе? Пишите в комментариях 👇
Please open Telegram to view this post
VIEW IN TELEGRAM