НАВИГАЦИЯ ПО КАНАЛУ
Оглавление всех постов:
О канале и авторе
🔧 HARD SKILLS
Интеграции и API
• Пректирование GraphQL API - цикл статей:
- Введение в GraphQL (07.2025)
- Схема GraphQL (07.2025)
- Архитектура и GraphQL (08.2025)
- Тестовый сервер с "живыми" примерами из статей (09.2025)
• Как познакомиться с GraphQL (10.2024)
• Чем опасен PATCH? (09.2024)
• 6 принципов проектирования API (08.2024)
• Инфографика: API technologies (07.2024)
• Проблема зависимых сообщений (07.2024)
• 12 способов сделать API безопаснее (12.2023)
• Event Driven Architecture - что почитать (07.2023)
• Доступ к данным в API (02.2023)
• Воркшоп по проектированию интеграций (11.2022)
• Идентификаторы в системах (08.2022)
• Что почитать про REST-like API (08.2022)
• Пагинация (04.2022)
• Основы интеграции систем - вебинар (03.2022)
• Обратная совместимость (01.2022)
Анализ и разработка
• Изучение Golang - первые впечатления (12.2025)
• Курсы по основам программирования (05.2025)
• Какого размера должны быть микросервисы? (04.2025)
• Дискуссия о книге Вигерса в 2024 году (08.2024)
• Важность реальных данных при разработке (12.2023)
• Памятка для погружения в новый проект (04.2022)
• Интервью о работе системного аналитика (11.2021)
• Бесплатные курсы по базам данных и SQL (10.2021)
• Статья про микросервисы на Хабре (10.2021)
• Документация в порядке - статья на Хабре (03.2021)
• Требования к ПО на пальцах - статья на Хабре (05.2020)
• А. Купер "Интерфейс" (09.2019)
🧠 SOFT SKILLS
Карьера и развитие
• Чем занимаются системные аналитики? (10.2025)
• Прожарка LinkedIn профиля (12.2024)
• Резюме для международного рынка (11.2024)
• Ресурсы для поиска работы (11.2021)
• Летний Аналитический Фестиваль (07.2021)
Написание текстов и коммуникация
• Позитивная коммуникация (11.2019)
• TED про когнитивные искажения (10.2019)
• 5 этапов написания текста (08.2019)
• Тексты, которые пишут люди - книги по писательству (08.2019)
Тайм-менеджмент и продуктивность
• Notion для личной базы знаний (08.2021)
• Книга про уверенность К. Форен (03.2021)
• Agile-методологии - космическая одиссея (10.2019)
• Энергия и откуда ее брать (09.2019)
• Секретный секрет тайм-менеджмента (09.2019)
Оглавление всех постов:
О канале и авторе
🔧 HARD SKILLS
Интеграции и API
• Пректирование GraphQL API - цикл статей:
- Введение в GraphQL (07.2025)
- Схема GraphQL (07.2025)
- Архитектура и GraphQL (08.2025)
- Тестовый сервер с "живыми" примерами из статей (09.2025)
• Как познакомиться с GraphQL (10.2024)
• Чем опасен PATCH? (09.2024)
• 6 принципов проектирования API (08.2024)
• Инфографика: API technologies (07.2024)
• Проблема зависимых сообщений (07.2024)
• 12 способов сделать API безопаснее (12.2023)
• Event Driven Architecture - что почитать (07.2023)
• Доступ к данным в API (02.2023)
• Воркшоп по проектированию интеграций (11.2022)
• Идентификаторы в системах (08.2022)
• Что почитать про REST-like API (08.2022)
• Пагинация (04.2022)
• Основы интеграции систем - вебинар (03.2022)
• Обратная совместимость (01.2022)
Анализ и разработка
• Изучение Golang - первые впечатления (12.2025)
• Курсы по основам программирования (05.2025)
• Какого размера должны быть микросервисы? (04.2025)
• Дискуссия о книге Вигерса в 2024 году (08.2024)
• Важность реальных данных при разработке (12.2023)
• Памятка для погружения в новый проект (04.2022)
• Интервью о работе системного аналитика (11.2021)
• Бесплатные курсы по базам данных и SQL (10.2021)
• Статья про микросервисы на Хабре (10.2021)
• Документация в порядке - статья на Хабре (03.2021)
• Требования к ПО на пальцах - статья на Хабре (05.2020)
• А. Купер "Интерфейс" (09.2019)
🧠 SOFT SKILLS
Карьера и развитие
• Чем занимаются системные аналитики? (10.2025)
• Прожарка LinkedIn профиля (12.2024)
• Резюме для международного рынка (11.2024)
• Ресурсы для поиска работы (11.2021)
• Летний Аналитический Фестиваль (07.2021)
Написание текстов и коммуникация
• Позитивная коммуникация (11.2019)
• TED про когнитивные искажения (10.2019)
• 5 этапов написания текста (08.2019)
• Тексты, которые пишут люди - книги по писательству (08.2019)
Тайм-менеджмент и продуктивность
• Notion для личной базы знаний (08.2021)
• Книга про уверенность К. Форен (03.2021)
• Agile-методологии - космическая одиссея (10.2019)
• Энергия и откуда ее брать (09.2019)
• Секретный секрет тайм-менеджмента (09.2019)
Telegram
Системный сервант
О КАНАЛЕ И АВТОРЕ
Привет!
Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.
Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю…
Привет!
Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.
Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю…
👍27🔥18❤9
Системный сервант pinned «НАВИГАЦИЯ ПО КАНАЛУ Оглавление всех постов: О канале и авторе 🔧 HARD SKILLS Интеграции и API • Пректирование GraphQL API - цикл статей: - Введение в GraphQL (07.2025) - Схема GraphQL (07.2025) - Архитектура и GraphQL (08.2025) …»
Статья «Введение в GraphQL»
Впервые я встретилась с GraphQL в 2021 году на проекте с мобильным приложением. К тому времени я уже несколько лет работала с REST-like APIs, что помогло, но не слишком. Чем больше я читала документацию и статьи по этой теме, тем меньше я понимала, а что вообще происходит. Ответ на любой базовый вопрос вроде “Что такое типы в GraphQL?” порождал несколько дополнительных вопросов, ответы на которые сложно было нагуглить и еще сложнее осознать.
После я спроектировала несколько GraphQL API с нуля и в течение 3 лет с ними работала. В итоге, кажется, что-то все-таки стала в этом понимать. Хотя на протяжение 3 лет мы всей командой обнаруживали что-то новое и неизведанное в мире GraphQL. Что-то, что если и было описано, то где-то в закромах у Apollo или в блогах компаний на Medium.
GraphQL — новый и сложный инструмент. При этом он сейчас на этапе развития и постоянно появляются новые паттерны и подходы для применения этой штуки в реальных системах.
Спецификация еще дорабатывается, а официальная документация не то чтобы дает исчерпывающие ответы на все вопросы. И это я не говорю про материалы на русском языке.
Поэтому у меня возникла идея написать статью, где бы я собрала и структурировала свои знания и опыт об этой технологии. В процессе написания меня немного занесло и материала получилось на целый цикл из 5 статей “Проектирование GraphQL API”. Не все они на данный момент дописаны.
Но сегодня вышла первая статья из цикла: “Введение в GraphQL”. 🥳 Очень этому рада, потому что от идеи до публикации прошел год. Надеюсь, для кого-то эти статьи окажутся полезными и помогут быстрее и лучше разобраться в хитросплетениях селективных запросов.
Очень благодарна Systems.Education за поддержку, публикацию и корректировки.
Первая статья вводная и очень общая, чтобы познакомиться с технологией и понять основную суть работы. А в ближайшее время выйдет вторая часть цикла — подробный лонгрид про схему GraphQL.
Впервые я встретилась с GraphQL в 2021 году на проекте с мобильным приложением. К тому времени я уже несколько лет работала с REST-like APIs, что помогло, но не слишком. Чем больше я читала документацию и статьи по этой теме, тем меньше я понимала, а что вообще происходит. Ответ на любой базовый вопрос вроде “Что такое типы в GraphQL?” порождал несколько дополнительных вопросов, ответы на которые сложно было нагуглить и еще сложнее осознать.
После я спроектировала несколько GraphQL API с нуля и в течение 3 лет с ними работала. В итоге, кажется, что-то все-таки стала в этом понимать. Хотя на протяжение 3 лет мы всей командой обнаруживали что-то новое и неизведанное в мире GraphQL. Что-то, что если и было описано, то где-то в закромах у Apollo или в блогах компаний на Medium.
GraphQL — новый и сложный инструмент. При этом он сейчас на этапе развития и постоянно появляются новые паттерны и подходы для применения этой штуки в реальных системах.
Спецификация еще дорабатывается, а официальная документация не то чтобы дает исчерпывающие ответы на все вопросы. И это я не говорю про материалы на русском языке.
Поэтому у меня возникла идея написать статью, где бы я собрала и структурировала свои знания и опыт об этой технологии. В процессе написания меня немного занесло и материала получилось на целый цикл из 5 статей “Проектирование GraphQL API”. Не все они на данный момент дописаны.
Но сегодня вышла первая статья из цикла: “Введение в GraphQL”. 🥳 Очень этому рада, потому что от идеи до публикации прошел год. Надеюсь, для кого-то эти статьи окажутся полезными и помогут быстрее и лучше разобраться в хитросплетениях селективных запросов.
Очень благодарна Systems.Education за поддержку, публикацию и корректировки.
Первая статья вводная и очень общая, чтобы познакомиться с технологией и понять основную суть работы. А в ближайшее время выйдет вторая часть цикла — подробный лонгрид про схему GraphQL.
systems.education
■ Статья. Введение в GraphQL
🔥39👍5❤2
Вот и статья про схему в GraphQL. Так как я в основном работала со схемой — получилось много практической информации. А так как схема — центральный элемент GraphQL — там есть о чем поговорить🙂.
systems.education
■ Статья. Схема GraphQL
Автор: Татьяна Сальникова
❤13👍8✍2🔥1
Коллеги из 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