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

Одна из самых частых и болезненных проблем в IT-командах — коммуникация с внутренними заказчиками. Со стороны разработки заказчики выглядят как генераторы сырых ТЗ, вечных правок и нереалистичных сроков. Со стороны бизнеса IT-специалисты кажутся «черным ящиком», который работает медленно, негибко и допускает ошибки.

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

В этой статье я собрал 11 принципов, которые помогут выстроить такую коммуникацию.

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

Быстрота изменений UX/UI дизайна, функциональности, влияния запусков конкурентов, предоставляющих аналогичный продукт, внешние факторы – все это отражается на метриках удержания и сроке пользования продуктом, а значит и на тех деньгах, которые продукт зарабатывает по P&L.

Пока соискателей учат быть «размалеванными барышнями», работодатели на «рынке лимонов» никому ничего не должны. Можно ли узнать, что ждет внутри, еще до получения оффера? Что, если я скажу: текст вакансии — это честная проекция «внутренней кухни» компании? Я уверена, так как проверила это на личном кейсе, и, вооружившись этим инструментом, проанализировала 146 000 вакансий. О том, почему и как это возможно — для тех, кто не считает неудачное трудоустройство «ценным опытом» — рассказываю ниже.

Типовая ситуация: в проект приходят умные люди, менеджеры внедряют эффективные процессы, а проект все равно превращается в болото. Фичи разрабатываются месяцами, релизы откладываются, а на ретроспективах все жалуются на зависимости. При этом на схемах все выглядит красиво: микросервисы, CI/CD, облака. Что с этим миром не так?

Понятно, что «не так» может быть что угодно и как обычно it depends, но здесь и сейчас разберем одну из возможных причин, а именно ситуацию, при которой архитекторы и техлиды работают только с одним видом сложности – технологической. Рисуют квадратики, проводят стрелочки, выбирают базы данных. Реальность разработки при этом гораздо сложнее: в любом проекте одновременно живут три вида сложности, и они постоянно влияют друг на друга.

В первой и второй частях мы рассматривали общий подход к бизнес-документации на нашем платформенном проекте в компании «Наука». А сейчас подобрались к главному – техническому проекту (ТП). Это – наш основной и наиболее распространенный документ для типовых задач в ERP-области.

За двадцать с лишним лет работы в области управления данными я видел всё: от Excel-таблиц вместо MDM до попыток построить Data Governance на коленке. Видел, как компании тратят миллионы на внедрение систем, которые никто не использует. И видел, как правильный инструмент меняет всё: от культуры работы с данными до скорости принятия решений.

Сегодня российский рынок Data Management активно развивается, растёт осознание важности управления данными. Но любопытство берёт своё: а что там, на западе? Какие подходы, какие фишки, какие боли они решают?

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

Хабр, привет! Меня зовут Раф, я работаю аналитиком ценообразования в Авито (а раньше — в Яндекс Лавке), преподаю машинное обучение в Центральном университете, окончил факультет компьютерных наук в НИУ ВШЭ и прошёл курс «Специалист по Data Science» в Яндекс Практикуме. В этом материале расскажу, как переходил из Лавки в Авито и к чему стоит быть готовым аналитикам, которые захотят повторить мой опыт.

Мы в Геоинтеллекте любим геоданные и геоаналитику. Часто миксуем технологии. Вот, например, мы попробовали генерировать графики BI системы DataLens внутри платформы для Геоаналитики “Геоинтеллект”. Что из этого вышло, посмотрим на реальном кейсе, которая выполняла наша сотрудница. 

Задача

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

В первой части статьи мы рассматривали общий подход к документации платформенного проекта компании NAUKA. А сейчас давайте погрузимся в детали и «начинку» конкретных документов: ADR, Vision и SRS

Sharpe 2.1 в pandas-бектесте, через три месяца реальной торговли упал до 0.3

Pandas-бектесты систематически завышают доходность на 30-70%. Одна строчка с shift(-1) и вы уже используете завтрашние данные для сегодняшних решений. Плюс survivor bias, плюс нереалистичные fills.

В статье разбираю источники look-ahead bias, сравниваю vectorized и event-driven подходы на данных MOEX (SBER, GAZP, LKOH за 2020-2024), мои замеры latency для Tinkoff API, и рассуждения о том, когда Python уже не вывозит и пора думать про C++

Есть такое направление в визуализации данных — называется Дата‑арт. То есть, когда данные пытаются визуализировать творчески, не с целью сделать их понятными, а с целью передать эмоции или привлечь внимание к эстетической красоте проекта на основе данных. 

И вот, изучая и классифицируя проекты в этой коллекции (их там несколько сотен), я обнаружила, что в дата‑арт направлении есть набор проектов, которые явно вдохновлены пейзажами — и я выделила их в отдельную группу. 

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

Как документировать разработку ERP-платформы?

Меня зовут Александр Курашов, и я работаю бизнес-аналитиком и архитектором в компании NAUKA. Один из наших знаковых проектов – разработка Платформы, объединяющей различные продукты компании в единую экосистему решений.

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

Недавно я участвовал в круглом столе на тему «аналитики против искусственного интеллекта». Это обсуждение вдохновило меня на более предметный разговор о том, почему нейронные сети — это не противник, а полезный инструмент, который реально экономит время. Меня зовут Владимир Бурмистров, я главный системный аналитик в IT-холдинге Т1. В отрасли я уже 18 лет — застал и времена адаптации под Internet Explorer 6, и приход нейросетей. И я могу уверенно сказать: благодаря нейросетям я ускоряю свою работу примерно на 30%. Как именно? Давайте разбираться по порядку.

В прошлой статье я закончил обзор open source решения для аналитики и, что важно для нас, решения для менеджера тегов - Matomo Tag Manager. В этой статье приступаем к разбору по косточкам самого решения. И начинаем с установки его на сервер. А я продолжаю выступать своего рода евангелистом Matomo Tag Manager в рунете, где он незаслуженно, по моему мнению, обойден стороной.

Всем привет! Я — Ольга Матушевич, преподаватель онлайн-магистратуры «Дата-аналитика для бизнеса», а в прошлом наставница на курсе «Аналитик данных» в Яндекс Практикуме. И сегодня я расскажу, чем Copilot может помочь аналитику при создании дашбордов в Power BI: как работающему в компании, только приступившей к использованию BI-системы, так и обладателю обширного legacy.

Привет, Хабр! С каждым годом ИИ способен решать более сложные задачи, одной из задач является понимание DAX, связанных предметных областей и генерация кода. Можно выделить несколько задач, которые не являются первостепенными, тем не менее актуальны для анализа или работы в Power BI, например, от простейших — создание клиента для выполнения DAX запросов в Power BI из произвольной среды (например, из .NET приложения) и импорт метаданных TOM модели, до более сложных задач — экспорта схемы данных и самих данных из Power BI в произвольную СУБД (понятно, что такая задача не всегда актуальна с точки зрения ETL, т.к. проще взять данные из исходных источников, а не из Power BI, но польза решения задачи «интуитивно понятна» пользователю) и задач генерации SQL запросов на основе DAX для заданной СУБД, причем результаты сгенерированного SQL должны совпадать с результатами DAX запросов.

Интересующимся применением ИИ на примере DAX из Power BI — добро пожаловать под кат :)

Рассказываю и наглядно показываю как делать понятные и красивые дашборды без лишнего шума, которые ответят на вопросы пользователей, а не создадут новые.

📊 Знаете, что общего у температуры в городах и валютных курсов? И то, и другое — относительные величины. У вас есть разницы, но нет абсолютных значений.

Можно ли из одних лишь парных котировок вроде EUR/USD или USD/JPY вычислить внутреннюю, абсолютную стоимость каждого доллара, евро или йены? Оказывается, можно — и для этого не нужен волшебный экономический калькулятор.

В этой статье мы делаем то, что звучит как задача для детектива: восстанавливаем абсолютные значения из одних лишь отношений. С помощью чистого Python и метода наименьших квадратов мы превращаем сеть из 85 рыночных котировок в единую шкалу стоимости для 45 валют.

Что вас ждёт:

Матрицы, логарифмы и МНК — как линейная алгебра очищает финансовые данные от шума.

Рабочий код — от построения матрицы инцидентности до ежедневного расчёта.

Фокус с разоблачением — на примере USD/JPY покажем, как понять, что на самом деле движет парой: укрепление доллара или ослабление йены?

Масштабирование до 153 валют — как та же математика работает для всей мировой системы.

Если вы когда-либо задумывались, как устроена «кухня» валютного рынка за пределами парных графиков — эта статья для вас. Переходите, чтобы узнать, как превратить относительность в абсолют.

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

В статье разбираю практический подход causal impact для случая, когда у нас есть одна метрика во времени и понятная дата изменения. Строим контрфакт (counterfactual) - прогноз того, какой была бы метрика без релиза - и сравниваем его с фактом. На этой основе считаем эффект в абсолютных значениях, накопленный эффект и относительный вклад в процентах.

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

Материал ориентирован на продуктовые задачи: когда релиз уже сделан, данные есть, а надежной оценки эффекта нет. В следующей части перейдем к более частому сценарию, когда изменение затронуло не всех, и вместо одной линии метрики у нас появляется набор линий по группам (географии, сегменты, кластеры). Там разберем синтетический контроль и diff-in-diff и частые ошибки, которые встречаются в таких данных.