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

/tl;dr

Бизнесу нужны рубли и проценты, а не слова про «выявление требований». Аналитик не кодит и не продаёт — как доказать, что он вообще что-то даёт? Цифрами.

Минимум метрик: трудозатраты на требования, доработки после релиза, конверсия, средний чек, время отклика бизнеса, ROI аналитики. Начните с двух–трёх — трудозатраты, баги, конверсия. Остальное добавите позже.

Сравнивать только «было» и «стало»: один и тот же функционал до и после переделки с аналитиком (например, при смене API). Иначе «задачи разные», «сезон другой» — и ваши цифры списывают на совпадение.

Зафиксируйте базовый период, нормализуйте цифры (на релизы, команду, сложность), постройте тренд и переведите эффект в рубли. Один график «до/после» сильнее десяти слайдов про «мы поработали хорошо».

ИИ и инструменты тоже измеримы: путь от требований до ТЗ сократился вдвое — считайте экономию в часах и рублях на фичу. Подставьте свои цифры — получите конкретный финансовый эффект.

Метрики — не способ оправдаться, а способ показать вклад аналитика и улучшать процессы. Сначала измеряй, потом убеждай.

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

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

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

Сегодня мы расскажем о книге, которая учит не просто строить графики, а проектировать визуальные истории, способные увлечь аудиторию, будь то совет директоров или миллионы читателей онлайн. Это второе, полностью переработанное издание бестселлера «Искусство визуализации в бизнесе. Как представить сложную информацию простыми способами» от Натана Яу, автора культового блога FlowingData.

Большинство статей на Хабре про архитекторов написаны в жанре «как я туда попал и вам советую». Я расскажу, почему попадают не все, и кому лучше не пробовать. Ошибки в ожиданиях, самодиагностика, честный разбор.

Привет, Хабр! Меня зовут Никита Трофимов, я старший менеджер Цифрового консалтинга Т1. Мы провели исследование российского стартап-ландшафта и хотим поделиться тем, что нашли. Не столько самим инструментом (хотя о нём тоже расскажу), сколько конкретными данными и технологическими решениями, которые обнаружили в процессе.

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

«Данные закончились». «Архитектура исчерпана». «LLM упёрлись в потолок».

Звучит умно. Проблема? Это одномерное мышление.

Когда говорят «данные закончились» — имеют в виду текстовые данные для supervised pre-training. Это правда. Но это одна ось из шести, по которым модели становятся умнее.

Inference-time compute (o1/o3), algorithmic efficiency (Mamba, MoE), мультимодальность, tool use, RL и self-play — пять осей, о которых забывают, когда хоронят AI.

В 2020 году консенсус был: GPT-3 — потолок. В 2022: нужны триллионы токенов для каждого улучшения. В 2023: reasoning невозможен без symbolic AI.

Все эти «потолки» были пробиты.

Даю ментальную модель, которая позволит не попадаться на ложные прогнозы о «смерти AI» — и задавать правильные вопросы, когда кто-то уверенно предсказывает будущее.

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

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

Статья получилась большая, поэтому можно сразу сориентироваться по плану:

●      предпосылки и типичные проблемы в командах аналитиков;

●      подготовка к делегированию или масштабированию задач;

●      шаблоны для описания артефактов;

●      технология дизайна;

●      план внедрения технологии дизайна;

●      распределение артефактов по ролям в команде.

Хабр, всем привет! С вами Лиза Акманова, ведущий аналитик ГК «Юзтех».

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

C помощью Python опроверг идею о ветре как о символе революции в поэме Александра Блока "Двенадцать". Поэма начинается со слов про ветер, написана про революцию и где-то внутри строк прячет загадочного Христа.

У меня был выбор: полностью уйти в декрет и на время «выпасть» из профессии — или попробовать найти баланс между работой, материнством и жизнью. Идеального решения не существует, но мой путь оказался про возможность оставаться в профессии, развиваться и при этом не предавать свою роль матери.

А теперь к сути...

Самые интересные новости финансов и технологий в России и мире за неделю: Маск подумывает склеить SpaceX с Теслой или xAI, в России всем правительством спасают пекарню «Машенька», Хаби Лейм продал сам себе права на создание своих ИИ-двойников, акции производителя унитазов растут из-за AI, а также лудомания Виталика Бутерина на Polymarket.

Как не потеряться в сотнях графиков и найти реальные рычаги влияния на бизнес? В статье представлен подробный разбор Дерева метрик на примере FoodTech-сервиса (доставки еды). Мы уходим от простого мониторинга цифр к системной декомпозиции North Star Metric.

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

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

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

Такой метод позволяет сократить время проведения тестов на 30-50%, не жертвуя при этом достоверностью. Это способ сделать процесс проверки гипотез более гибким и быстрым, сохраняя безупречную математическую строгость в каждой точке принятия решения.

В январе 2026 года информационная служба Хабра выпустила 842 публикации (801 новость и пост, 8 лонгридов и 33 перевода). В текущем дайджесте представлены лучшие технические новости, переводы и лонгриды (отдельные большие публикации) инфослужбы Хабра, согласно оценкам пользователей.

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

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

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

Давайте разберемся, как сделать ее союзником, а не врагом.

Большие языковые модели, типа GPT, Claude, Gemini и другие ИИ-системы, поразили разработчиков своей способностью генерировать тексты, звучащие как человеческие. Однако, если вы когда-либо использовали ChatGPT или подобные инструменты, вероятно, они не раз уверенно говорили вам что-то совершенно неверное. Эти ошибки ИИ, часто называемые «галлюцинациями», варьируются от незначительных фактических ошибок до полных выдумок. Они могут быть забавными (например, ИИ изобретает вымышленный исторический факт) или представлять серьезную проблему (представьте, что ИИ-ассистент предлагает несуществующую функцию или чат-бот выдает медицинский совет, которого не существует).

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

Всем привет! Меня зовут Иван Логинов, я аналитик данных в команде антифрода в Авито. Антифрод — направление на стыке бизнеса, продуктовых команд, пользователей и юридических ограничений, где любое решение требует тонкого баланса. В статье разберу требования к антифрод-системам и шаги, которые помогают удерживать баланс между безопасностью, ростом и требованиями законодательства. Текст будет полезен аналитикам, разработчикам, которые работают с подобными системами, а также тем, кто только подступается к таким задачам.

Привет! Меня зовут Паша, я маркетинговый аналитик в Купере. В этой статье речь пойдет о проверке качества «каузальных» моделей. На примере такой модели, как Double Machine Learning разберемся, откуда вообще берутся «каузальные» предсказания, как понять, что им можно доверять, и что делать с фундаментальной проблемой «скрытых конфаундеров».

Некоторое время назад администрация платформы, номинально, ведомая проникновением ИИ во все сферы нашей жизни, предложила пользователям помочь Хабру идеями. Это предложение было оформлено в виде поста со ссылкой на опрос, который выяснял: нравится ли пользователю ИИ‑контент и что делать с ИИ‑контентом на Хабре?

Данное официальное сообщение администрации, однако, находится в некотором концептуальном противоречии с заметкой «Инфляция обратной связи» продукт‑менеджера Хабра в его публичном тг‑канале:
«Когда проект становится значимым, обратная связь теряет в цене: мнение одного человека плохо масштабируется на миллионы; отклики часто противоречат друг другу. Поэтому статьи в духе «5 идей как сделать Хабр лучше» всегда хорошо обсуждают, но пользу из них извлечь сложно»

Обдумывая это противоречие, мне стало интересно, когда именно Хабр превратился из маленькой деревушки, где староста знал каждого в лицо, в Олимп, с вершины которого ропот внизу не особо различим? Так как батарейки в моём Б3‑18М сели, я взял арифмометр «Феликс», бумагу, перьевую ручку и решил выписать некоторые числа, а затем кое‑что посчитать.

Но как это часто бывает, исследование привело туда, где сам вопрос уже не вполне имеет значение :)