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

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

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

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

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

Всем привет! Заключительная часть о требованиях, которые вспоминают в последний день перед релизом.

В первой части мы говорили о производительности и масштабируемости, во второй — о сопровождаемости, надёжности и безопасности.

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

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

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

В данной работе представлен комплексный анализ звёздного населения Млечного Пути на основе данных миссии Gaia DR3. Рассматриваются методы массовой выгрузки и обработки десятков миллионов астрономических объектов с использованием распределённой архитектуры Map/Reduce. Построены ключевые распределения: расстояния, фотометрические величины (G, BP, RP), собственные движения, HR‑диаграмма, а также карта небесной сферы. Проведен анализ погрешностей измерений и выявлены наблюдательные и селекционные эффекты.

Привет, Хабр! Это вторая статья про BPMN, в которой мы переходим от теории к практике.

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

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

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

Где-то с месяц я вынашиваю план исследования, с помощью которого хочу оценить эффект практики заметковедения на профессиональную и личную деятельность человека. И каждый раз, как я подходил к этому «снаряду», люди, чье мнение имеет значение, задавали мне вопрос: а что такое заметковедение?

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

Каждый человек, когда я интересовался у него относительно того, как он ведет свои личные и профессиональные записи, отвечая, описывал технические особенности приложений и сервисов, или начинал душнить[^1], или говорил, что он записывает в приложении и «потом» разбирает, без уточнения, что значит «разбирает» и когда это «потом» наступает.

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

В какой-то момент мне подсказали, что можно сделать, а именно объяснили, как операционализировать понятие «заметковедение», спросив, что люди делают, когда им приходит идея, попросив описать то, как они «потом» разбирают свои записи, и что происходит при процессе «вдумчивого» обучения.

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

Внедряя системы класса Business Intelligence (BI), приходилось в проектах разрабатывать систему показателей для различных бизнес-процессов. Почему пришлось создать данный подход? Потому что представители заказчика часто не могли сформулировать перечень ожидаемых показателей по процессу, и поэтому пришлось проектировать систему показателей для анализа процесса за них. Подробнее про показатели процессов и основные определения (бизнес-объект, метрика, аналитический разрез и показатель) можно прочитать в моей ленте ранее. В данной статье хочу «спуститься» от системы показателей по процессу к структуре данных на примере процесса подготовки коммерческого предложения.

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

Финансовые рынки редко движутся изолированно. Криптовалюты реагируют на фондовые индексы, золото реагирует на макроэкономику, а внутри крипторынка движение биткоина задаёт направление для альткоинов.

Гипотеза проекта:

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

Привет! Меня зовут Маша, я продакт ITSM 365 в Naumen. Более 8 лет я работаю в ИТ: начинала как бизнес‑аналитик, затем стала продуктовым аналитиком, позже — менеджером продукта. Сейчас занимаюсь Discovery — исследую новые области, где наши решения могут принести бизнесу пользу.

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

UUIDv4 как первичный ключ в PostgreSQL обычно ругают за «случайность» — но за этим словом прячется конкретная физика: сплиты страниц B-дерева, рыхлый листовой уровень, фрагментация и лишний случайный I/O при чтении. В PostgreSQL 18 появился UUIDv7 — и это хороший повод посмотреть на проблему не на уровне вкусов, а на уровне того, как реально устроены индекс и heap: от корреляции и ctid до статистики страниц и плотности листьев.

Самые интересные новости финансов и технологий в России и мире за неделю: тульскую бабулю собираются посадить за неудачный ларисодолинг, ЦБ РФ снизил ставку до 16%, ЕС не решился трогать российские активы, iRobo-пылесосы обанкротились, в США дропнули файлы Эпштейна, запрет лотереи гринкарт, китайские миллиардеры суррогатно рожают себе армии детей, а также еще одна сделка OpenAI.

Какие навыки реально нужны в IT? Разбор рынка по данным hh.ru. Мы обработали 393 000 вакансий за 2025 год и делимся результатами: универсальный стек технологий, медианные зарплаты по специальностям и доля удаленки. А еще — техническая реализация нашего open-source проекта для сбора данных.

В классическом алготрейдинге рынок часто моделируется как временной ряд: индикаторы, скользящие средние, осцилляторы. Аукционная теория рассматривает рынок иначе — как процесс распределения объёма по ценовым уровням, где цена ищет баланс между спросом и предложением.

Ключевым элементом такого подхода является Volume Profile, а именно Point of Control (POC) — уровень цены, на котором за выбранный период был проторгован максимальный объём. В терминах аукционной теории POC соответствует зоне максимального согласия участников рынка.

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

В августе 2023 года вступил в силу закон «О развитии технологических компаний в РФ», который ввёл новую категорию — «малая технологическая компания» (МТК). Под неё могут подпасть как заводы, так и ИТ-компании, создающие продукты и технологии, критически важные для обеспечения технологического суверенитета. Уже к концу 2025 года статус МТК получили более 6,4 тысяч организаций.

Наша компания занимается аналитикой для промышленности, и мы формируем большие массивы данных из открытых источников. Нам показалось интересным провести исследование именно на примере заводов, производящих электронику, специальное оборудование, новые материалы, чтобы понять: 1) какие меры поддержки работают на практике; 2) даёт ли статус МТК реальные конкурентные преимущества промышленности.

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

Проблема неприятная и распространённая. Она решается не просто и не быстро, но для построения устойчивого бизнеса в конкурентной среде решить её всё-таки придётся.

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

В чём, на мой взгляд, лежит корень этой проблемы?

Основной барьер для получения дивидендов от аналитической функции — это не просто культура принятия решений на данных (которую все пытаются описать модным и часто спекулятивным термином data-driven culture). Ключевая проблема — в системе взаимодействия, обратной связи и ответственности за результат, принятой в компании.

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

В продуктовой аналитике легко дойти до того момента, когда экспериментов много, а доверия к результатам все меньше и меньше: тесты закрывают “когда стало понятно”, p-value проверяют чуть ли не каждый день (принимая преждевременные решения), MDE забывают фиксировать, а денежные метрики зашумлены так, что выводы получаются, мягко говоря, спорные.

В этой статье я показываю практический каркас для более надежных A/B-тестов в B2C: как делать анализ мощности и размера выборки для конверсии и ARPU, как интерпретировать кривую мощности анализа теста и trade-off между MDE, длительностью и доступным трафиком, и почему ratio-метрики вроде выручки на сессию часто лучше голого ARPU.

Отдельно разбираю линеаризацию ratio-метрик: как привести их к user-level значениям, чтобы применять стандартные тесты корректнее и стабильнее.

Привет! Я Александр Моисеев, директор по аналитике Авито. Чтобы рост стал более прозрачным и предсказуемым, а оценка перформанса более объективной, мы пересобрали менеджерскую линейку и внедрили числовые грейды для менеджеров аналитики. В статье расскажу, зачем мы это сделали, как устроили новую линейку и что это дало сотрудникам и компании. Читайте мой небольшой обзор новой матрицы и забирайте наши практики себе в компанию — ссылка на матрицу компетенций в конце материала.