ru
Feedback
Business | System analyst

Business | System analyst

Открыть в Telegram

Авторский канал для бизнес/системных аналитиков от аналитика со стажем, как для начинающих, так и для бывалых Сотрудничество: @the_real_bird Регистрация РКН: https://knd.gov.ru/license?id=673c68d031a9292acd1c5784®istryType=bloggersPermission #J6THB

Больше

📈 Аналитический обзор Telegram-канала Business | System analyst

Канал Business | System analyst (@ba_and_sa) языкового сегмента Русский является активным участником. Сейчас сообщество объединяет 17 954 подписчиков, занимая 578 место в категории Маркетинг и PR и 37 166 место в регионе Россия.

📊 Показатели аудитории и динамика

С момента создания невідомо проект демонстрирует стремительный рост, собрав аудиторию из 17 954 подписчиков.

Согласно последним данным от 23 июля, 2026, канал показывает стабильную активность. За последние 30 дней изменение числа участников составило -75, а за последние 24 часа — 2, при этом общий охват остаётся высоким.

  • Статус верификации: Не верифицирован
  • Уровень вовлечённости (ER): Средний показатель вовлечённости аудитории составляет 13.51%. В первые 24 часа после публикации контент обычно набирает 5.79% реакций от общего числа подписчиков.
  • Охват публикаций: В среднем каждый пост получает 2 426 просмотров. В течение первых суток публикация набирает 1 039 просмотров.
  • Реакции и взаимодействия: Аудитория активно поддерживает контент: среднее количество реакций на один пост — 10.
  • Тематические интересы: Контент сосредоточен на ключевых темах, таких как ba|sa, архитектура, api, аналитика, bpmn.

📝 Описание и контентная политика

Автор описывает ресурс как площадку для выражения субъективного мнения:
Авторский канал для бизнес/системных аналитиков от аналитика со стажем, как для начинающих, так и для бывалых Сотрудничество: @the_real_bird Регистрация РКН: https://knd.gov.ru/license?id=673c68d031a9292acd1c5784&registryType=bloggersPermission #J6...

Благодаря высокой частоте обновлений (последние данные получены 24 июля, 2026) канал поддерживает актуальность и высокий уровень охвата публикаций. Аналитика показывает, что аудитория активно взаимодействует с контентом, что делает его важной точкой влияния в категории Маркетинг и PR.

17 954
Подписчики
+224 часа
-627 дней
-7530 день
Привлечение подписчиков
июль '26
июль '26
+283
в 1 каналах
июнь '26
+165
в 2 каналах
Get PRO
май '26
+137
в 2 каналах
Get PRO
апрель '26
+232
в 1 каналах
Get PRO
март '26
+241
в 1 каналах
Get PRO
февраль '26
+227
в 1 каналах
Get PRO
январь '26
+636
в 1 каналах
Get PRO
декабрь '25
+701
в 2 каналах
Get PRO
ноябрь '25
+180
в 10 каналах
Get PRO
октябрь '25
+407
в 1 каналах
Get PRO
сентябрь '25
+504
в 19 каналах
Get PRO
август '25
+180
в 1 каналах
Get PRO
июль '25
+123
в 2 каналах
Get PRO
июнь '25
+508
в 4 каналах
Get PRO
май '25
+303
в 18 каналах
Get PRO
апрель '25
+282
в 1 каналах
Get PRO
март '25
+551
в 10 каналах
Get PRO
февраль '25
+311
в 4 каналах
Get PRO
январь '25
+262
в 2 каналах
Get PRO
декабрь '24
+186
в 1 каналах
Get PRO
ноябрь '24
+258
в 3 каналах
Get PRO
октябрь '24
+583
в 2 каналах
Get PRO
сентябрь '24
+336
в 2 каналах
Get PRO
август '24
+612
в 2 каналах
Get PRO
июль '24
+245
в 1 каналах
Get PRO
июнь '24
+189
в 2 каналах
Get PRO
май '24
+362
в 3 каналах
Get PRO
апрель '24
+605
в 3 каналах
Get PRO
март '24
+310
в 1 каналах
Get PRO
февраль '24
+319
в 2 каналах
Get PRO
январь '24
+288
в 1 каналах
Get PRO
декабрь '23
+287
в 2 каналах
Get PRO
ноябрь '23
+237
в 3 каналах
Get PRO
октябрь '23
+280
в 5 каналах
Get PRO
сентябрь '23
+286
в 0 каналах
Get PRO
август '23
+458
в 0 каналах
Get PRO
июль '23
+307
в 0 каналах
Get PRO
июнь '23
+250
в 0 каналах
Get PRO
май '23
+451
в 0 каналах
Get PRO
апрель '23
+225
в 0 каналах
Get PRO
март '23
+311
в 0 каналах
Get PRO
февраль '23
+355
в 0 каналах
Get PRO
январь '23
+238
в 0 каналах
Get PRO
декабрь '22
+212
в 0 каналах
Get PRO
ноябрь '22
+341
в 0 каналах
Get PRO
октябрь '22
+653
в 0 каналах
Get PRO
сентябрь '22
+249
в 0 каналах
Get PRO
август '22
+255
в 0 каналах
Get PRO
июль '22
+227
в 0 каналах
Get PRO
июнь '22
+269
в 0 каналах
Get PRO
май '22
+304
в 0 каналах
Get PRO
апрель '22
+390
в 0 каналах
Get PRO
март '22
+308
в 0 каналах
Get PRO
февраль '22
+406
в 0 каналах
Get PRO
январь '22
+365
в 0 каналах
Get PRO
декабрь '21
+369
в 0 каналах
Get PRO
ноябрь '21
+253
в 0 каналах
Get PRO
октябрь '21
+320
в 0 каналах
Get PRO
сентябрь '21
+388
в 0 каналах
Get PRO
август '21
+883
в 0 каналах
Get PRO
июль '21
+240
в 0 каналах
Get PRO
июнь '21
+808
в 0 каналах
Get PRO
май '21
+555
в 0 каналах
Get PRO
апрель '21
+624
в 0 каналах
Get PRO
март '21
+999
в 0 каналах
Get PRO
февраль '21
+1 691
в 0 каналах
Дата
Привлечение подписчиков
Упоминания
Каналы
23 июля+3
22 июля+6
21 июля+4
20 июля0
19 июля+5
18 июля0
17 июля+3
16 июля+3
15 июля+4
14 июля+1
13 июля+2
12 июля0
11 июля+1
10 июля+3
09 июля0
08 июля+3
07 июля+160
06 июля+70
05 июля+1
04 июля+3
03 июля+8
02 июля0
01 июля+3
Посты канала
Как брать интервью у производственников — это совсем другая игра Салют! Сегодня у нас разбор интервью производственников)) Пе
Как брать интервью у производственников — это совсем другая игра Салют! Сегодня у нас разбор интервью производственников)) Первый раз я пришла на интервью к начальнику смены на установке с ноутбуком, красивым шаблоном вопросов и уверенностью что всё пройдёт как обычно. Через десять минут поняла — ничего как обычно не будет. Он смотрел на меня как на человека который пришёл отнять у него время. Отвечал односложно. На вопрос “расскажите как вы работаете с данными по выходу продукта” — пожал плечами и сказал “ну, смотрим”. Я вышла с того интервью почти с пустым блокнотом. И пошла думать что сделала не так. Почему стандартный подход не работает 🧐 На офисных проектах люди в целом готовы говорить. Они привыкли к встречам, к обсуждениям, к тому что их мнение спрашивают. У производственника другая картина мира. Его день — это смена, регламент, ответственность за процесс. Встреча с аналитиком из IT — это помеха в этом ритме. Не потому что он плохой человек. Просто у него реально другие приоритеты. Плюс есть негласная установка: “скажешь лишнее — потом переделывай”. Люди на производстве умеют молчать. Это навык выживания в большой организации. Что изменила в своём подходе❗️ 1️⃣ Никакого ноутбука в начале Ноутбук на столе — это протокол, это фиксация, это официально. Человек закрывается. Я стала приходить с блокнотом и ручкой. Иногда вообще без ничего — просто поговорить. Записи делала после, по памяти. Да, это сложнее. Но люди говорили в разы открытее. Сначала про работу, потом про систему Ошибка которую я делала в начале — сразу спрашивала про будущую систему. “А как вы хотите чтобы это работало?” Человек не знает. Он никогда не думал в этих категориях. Правильный порядок: сначала полностью понять как устроена работа сейчас. Только потом — осторожно — переходить к тому что можно улучшить. Вопросы которые реально работают:
— Покажите как вы это делаете прямо сейчас
— А что происходит если вот это пошло не так?
— Откуда вы узнаёте что нужно действовать?
— Кому вы передаёте эту информацию дальше?
Никаких “а как вы видите идеальный процесс”. 
Производственник не обязан думать об идеальных процессах — это наша работа. 2️⃣ Идти на рабочее место, а не звать в переговорку Переговорка — чужая территория. Человек там скован. Когда я начала приходить прямо к установке, к рабочему месту — всё менялось. Он в своей среде, уверен, может показать руками. “Вот смотри — вот этот показатель, вот журнал, вот куда я смотрю когда что-то идёт не так.” Один такой визит заменял три переговорки. И информации было в разы больше. Не спорить и не умничать Если технолог говорит что-то что кажется нелогичным — не спорить. Уточнять. “Правильно я понимаю что вы делаете вот так потому что…?” Часто за нелогичным на первый взгляд решением стоит опыт десятилетий и несколько аварийных ситуаций которые этот человек пережил лично. Найти союзника внутри На каждом производственном проекте я искала одного человека который понимает зачем всё это нужно и готов помочь. Не обязательно руководителя — иногда это молодой инженер которому интересно. Такой человек помогал договориться о встречах, объяснял коллегам что я не враг, и переводил с технологического на человеческий когда я совсем не понимала о чём речь. 3️⃣ Отдельно про документацию которой нет На производстве часто слышишь: “Да всё написано в регламенте”. Берёшь регламент — а там описан процесс образца 2009 года который давно работает по-другому. Просто никто не обновлял. Реальный процесс живёт в головах людей и в неофициальных инструкциях которые передаются от старшего к младшему устно. Задача аналитика — вытащить именно это, а не переписать регламент который и так все игнорируют. И главное Производственники — одни из самых ценных экспертов с которыми мне приходилось работать. Они знают свой процесс до деталей которые ни в каком документе не найдёшь. Просто язык у них другой. И подход нужен другой. Когда перестаёшь приходить как “человек из IT который сейчас всё улучшит” и начинаешь приходить как человек который хочет разобраться — всё меняется. Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA

2
Можно ли аналитику в 2026 году положиться на ИИ и агентов или ещё нет? ⏳ 15 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA
2 115
3
Когда заказчик говорит “сделайте как раньше” — а раньше уже не работает Салют! Есть особая категория проектов, о которых в уч
Когда заказчик говорит “сделайте как раньше” — а раньше уже не работает Салют! Есть особая категория проектов, о которых в учебниках по системному анализу не пишут. Это автоматизация на производстве. Не стартап, не интернет-магазин — ЗАВОД. Со своей культурой, своими людьми и своим отношением к любым изменениям. Несколько лет я работала на проектах автоматизации производственных процессов. Нефтепереработка, цеха, технологи у которых за плечами по 20-30 лет стажа. Это был совершенно другой мир по сравнению с офисными проектами. И он многому меня научил. 1️⃣ Первый урок: эксперт в предметной области — не ты В обычных проектах аналитик быстро разбирается в предметке. Бухгалтерия, логистика, HR — за несколько недель погружаешься и уже можешь говорить на одном языке с бизнесом. На производстве это не работает. Технолог который обслуживает установку первичной переработки нефти знает её так, как ты никогда не узнаешь. И он это чувствует. Первое время я пыталась быстро вникнуть в технологические процессы — читала регламенты, смотрела схемы. Потом поняла: моя задача не стать экспертом в нефтепереработке. Моя задача — правильно упаковать знания эксперта в требования. Как только перестала делать вид что разбираюсь — люди начали говорить открыто. Простой вопрос “объясните мне как будто я первый раз это слышу” творит чудеса. 2️⃣ Второй урок: “сделайте как в Excel” — это не хотелка, это сигнал Классическая история. Приходишь автоматизировать процесс, а там — огромная Excel-таблица которую технолог ведёт вручную уже восемь лет. Вся логика в ней, все расчёты, весь опыт. Первый инстинкт: переписать в нормальную систему, убрать ручной труд, сделать красиво. Стоп. Прежде чем автоматизировать — нужно понять почему Excel выглядит именно так. Каждая колонка, каждый цвет, каждая формула — это чьё-то решение, принятое по какой-то причине. Иногда причина устарела. Но иногда в ней зашита бизнес-логика которую никто не догадался задокументировать. Я научилась задавать один вопрос: “А вот эта колонка — зачем она? Что вы с ней делаете дальше?” И половина интервью уходила именно на разбор таблицы. 3️⃣ Третий урок: сопротивление изменениям на производстве — это не каприз Когда офисный сотрудник сопротивляется новой системе — обычно это про привычку или про страх что станет сложнее. Когда технолог на заводе говорит “я не буду работать в новой системе” — за этим может стоять кое-что серьёзнее. Люди несут реальную ответственность за процессы. Цена ошибки на производстве — это не “клиент недоволен”, это остановка установки или хуже. Поэтому недоверие к новому инструменту здесь — абсолютно рациональная реакция. И продавить его административно можно, но система будет саботироваться тихо и методично. Что работало у меня: брать самого скептичного человека в команду пилота. Не самого лояльного — самого скептичного. Если он найдёт проблемы раньше запуска — это подарок. Если в итоге скажет “ну, работает” — остальные поверят быстрее любой презентации. 4️⃣ Четвёртый урок: требования живут в головах людей предпенсионного возраста И это не проблема — это факт с которым нужно работать. На производственных проектах я несколько раз сталкивалась с ситуацией: единственный человек который знает как работает процесс — уходит на пенсию через полгода. И никаких документов нет. Вообще. В таких случаях интервью превращается в спасательную операцию. Сидишь, записываешь, уточняешь, рисуешь схемы прямо на встрече и просишь подтвердить. Иногда по три раза возвращаешься к одному и тому же человеку. Это медленно. Но это единственный способ не потерять знания которые потом не восстановить. Производственные проекты изменили меня как аналитика больше, чем любые курсы и книги. Там не получается работать по шаблону — слишком высокая цена ошибки и слишком живые люди с которыми приходится работать. Если у вас был опыт автоматизации на производстве — очень интересно услышать. Уверена, у каждого своя история 👇 Ставьте реакции, если понравилась тема)) ___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA
1 866
4
Как использовать Kafka на собеседовании по System Design ⏳ 17 мин | 🟡⚪️⚪️ Читать статью | @analysis_it 💙 Analyst IT | 💬 Analyst IT
1 559
5
Компании ценят специалистов, которые разбираются как в технической стороне продукта, так и в потребностях бизнеса. Перекрёстн
Компании ценят специалистов, которые разбираются как в технической стороне продукта, так и в потребностях бизнеса. Перекрёстные навыки часто встречаются в вакансиях. Нетология объединила две профессии в один курс — «Системный и бизнес-аналитик». На занятиях своим опытом поделятся эксперты из Qiwi, М.Видео — Эльдорадо и Bolt. За 12 месяцев вы научитесь: - использовать гибкие методологии Agile и Scrum; - разбираться в нотациях моделирования: UML, BPMN, IDEF; - описывать user story и use case; - создавать прототипы приложений и сервисов; - работать с АРІ и проектной документацией. Сейчас на курс действует скидка 50%, а с промокодом IT10JULY цена станет ещё на 10% ниже. Плюсом подарим курс о развитии карьеры при покупке до 31 июля. Записаться Реклама. ООО “Нетология” ОГРН 1207700135884 Erid: 2VSb5xpZMyt
1 946
6
Думаете, что знаете все про LLM? Тогда мы идем к вам ⏳ 27 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA
1 799
7
Как я готовился к сертификации по LLMархитектуре и понял, что три года путал промпты с архитектурой ⏳ 5 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA
2 048
8
Сказ про Лукаса-героя да про Postgres и Timescale: SA и его необычная задача ⏳ 4 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA
2 276
9
Как работать с требованиями которые меняются — без нервов и переработок Салют! Помню проект, где требования менялись так част
Как работать с требованиями которые меняются — без нервов и переработок Салют! Помню проект, где требования менялись так часто, что я перестала распечатывать документацию — смысла не было. Разработчики смотрели на меня с немым вопросом, я смотрела на бизнес с тем же вопросом. ❗️Тогда поняла: проблема не в том что требования меняются. Они всегда будут меняться. Проблема в том как ты выстраиваешь работу с ними. Сразу честно: ни один инструмент не спасёт если в компании хаос на уровне управления. Но даже в таких условиях правильный подход помогает выжить с меньшими потерями для себя и команды. И это тоже результат. Почему требования меняются — без прикрас — Бизнес не знал чего хочет до конца. Это нормально — люди часто понимают что им нужно только увидев первый результат — Изменился контекст: рынок, конкурент, законодательство, новый руководитель с другим видением — Требования были размыты с самого начала — вот это уже наша зона ответственности Злиться на второй пункт бессмысленно. Над третьим работать — полностью в наших силах. Что реально помогает (или помогало в моем случае): 1️⃣Фиксируйте договорённости сразу Любое решение с встречи — в письмо в тот же день. Люди искренне забывают что говорили три недели назад, это не злой умысел. Иногда такая фиксация воспринимается в штыки: “ты мне не доверяешь?” Я на это отвечала спокойно: “Доверяю, просто у меня плохая память” — обычно разряжало обстановку. Договорились: ... Следующий шаг: ... Жду подтверждения до [дата]. 2️⃣Спрашивайте “зачем”, а не “как” Это работает всегда и везде — просто здравый смысл. Приходит менеджер: “Хочу менять цвет строк в таблице”. Спрашиваю зачем. Оказывается — хочет видеть просроченные заказы. Реальное требование: автоматически подсвечивать просрочку. Другая задача, проще и полезнее. Половина изменений при правильном вопросе превращается в уточнение исходного требования, а не в новую задачу. 3️⃣ Показывайте стоимость изменения Когда бизнес приходит с правкой, говорю прямо: “Эта правка затрагивает три модуля, сдвигает сроки на неделю. Готовы?” Важна подача. Не “это дорого и мы не будем делать”, а “давайте я покажу что затронет эта правка — и вы примете решение”. Некоторые заказчики всё равно воспримут это как отказ помочь — но большинство после такого разговора спокойно отправляют правку в следующий релиз. 4️⃣ Приоритизируйте, не складывайте в кучу Приоритет / Критерий Срочно и важно / Блокирует работу прямо сейчас Важно, не срочно / В следующий спринт Хотелка / В бэклог Честно: в компаниях где всё “срочно и важно” по умолчанию — эта таблица работает плохо. Но даже там она помогает хотя бы начать разговор о приоритетах. 5️⃣ Договоритесь о правилах на берегу В начале проекта проговариваю с заказчиком: как обрабатываем изменения, когда правка идёт в текущий релиз, а когда в следующий, кто финальный ЛПР. Сложность в наших реалиях: ЛПР часто недоступен, меняется или принимает решения в коридоре после планёрки. В таком случае фиксирую хотя бы того кто есть — пусть не идеально, но лучше чем ничего. ❗️И про внутреннее состояние — это важно Я долго воспринимала каждое изменение как личную неудачу. Значит плохо собрала, не так спросила, недоработала. Потом поняла: идеальных требований не бывает. Иногда проблема вообще не в аналитике — а в том что решения принимаются спонтанно на самом верху, и никакой инструмент это не исправит. Наша ценность не в том чтобы зафиксировать всё раз и навсегда. А в том чтобы управлять изменениями так, чтобы команда не сходила с ума и бизнес получал то что реально нужно. 🧐 Если было полезно, ставьте реакции, буду делиться больше такой информацией)) ___________ Источник: @ba_and_sa 💙 BA|SA | 💬 BA|SA
3 649
10
Системный аналитик 2026: вы всё ещё пишете документацию, но теперь её читает только LLM ⏳ 5 мин | 🟤🟤⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA
2 490
11
🎉 Результаты розыгрыша: 🏆 Победители: 1. Роман (@zkhromann) 2. AlexUnit (@AlexxUnit) 3. Tryshch (@Tryshch) ✔️Проверить результаты
2 448
12
Салют! Напоминаю о нашем розыгрыше Присоединяйтесь и получите шанс выиграть от нас подарочки))
2 307
13
Event Storming: как за один сеанс вытащить из бизнеса всё что нужно Салют! Расскажу про технику, которая перевернула мой подх
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 486
14
Хочешь сделать хорошо — сделай сам: как у нас появилась собственная система работы со стендами ⏳ 12 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA
2 819
15
Как читать чужую документацию на API, чтобы не наступить на грабли Салют! Решила еще написать пару постов на тему API и расск
Как читать чужую документацию на 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 306
16
ТЗ на API: что написать, чтобы разработчик не придумывал за вас Однажды я получила от разработчика готовый эндпоинт, который
ТЗ на 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
4 239
17
Что такое нейросети и как они устроены под капотом (на пальцах, с примерами на python) ⏳ 6 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA
2 542
18
3 бесплатных курса, 30+ уроков, 100+ задач 🫠 Кажется, Симулейтив сошли с ума, они отдают бесплатно три курса, за которые мно
3 бесплатных курса, 30+ уроков, 100+ задач 🫠 Кажется, Симулейтив сошли с ума, они отдают бесплатно три курса, за которые многие берут деньги. Если вы хотите прокачаться в аналитике данных - начните с бесплатных курсов по самым важным разделам. Именно эти блоки помогут вам вкатиться в профессию, спрос на которую не падает из года в год. В наборе вы получите: 🐍 Основы Python — 10 уроков, 100+ практических задач, 3 проекта для портфолио. Реальные кейсы: аналитика продуктовых метрик, автоматизация обработки чеков. Спойлер: именно с этого начинается карьера аналитика. 🗄 Основы SQL — 12 уроков, 70 задач на PostgreSQL, оконные функции, финальный проект. Без SQL не возьмут ни на одну позицию, связанную с данными. 🐼 Pandas — библиотека, которую аналитик использует каждый день. ABC/XYZ-анализ, EDA, динамика продаж, реальный проект на данных аптечной сети. Всё это с нуля, с поддержкой в чате и доступом сразу после регистрации. Забирайте, пока не передумали 👉 [Забрать набор курсов]
2 965
19
Дарим подарки нашим подписчикам 🎁 Мы с ребятами решили порадовать вас интересными подарками от наших каналов: - Внешний жест
Дарим подарки нашим подписчикам 🎁 Мы с ребятами решили порадовать вас интересными подарками от наших каналов: - Внешний жесткий диск - Настольная игра от Школы Систем Аналист - Футболка BA | SA Условия максимально простые: - подписаться на каналы; - нажать «участвую». 1. Системный анализ | Ольга Пономарева 2. Business | System analyst 3. Analyst IT 07.07 в 17:00 мы проведем розыгрыш и троим из вас улыбнется удача)))
2 863
20
Средовой подход вместо системного: как проектировать ИТ-продукты, которые растят сами себя ⏳ 12 мин | 🟤⚪️⚪️ Перейти | @ba_and_sa 💙 BA|SA | 💬 BA|SA
2 700