Салют! Сегодня продолжим тему документации API, и я немного расскажу, что делаю я))

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

Расскажу, как я строю документацию, что включаю и какие правила соблюдаю.

📌 Из чего состоит моя документация API?

1️⃣ Обзор (Overview)

- Для чего этот API? (например, "Платежный шлюз для обработки транзакций").
- Ключевые возможности (например, "Создание платежа, проверка статуса, возврат средств").
- Форматы данных (JSON/XML, кодировка).
- Базовый URL (`https://api.example.com/v1`).

📌 Совет: Добавьте диаграмму взаимодействия, если API сложный (например, схему работы OAuth).

2️⃣ Аутентификация и авторизация

- Как получить токен/ключ?
- Где его передавать (`Header`, Query, `Body`)?
- Пример запроса:

   curl -X POST https://api.example.com/auth \
    -H "Content-Type: application/json" \
    -d '{"api_key": "your_key"}'  
    

- Срок жизни токена, refresh-токены (если есть).

📌 Совет: Добавьте ссылку на генератор тестовых ключей (если есть Sandbox).

3️⃣ Эндпоинты (Endpoints)

Каждый метод описываю по шаблону:
🔹 Метод `GET /users`
- Назначение: Получение списка пользователей.
- Параметры:
- limit (макс. количество записей, по умолчанию 20).
- offset (пагинация).
- Заголовки:
- Authorization: Bearer <token>.
- Пример запроса:

   curl -X GET "https://api.example.com/users?limit=10" \
    -H "Authorization: Bearer YOUR_TOKEN"  
    

- Пример ответа:

   {
    "data": [
      {"id": 1, "name": "Alice"},
      {"id": 2, "name": "Bob"}
    ],
    "total": 2
  }  
    

- Возможные ошибки:
- 401 Unauthorized — неверный токен.
- 400 Bad Request — некорректные параметры.

📌 Совет:
- Группируйте методы по логическим блокам (например, Users, Orders, `Payments`).
- Для неочевидных параметров добавьте пояснение (например, amount в **копейках**).

4️⃣ Примеры кода

Добавляю готовые сниппеты для разных языков:
- cURL (для быстрого тестирования).
- Python (`requests`).
- JavaScript (`fetch`/`axios`).
- PHP, Java (если аудитория использует).

📌 Совет: Используйте Swagger Codegen или Postman Snippets для автоматической генерации.

5️⃣ Обработка ошибок

Отдельный раздел с:
- HTTP-кодами (4xx, 5xx).
- Типовыми ошибками и способами их исправить.
- Примером ошибки:

   {
    "error": "invalid_request",
    "message": "API key is missing",
    "details": "Add 'Authorization: Bearer YOUR_KEY' header"
  }  
    

📌 Совет: Добавьте ссылку на сервис мониторинга (если есть, например, статус-страницу API).

6️⃣ Вебхуки (Webhooks)

Если API отправляет события:
- Какие события есть (например, payment.success, `order.canceled`).
- Как настроить URL для вебхуков.
- Пример payload:

   {
    "event": "payment.success",
    "data": {"id": "123", "amount": 1000}
  }  
    

- Рекомендации:
- Всегда проверяйте подпись (если есть).
- Idempotency-ключи для избежания дублей.

📌 Совет: Добавьте инструкцию по тестированию вебхуков (например, через ngrok или локальный тунель).

7️⃣ Лимиты и ограничения

- Rate limiting (например, 100 запросов/минуту).
- Максимальный размер запроса (например, 10 MB для `POST`).
- Ограничения на поля (например, description не больше 500 символов).

📌 Совет: Укажите, как проверить текущий лимит (например, через заголовки X-RateLimit-Limit и `X-RateLimit-Remaining`).

8️⃣ Чейнджлог (Change Log)

- Версии API и даты изменений.
- Breaking changes (например, удаление поля created_at в v2).
- План по депрекейшену старых версий.

📌 Совет: Используйте семантическое версионирование** (`v1.0.0` → `v1.1.0`).

P.s. Я на двух проектах сталкивалась с документированием API, и там и там использовала одно и тоже содержание, но где-то что-то отличалось, но суть была одна!

Источник: @ba_and_sa

Паттерны кеширования: проблемы, решения, практические рекомендации

⏳ 14 мин | 🟤🟤⚪️

Перейти | BA|SA

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

⏳ 7 мин | 🟤🟤⚪️

Перейти | BA|SA

Салют! Любой Аналитик (БА или СА) может столкнуться с Базами данных (БД), в любом случае это любимые вопросы на собесах. Поэтому предлагаю эту тему тоже не оставлять в стороне)

#БД #базыданных

1️⃣ Основные понятия

База данных (БД) – это структурированный набор данных, организованный для удобного хранения, управления и доступа.

Ключевые термины:
- Таблица (Table) – структура для хранения данных в виде строк (записей) и столбцов (полей).
- Запись (Row, Record) – строка в таблице, содержащая данные об одном объекте.
- Поле (Column, Field) – столбец в таблице, определяющий тип данных (например, имя, `возраст`).
- Первичный ключ (Primary Key, PK) – уникальный идентификатор записи (например, `id`).
- Внешний ключ (Foreign Key, FK) – поле, связывающее таблицы между собой.
- Индекс (Index) – структура для ускорения поиска данных (как оглавление в книге).
- Нормализация – процесс устранения дублирования данных для улучшения структуры БД.

2️⃣ Разница между БД и СУБД

БД (База данных) — это просто хранилище информации, как цифровая "коробка с данными".

СУБД (Система управления базами данных) — это "умная программа", которая:
- Организует хранение данных в БД,
- Быстро находит и изменяет информацию,
- Защищает данные от ошибок и несанкционированного доступа,
- Позволяет удобно работать с БД через запросы (например, SQL).

Проще:
- БД — это как файл Excel (там лежат данные).
- СУБД — это как сам Excel (он умеет сортировать, фильтровать и защищать эти данные).

Без СУБД БД — просто беспорядочная куча информации. СУБД делает её удобной и рабочей

Аналогия:
- БД – это библиотека с книгами (данными).
- СУБД – это библиотекарь, который ищет, добавляет и изменяет книги.

3️⃣ Реляционные vs Нереляционные БД

Реляционные БД (SQL)

- Структура: Таблицы с жесткой схемой (строгие типы данных).

- Примеры: MySQL, PostgreSQL, Oracle, SQL Server.

- Плюсы:
- Четкая структура и связи (FK).
- Поддержка транзакций (ACID).
- Удобны для сложных запросов (`JOIN`, агрегации).

- Минусы:
- Менее гибкие (схему сложно изменить).
- Могут быть медленными при больших объемах.

Нереляционные БД (NoSQL)

- Структура: Документы, ключ-значение, графы, колоночные хранилища.

- Примеры: MongoDB (документы), Redis (ключ-значение), Cassandra (колоночная).

- Плюсы:
- Гибкость (данные могут быть без строгой схемы).
- Высокая производительность и масштабируемость.

- Минусы:
- Нет стандартных JOIN (связи сложнее).
- Меньше гарантий целостности данных.

Когда что выбирать?
- SQL – если важны транзакции, сложные запросы, строгая структура (банки, ERP).

- NoSQL – если нужна масштабируемость и гибкость (соцсети, IoT, big data).

4️⃣ Что должен знать начинающий системный аналитик про БД?

1. Умение читать схемы БД (ER-диаграммы).
2. Базовый SQL (`SELECT`, JOIN, `GROUP BY`).
3. Понимание нормальных форм (1NF, 2NF, 3NF).
4. Различие типов БД и их применение.
5. Как данные связаны между собой (один-ко-многим, многие-ко-многим).
6. Основы индексов (зачем нужны и как влияют на производительность).

Вместо вывоводов:

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

🔥 Совет: Попробуйте создать простую БД (например, в SQLite или PostgreSQL) и потренируйтесь в SQL – это лучший способ разобраться!

В след раз углубимся в тему 😉

Ну и для новичков в сфере БД, небольшой гайд с чего начинать путь работы с данными:

1️⃣ Поймите основы теории

Что такое БД и зачем она нужна?

- Хранение, поиск и управление структурированными данными (клиенты, заказы, товары и т. д.).
- Основные термины: таблицы, записи, поля, ключи (PK, FK), индексы.
- Типы БД: реляционные (SQL) и нереляционные (NoSQL).

Ресурсы:

- 📖 Можно прочитать книгу: «SQL для чайников» (Аллен Тейлор) – просто о главном.
- 📺 Почитать статьи или посмотреть разные Видео: как вариант - «Базы данных за 1 час» (YouTube, если работает 🙈)

2️⃣ Установите СУБД и попробуйте на практике

Начните с SQL-баз (реляционных):
- SQLite (самая простая, не требует установки сервера).
- PostgreSQL или MySQL (популярные в enterprise-разработке).

Попробуйте NoSQL:
- MongoDB (документная БД).

Как попрактиковаться:
1. Создайте простую БД (например, «Библиотека» или «Магазин»).
2. Научитесь:
- Создавать таблицы (`CREATE TABLE`).
- Добавлять данные (`INSERT`).
- Делать выборки (`SELECT`, WHERE, `JOIN`).

3️⃣ Освойте базовый SQL
Минимум для старта:

- SELECT (выборка данных).
- INSERT, UPDATE, DELETE (изменение данных).
- JOIN (связи между таблицами).
- GROUP BY, ORDER BY (агрегация и сортировка).

Где тренироваться:
- 🎮 Интерактивные тренажеры:
- SQL Academy - Интерактивный курс по SQL (сам курс бесплатный, решение задач может быть платным) но курс полезный
- SQLZoo - английский, задачи от простых до сложных)
- SQLBolt - пошаговый интерактивный учебник (уроки + упражнения)
- SQL Fiddle  - эмулятор написания SQL-запросов (MySQL, PostgreSQL, SQLite, MS SQL Server);
- SQL Tutorial - справочник с множеством примеров и упражнений

- Или просто создайте БД и тренируйтесь))

4️⃣ Разберитесь, как БД связаны с системами

- Как приложение работает с БД? (CRUD: Create, Read, Update, Delete).

- Что такое схемы (ER-диаграммы)?
Учитесь читать и рисовать связи между таблицами.

- Зачем нужна нормализация? (1NF, 2NF, 3NF – чтобы избежать дублирования данных).

Инструменты для визуализации:
- Draw.io (бесплатно) – для рисования ER-диаграмм.
- DBeaver – удобный клиент для работы с разными БД.

5️⃣ Углубитесь в специфику для системного анализа

Как аналитик описывает требования к БД?
- Пишет структуру данных (атрибуты сущностей).
- Определяет, какие запросы будут частыми (чтобы добавить индексы).

Что такое транзакции и ACID? (Важно для банковских систем).

Когда выбрать SQL, а когда NoSQL?

Пример задачи аналитика:
«Пользователь ищет товары по категориям. Нужно предложить оптимальную структуру БД и запросы»

6️⃣ Дополнительные шаги (если есть время)

- Основы производительности: что такое индексы, как работают EXPLAIN и оптимизация запросов.

- API и БД: как системы общаются с БД (REST, GraphQL).

- Облачные БД: попробуйте Firebase (NoSQL) или Amazon RDS (SQL).

Итог: план на первый месяц
1. Неделя 1: Теория + установка PostgreSQL/SQLite.
2. Неделя 2: Простые SQL-запросы (SELECT, INSERT).
3. Неделя 3: Связи между таблицами (JOIN), нормализация.
4. Неделя 4: Практика на реальных кейсах (например, дашборд для магазина).

Главное: больше практики! Чем чаще пишете запросы, тем быстрее поймёте логику БД

Источник: @ba_and_sa

Салют! Сегодня разберем еще один из любимых вопросов от моих подписчиков: «Как пройти техническое собеседование на ИТ-аналитика (системный/бизнес-аналитик): поделитесь опытом или советами»

Я — системный аналитик с многолетним опытом (уже больше 10 лет я в этой сфере, начинала с Бизнес-аналитика), прошла десятки собеседований (и как кандидат, и как интервьюер). Расскажу, на что действительно обращают внимание и как пройти техническую часть без стресса.

1️⃣ Что проверяют на техническом собеседовании? Для чего вообще его проводят:

Вас будут оценивать по нескольким ключевым направлениям и тут уже не важно какой у вас стаж:

1.1. Понимание процессов разработки

- SDLC (Software Development Life Cycle) – какие этапы, кто за что отвечает. Если уже с опытом, попросят поделиться им и рассказать как было на ваших проектах.

- Методологии (Agile, Scrum, Kanban, Waterfall) – не просто названия, а как они применяются в реальных проектах. Спросят что и для чего выберете вы сами, с чем работали, с чем сталкивались.

- Роль аналитика в команде – взаимодействие с PM, разработчиками, тестировщиками. С чем были трудности, как решали конфликты.

❌ Ошибка новичка: Путать обязанности аналитика и проджект-менеджера.

1.2. Работа с требованиями

- Виды требований (BRS, SRS, User Stories, Use Cases).
- Как писать четкие, нефтогенерящие требования.
- Техники сбора требований (интервью, workshops, прототипирование).

✅ Совет: Будьте готовы разобрать кейс – например, как вы будете собирать требования для нового функционала в мобильном приложении.

1.3. Документирование и моделирование

- Диаграммы (BPMN, UML, ER, DFD) – хотя бы базовое понимание.
- Инструменты (Confluence, Jira, Figma, Miro, draw.io) – если не знаете, скажите, что быстро освоите.

❌ Ошибка новичка: Говорить, что вы "отлично знаете BPMN", но не суметь нарисовать простой процесс. А это точно проверят)))

1.4. SQL и данные (часто спрашивают!)

- Базовый SQL (SELECT, JOIN, GROUP BY, подзапросы).
- Нормализация БД, ключи, индексы – хотя бы основы.
- NoSQL vs SQL – когда что применяется.

✅ Совет: Если не уверены в SQL, потренируйтесь на leetcode.com или sql-ex.ru.

1.5. API и интеграции

- REST vs SOAP.
- Что такое Swagger/OpenAPI.
- Форматы данных (JSON, XML).

❌ Ошибка новичка: Путать PUT и POST в REST API.

2️⃣ Как готовиться к собеседованию?

📌 2.1. Разберите типовые вопросы

Примеры:
- "Как вы будете собирать требования, если заказчик сам не знает, что хочет?"
- "Как вы отслеживаете изменения в требованиях?"
- "Какие диаграммы вы используете и зачем?"

Пробегитесь по часто-задоваемым вопросам, которые я описывала: Часть 1 и Часть 2

📌 2.2. Практика на кейсах

Вас могут попросить:
- Описать процесс "Оформления заказа" в интернет-магазине.
- Написать User Story для функции "Поиск по фильтрам".
- Нарисовать схему взаимодействия систем.

📌 2.3. Повторите основы
- SQL (хотя бы SELECT + JOIN).
- Протоколы HTTP, методы API.
- Основы тестирования (что такое smoke-тесты, регресс?).

3️⃣ Как вести себя на собеседовании?

🎯 3.1. Говорите структурированно
Используйте метод STAR (Situation, Task, Action, Result) для ответов:
- "Был проект Х, задача Y, я сделал Z, результат – W".

🎯 3.2. Не бойтесь говорить "не знаю"
Лучше честно сказать *"Я с этим не сталкивался, но могу разобраться"*, чем врать.

🎯 3.3. Задавайте вопросы
- "Как в вашей компании строится процесс работы с требованиями?"
- "Какие инструменты вы используете?"
- "Какие сложности бывают в проектах?"

4️⃣ Что делать после собеседования?

- Запишите вопросы, которые вызвали трудности – разберите их.
- Спросите фидбек, даже если не взяли – это ценный опыт.
- Анализируйте каждое интервью – со временем будет получаться лучше.

Вместо вывода:

Главное – практика и уверенность. Даже если не знаете ответ, покажите ход мыслей. IT-аналитика – это не про зазубренные ответы, а про умение разбираться в процессах и доносить идеи.

Источник: @ba_and_sa

Удачи на собеседовании! 🚀 Если есть вопросы – пишите в комментарии👇

Требования vs Реальность: Почему в ТЗ находят «дыры» и как это исправить

⏳ 11 мин | 🟤🟤⚪️

Перейти | BA|SA

Новые процессы без боли: как сделать так, чтобы команда не сопротивлялась

⏳ 4 мин | 🟤⚪️⚪️

Перейти | BA|SA

Салют! Исходя из вчерашнего опроса, сегодня у нас будет разбор эволюции бизнес- и системного анализа: как изменилась профессия за 12 лет моей работы

1️⃣ Раньше (2013–2016):
BA - фокус на бизнес-процессах, требованиях стейкхолдеров и документация (BPMN, Use case)

Моя первая работа:
- Основная задача: Описание AS-IS процессов, написание регламентов, инструкций, иногда — сбор требований для доработок в Excel

- Инструменты: Visio, BPMN (на базовом уровне), Excel, PowerPoint. SQL знали единицы

- Требования к кандидатам:
- Умение общаться с бизнесом и структурировать информацию.
- Базовое понимание процессов компании (например, производственных циклов в нефтянке).
- Опыт в предметной области ценился выше технических навыков .

Мой опыт: В производственной компании 80% времени уходило на визуализацию процессов в нотациях типа EPC. В нефтянке добавились дашборды в Tableau, но ИТ-составляющая была минимальна — мы лишь «переводили» запросы бизнеса на язык техников.

2️⃣ Переходный период (2017–2019): Слияние BA и SA, первые интеграции

Что изменилось:
- Роль BA стала более технической: В нефтяной компании я уже проектировала БД, писала ТЗ для разработчиков, тестировала API

- Появились Agile и Scrum: Раньше работали по Waterfall, теперь — короткие итерации и user stories

- Новые требования:
- SQL (простые запросы — JOIN, GROUP BY).
- UML для диаграмм классов и последовательности.
- Понимание интеграций (REST/SOAP).

Кейс: Внедрение системы на заводе потребовало работы с ERP, интеграцией с SAP — пришлось учить основы XML и EDI.

3️⃣ Сейчас (2020–2025): Системный анализ как «гибридная» профессия

Тренды:
- Стирание границ BA/SA: В ИТ-компаниях один аналитик часто совмещает обе роли:
- BA-часть: Общение с заказчиком, гипотезы, CJM.
- SA-часть: Проектирование API, работа с Kafka, микросервисами, нагрузочным тестированием

- Hard Skills обязательны:
- SQL (оконные функции, оптимизация запросов).
- Python (скрипты для анализа данных, pytest для тестирования).
- Системы (Kubernetes, Docker — хотя бы на уровне понимания).
- Документирование (Swagger, OpenAPI, архитектурные Decision Records)

- Soft Skills: Умение вести переговоры с DevOps и CTO, а не только с продукт-менеджерами.

Пример из практики: В финтехе мой типичный день — это:
1. Утром: Создание спецификации gRPC-сервиса для платежей.
2. Днем: Сессия с бизнесом по поводу фрод-правил (тут нужен BA-скилл).
3. Вечером: Ревью логики в ClickHouse для аналитического дашборда.

4️⃣ Исчезнут ли BA и SA как отдельные роли?

Прогноз:
- В корпорациях (банки, нефть) разделение останется: BA — для регуляторики и процессов, SA — для технической реализации

- В IT-продуктах (стартапы, SaaS) будет доминировать Product Analyst — гибрид BA+SA+Data Analyst

Важно: Уже сейчас в 60% вакансий пишут «Бизнес/Системный аналитик» и ждут знания:
- BPMN и Event Storming.
- User Stories и диаграммы последовательности в PlantUML.
- Figma для прототипов и Postman для тестирования API .
И многое другое.

📌‼️Советы тем, кто начинает сейчас

1. Не выбирайте «чистый» BA — без технических навыков будет сложно после 3–5 лет опыта

2. Учите не только SQL, но и основы DevOps (CI/CD, логирование). Это то, чего не хватало мне в 2017

3. Осваивайте генерацию документации через ChatGPT (но валидируйте выводы!). В 2025 году ручное написание SRS — анахронизм

4. Следите за трендами:
- Low-code (Mendix, Retool) — бизнес теперь сам правит логику, аналитик проектирует только стыки.
- AI-augmented analysis — GPT для первичного анализа требований, но финальное решение всегда за человеком .

Итог: За 12 лет я прошла путь от «описателя процессов» до проектировщика архитектуры. Главное изменение — аналитик теперь не переводчик, а инженер решений. И да, границы между BA и SA размыты, но это делает профессию только интереснее.

Источник: @ba_and_sa

Вопрос к вам: Как вы видите будущее анализа — будет ли разделение ролей или полное слияние?

Если говорить про требования к кандидатам, тогда (2012-2013) и сегодня (2024-2025), то отличия тоже есть:

✅ 2012-2013 г.

- Раньше было проще попасть даже с минимальными знаниями бизнес-анализа (я прошла 3 собеседования и мне прислали оффер). За плечами было только образование прикладной информатики, знаний было мало, опыта практически не было, только прохождение практики на одном проекте, ну и диплом с описанием процессов.

- Технические требования: моделирование БП в любой из нотаций, знание Excel, умение общаться с заказчиками, написание документации.

✅ 2024-2025 г.:

- Тут уже сложнее, кандидатов все больше, требования все серьезней.
Компании ищут, в основном, хоть с каким-то опытом за плечами (минимум один проект). Чтобы было не только образование (и то с уклоном на ИТ), но и курсы, вебинары, и тд.

- Технические требования: моделирование БП, основы интеграции, api, понимание архитектуры, знание БД (написание простых запросов), и многое другое . Напомню, что я делала анализ рынка по требованиям к кандидатам в 2024г., там как раз есть описание требований по опыту работы кандидатов.

⁉️ Что ждет аналитиков в будущем?

1. Полное исчезновение «чистых» BA в IT-продуктах (но сохранение в госсекторе в банках, крупных компаниях (нефтяных например)

2. Рост спроса на аналитиков-«переводчиков» между бизнесом и Data Science-командами

3. Упрощение entry-level: Junior-аналитикам будут доверять меньше задач, но требовать базового понимания DevOps (CI/CD, логирование) Ну и технические навыки будут серьезней.

Вывод

Аналитика движется к гибридным ролям с акцентом на:

✅ Техническую грамотность (код + инфраструктура).

✅ Гибкость (быстрое переключение между бизнесом и tech).

✅ Работу с ИИ (использование, но не зависимость от него).

Совет: Прокачивайте системное мышление и навыки презентации — это то, что не автоматизируется в ближайшие 10 лет.

Источник: @ba_and_sa

Салют! Сегодня у нас новая тема для обсуждения «Как ИИ изменит профессию системного аналитика: угроза или новые возможности?»

За последние несколько лет искусственный интеллект (ИИ) проник во многие сферы IT, автоматизируя рутинные задачи и даже создавая код. Но что ждет бизнес-/системных аналитиков? Полностью ли ИИ заменит нас или станет мощным инструментом в наших руках? Давайте разбираться.

1️⃣ Как ИИ уже влияет на бизнес-/системный анализ?

Автоматизация документирования
- ИИ (например, ChatGPT, Notion AI) помогает быстро генерировать пользовательские истории, Use Cases, BPMN-описания.
- Анализ требований стал быстрее: нейросети умеют структурировать информацию из интервью и писем.

Если смотреть на мои кейсы, то вот пример, как я использую ИИ уже сейчас:

Автоматизация документирования требований:

Задача: Преобразовать разрозненные бизнес-постановки в структурированные требования.

Как помогает ИИ:
- ввожу в ChatGPT или аналогичный инструмент описание задачи: описать требования (BR, UR, FR, NFR) к задачи «Разработать сервис для отправки писем с ЭЦП через API для внутренних сервисов компании».
- ИИ генерирует готовый список требований, включая бизнес- (BR), пользовательские (UR), функциональные (FR) и нефункциональные (NFR) требования, с нумерацией и детализацией .

Пример вывода ИИ:
“> BR-001: Повысить безопасность отправки писем за счет ЭЦП.
> FR-002: Подпись файлов должна выполняться с использованием закрытого ключа” и тд.

Результат: Экономия 50–70% времени на первичную формализацию требований.

Умный анализ данных
- ML-модели выявляют аномалии в логах, предсказывают нагрузки на систему, помогают в принятии решений.

Генерация прототипов и UML
- Инструменты вроде Miro AI, Lucidchart предлагают автоматическую визуализацию процессов.

Вывод: Пока ИИ берет на себя рутину, но не заменяет аналитика полностью. Но! Это мощный помощник в нашей рутинной работе)))

2️⃣ Что будет через 5–10 лет?

🤯 Пессимистичный сценарий:

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

😀 Оптимистичный сценарий:

- Аналитики перейдут на более высокий уровень: стратегическое проектирование, глубокая аналитика, управление ИИ-инструментами.
- ИИ станет "цифровым ассистентом", как калькулятор для математика — без него работать можно, но с ним эффективнее.

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

3️⃣ Что делать уже сейчас?

✅ Осваивать ИИ-инструменты (ChatGPT, Claude, Copilot для анализа кода).
✅ Развивать soft skills — переговоры, управление ожиданиями стейкхолдеров.
✅ Углубляться в бизнес-аналитику — ИИ пока плохо понимает контекст бизнеса.
✅ Изучать Data Science basics — чтобы говорить на одном языке с ML-инженерами.
✅ Системный анализ - углубиться больше в системную часть нашей профессии, бизнес пока боится полностью отдавать ИТ-часть на ИИ (архитектура, интеграции, код, общение с командой разработки и тд)

4️⃣ Статьи по теме, или другие мнения на этот счет:

1. Как ИИ меняет работу IT-аналитиков: возможности и угрозы

2. Как изменится системный анализ и работа аналитика, когда ИИ «победит»

3. Как искусственный интеллект меняет будущее бизнес-аналитики и аналитики 

Вместо вывода:
ИИ не заменит системных аналитиков, но изменит их роль. Те, кто научится использовать ИИ как инструмент, получат преимущество. Будущее за гибридом "аналитик + ИИ".

А как вы используете ИИ в работе? И как вы считаете, как повлияет ИИ на нашу сферу?
Делитесь в комментариях! 🚀

Docs as Code — это подход к созданию документации, при котором:

- Документация пишется как код (в текстовых форматах: Markdown, reStructuredText, AsciiDoc).
- Хранится в системе контроля версий (Git).
- Сборка и публикация автоматизируются через CI/CD (например, GitHub Actions, GitLab CI).
- Изменения проходят ревью, как код.

📎И небольшая подборка статей на эту тему:

- Docs as Code: введение в предмет
- Инструменты подхода Docs-as-code
- Как перейти на Docs-as-a-Code и какие инструменты для этого использовать
- Docs As Code: Документация как Код

@ba_and_sa

Салют! Сегодня делюсь с вами своими советами по составлению резюме для новичка😊

1️⃣ Структура резюме

Резюме должно быть четким, читаемым и релевантным.

Оптимальная структура:
- Контактные данные (имя, телефон, email, LinkedIn/GitHub если есть)
- Цель / Краткое описание (2-3 предложения о твоих навыках и ожиданиях от работы):

- Навыки (Hard & Soft Skills)
- Опыт работы (если есть) / Стажировки / Проекты
- Образование
- Дополнительная информация (сертификаты, курсы, языки, хобби, если это релевантно)

2️⃣ На что обратить внимание?

✅ Что выделить:

1. Технические навыки (даже если опыта мало):
- Работа с требованиями (User Stories, Use Cases)
- Основы SQL (простые запросы)
- UML / BPMN (даже базовые диаграммы)
- Знание методологий (Agile, Waterfall)
- Инструменты (Jira, Confluence, Trello, Figma, Postman)

2. Soft Skills (очень важны для аналитика):
- Коммуникация, работа с stakeholders
- Аналитическое мышление
- Умение структурировать информацию

3. Проекты / Кейсы (если нет коммерческого опыта):
- Учебные проекты (например, разбор бизнес-процессов магазина)
- Курсовые работы (если связаны с анализом)
- Фриланс / Волонтерство (если помогал с документацией)

4. Образование и курсы:
- Диплом по смежной специальности (IT, экономика, менеджмент)? Укажи.
- Курсы по аналитике (Coursera, Stepik, Skillbox)? Обязательно впиши.

❌ Чего избегать:

- Общих фраз в стиле "быстро учусь, стрессоустойчивый" (лучше показать на примере).
- Списка всех подряд технологий (если не уверен — не пиши).
- Длинных описаний нерелевантного опыта (например, если работал официантом — можно кратко, без деталей).

3️⃣ Как повысить шансы на собеседование?

- Подстрой резюме под вакансию (используй ключевые слова из описания).
- Добавь цифры (если есть проекты — укажи результаты: "автоматизировал процесс, что сократило время обработки данных на 20%").
- Сделай одностраничное резюме (новичку хватит).
- Проверь на ошибки (HR отсеивают резюме с опечатками).

‼️ Вместо вывода:

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

Источник: @ba_and_sa

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

1️⃣ Пример раздела "Навыки"

🔹 Hard Skills:

- Сбор и анализ требований (User Stories, Use Cases, SRS)
- Моделирование процессов (UML: Use Case, Activity, BPMN)
- Основы SQL (SELECT, JOIN, подзапросы)
- Работа с API (понимание основ Postman, Swagger)
- Инструменты: Jira, Confluence, Figma, Miro - начальный уровень

🔹 Soft Skills:

- Коммуникация с заказчиками и разработчиками
- Документирование процессов (тех. задания, инструкции)
- Решение конфликтов требований (приоритизация)

Если знаешь хотя бы 30% из этого — уже хорошо!

2️⃣ Пример раздела "Опыт" (для новичка)

🔹 Учебный проект: «Разработка мобильного приложения для заказа еды»

Даже если это был курс или хакатон — подавай как проект!

- Провела интервью с "заказчиком" (преподавателем), выявила 12 ключевых требований.
- Создала Use Case-диаграмму и User Flow для процесса заказа.
- Проанализировала сценарии оплаты, предложила упрощение (уменьшила шаги с 5 до 3).
- Результат: защитила проект на 9/10 баллов, получила рекомендацию для стажировки.

🔹 Фриланс (микрозаказ): Оптимизация процесса для малого бизнеса

- Проанализировала текущий процесс учета товаров в Excel.
- Разработала инструкцию по автоматизации отчетов (Google Sheets + формулы).
- Клиент сократил время на формирование отчетов на 40%.

Суть: покажи, что ты реально делала, даже если это маленький проект.

3️⃣ Пример раздела "Образование и курсы"

🔹 Высшее образование -
Московский Технический Университет

Факультет: Информационные системы (2020–2024)
- Дипломная работа: "Анализ требований к CRM-системе для малого бизнеса" (оценка: 5).

🔹 Курсы

- "Системный анализ и проектирование" (Otus/Stepik, 2023)
- Изучила: сбор требований, UML, базовый SQL.
- Выполнила 5 практических кейсов.
- "Основы Agile и Scrum" (Coursera, 2022)
- Участие в симуляции спринта (роль: Product Owner).

4️⃣ Пример "Цели" в резюме

➖Плохо:
"Хочу работать системным аналитиком, чтобы развиваться в IT."

➕Хорошо:
"Начинающий системный аналитик с практическим опытом в сборе требований и моделировании процессов. Ищу команду, где смогу применять знания в аналитике и участвовать в реализации IT-решений. Готов обучаться и вносить вклад в проекты."

5️⃣ Что я убрала бы из резюме (из личного опыта)

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

✅ Ключевой совет

HR смотрят на конкретику и потенциал. Даже если твой опыт — это 2 учебных проекта, но они хорошо оформлены, шансы есть‼️

Удачи вам на собеседованиях!!! С вами всегда на связи @ba_and_sa