Business | System analyst
Авторский канал для бизнес/системных аналитиков от аналитика со стажем, как для начинающих, так и для бывалых Сотрудничество: @the_real_bird Регистрация РКН: https://knd.gov.ru/license?id=673c68d031a9292acd1c5784®istryType=bloggersPermission #J6THB
Mostrar más📈 Análisis del canal de Telegram Business | System analyst
El canal Business | System analyst (@ba_and_sa) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 18 011 suscriptores, ocupando la posición 572 en la categoría Marketing y relaciones públicas y el puesto 37 107 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 18 011 suscriptores.
Según los últimos datos del 17 julio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -20, y en las últimas 24 horas de -1, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 15.30%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 6.29% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 757 visualizaciones. En el primer día suele acumular 1 134 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 21.
- Intereses temáticos: El contenido se centra en temas clave como ba|sa, архитектура, api, аналитика, bpmn.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Авторский канал для бизнес/системных аналитиков от аналитика со стажем, как для начинающих, так и для бывалых
Сотрудничество: @the_real_bird
Регистрация РКН: https://knd.gov.ru/license?id=673c68d031a9292acd1c5784®istryType=bloggersPermission
#J6...”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 18 julio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Marketing y relaciones públicas.
Carga de datos en curso...
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 18 julio | 0 | |||
| 17 julio | +3 | |||
| 16 julio | +3 | |||
| 15 julio | +4 | |||
| 14 julio | +1 | |||
| 13 julio | +2 | |||
| 12 julio | 0 | |||
| 11 julio | +1 | |||
| 10 julio | +3 | |||
| 09 julio | 0 | |||
| 08 julio | +3 | |||
| 07 julio | +160 | |||
| 06 julio | +70 | |||
| 05 julio | +1 | |||
| 04 julio | +3 | |||
| 03 julio | +8 | |||
| 02 julio | 0 | |||
| 01 julio | +3 |
| 2 | Как использовать Kafka на собеседовании по System Design
⏳ 17 мин | 🟡⚪️⚪️
Читать статью | @analysis_it
💙 Analyst IT | 💬 Analyst IT | 930 |
| 3 | Компании ценят специалистов, которые разбираются как в технической стороне продукта, так и в потребностях бизнеса. Перекрёстные навыки часто встречаются в вакансиях.
Нетология объединила две профессии в один курс — «Системный и бизнес-аналитик». На занятиях своим опытом поделятся эксперты из Qiwi, М.Видео — Эльдорадо и Bolt.
За 12 месяцев вы научитесь:
- использовать гибкие методологии Agile и Scrum;
- разбираться в нотациях моделирования: UML, BPMN, IDEF;
- описывать user story и use case;
- создавать прототипы приложений и сервисов;
- работать с АРІ и проектной документацией.
Сейчас на курс действует скидка 50%, а с промокодом IT10JULY цена станет ещё на 10% ниже. Плюсом подарим курс о развитии карьеры при покупке до 31 июля.
Записаться
Реклама. ООО “Нетология” ОГРН 1207700135884 Erid: 2VSb5xpZMyt | 1 433 |
| 4 | Думаете, что знаете все про LLM? Тогда мы идем к вам
⏳ 27 мин | 🟤⚪️⚪️
Перейти | @ba_and_sa
💙 BA|SA | 💬 BA|SA | 1 408 |
| 5 | Как я готовился к сертификации по LLMархитектуре и понял, что три года путал промпты с архитектурой
⏳ 5 мин | 🟤⚪️⚪️
Перейти | @ba_and_sa
💙 BA|SA | 💬 BA|SA | 1 660 |
| 6 | Сказ про Лукаса-героя да про Postgres и Timescale: SA и его необычная задача
⏳ 4 мин | 🟤⚪️⚪️
Перейти | @ba_and_sa
💙 BA|SA | 💬 BA|SA | 1 896 |
| 7 | Как работать с требованиями которые меняются — без нервов и переработок
Салют! Помню проект, где требования менялись так часто, что я перестала распечатывать документацию — смысла не было. Разработчики смотрели на меня с немым вопросом, я смотрела на бизнес с тем же вопросом.
❗️Тогда поняла: проблема не в том что требования меняются. Они всегда будут меняться. Проблема в том как ты выстраиваешь работу с ними.
Сразу честно: ни один инструмент не спасёт если в компании хаос на уровне управления. Но даже в таких условиях правильный подход помогает выжить с меньшими потерями для себя и команды. И это тоже результат.
Почему требования меняются — без прикрас
— Бизнес не знал чего хочет до конца. Это нормально — люди часто понимают что им нужно только увидев первый результат
— Изменился контекст: рынок, конкурент, законодательство, новый руководитель с другим видением
— Требования были размыты с самого начала — вот это уже наша зона ответственности
Злиться на второй пункт бессмысленно. Над третьим работать — полностью в наших силах.
Что реально помогает (или помогало в моем случае):
1️⃣Фиксируйте договорённости сразу
Любое решение с встречи — в письмо в тот же день. Люди искренне забывают что говорили три недели назад, это не злой умысел.
Иногда такая фиксация воспринимается в штыки: “ты мне не доверяешь?” Я на это отвечала спокойно: “Доверяю, просто у меня плохая память” — обычно разряжало обстановку.
Договорились: ...
Следующий шаг: ...
Жду подтверждения до [дата].
2️⃣Спрашивайте “зачем”, а не “как”
Это работает всегда и везде — просто здравый смысл.
Приходит менеджер: “Хочу менять цвет строк в таблице”. Спрашиваю зачем. Оказывается — хочет видеть просроченные заказы.
Реальное требование: автоматически подсвечивать просрочку. Другая задача, проще и полезнее.
Половина изменений при правильном вопросе превращается в уточнение исходного требования, а не в новую задачу.
3️⃣ Показывайте стоимость изменения
Когда бизнес приходит с правкой, говорю прямо: “Эта правка затрагивает три модуля, сдвигает сроки на неделю. Готовы?”
Важна подача. Не “это дорого и мы не будем делать”, а “давайте я покажу что затронет эта правка — и вы примете решение”. Некоторые заказчики всё равно воспримут это как отказ помочь — но большинство после такого разговора спокойно отправляют правку в следующий релиз.
4️⃣ Приоритизируйте, не складывайте в кучу
Приоритет / Критерий
Срочно и важно / Блокирует работу прямо сейчас
Важно, не срочно / В следующий спринт
Хотелка / В бэклог
Честно: в компаниях где всё “срочно и важно” по умолчанию — эта таблица работает плохо. Но даже там она помогает хотя бы начать разговор о приоритетах.
5️⃣ Договоритесь о правилах на берегу
В начале проекта проговариваю с заказчиком: как обрабатываем изменения, когда правка идёт в текущий релиз, а когда в следующий, кто финальный ЛПР.
Сложность в наших реалиях: ЛПР часто недоступен, меняется или принимает решения в коридоре после планёрки. В таком случае фиксирую хотя бы того кто есть — пусть не идеально, но лучше чем ничего.
❗️И про внутреннее состояние — это важно
Я долго воспринимала каждое изменение как личную неудачу. Значит плохо собрала, не так спросила, недоработала.
Потом поняла: идеальных требований не бывает. Иногда проблема вообще не в аналитике — а в том что решения принимаются спонтанно на самом верху, и никакой инструмент это не исправит.
Наша ценность не в том чтобы зафиксировать всё раз и навсегда. А в том чтобы управлять изменениями так, чтобы команда не сходила с ума и бизнес получал то что реально нужно.
🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией))
___________
Источник: @ba_and_sa
💙 BA|SA | 💬 BA|SA | 2 934 |
| 8 | Системный аналитик 2026: вы всё ещё пишете документацию, но теперь её читает только LLM
⏳ 5 мин | 🟤🟤⚪️
Перейти | @ba_and_sa
💙 BA|SA | 💬 BA|SA | 2 359 |
| 9 | 🎉 Результаты розыгрыша:
🏆 Победители:
1. Роман (@zkhromann)
2. AlexUnit (@AlexxUnit)
3. Tryshch (@Tryshch)
✔️Проверить результаты | 2 358 |
| 10 | Салют! Напоминаю о нашем розыгрыше
Присоединяйтесь и получите шанс выиграть от нас подарочки)) | 2 219 |
| 11 | Event Storming: как за один сеанс вытащить из бизнеса всё что нужно
Салют! Расскажу про технику, которая перевернула мой подход к сбору требований. Я до неё несколько лет ходила на интервью с бизнесом по старинке — вопрос-ответ, протокол, снова вопрос. Долго, сухо, и всё равно что-то важное всплывало уже в процессе разработки.
Потом познакомилась с Event Storming. И поняла что теряла время.
❓ Что это вообще такое
Event Storming — это фасилитационная техника, которую придумал Альберто Брандолини в 2013 году. Суть простая: вы собираете в одной комнате всех причастных — бизнес, разработку, аналитику — и вместе моделируете процесс через события.
Не через функции системы. Не через экраны. Через события — то, что происходит в бизнесе.
Главный материал — стикеры. Цвет каждого имеет значение.
Язык стикеров — запомните один раз
🟠 Оранжевый — доменное событие Что-то произошло в системе. Формулируется в прошедшем времени: “Заказ создан”, “Оплата подтверждена”, “Товар отгружен”
🔵 Синий — команда Действие, которое инициирует событие: “Создать заказ”, “Подтвердить оплату”
🟡 Жёлтый — актор Кто выполняет команду: пользователь, менеджер, система
🟣 Фиолетовый — политика Правило или реакция: “Когда заказ создан — отправить уведомление”
🔴 Красный — проблема или вопрос То, что непонятно прямо сейчас. Не пытаемся решить на месте — фиксируем и идём дальше.
Как проходит сессия — по шагам:
Шаг 1. Хаотичный штурм — 20-30 минут
Все участники одновременно пишут оранжевые стикеры — доменные события. Без порядка, без очерёдности. Просто всё что происходит в процессе.
Здесь важно не останавливать поток. Дубли — нормально, противоречия — отлично, значит нашли точку для обсуждения.
Шаг 2. Выстраиваем хронологию
Берём все события и раскладываем на стене слева направо — по времени. Именно здесь начинается самое интересное: бизнес видит свой процесс целиком, часто впервые. И сам находит дыры.
Шаг 3. Добавляем команды и акторов
К каждому событию добавляем — кто и что сделал чтобы оно произошло. Здесь выясняется кто реально принимает решения, а не кто написан в регламенте.
Шаг 4. Фиксируем политики и проблемы
Правила бизнеса, автоматические реакции, спорные моменты — всё на стикеры. Красных стикеров не бойтесь, чем их больше — тем честнее сессия.
Живой пример: интернет-магазин
Вот фрагмент того, что получается на стене:
[Пользователь] → Оформить заказ
→ 🟠 Заказ создан
→ 🟣 Когда заказ создан — проверить наличие товара
→ 🟠 Наличие подтверждено
→ [Система] → Создать платёж
→ 🟠 Платёж инициирован
→ 🟠 Оплата подтверждена
→ 🟣 Когда оплата подтверждена — передать в склад
→ 🟠 Заказ передан на сборку
И вот тут кто-нибудь из бизнеса обязательно скажет: “Стоп, а если товара нет — что происходит?” И выясняется, что этот сценарий никто не описал. Вешаем красный стикер.
За один такой вечер находим больше пробелов, чем за месяц переписки в почте.
Почему это работает лучше классических интервью
На интервью бизнес отвечает на ваши вопросы — то есть вы ограничены тем, что догадались спросить. На Event Storming бизнес сам моделирует свой процесс и сам видит где он не доработан.
Аналитик здесь не интервьюер, а фасилитатор. Вы не задаёте вопросы — вы создаёте условия чтобы знания вышли наружу сами.
Когда это особенно полезно
— Старт нового проекта когда процессы ещё не описаны — Сложные интеграции между несколькими командами — Когда разные отделы по-разному понимают один и тот же процесс — Рефакторинг legacy-системы где документации нет вообще
Что важно для хорошей сессии
Несколько вещей которые я поняла уже на практике, не из книжек:
— Зовите всех кто принимает решения, не только исполнителей. Без ЛПР сессия даёт половину результата — Физическая стена и стикеры работают лучше любого онлайн-инструмента. Miro — только если нет выбора — Сессия не должна длиться больше 4 часов. После люди перестают думать — Фасилитатор не эксперт в предметной области — и это хорошо. Глупые вопросы вскрывают самые интересные противоречия
Источник: @ba_and_sa
💙 BA|SA | 💬 BA|SA | 2 166 |
| 12 | Хочешь сделать хорошо — сделай сам: как у нас появилась собственная система работы со стендами
⏳ 12 мин | 🟤⚪️⚪️
Перейти | @ba_and_sa
💙 BA|SA | 💬 BA|SA | 2 543 |
| 13 | Как читать чужую документацию на API, чтобы не наступить на грабли
Салют! Решила еще написать пару постов на тему API и рассказать случай из практики:
Получаю как-то документацию на внешнее API — для интеграции с платёжным сервисом. Открываю Swagger, всё красиво, эндпоинты на месте. Согласовываю интеграцию, передаю в разработку.
Через две недели разработчик приходит с вопросом: “А что возвращает API если платёж завис в статусе pending дольше часа?” И тут выясняется — в документации этого нет вообще. Ни слова.
Хорошая документация — редкость. Поэтому аналитик должен уметь читать её критически, а не просто принимать как есть.
Вот на что я теперь смотрю в первую очередь:
1. Есть ли вообще схема ошибок
Если описаны только успешные ответы — это красный флаг. Спрашиваю прямо: “пришлите список всех кодов ошибок и их тела ответов”. Если в ответ тишина или “ну, обычно 400 и 500” — закладываю время на уточнения в процессе разработки. Они будут точно.
2. Что значит “опциональное” поле на самом деле
Поле помечено как optional. Окей, а что если его не передать?
— Подставится дефолт? — Просто проигнорируется? — Или вернётся ошибка, потому что поле опциональное только формально, а по факту обязательное при определённых условиях?
Третий вариант встречается чаще, чем хотелось бы. Проверяю на реальном запросе, документации на слово не верю.
3. Идемпотентность — спрашиваю прямо
Если интеграция создаёт сущности — платёж, заказ, бронирование — обязательно уточняю: что при повторном запросе с теми же данными? Дубль? Та же сущность вернётся? Для платежей это критично — повторный запрос из-за обрыва сети не должен списать деньги дважды.
Если в документации об этом ни слова, это не значит что идемпотентности нет. Значит, про неё просто забыли написать. Спрашиваю у владельцев API напрямую, не додумываю сама.
4. Лимиты и троттлинг
Сколько запросов в секунду разрешено? Что происходит при превышении — 429 Too Many Requests, как и положено по спецификации? Или, как бывает на практике, сервис просто молча обрывает соединение либо отдаёт 503? Это нужно знать заранее, а не выяснять на проде в пятницу вечером.
5. Версионирование — какая версия актуальна на самом деле
Иногда документация описывает v2, а в реальности эндпоинт всё ещё на v1, потому что миграция не завершена. Смотрю дату последнего обновления документации. Если её нет — тоже звоночек.
6. Тестовая среда — её поведение реально совпадает с продом?
Самое неприятное открытие — когда на тестовом стенде всё работает идеально, а на проде логика чуть другая. Уточняю у поставщика API: гарантируется ли идентичность тестовой и боевой среды, или есть нюансы, о которых стоит знать заранее.
Документация — это обещание. Но обещания не всегда выполняют полностью. Задача аналитика — найти дыры до того, как их найдёт разработчик в проде, а не после.
🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией))
___________
Источник: @ba_and_sa
💙 BA|SA | 💬 BA|SA | 4 055 |
| 14 | ТЗ на API: что написать, чтобы разработчик не придумывал за вас
Однажды я получила от разработчика готовый эндпоинт, который работал. Технически. Но в таком формате, что фронт не мог его использовать без дополнительного преобразования. Когда спросила почему — пожал плечами: “в ТЗ не было написано как, я сделал как удобнее”.
И знаете что? Он был прав.
С тех пор у меня есть чеклист того, что обязательно должно быть в ТЗ на API. Делюсь.
1️⃣ Название и назначение
Не “создать API для заказов”, а конкретно:
Эндпоинт: Создание заказа
Используется: мобильное приложение, личный кабинет
Контекст “кто вызывает” влияет на авторизацию и требования к нагрузке.
2️⃣ Метод и URL
POST /api/v1/orders
Точный адрес, метод, версия. Без этого разработчик придумает сам.
3️⃣ Авторизация
Bearer token (JWT)
Authorization: Bearer {token}
Не написали — получите либо открытый эндпоинт, либо неожиданную схему авторизации.
4️⃣ Тело запроса
Каждое поле с типом, обязательностью и ограничениями:
{
"userId": 123, // integer, обязательное
"items": [...], // array, обязательное, min: 1
"comment": "..." // string, необязательное, max: 500
}
Для необязательных полей — что происходит если не передали? Дефолт? Игнорируется? Напишите явно.
5️⃣ Ответ при успехе
HTTP 201 Created
{
"orderId": 789,
"status": "created",
"createdAt": "2026-06-17T10:00:00Z" // UTC, ISO 8601
}
Формат даты фиксируйте явно — иначе получите локальное время сервера и долгие поиски расхождений.
6️⃣ Ошибки — то, что забывают в 80% ТЗ
422 - Не передан обязательный параметр
404 - Пользователь не найден
401 - Нет авторизации
409 - Товар недоступен
Для каждого кода — тело ответа с понятным error code. Договоритесь о едином формате ошибок на весь проект и зафиксируйте один раз.
7️⃣ Бизнес-логика
Самое недооценённое. Структура понятна — но что происходит внутри?
Пишите явно: заказ создаётся только если все товары в наличии, после создания резервируется остаток, уходит email-уведомление. Если этого нет в ТЗ — разработчик придумает сам. Иногда угадывает. Чаще нет.
8️⃣ Нефункциональные требования
Таймаут: не более 2 секунд
Нагрузка: до 100 запросов в минуту
Если нужна защита от дублей — опишите механизм явно через Idempotency-Key в заголовке. Само собой не появится.
Хорошее ТЗ — это не формальность. Это единственный способ получить то, что вы имели в виду, а не то, что разработчик имел в виду за вас 🙂
🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией))
___________
Источник: @ba_and_sa
💙 BA|SA | 💬 BA|SA | 3 898 |
| 15 | Что такое нейросети и как они устроены под капотом (на пальцах, с примерами на python)
⏳ 6 мин | 🟤⚪️⚪️
Перейти | @ba_and_sa
💙 BA|SA | 💬 BA|SA | 2 481 |
| 16 | 3 бесплатных курса, 30+ уроков, 100+ задач 🫠
Кажется, Симулейтив сошли с ума, они отдают бесплатно три курса, за которые многие берут деньги.
Если вы хотите прокачаться в аналитике данных - начните с бесплатных курсов по самым важным разделам. Именно эти блоки помогут вам вкатиться в профессию, спрос на которую не падает из года в год.
В наборе вы получите:
🐍 Основы Python — 10 уроков, 100+ практических задач, 3 проекта для портфолио. Реальные кейсы: аналитика продуктовых метрик, автоматизация обработки чеков. Спойлер: именно с этого начинается карьера аналитика.
🗄 Основы SQL — 12 уроков, 70 задач на PostgreSQL, оконные функции, финальный проект. Без SQL не возьмут ни на одну позицию, связанную с данными.
🐼 Pandas — библиотека, которую аналитик использует каждый день. ABC/XYZ-анализ, EDA, динамика продаж, реальный проект на данных аптечной сети.
Всё это с нуля, с поддержкой в чате и доступом сразу после регистрации.
Забирайте, пока не передумали
👉 [Забрать набор курсов] | 2 905 |
| 17 | Дарим подарки нашим подписчикам 🎁
Мы с ребятами решили порадовать вас интересными подарками от наших каналов:
- Внешний жесткий диск
- Настольная игра от Школы Систем Аналист
- Футболка BA | SA
Условия максимально простые:
- подписаться на каналы;
- нажать «участвую».
1. Системный анализ | Ольга Пономарева
2. Business | System analyst
3. Analyst IT
07.07 в 17:00 мы проведем розыгрыш и троим из вас улыбнется удача))) | 2 824 |
| 18 | Средовой подход вместо системного: как проектировать ИТ-продукты, которые растят сами себя
⏳ 12 мин | 🟤⚪️⚪️
Перейти | @ba_and_sa
💙 BA|SA | 💬 BA|SA | 2 656 |
| 19 | Системный аналитик помогает бизнесу и разработке говорить на одном языке: разбирает задачи компании, описывает требования, проектирует IT-решения и следит, чтобы система работала на реальные цели бизнеса.
Онлайн-магистратура СПбГУ и Нетологии «Системный анализ и интеллектуальные системы управления бизнес-процессами» готовит специалистов на стыке IT и управления.
В программе сочетаются академическая база СПбГУ и прикладные инструменты Нетологии. Студенты изучают математическое моделирование, алгоритмы, системный анализ, Python, BI-системы, no-code-инструменты, управление проектами и подходы к внедрению искусственного интеллекта.
Такой набор навыков помогает работать со сложными бизнес-процессами: находить узкие места, снижать риски при разработке, формулировать требования к системам и сопровождать внедрение IT-решений.
Обучение проходит полностью онлайн. После выпуска вы получаете диплом магистра СПбГУ очного образца по направлению «Прикладная информатика».
Подробнее о программе
Реклама. ООО “Нетология” ОГРН 1207700135884 Erid: 2VSb5yADhXg | 2 631 |
| 20 | Год назад я думал, что ИИ заменит архитектора. Я ошибался
⏳ 15 мин | 🟡⚪️⚪️
Читать статью | @analysis_it
💙 Analyst IT | 💬 Analyst IT | 2 235 |
