Коллеги из NextWay устраивают 2 августа онлайн-конференцию для аналитиков. Мне показался интересным разброс тем в программе: от стриминговых платформ и ИИ-агентов до антикризисной карьеры и “Как выжить в 2025 и не выгореть”.
Ощущается, как аналитический пост-апокалипсис: собираем бластер за кучей легаси, чтобы успеть отбиться от роботов🤖 . Да, сейчас “сложный рынок”, но у меня не было ощущения, что профессия сама по себе в кризисе. Сообщество развивается, IT-компании внедряют процессы проектирования, открываются позиции для аналитиков. Всё реже встречаю людей, которые никогда не работали с БА/СА и вообще не в курсе, чем мы занимаемся. Да, развивается ИИ, но ему все равно нужны будут вводные: требования, цели, ограничения. Вроде за этим и нужен аналитик. Или уже нет?🤔
То есть кажется, что кризис на рынке и быстрое развитие ИИ разогнали всем воображение и уже сложно понять: кто мы, что мы делаем и зачем? Как будто мы бежим вокруг дерева со скоростью света и вот-вот себя нагоним.
Поэтому интересно послушать спикеров на конференции: с какими вызовами встречаются коллеги и как их решают? На сколько сильно изменились требования от аналитиков и их задачи? Можно ли определить какой-то вектор развития профессии, или пока это броуновское движение?
А вы как считаете: ИИ просто вскружил нам головы или грядут великие перемены?
Ощущается, как аналитический пост-апокалипсис: собираем бластер за кучей легаси, чтобы успеть отбиться от роботов
То есть кажется, что кризис на рынке и быстрое развитие ИИ разогнали всем воображение и уже сложно понять: кто мы, что мы делаем и зачем? Как будто мы бежим вокруг дерева со скоростью света и вот-вот себя нагоним.
Поэтому интересно послушать спикеров на конференции: с какими вызовами встречаются коллеги и как их решают? На сколько сильно изменились требования от аналитиков и их задачи? Можно ли определить какой-то вектор развития профессии, или пока это броуновское движение?
А вы как считаете: ИИ просто вскружил нам головы или грядут великие перемены?
Please open Telegram to view this post
VIEW IN TELEGRAM
nextconf.pro
Профессия аналитик - настоящее и будущее. Архитектура и технологии, карьера и развитие, AI-инструменты для работы и жизни.
👍10❤🔥4🔥4❤1
А еще в августе буду жюрить в конкурсе авторских постов🤗
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤3👏2
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
🏆 Конкурс авторских публикаций «Продолжи мысль» от Systems.Education
За последние годы сообщество авторов экспертных постов в Telegram серьёзно выросло. Мы предлагаем возможность ведущим профессиональных каналов заявить о себе. На конкурсе мы будем оценивать ваше умение не только писать чётко, понятно и по делу, но и рецензировать публикации коллег.
▫️ Участниками конкурса могут стать авторы, ведущие Telegram-каналы на темы, связанные с системным, бизнес-анализом, проектированием ИТ-систем и смежными дисциплинами.
Формат конкурса — Дистанционный. Участники будут размещать свои авторские публикации в собственных Telegram-каналах.
▫️ Зачем это вам:
— Заявите на большую аудиторию о своих знаниях, опыте и наработках
— Получите бесплатную нативную рекламу ваших блогов, если пройдёте в первый и второй туры
— Победители конкурса получат профессиональное развитие за счёт SE на свой выбор: оплата подписок на профессиональные ресурсы, продюсирование и методическая поддержка авторов, менторство и карьерные консультации от экспертов
▫️ Зачем это нам:
Мы стремимся развивать профессиональное сообщество системных и бизнес-аналитиков. Поэтому мы готовы поддерживать авторов качественного контента и распространять знания в области анализа и проектирования ИТ-систем.
⬆️ На карточках мы подробно рассказали о процессе подачи заявки, номинациях и этапах конкурса.
На лендинге вы найдете ссылку на регламент с методикой оценивания конкурсных работ и список жюри.
Подавайте заявку — и пусть мысль не просто продолжится, а станет вирусной
Контакт координатора для ответов на вопросы и подачи заявки на конкурс — @kosvetlanov
#продолжи_мысль_SE
За последние годы сообщество авторов экспертных постов в Telegram серьёзно выросло. Мы предлагаем возможность ведущим профессиональных каналов заявить о себе. На конкурсе мы будем оценивать ваше умение не только писать чётко, понятно и по делу, но и рецензировать публикации коллег.
▫️ Участниками конкурса могут стать авторы, ведущие Telegram-каналы на темы, связанные с системным, бизнес-анализом, проектированием ИТ-систем и смежными дисциплинами.
Формат конкурса — Дистанционный. Участники будут размещать свои авторские публикации в собственных Telegram-каналах.
▫️ Зачем это вам:
— Заявите на большую аудиторию о своих знаниях, опыте и наработках
— Получите бесплатную нативную рекламу ваших блогов, если пройдёте в первый и второй туры
— Победители конкурса получат профессиональное развитие за счёт SE на свой выбор: оплата подписок на профессиональные ресурсы, продюсирование и методическая поддержка авторов, менторство и карьерные консультации от экспертов
▫️ Зачем это нам:
Мы стремимся развивать профессиональное сообщество системных и бизнес-аналитиков. Поэтому мы готовы поддерживать авторов качественного контента и распространять знания в области анализа и проектирования ИТ-систем.
⬆️ На карточках мы подробно рассказали о процессе подачи заявки, номинациях и этапах конкурса.
На лендинге вы найдете ссылку на регламент с методикой оценивания конкурсных работ и список жюри.
Подавайте заявку — и пусть мысль не просто продолжится, а станет вирусной
⏰Прием заявок до 11.08 включительно
Контакт координатора для ответов на вопросы и подачи заявки на конкурс — @kosvetlanov
#продолжи_мысль_SE
❤7⚡3👍2
Опубликовала третью статью из цикла про GraphQL, посвященную архитектуре. На мой взгляд, это самая головоломная часть истории.
Есть множество вариантов, как примостить GraphQL API в рамках ИТ-ландшафта компании. Однако понять, какой из этих вариантов не превратит жизнь команды в боль и страдания — задачка не из легких🤯.
Конечно, бремя выбора ложится на плечи архитекторов и руководителей разработки. Но и нам, простым смертным, хорошо бы понимать — а что вообще происходит? Постаралась разобраться и объяснить существующие картины мира с GraphQL в рамках статьи.
Есть множество вариантов, как примостить GraphQL API в рамках ИТ-ландшафта компании. Однако понять, какой из этих вариантов не превратит жизнь команды в боль и страдания — задачка не из легких🤯.
Конечно, бремя выбора ложится на плечи архитекторов и руководителей разработки. Но и нам, простым смертным, хорошо бы понимать — а что вообще происходит? Постаралась разобраться и объяснить существующие картины мира с GraphQL в рамках статьи.
Хабр
Архитектура и GraphQL
Это третья статья из цикла « Проектирование GraphQL API ». Введение В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы . Теперь перейдём к архитектуре — фундаменту,...
🔥13❤7👍7🎉1😐1
Сделала тестовый Apollo сервер с примерами для моего цикла статей про GraphQL.
То есть можно зайти, повыбирать параметры, позапускать запросы.
Сервер находится на CodeSandbox. Поэтому сначала надо нажать “Yes, proceed to preview”, а затем “Query your server”.
Дальше в UI Apollo Studio:
1. Слева выбираем запросы и фильтры, которые хочется подергать.
2. По центру внизу вносим значения переменных запроса.
3. Нажимаем кнопку запуска и смотрим на результат справа. 😊
На картинке краткая визуальная инструкция.
Примеры для запросов и полную схему можно найти здесь.
Подписки можно протестировать локально. 🙂
То есть можно зайти, повыбирать параметры, позапускать запросы.
Сервер находится на CodeSandbox. Поэтому сначала надо нажать “Yes, proceed to preview”, а затем “Query your server”.
Дальше в UI Apollo Studio:
1. Слева выбираем запросы и фильтры, которые хочется подергать.
2. По центру внизу вносим значения переменных запроса.
3. Нажимаем кнопку запуска и смотрим на результат справа. 😊
На картинке краткая визуальная инструкция.
Примеры для запросов и полную схему можно найти здесь.
Подписки можно протестировать локально. 🙂
🔥16👏3❤2👍2🤯1
Пример подписок GraphQL
Сделать для подписок одну красивую ссылку не удалось, к сожалению. Но я навайбкодила докер-контейнер, который можно запустить локально. Это несложно😉.
Для начала нужен установленный Docker Desktop на компьютере.
Дальше в терминале:
1. Клонируем репозиторий: git clone https://github.com/spenderella/graphql-articles
2. Переходим в папку с сервером: cd graphql-articles/test-server
3. Запускаем сервер: docker-compose up --build
4. После получения сообщения "Server ready" в консоли, открываем http://localhost:8080/graphql
5. Дальше играемся с тестовой схемой, как хотим: примеры запросов доступны в папке /queries репозитория
6. Чтобы посмотреть подписки, надо открыть две вкладки: на одной запустить подписку, а с другой отправлять обновления в мутациях. На первой вкладке должны появляться сообщения об изменениях
7. Останавливаем сервер через Ctrl+C в терминале, и после закрываем контейнер: docker-compose down
А если вам нравятся мои материалы и вы хотите отблагодарить меня донатом — сейчас как раз то время, когда я буду им особенно рада❤️
ЮMoney | PayPal
Сделать для подписок одну красивую ссылку не удалось, к сожалению. Но я навайбкодила докер-контейнер, который можно запустить локально. Это несложно😉.
Для начала нужен установленный Docker Desktop на компьютере.
Дальше в терминале:
1. Клонируем репозиторий: git clone https://github.com/spenderella/graphql-articles
2. Переходим в папку с сервером: cd graphql-articles/test-server
3. Запускаем сервер: docker-compose up --build
4. После получения сообщения "Server ready" в консоли, открываем http://localhost:8080/graphql
5. Дальше играемся с тестовой схемой, как хотим: примеры запросов доступны в папке /queries репозитория
6. Чтобы посмотреть подписки, надо открыть две вкладки: на одной запустить подписку, а с другой отправлять обновления в мутациях. На первой вкладке должны появляться сообщения об изменениях
7. Останавливаем сервер через Ctrl+C в терминале, и после закрываем контейнер: docker-compose down
А если вам нравятся мои материалы и вы хотите отблагодарить меня донатом — сейчас как раз то время, когда я буду им особенно рада❤️
ЮMoney | PayPal
GitHub
graphql-articles/test-server at main · spenderella/graphql-articles
Examples GraphQL schemas & queries for series of articles - spenderella/graphql-articles
🔥7❤5
Чем занимаются системные аналитики?
Часто на менторингах и в неформальном общении встречаю вопрос: а чем именно должен заниматься системный аналитик на проекте?
Я обычно ссылаюсь на профстандарт. Но это общее описание, к тому же, далеко не все нанимающие менеджеры его читали.
В первой компании, где у меня была должность системный аналитик (2019г), я занималась: проектным менеджментом, UX-дизайном, бизнес и системным анализом, ручным тестированием, поиском багов в коде, поддержкой пользователей, внедрением системы в работу компании.
Мне было интересно проектировать требования, поэтому дальше я искала компании, где бОльшую часть рабочего времени надо будет этим и заниматься. Открыто говорила это на собеседованиях и спрашивала, какой процент времени у меня будет занимать именно проектирование.
В итоге следующие 5 лет я занималась в основном бизнес и системным анализом, с упором на системный. И тут надо было погружаться в технику: описывать спецификации API, интеграционные процессы, физ модели БД и архитектурные решения.
Мне это интересно, и я уходила все больше в детали реализации и все дальше от пользователей. И вроде бы все хорошо — рынок такое сейчас приветствует. Но иногда я ловила себя на мысли: а почему я прописываю индексы на этапе проектирования БД? Это же разработчик пишет запросы. Хотя в некоторых случаях запросы в виде псевдокода тоже пишу я.🤷🏻♀️
От коллег слышала, что бывают также системные аналитики: девопсы, сетевые инженеры, деливери менеджеры и т.д.
В общем, грань очень тонка и как будто становится все тоньше. И сейчас у меня, как и в 2019 году, нет полного понимания: где начинается и заканчивается зона компетенций СА?
И надо ли мне проходить курсы бекенд-разработчиков, SRE, Data и DevOps? И обязательно ли уметь жонглировать аналитикой и метриками?
Понятно, что в идеале хорошо бы все знать и все уметь. Но человеческий ресурс несколько ограничен. И хочется также ограничить область знаний, необходимых для той или иной работы.
Мне лично нравится стратегия постепенно изучать основы разных технологий и областей. Посмотреть про основы докера и кубернетиса, почитать про нефункциональные требования и надежность, изучить что-то про ИБ и способы шифрования, разобраться с основными принципами кеширования и т.д.
А дальше погружаться глубже уже в какую-то конкретную тему при необходимости или интересе.
Однако востребован ли сейчас на рынке такой подход?
Я не очень активный участник собеседований в последнее время, но есть ощущение, что на российском рынке СА — это проектировщик, который чем больше погружен в код и инфраструктуру, тем лучше.
При этом на международном рынке, кажется, обратная картина: чаще всего под СА понимают технического менеджера/владельца продукта, который будет вести процесс бизнес-анализа, разработки и документирования. А степень вовлеченности в проектирование и техническую реализацию чаще не так важна.
Находиться в таком неопределенном поле непросто, но с другой стороны — это открывает много возможностей для развития. И, быть может, нужно просто быть готовым к долгим поискам именно той компании, в которой СА делает именно то, что тебе интересно.
А какой у вас был опыт в роли СА? И какую стратегию на современном карьерном рынке вы выбираете?
Часто на менторингах и в неформальном общении встречаю вопрос: а чем именно должен заниматься системный аналитик на проекте?
Я обычно ссылаюсь на профстандарт. Но это общее описание, к тому же, далеко не все нанимающие менеджеры его читали.
В первой компании, где у меня была должность системный аналитик (2019г), я занималась: проектным менеджментом, UX-дизайном, бизнес и системным анализом, ручным тестированием, поиском багов в коде, поддержкой пользователей, внедрением системы в работу компании.
Мне было интересно проектировать требования, поэтому дальше я искала компании, где бОльшую часть рабочего времени надо будет этим и заниматься. Открыто говорила это на собеседованиях и спрашивала, какой процент времени у меня будет занимать именно проектирование.
В итоге следующие 5 лет я занималась в основном бизнес и системным анализом, с упором на системный. И тут надо было погружаться в технику: описывать спецификации API, интеграционные процессы, физ модели БД и архитектурные решения.
Мне это интересно, и я уходила все больше в детали реализации и все дальше от пользователей. И вроде бы все хорошо — рынок такое сейчас приветствует. Но иногда я ловила себя на мысли: а почему я прописываю индексы на этапе проектирования БД? Это же разработчик пишет запросы. Хотя в некоторых случаях запросы в виде псевдокода тоже пишу я.🤷🏻♀️
От коллег слышала, что бывают также системные аналитики: девопсы, сетевые инженеры, деливери менеджеры и т.д.
В общем, грань очень тонка и как будто становится все тоньше. И сейчас у меня, как и в 2019 году, нет полного понимания: где начинается и заканчивается зона компетенций СА?
И надо ли мне проходить курсы бекенд-разработчиков, SRE, Data и DevOps? И обязательно ли уметь жонглировать аналитикой и метриками?
Понятно, что в идеале хорошо бы все знать и все уметь. Но человеческий ресурс несколько ограничен. И хочется также ограничить область знаний, необходимых для той или иной работы.
Мне лично нравится стратегия постепенно изучать основы разных технологий и областей. Посмотреть про основы докера и кубернетиса, почитать про нефункциональные требования и надежность, изучить что-то про ИБ и способы шифрования, разобраться с основными принципами кеширования и т.д.
А дальше погружаться глубже уже в какую-то конкретную тему при необходимости или интересе.
Однако востребован ли сейчас на рынке такой подход?
Я не очень активный участник собеседований в последнее время, но есть ощущение, что на российском рынке СА — это проектировщик, который чем больше погружен в код и инфраструктуру, тем лучше.
При этом на международном рынке, кажется, обратная картина: чаще всего под СА понимают технического менеджера/владельца продукта, который будет вести процесс бизнес-анализа, разработки и документирования. А степень вовлеченности в проектирование и техническую реализацию чаще не так важна.
Находиться в таком неопределенном поле непросто, но с другой стороны — это открывает много возможностей для развития. И, быть может, нужно просто быть готовым к долгим поискам именно той компании, в которой СА делает именно то, что тебе интересно.
А какой у вас был опыт в роли СА? И какую стратегию на современном карьерном рынке вы выбираете?
classinform.ru
Профстандарт 06.022 | Системный аналитик | Профессиональные стандарты 2025
Профессиональный стандарт 06.022. Профстандарт Системный аналитик
❤19🔥9👍3
ИЗУЧЕНИЕ GOLANG — ПЕРВЫЕ ВПЕЧАТЛЕНИЯ
Вы спросите: куда я пропала? А я изучаю бэкенд-разработку на Golang. Прошла базовый курс, сделала один маленький пет-проект и начала делать еще один — побольше.
Занимаюсь этим, потому что интересно. В своем пути в IT я постепенно шла от бизнеса к технике. И вот дошла до той точки, когда уже хочется писать код.
К чему все это приведет — никто не знает. Но на данный момент у меня есть несколько мыслей об изучении программирования после 10 лет в анализе:
1️⃣ Опыт в анализе помогает осознать общие концепции и процессы при написании кода. Но иногда мешает в конкретных задачах. Потому что паттерн мышления меняется с “думай, потом делай” на “просто делай”.
Это не значит, что в программировании не надо думать. Но тут сложно думать над чистым листом. В анализе можно сделать пару заметок и набросков на бумажке и медитировать над ними полдня. С кодом у меня пока так не получается, я не могу держать в голове все структуры данных, объекты и их взаимосвязи, их слишком много. Поэтому я стала учиться просто садиться и начинать писать код, хоть какой-то, а потом уже обозревать все написанное и пытаться переписать нормально. Кстати, этот паттерн мне всегда помогал в написании текстов.
2️⃣ Ты практически приклеен к компьютеру.
Когда ты аналитик, сидеть нужно, только когда пишешь требования. Сбор, анализ и синтез можно делать из любых положений. С кодом мне сложно проводить какой-то анализ и синтез без напряженного вглядывания в экран. Может, это и пройдет с опытом, но пока мне пришлось купить ортопедическую подушку на стул😅.
3️⃣ LLM помогают и развращают.
В какой-то момент я поняла, что не могу сходу вспомнить некоторые способы объявления переменных и синтаксис базовых структур🙈. Потому что все обертки копирую либо из ллм, либо из своего же кода.
С другой стороны, когда я раньше бралась что-то кодить — то редко доводила проекты до конца. Потому что бесконечный поиск определений и попытки понять и адаптировать какой-то код со stackoverflow меня очень сильно демотивировали. Конечно, ко всем ответам LLM (и не только) стоит относиться с подозрением и по возможности перепроверять. Но это все равно гораздо легче, чем дойти до 10й страницы выдачи поисковика и окончательно запутаться.
4️⃣ Еще мне очень помогает Docker. Сталкивалась с ним раньше в работе, но только сейчас познала истинную мощь этого инструмента.
Какой же болью раньше было устанавливать и настраивать инфраструктуру. Даже чтобы сделать простой коннект к БД надо было перепробовать 5 библиотек, чтобы потом выяснить, что именно та, с которой твой коннект работает, ну никак не устанавливается в AWS. Кстати, очень рекомендую этот короткий курс по докеру для начинающих и его расширенную версию (оба на английском).
5️⃣ В программировании получаешь результат и фидбек очень быстро, но в очень небольших масштабах.
Как аналитик за пару часов ты можешь описать небольшой юзкейс с диаграммой последовательности и всеми флоу. Как начинающий разработчик за это же время ты настроишь коннект к базе и напишешь пару миграций для простого проекта. Зато через пару часов ты точно знаешь, что коннект и миграции работают.
🥁
Пока такие впечатления. Со временем, конечно, что-то поменяется и добавятся новые прозрения и осознания. Главное, не забыть весь системный анализ за это время😉.
А как у вас с программированием? Практикуете или пытаетесь забыть, как страшный сон?
Вы спросите: куда я пропала? А я изучаю бэкенд-разработку на Golang. Прошла базовый курс, сделала один маленький пет-проект и начала делать еще один — побольше.
Занимаюсь этим, потому что интересно. В своем пути в IT я постепенно шла от бизнеса к технике. И вот дошла до той точки, когда уже хочется писать код.
К чему все это приведет — никто не знает. Но на данный момент у меня есть несколько мыслей об изучении программирования после 10 лет в анализе:
Это не значит, что в программировании не надо думать. Но тут сложно думать над чистым листом. В анализе можно сделать пару заметок и набросков на бумажке и медитировать над ними полдня. С кодом у меня пока так не получается, я не могу держать в голове все структуры данных, объекты и их взаимосвязи, их слишком много. Поэтому я стала учиться просто садиться и начинать писать код, хоть какой-то, а потом уже обозревать все написанное и пытаться переписать нормально. Кстати, этот паттерн мне всегда помогал в написании текстов.
Когда ты аналитик, сидеть нужно, только когда пишешь требования. Сбор, анализ и синтез можно делать из любых положений. С кодом мне сложно проводить какой-то анализ и синтез без напряженного вглядывания в экран. Может, это и пройдет с опытом, но пока мне пришлось купить ортопедическую подушку на стул😅.
В какой-то момент я поняла, что не могу сходу вспомнить некоторые способы объявления переменных и синтаксис базовых структур🙈. Потому что все обертки копирую либо из ллм, либо из своего же кода.
С другой стороны, когда я раньше бралась что-то кодить — то редко доводила проекты до конца. Потому что бесконечный поиск определений и попытки понять и адаптировать какой-то код со stackoverflow меня очень сильно демотивировали. Конечно, ко всем ответам LLM (и не только) стоит относиться с подозрением и по возможности перепроверять. Но это все равно гораздо легче, чем дойти до 10й страницы выдачи поисковика и окончательно запутаться.
Какой же болью раньше было устанавливать и настраивать инфраструктуру. Даже чтобы сделать простой коннект к БД надо было перепробовать 5 библиотек, чтобы потом выяснить, что именно та, с которой твой коннект работает, ну никак не устанавливается в AWS. Кстати, очень рекомендую этот короткий курс по докеру для начинающих и его расширенную версию (оба на английском).
Как аналитик за пару часов ты можешь описать небольшой юзкейс с диаграммой последовательности и всеми флоу. Как начинающий разработчик за это же время ты настроишь коннект к базе и напишешь пару миграций для простого проекта. Зато через пару часов ты точно знаешь, что коннект и миграции работают.
🥁
Пока такие впечатления. Со временем, конечно, что-то поменяется и добавятся новые прозрения и осознания. Главное, не забыть весь системный анализ за это время😉.
А как у вас с программированием? Практикуете или пытаетесь забыть, как страшный сон?
Please open Telegram to view this post
VIEW IN TELEGRAM
Stepik: online education
Программирование на Golang
Курс посвящен основам языка программирования Golang. Курс будет полезен тем, кто уже имеет базовый опыт в программировании. На курсе будет рассмотрена теория, подкрепленная практикой.
🔥17❤8💯1