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

Предыдущие две статьи сформулировали гипотезу: распределённое сообщество IT-специалистов может координироваться без иерархии, зарплат и венчурного капитала — если протокол взаимодействия спроектирован правильно. Гипотеза красивая. Но красота — не аргумент. Нужна верификация. Здесь — первая попытка её провести: агентная симуляция на 500 независимых прогонов, математические метрики и один неудобный результат, который требует решения.

Если вы только начинаете работать с требованиями, эта статья для вас.

Бизнес говорит на языке стратегических направлений. «Комплексная трансформация», «синергетический эффект», «актуализация векторов развития» — эти формулировки звучат весомо, но за ними не всегда видна конкретная задача. Как из таких фраз сформулировать понятные требования для разработки? В статье разбираем 6 типичных ловушек и даём конкретные вопросы, которые помогут услышать реальную задачу.

Хотите научиться предсказывать продажи, цены на недвижимость или спрос на товары, учитывая сразу несколько факторов? Вам поможет множественная регрессия.

В этой статье вы узнаете:

• Математическую основу множественной линейной регрессии – от уравнения гиперплоскости до метода наименьших квадратов;
• Разбор полного кода на Python с использованием scikit-learn на реальном датасете Advertising (200 наблюдений);
• Как интерпретировать коэффициенты модели;
• Сравнение с простой линейной регрессией – насколько лучше работает множественная модель;
• Расширение до полиномиальной регрессии, когда линейности недостаточно.

Видеонаблюдение умеет быть очень вежливым. Сначала оно тихо просит подключить еще пару камер. Потом добавить удаленный доступ. Потом аналитику. Потом второе рабочее место. Потом архив подольше. Потом мобильный просмотр. Потом облачное дублирование. А потом внезапно выясняется, что система, которую считали как “небольшую на 15 камер”, ведет себя как полноценная инфраструктура с десятками параллельных видеопотоков, конкуренцией за сеть, сервер, хранилище и внимание администратора.

Красивый средний MAPE не спасает, если однажды модель крупно промахнулась именно в тот момент, когда по прогнозу принимают решения. После этого бизнес перестаёт верить цифрам и начинает либо “на всякий случай” жечь миллиарды на промо, либо, наоборот, игнорирует сигнал и до последнего верит, что план выполнится сам.

В этой статье – сразу два пути: от простой Excel-сезонки, которая неожиданно обыграла Prophet и классику на длинном горизонте, к ансамблю на базе TSMixer и от наивной веры в средний MAPE – к нормальной системе оценки качества с rolling backtest, bias, EOM и деградацией по горизонту.

Это не лонгрид про ML ради ML, а история о том, как сделать прогноз рабочим инструментом бизнеса.

Всем привет! Это команда Яндекс Практикума. Недавно мы провели исследование рынка, чтобы узнать актуальные требования к джуниор СА. Для этого мы поговорили с нанимающими тимлидами и синьорами из крупных и средних компаний, проанализировали вакансии и опросили выпускников курса «Системный аналитик» — джунов, которые недавно проходили процесс найма.

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

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

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

Статья будет полезна аналитикам, которые только входят в чудесный мир разметки и не хотят набивать шишки и плодить события пачками :-)

Итак, в системе появилось требование: считать сроки не в календарных, а в рабочих днях. Что делать и на что обратить внимание?

В этой статье много примеров, вопросов и вариантов ответов на них, а также кратких рекомендаций по реализации и тестированию.

Расскажу, как я автоматизировала регулярную отправку графиков из BI в мессенджер.

Задача была довольно типичная: есть дашборд в redash, на который смотрят каждый день. Данные иногда приходят с задержками и нельзя быть уверенным, что в 9 утра все "доедет", плюс зайти руками и прокликать несколько разрезов это долго и неудобно, хочется сразу все видеть в мессенджере как только данные обновились.

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

Iceberg становится де-факто отраслевым стандартом при построении lakehouse в России. Для сравнения, на последней конференции smart-data, Iceberg по частоте упоминания уступает только Spark. Это значит, что уверенное владение механикой работы Iceberg становится обязательным навыком для инженеров данных и платформенных команд. Однако на практике большинство команд при внедрении ограничиваются базовыми возможностями, вроде создания таблиц, настройки партиционирования, настройки сompaction-процедур

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

В этой статье я разберу несколько неочевидных оптимизаций Iceberg таблиц.

В одной из предыдущих статей я описал, как простой Telegram-бот помогает с подбором и при этом экономит деньги банку. За прошедшие три года решение значительно эволюционировало, обросло новым функционалом, было масштабировано на многие подразделения банковского ИТ.

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

Привет, хабр! Решил поделиться с миром своим проектом, который делался в свободное время и был мне полезен на моей текущей работе. Ссылка на гитхаб https://github.com/simplepersonru/SimpleOntoDoc

Проект - генератор статического сайта документации для онтологической модели данных
Онтологическая модель данных — это способ формального описания предметной области, в основе которого лежат три главные вещи:

1. Классы (типы объектов, «сущности»).
2. Атрибуты (свойства этих классов).
3. Связи (отношения между классами).

Под катом:

+ Мотивация (зачем мне это нужно)
+ Как это выглядит (с опубликованным примером)
+ Как можно применить (зачем Вам это нужно)

AI дисклеймер - при написании статьи активно использовалась нейросеть головного мозга, будьте осторожны

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

Меня зовут Станислав Решетнев, я руковожу отделом разработки в компании Sape по направлению Link Building (инструменты для продвижения в поисковых системах). В этой статье хочу рассказать об оригинальном архитектурном решении, которое мы внедрили, чтобы пользовательский интерфейс всегда оставался актуальным.

Когда вы последний раз читали документацию размером более страницы А4 без привлечения LLM? Вопрос риторический.

Кажется пришло время вычеркнуть написание документации из списка тех. долга.

В статье я попытался переосмыслить саму идею документации для enterprise разработки, а также рассказать о практическом решении поднятого вопроса для любой системы на платформе 1С 8.3 и выше. 

Расскажем, как на наш взгляд не стоит писать функциональные требования для Технического Задания.

Напомним, что функциональные требования – это не 50% от общего объема всех требований к Системе, которые определяют 100+ % успеха разработки и реализации.

Итак, что точно не нужно делать.

Более 5 лет я работаю ClickHouse DBA и помогаю командам разработки и аналитики эффективно использовать ClickHouse. Неизменным помощником в этом мне служит хеш-функция cityHash64(). В данной статье мы поговорим в основном про оптимизацию SQL запросов с помощью хеш-функций. Вероятно, рассматриваемые приемы в той или иной степени актуальны не только для ClickHouse, но и для других баз данных, и могут быть полезны любому, кто пишет SQL запросы.

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

В российских проектах НСИ часто выходит далеко за рамки справочников и включает задачи MDM и Data Quality. Разбираемся, чем это отличается от классического RDM и к чему это приводит.

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

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

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

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

Код идеально отвечает на вопрос «как?», но в нем нет ответа на вопросы «зачем?», «для кого?», «почему?».  Без знания ответов на эти вопросы, любая доработка —  это гадание на кофейной гуще.

В этой статье проследим эволюцию: от Водопада к Agile, от Agile к Гибридам и Everything as Code.

Привет, Хабр!

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

В этой статье мы рассмотрим один из мощнейших инструментов ClickHouse — Materialized View.