Системный и бизнес-анализ

Всем привет, уважаемые читатели! В архитектуре проектов мы можем наблюдать применение паттерна BFF (Backend for frontend). При этом BFF может быть в архитектуре, где есть взаимодействие с клиентскими приложениями: веб, мобильное, смарт-устройства и т.д, но может быть всего-навсего один служебный фронтенд, доступ к которому возможен во внутрикорпоративном сегменте, например, банковская система, hr, логистика. Кажется, что при наличии одного фронтенда введение BFF избыточно.

И возникает закономерный вопрос: если клиент всего один, да еще и работает внутри защищенного контура, зачем нам плодить отдельные компоненты системы? Не превращается ли BFF в лишний прокси-сервис, который только пробрасывает запрос и добавляет сетевую задержку?

Но что, если фронтенд один и вдруг нуждается в данных из разных API системы, чтобы нормально функционировать? При этом запросы могут быть сложными: каждый требует особых параметров и возвращает много лишней информации. А если у вас несколько клиентских приложений и так же нужно подтягивать данные из разных API?

Data Mesh, Data Fabric, Lakehouse: разбираем модные термины

Data Mesh, Fabric, Lakehouse – все говорят, но никто толком не объясняет, чем они отличаются и можно ли их использовать вместе. Разобралась и делюсь структурированно и без воды.

➕ Сравнительная таблица и чек-лист: что выбрать под свою боль.

✔️Сохраняйте, чтобы больше никогда не путаться.

Представим ситуацию.

Маркетолог работает в крупной компании с собственной A/B-платформой. Каждый квартал он должен запускать несколько новых маркетинговых кампаний, и подтверждать их эффективность с помощью экспериментов. Ресурса аналитика всегда не хватает на подобные задачи. А A/B-платформа позиционируются как инструмент, доступный в том числе маркетологам и проектным менеджерам. В итоге, наш герой решает запустить эксперимент самостоятельно.

Гипотеза. «Новый лендинг увеличивает среднюю выручку на пользователя (ARPU) в выбранном сегменте».

Спустя несколько недель маркетолог открывает AB-платформу, чтобы подвести итоги эксперимента. Видит, что пользователи распределены по группам примерно равное: 9 936 в тесте и 10 068 в контроле. Результат радует глаз: effect = 18.28%. "Какой эффект! Вот только чувствительности для "прокраса" немного не хватило", - думает он, - "глядя на p-value = 0.1179".

Но можно ли принимать решения на основе этих данных? Давайте разберемся, проведя анализ вероятных искажений.

Хотите стать аналитиком, но не знаете, с какой стороны подступиться? Расскажу, что бы я делала, если бы сейчас входила в профессию с нуля – без дорогих курсов и кредитов.

🔹 Бесплатные курсы, которые дают реальную базу (и где искать правдивые отзывы)
🔹 Как подружиться с ИИ и заставить его работать вашим личным наставником
🔹 Честный тест-драйв: как понять, что аналитика – это ваше, до покупки курса
🔹 Когда идти на платное обучение и как выбрать курс, чтобы не выбросить деньги на ветер

«Зачем мне эта ваша математика?» честный разбор для тех, кто хочет расти в аналитике

Если вы работаете в аналитике и ни разу не задавались вопросом «а зачем мне эти интегралы и производные» – вы либо гений, либо врете.
В интернете много статей про матан для аналитиков, но они либо уходят в дебри интегрирования по частям, либо ограничиваются уровнем «логарифм делает большие числа маленькими». Где золотая середина?

Что внутри:
Логарифмы: не просто log1p, а эластичность и среднее геометрическое
Производные: как поймать момент перед падением (вторая производная)
Пределы: почему retention не упадет ниже 15% (и при чем тут асимптоты)
Интегралы: LTV с дисконтированием и площадь под uplift-кривой

Для кого: аналитики, которые уже вышли из Excel и хотят понимать, что на самом деле делают их .diff() и .cumsum().

Корпоративный мир ушёл далеко вперёд. Если 10 лет назад сотрудники выходили на работу, чтобы создавать продукты «с нуля», то сегодня конъюнктура изменилась. IT-ландшафт крупных компаний перенасыщен решениями на любой вкус. На смену классическому проектному управлению, ориентированному на создание чего-то нового, пришло управление продуктами, где гибкие методологии работают на развитие и стабилизацию уже существующих систем.

Но любой продукт когда-то был просто идеей. Поэтому давайте договоримся о терминах: в этой статье проект — это нулевая ступень, фундамент, с которого начинается жизненный путь любого продукта. Расскажу об этом подробнее на примере из личной практики.

Расскажу какие навыки потребуются, чтобы начать свой карьерный путь в качестве BI-аналитика, и поделюсь ресурсами, которые помогут прокачать эти навыки. Подборка из статьи будет полезна и начинающим специалистам, и профи - для увеличения кругозора.

Разработка любого ИТ-продукта, если она ведётся осознанно и целенаправленно, а не спонтанно и хаотически, требует чёткой постановки задачи – что должно быть получено в результате. Соответственно, необходимо описание требований к создаваемому продукту, которое и принято называть «ТЗ» – Техническим заданием.

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

Однако, возникает логичный вопрос – ДЛЯ КОГО должно быть написано ТЗ.

Из этого уже вытечет следующий вопрос – ЧТО должно быть включено в ТЗ, т.е. какие требования составляют спецификацию (как, собственно, в иностранных языках ТЗ обычно и называется – «спецификация требований»).

Конечно, можно (и, в большинстве случаев, нужно) использовать существующие стандарты – например, отечественные ГОСТ 19.201 для программы и ГОСТ Р 34.602 для автоматизированной системы. Есть и другие стандарты, которые достаточно хорошо описывают структуру и содержания таких документов. Но увы, в большинстве случаев эти стандарты описывают спецификации «внешних» требований заказчика к целевому продукту (что, в сущности, верно), т.е. продукт рассматривается как «чёрный ящик», который что-то и как-то делает, и вот эти «что-то» и «как-то» в их внешнем проявлении в ТЗ как спецификации требований и описываются. А вот вопрос о том, может ли быть ТЗ «для разработчика», остаётся открытым.

📚Линейная регрессия – это первый алгоритм, который осваивает аналитик, и последний, который он перестает использовать.
✔️В статье разберем, что это такое, как работает, где применяется и с какими подводными камнями вы обязательно столкнетесь.

Привет, Хабр! Меня зовут Руслан Каллагов, я системный аналитик в Лаборатории Globus — партнёре Нетологии по стажировкам на курсах ИТ-профессий. Уже 4,5 года я работаю в проектировании программного обеспечения и верю в силу синергии человеческой экспертизы и ИИ. В этой статье расскажу, как именно меняется рабочий процесс, инструментарий и зона ответственности системного аналитика под влиянием технологий вроде ChatGPT. 

Это не паническое эссе, а руководство по переходу от роли добытчика и писателя требований к позиции архитектора AI-процессов в команде. Мы не будем гадать о далёком будущем, а сделаем практический разбор сегодняшней реальности. Вы получите конкретные промпты, чек-листы и схемы, которые сможете применить в своей работе уже завтра, чтобы не просто адаптироваться к изменениям, а использовать ИИ как мощный леверидж для роста своей экспертизы и ценности.

Если вы уже используете Битрикс24, но вручную анализируете сделки через фильтры и стандартные отчеты, то теряете скорость и масштаб аналитики. В статье рассказываю, как встроенный BI-конструктор помогает собирать кастомные метрики без подключения внешних BI-платформ.

📊 Хотите стать аналитиком данных, но не знаете, с какой стороны подойти?

Я собрала чек-лист для старта в 2026 году, никакой воды - только то, что реально спросят на собеседовании:
🛠 Что учить: SQL (с оконными функциями), Python (Pandas), BI-системы.
🧠 Важный софт-скилл, о котором молчат курсы — управление ожиданиями заказчика.
🔮 Бонус: что нужно знать про DWH и ML, чтобы выделяться среди других джунов.

В мире разработки программного обеспечения существует понятие, которое окружено множеством мифов, страхов и недопонимания. 

Это технический долг. 

Часто его воспринимают как нечто сугубо негативное, как признак некомпетентности команды или халатности архитектора. Однако чем глубже ты погружаешься в тему и анализируешь практический опыт, приходишь к выводу, что техдолг — это неизбежная часть жизненного цикла любого продукта. Не ошибка, а стратегические компромиссы. В этом материале хочу поделиться своим видением подходов к работе с техдолгом: поразмышляю о природе техдолга, инструментах для работы с ним, стратегиях взаимодействия с бизнесом, чтобы показать, как тонкая грань между быстрым стартом и катастрофой может быть успешно пройдена.

Всем привет! Меня зовут Катя, я развиваю Gramax — базу знаний для ИТ-команд. Эта статья — интервью с Екатериной Ушаковой о ее книге «Если ты — технический писатель». Екатерина Ушакова — одна из узнаваемых фигур в сообществе технических писателей. Она создала техническую редакцию в Ozon, преподает в Университете Иннополис, организует конференции и ведет сообщество руководителей технических редакций.

Сейчас Катя готовится к выпуску книги о современном техническом писательстве. В статье вы узнаете:

📌 Как и зачем Катя решила написать книгу о роли «Технический писатель».

📌 Почему выбрала печатный, а не электронный формат.

📌 Как Gramax помог справиться с редактурой сотен комментариев.

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

Data governance, data mesh, modern data stack, data lineage – столько разных data, столько разных популярных подходов и инструментов. Лидером по популярности (на мой скромный взгляд) среди всех них является data catalog. Многие говорят о нем, многие хотят его, многие уже внедрили. Но внедрить это одно дело, а вот получить от него пользу – дело совсем другое.

Мы сформировали список самых частых проблем, основанные не только на нашем опыте, но и на опыте наших коллег, проанализировав множество статей и материалов на эту тему.

Если вам больше 14 лет, вы почти наверняка уже пробовали «поговорить» с нейросетью о чём-то личном. Поздно ночью, перед сложным разговором с партнёром или на фоне выгорания. И, скорее всего, результат вас и удивил, и разочаровал.

Копнем глубже, что ИИ в психологии реально умеет, где его потолок — и как использовать это без иллюзий, но с пользой.

Что ИИ уже умеет в «психологии»

ИИ стал сильным инструментом, но с одним ограничением: он обучен на текстах, а не на живом внутреннем опыте людей. Это многое определяет. На уровне «первой помощи» Копнем работают неплохо.
Они могут:

Мы часто проектируем «правильно»: используем проверенные подходы, следуем best practices, применяем паттерны. Но результат всё равно может оказаться далеким от ожидаемого. Архитектура выглядит логичной, решения — обоснованными, а в реальности система становится сложнее, дороже и больнее в сопровождении.

Почему так происходит? Разберём паттерны это на реальном кейсе миграции с Legacy-системы — и посмотрим, где заканчивается сила паттернов и начинается суровая реальность.

Краткое содержание статьи:

— Как проектировать правильно?
— К чему может провести правильное проектирование на примере истории миграции
— Почему получилось что-то «неправильное»?
— Выводы.

За переводы сонетов Шекспира брались многие мастера и любители. Мне стало интересным провести лексико-семантический анализ нескольких переводов 74 сонета и сравнить их с оригиналом. Я взял авторов, авторитет которых как поэтов и переводчиков вне сомнения Маршака и Пастернака. И двух переводчиков, не известных как поэты - Николая Гербеля и Модеста Чайковского. Я захотел проверить, кто из переводчиков точнее всего передал смысл, ритм и эмоции оригинала, используя алгоритмы машинного обучения.

Свершилось! Спустя двадцать лет после старта проекта на Хабре вышла публикация с миллионным уникальным номером ID (сокращение от англ. identifier — «идентификатор»). Черновик этой публикации создался 16 февраля 2026 года. Примечательно, что такое событие случилось также через 16 лет после выхода публикации со стотысячным ID.

Привет, Хабр! Меня зовут Дмитрий Кислов, я системный аналитик в команде автоматизированной банковской системы в ПСБ. 

Рано или поздно каждый ИТ-специалист сталкивается с ситуацией, когда бизнес ставит почти невыполнимую задачу с жёстким дедлайном. Как тут не вспомнить старую шутку: «Можно ли заставить 9 женщин родить ребёнка за один месяц?». Ответ очевиден — нет, законы природы (и разработки) не обманешь.

Конечно, мой главный совет по таким ситуациям — не оказываться в них. Но в реальности случается форс-мажор: внезапные изменения в законодательстве, упущенные сроки, требования ключевых клиентов. Команда оказывается перед фактом: «Нужно сделать невозможное, и, кстати, дедлайн — вчера».

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