Меня зовут Андрей Рыжик, я product owner BI-направления в компании «Белый код». Это шестая статья из серии, в которой мы изучаем российские BI-системы с поддержкой ETL для клиентов из малого и среднего бизнеса с бюджетом 1,5-2 млн рублей. Сегодня разбираем «Форсайт. Аналитическую платформу» – один из старейших российских BI-продуктов класса Enterprise.
В какой‑то момент мы столкнулись с ситуацией, когда качество входящих требований от бизнеса заметно просело. Это произошло не из‑за одной причины, а из‑за сочетания факторов: изменения в командах, большое количество новых сотрудников, постоянные регуляторные изменения и, как следствие, отсутствие времени на полноценный онбординг. В быстро меняющейся среде это довольно типичная история, когда процессы не успевают адаптироваться с той же скоростью, с которой меняется сама организация.
Для функции бизнес‑анализа такие изменения особенно чувствительны. Когда требования приходят сырыми, аналитики начинают тратить время не на проработку решений, а на базовую подготовку материала к работе: уточнение целей, сбор контекста, определение границ задачи, фиксацию сценариев и устранение противоречий.
Когда аналитика превращается в расшифровку задач
Именно это и начало происходить у нас. На вход от бизнеса мы всё чаще получали не требования, а скорее описание идеи и иногда перспективной, масштабной, но слабо структурированной. Такие запросы могли звучать примерно так: «Нужно улучшить уведомления», «Пользователи где‑то отваливаются, надо исправить», «Давайте попробуем новый оффер», «Нужно что‑то поменять в процессе». Иногда это выглядело еще проще: «Нужна интеграция с новой системой, документация во вложении» или «Нужно запустить новый эксперимент на сайте».
Формально задача есть. По факту нет ни границ, ни сценария, ни критериев успеха, ни понимания того, что именно требуется реализовать.
Мы увидели проблему одними из первых, потому что именно на нашей стороне накапливалась вся неопределенность входящих задач. Значительная часть времени начала уходить не на анализ и проработку решений, а на приведение запросов в рабочий вид. Вместо содержательной аналитики команда всё чаще занималась расшифровкой задач: проводила встречи, собирала контекст по кускам, искала связанные процессы, изучала вложения и пыталась превратить сырую идею в понятный запрос для дальнейшей работы.
Хабравчане, всех рада приветствовать! Меня зовут Акманова Елизавета, я ведущий аналитик ГК «Юзтех». В своих статьях я стараюсь затрагивать темы, которые считаю важными, и обязательно с опорой на личный практический опыт.
Признаюсь, к этой статье я шла долго и это волнительно для меня. Вот почему.
ДИСКЛЕЙМЕР
Данная статья отражает личный опыт автора и не претендует на статус эталонного или единственно верного решения. Некоторые моменты могут вызывать несогласие или внутреннее сопротивление, это совершенно нормально. Я описываю конкретную ситуацию, сложившуюся в моей команде в рамках одного проекта. Это довольно специфический кейс, который не обязательно окажется применим в других условиях. Однако для нас он оказался полезным, и я не утверждаю, что так должно быть у всех. Моя цель — просто показать один из возможных вариантов развития событий. Возможно, наше решение совсем не идеально и не безупречно, но оно помогло нам улучшить ситуацию. Поэтому, пожалуйста, не торопитесь с критикой, будет здорово, если просто поддержите.
Надеюсь, это небольшое предисловие поможет настроиться на нужный лад.
Из названия статьи, уже понятно: мы дошли до того, что аналитики начали заниматься нагрузочным тестированием. Более того, они проводят его на этапе обследования, когда ещё не написано ни одной строки кода. О том, как мы к этому пришли, почему эту роль взяли на себя именно аналитики и какие инструменты нам помогают, я и расскажу.
Когда классические SQL‑базы падают под аналитической нагрузкой, а Hadoop‑кластер напоминает чемодан без ручки — пора искать новое решение.
В этой статье разбираем, как ClickHouse в связке с NoSQL‑экосистемой закрывает бреши в высоконагруженных проектах. Разберём архитектурные ловушки, Best Practices и честно оценим, где этот инструмент экономит миллионы, а где может создать проблемы.
Меня зовут Сергей Москалев, я основатель небольшой студии. Мы делаем сайты, приложения и дизайн. Команда — восемь человек: четверо разработчиков, проджект-менеджер, тестировщик, дизайнер и я. Год назад мы оказались в точке, которую многие владельцы аутсорс- и продакшн-студий, думаю, узнают с полувзгляда.
За год мы не выросли вообще. Совсем.
Современные S3-хранилища давно перестали быть «черным ящиком»: от их архитектуры напрямую зависят отказоустойчивость, производительность и экономика сервисов, которые на них опираются. Но за внешне простым API скрывается интересная, сложная, промышленная система — от железа в стойках до многослойного распределенного приложения.
В этой статье разберем, как устроено промышленное объектное хранилище на практике: какие архитектурные решения лежат в основе, как достигается масштабируемость и где проходят реальные технические компромиссы.
Меня зовут Александр Гришин, я руковожу направлением хранения и обработки данных в Selectel. Отвечаю за развитие облачных баз данных, S3-хранилища, аппаратных СХД и сервисов для построения DLH. Материал будет полезен CTO, CIO и архитекторам, которые выбирают или проектируют собственное S3-совместимое хранилище. Или инженерам которые хотят просто лучше понимать, что же происходит у нашего сервиса под капотом.
Я, Ирина Чекулаева, обожаю BI и с удовольствием разоблачаю мифы и ищу ошибки в системах бизнес‑аналитики.
Здесь хочу порассуждать на тему CRM аналитики по результатам реального проекта. Чем дальше, тем очевиднее становится один парадокс, что CRM фиксирует звонки, письма, сделки, статусы, но она не отвечает на главный вопрос: почему продажи происходят или не происходят.
Сегодня у компаний данных больше, чем когда‑либо. Проблема уже не в их отсутствии, а в том, что они не собираются в управляемую картину. Метрики существуют, отчёты строятся, дашборды обновляются, при этом контекст бизнес‑ситуации теряется.
В итоге СЕО компании управляет не системой, а её отражением в отчётах. Или просто вынужден доверять собственным ощущениям. Продавцы активны, лиды поступают, сделки двигаются по воронке, и формально всё выглядит корректно. Но в конце месяца происходит знакомая ситуация: план не выполняется, прогнозы не сходятся, а объяснения звучат одинаково — «не дожали», «почти закрыли», «в следующем месяце точно догоним».
С похожей ситуацией столкнулся собственник небольшой консалтинговой компании. Вроде бы все учитывается и под контролем, при этом на уровне управления остались без ответа базовые вопросы:
• где теряются сделки;
• сколько времени они проводят на этапах;
• какая часть воронки реально конвертирует, а какая существует формально.
В момент, когда уходит руководитель отдела продаж, это становится критичным — вместе с ним исчезает «интерпретатор данных».
Почему обычная воронка — уже недостаточна, но ещё нужна
Самые интересные новости финансов и технологий в России и мире за неделю: заявка на новую пандемию, кибердружины из студентов, национализация Русагро, параллельный импорт заменят на отечественные компы, Пентагон публикует фотки НЛО, срок португальских гражданств удлинили, а также альтманофон от OpenAI.
Navisworks хорошо находит BIM‑коллизии, а Revit — инструмент для исправления. Но между ними часто остаётся хаос: XML и HTML‑отчёты, Excel, переписки, ручной поиск ID и вопросы руководителей в стиле «ну как там с коллизиями?».
Я расскажу, как из этой боли вырос внутренний web‑сервис Clash Analytics: импорт XML‑отчётов Navisworks, аналитика по проектам, история коллизий, статусы, комментарии, назначение отделам и локальный Revit Bridge, который открывает проблемное место в модели за один клик.
У нас было 2 телефонии от разных вендоров, одна речевая аналитика и 300 тысяч звонков в месяц. И задача: сделать сквозную аналитику по звонкам сотрудников.
Привет! Я Никита, инженер системного проектирования в компании Передовые Платежные Решения. Расскажу, как мы использовали единый идентификатор через службу каталогов Active Directory (AD), и стали точно определять, кому из сотрудников принадлежит звонок. Независимо от того, из какой телефонии он исходит.
Наш опыт может быть полезен архитекторам, инженерам и техническим лидерам команд, которым предстоит интеграция разнородных систем телефонии.
Обычно те, кто выбирает направление разработки в IT, идут учить Python, Java или JavaScript. 1С в этот список не попадает: платформа и профессия, связанные с ней, часто воспринимаются менее «модными», хотя по сложности и масштабу задач это не всегда справедливо.
Но в 2026 году есть несколько обстоятельств, которые влияют на восприятие 1С. На российском рынке у 1С очень сильные позиции, особенно в учёте и ERP (Enterprise Resource Planning — система планирования ресурсов предприятия). Зарплаты 1С-специалистов в 2025–2026 годах заметно выросли, а на уровнях мидл и сеньор они стали сопоставимы с доходами в других популярных IT-направлениях.
В этой статье мы делаем честный обзор того, как сегодня обстоят дела в 1С-разработке, какие преимущества и недостатки есть у этого направления и стоит ли учиться на программиста 1С.
Ракету не отправляют в космос только потому, что её двигатель и насос успешно прошли стендовые испытания по отдельности. Перед стартом инженеры рассчитывают траекторию, моделируют режимы работы и анализируют сценарии отказов. Расчёт не заменяет реальные тесты, но задаёт для них осмысленную рамку.
В софте всё обычно иначе. Распределённый пользовательский путь — например, оформление заказа — собирается из десятков микросервисов, баз и очередей. Разработчики добавляют новую зависимость, видят зелёные тесты, проверяют локальные метрики и выкатывают релиз. Считается, что если при сбое что-то пойдёт не так, настроенная система наблюдаемости обязательно это покажет.
Она, конечно, покажет. Но почему при проектировании микросервисов мы так спокойно относимся к тому, что узнаём о хрупкости архитектуры в основном по факту инцидента?
Эта статья о том, как получить грубый расчёт деградации системы ещё до релиза. Без отказа от хаос-инжиниринга или мониторинга, а как шаг перед ними. Я расскажу о двух экспериментах, в которых топологическая модель автоматически извлекалась из распределённых трейсов, после чего на ней просчитывались сценарии отказов методом Монте-Карло. Результаты моделирования я затем сравнивал с реальными инъекциями отказов на стендах DeathStarBench и OpenTelemetry Demo.
Представьте: ваш первый день в офисе, вам дали доступы ко всем 15 репозиториям проекта, рассказали где что лежит, и теперь ждут от вас великих дел. Тем временем вы едва можете вспомнить, какой карточкой открывается этаж и где стоит кофемашина.
Добро пожаловать в 50% IT-компаний во вторую статью цикла про онбординг в сложную систему!
В этой статье превратим плоский список репозиториев в рабочую onboarding-map: сначала определить роли, потом соберем dependency matrix, а затем получим relationship diagram.
Привет, Хабр! На связи Илья Амосов из команды поддержки Lakehouse-платформы данных Data Ocean Nova вендора Data Sapience. В сегодняшней публикации я раскрою тему влияния динамического сокрытия чувствительных данных на производительность SQL-запросов. Мы сравним различные методики маскирования, узнаем, как работает оптимизатор и движок со скрытыми полями, происходит ли деградация пропускной способности платформы, как влияет на производительность выбранный метод сокрытия чувствительных данных в случаях, если вы используете компонент на базе Apache Ranger.
Почему Agile‑команды скатываются в неконтролируемый хаос, а проекты на Waterfall годами пилят никому не нужный продукт? Спойлер: проблема не в методологиях, а в нас самих. Вы узнаете, как сильные команды совмещают лучшие практики обоих миров, почему Contract‑First и Trunk‑based Development спасают даже в Agile.
В работе аналитика данные часто говорят одно, интуиция — другое, а неопределенность сопровождает на каждом шагу. Важно уметь применять ее в свою пользу и не бояться.
В этой статье хочу поделиться, как работать с неопределенностью: какие у нее есть виды, как она обманывает мозг и какие есть способы сделать ее понятнее.
Привет, Хабр! Я Ирина Хабенская, руководитель направления аналитики в Авито. Хочу поделиться прикладными пошаговыми советами по развитию ключевых софт-скиллов. Статья будет полезна мидл-аналитикам, которые хотят дорасти до синьора.
Часто я сталкиваюсь с таким запросом от ребят-мидлов: «харды уже ого-го, но лычки синьора почему-то не дают». На основании своего опыта я хочу поделиться в этой статье наиболее распространёнными софтовыми навыками, которых и не хватает сильному мидл-аналитику, чтобы сделать последний рывок до синьорства.
Я также часто рассказывала этот материал и встречала комментарии уровня «Да, чертовски полезно, со всем согласен!», но также в глазах аналитиков читалось «А делать-то что?». Поэтому я добавила в статью прикладные пошаговые советы, которые помогут не просто получить полезную информацию «на подумать», но и начать реально расти.
Всем привет! Меня зовут Владимир Зуев, я руководитель разработки JAVA-практики в компании Axenix. Сегодня я хочу рассказать о нотации ArchiMate, используемой для разработки и моделирования информационных систем. Несмотря на свои уникальные возможности, нотация ArchiMate не получила широкого распространения. Даже среди практикующих архитекторов распространенность нотации не превышает 25%. Отчасти это связано со скудным описанием в официальной документации и отсутствием практических руководств. Я хочу исправить эту ужасную несправедливость и показать сильные стороны ArchiMate, подробно разобрав ее использование на практическом примере, а так же показать как применение ИИ может помочь архитектору.
Идея этого продукта родилась дома. Моя жена работает врачом в клинике Фомина (известная московская клиника), и однажды она рассказала мне вещь, к которой я был не готов: российские клинические рекомендации (КР) в среднем отстают от международных гайдлайнов на два года. Это не просто задержка во времени — это отставание в методиках, дозировках и качестве ухода за пациентом.
И дотянуться до свежих международных гайдов российскому врачу сейчас почти негде: UpToDate отрезан, обходы через зарубежные SIM-карты прикрыли (разве что опытные айтишники знают пути обхода), Notion ушёл — а вместе с ним разлетелись по чатам и заметкам рабочие шаблоны, которые врачи годами в нём вели.
Когда жена это рассказала, мы взяли тему в работу как обычную задачу: гипотеза, интервью с врачами, валидация, MVP на нашей платформе. Так получился МедБро — бесплатный справочник, который рядом с международной рекомендацией сразу показывает соответствующую позицию из российского КР. Работает на medbro.pro, есть Android-сборка, iOS на модерации App Store. Сейчас продукт в режиме альфа-тестирования: загружено около 80 гайдлайнов, к 30 мая планируем закрыть основные специальности и выкатить личный кабинет врача с закладками.
В статье разберу четыре конкретные боли врача, ту самую функцию, ради которой во многом и затевался продукт, и то, как мы построили под неё граф клинических знаний.
Как вы знаете, мы в Humathèq помогаем создавать новые продукты, а каждый наш проект стартует с погружения в ассортиментную матрицу клиента, чтобы найти в ней место для этого продукта.
С каждым погружением мы видим, что практически все исследуемые матрицы похожи на одну из 8 метафор: