В бэклоге может быть десятки аккуратно оформленных user stories — и несколько противоречий, которые сорвут спринт.
Покажем, как за 10 минут проверить требования с помощью ИИ, найти скрытые конфликты и получить конкретные варианты исправления до того, как разработчики начнут писать код.
Когда я первый раз пришёл на встречу со стейкхолдером в роли аналитика, я честно не знал с чего начать. Вопросы в голове были — но не в том порядке. Половину забыл по ходу. Вышел с ощущением что поговорили хорошо, но непонятно о чём.
Я поискал готовые шаблоны. Нашёл Excel-таблицы, PDF-чеклисты и десятки статей с советами. Ни одно из этого не открывалось быстро прямо на встрече и не помогало думать в реальном времени.
Поэтому я сделал BA Toolkit — набор интерактивных инструментов для структурирования BA-встреч. Открываешь в браузере, идёшь по шагам, фиксируешь всё на месте.
Три месяца спустя — три инструмента в продакшене, открытый код на GitHub и эта статья.
Привет, Хабр! Я Анастасия Глущенко, бизнес‑аналитик направления BI в компании «ДАР» (ГК «КОРУС Консалтинг»). Люблю красивый, сочный визуал, а также яркие и емкие метафоры — короче говоря, я та еще сказочница. В этой статье я расскажу о сказочных персонажах и ситуациях, которые встречаются на пути аналитика. Ведь всем знакома фраза «пойди туда — не знаю куда, принеси то — не знаю что»?
Всем привет, я Катя, развиваю Gramax. Мы часто говорим, что документация должна жить в одном ритме с продуктом. В этом кейсе как раз видно, что за этой фразой стоит на практике.
Команда CRM-платформы «Модус» от ИТ-холдинга Т1 переводит руководства пользователя и администратора из Confluence в Docs as Code. Задача — связать документацию с релизами продукта, сократить ручную сборку и сделать так, чтобы аналитики могли писать в Markdown без боли.
Подробно об этом мы поговорили с Екатериной, владельцем продукта «Модус», и Еленой, ведущим аналитиком, которая драйвила переход на новый процесс. В статье раскроем: что не работало в старой схеме, как команда выбирала инструмент, как прошел пилот и какого эффекта удалось добиться.
Привет! Это вторая статья из цикла о 6 базовых понятиях бизнес-анализа по BABOK.
В прошлой статье мы разобрали первое базовое понятие BABOK — Заинтересованные стороны (ЗСт) Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» / Хабр. Мы выяснили, что каждый проект начинается с вопроса «кто в игре?». Но как только мы собрали нужных людей в рабочую группу проекта, перед нами встает следующий, не менее критичный вызов: что на самом деле нужно бизнесу?
По данным исследований PMI (Pulse of the Profession, 2023), около 37% проектов терпят неудачу именно из-за неточно сформулированных требований, в основе которых лежит непонимание истинной потребности бизнеса. Иными словами, проблема системная и дорогостоящая.
Бизнес-аналитик может идеально собрать требования, разработчик написать код, а тестировщик протестировать его, но в итоге получится решение, которое не удовлетворяет ни одну из потребностей бизнеса. Чтобы не наступить на эти грабли, разберем второе базовое понятие BABOK в этой статье — Потребность (Need).
Всем привет! На связи снова Никита Таскин и Анастасия Ильина. Продолжаем тему о контроле доступа применительно к системным интерфейсам, и на этот раз речь пойдёт об API. Напомним, что первая часть была про авторизацию UI, и ознакомиться с ней можно здесь. У нас всё так же разбор контекста ABAC-авторизации для управления задачами команд разработки в Сфера.Задачи. В этот раз мы глубже окунёмся в архитектуру и спроектируем решения для разных по сложности вариантов атрибутного контроля. Также посмотрим на другой вариант применения нашего экспериментального подхода «постанализ юзкейсов».
Привет, Хабр!
На связи команда Дирекции автоматизации девелопмента ПИК — Маргарита Золотых и Ольга Абражевич. В этой статье нам хотелось бы обсудить, какие аналитики будут востребованы в реалиях 2026 года и как найти себя в профессии тем, кто вырос до позиции Senior. С одной стороны, однотипное описание требований и фиксация чужих решений аналитикам становятся неинтересными. С другой стороны, компаниям с приходом доступных ИИ-инструментов и в тренде на оптимизацию бюджетов такой посредник становится нужен все меньше.
Как же повысить свою выживаемость в корпоративном мире и найти для себя новые вызовы и мотивацию в работе? Поговорим об этом на примере аналитика, который перешел от роли сборщика требований к роли партнера, отвечающего за ценность технических решений в контексте бизнеса, а не просто их работоспособность.
Мы хотим показать это наглядно — на кейсе доработок систем при изменении ставки НДС, где аналитик уже не просто описывает принятые решения, но и сам инициирует задачу и ее обсуждения, сам предлагает реализацию благодаря глубокой погруженности в контекст бизнеса и текущее поведение систем.
Всем привет, меня зовут Катя, я развиваю Gramax. Уже несколько месяцев мы делаем ИИ-агента для работы с текстом и документацией, поэтому много смотрим на реальные кейсы в разных компаниях. Один из самых сильных принесли друзья из SellOut+. Они делают аналитические системы для фармы и FMCG, быстро пробуют новые подходы и в какой-то момент взяли первую версию функции агентов в Gramax.
Но самое интересное случилось не в нашем продукте как таковом. На реальном проекте команда собрала «второй мозг» из десятков встреч с заказчиком. А потом использовала его, чтобы восстановить требования, проверить спорные места и собрать цельную картину проекта поверх уже существующих задач, описаний и договоренностей.
Новички часто воспринимают математику и имитационное моделирование как две совершенно разные, никак не связанные между собой вещи. Возникает этакая отчуждённость. И это понятно: современное программное обеспечение позволяет закрывать глаза на разного рода «ненужные» тонкости – достаточно перетащить блок, нажать кнопку, и модель уже работает. Проблема в том, что именно из-за этого мы постепенно теряем понимание основ. Но то, что кажется сиюминутно бесполезным, может быть стратегически важным. Потому что сама возможность моделировать – генерировать случайность, описывать динамику, получать достоверные результаты – опирается на дифференциальные уравнения и вероятностные распределения.
Поэтому я считаю важным данной статьёй провести небольшой экскурс в мир нестрашной математики на примере самых востребованных распределений имитационного моделирования. Зная их и немного статистики, уже можно называть себя неплохим «модельером». Так давайте сделаем ещё один шаг к этому званию.
Как отличить инжениринг AI-систем от применения ИИ в разработке и почему coding agents в 2026 году требуют больше контроля, тестов и архитектурных границ
Как на собеседовании отличить системного аналитика, который учил REST по учебнику, от того, кто реально проектировал API?
В статье — три живых кейса из практики в FinTech и e‑commerce. Вы сможете проверить себя, увидите разбор популярных ошибок и узнаете, почему даже опытные инженеры спорят про PATCH и 409.
Самые интересные новости финансов и технологий в России и мире за неделю: MAX выпилили из AppStore, Трамп придумал новые тарифы, миллионы Гугл-комаров выпустят в США, Google и Цукерберг хотят продать много новых акций для строительства датацентров, а фондовый рынок и крипта падают дружно упали, как только Майкл Сейлор начал продавать биткоины.
В прошлых статьях мы разобрали, что такое цифровой двойник предприятия, а также механизм управления изменениями. Определили, как выстроить процесс изменения, чтобы изменения не привели к хаосу в ЦДП (Цифровом двойнике предприятия). Разобрали, что такое Задание на разработку, Релизный контейнер, Проект, и определили процессы для этих документов. Теперь приступим к рассмотрению того, каким образом необходимо реализовывать изменения в ЦДП.
Когда вокруг десяток микросервисов, документация устарела, а на согласование архитектурного решения есть два дня, обсуждение быстро погружается в детали и теряет общую картину.
На примере внедрения кэширования в API‑шлюз разберём, как системному аналитику применять C4-модель: пройти от границ системы до зон ответственности внутри сервиса, зафиксировать сценарии сбоев и сохранить архитектуру в виде кода.
В 2026 году уже не нужно гадать, человек писал GitHub-репозиторий или AI. Я сделал Chrome-расширение, которое оценивает репозиторий по прозрачным эвристикам: README, коммиты, структуру файлов и метаданные. Без нейросети, без чёрного ящика — только понятные правила и объяснимый вердикт.
В статье рассказываю, как появился детектор, почему просто “число AI-похожести” оказалось недостаточно, как я перешёл к профилям вроде “AI-код”, “AI-документация” и “код человека”, и какие сигналы реально помогают отличать vibe-coded репозиторий от ручной работы.
Любой аналитик знает, что самым надёжным способом проверки гипотез являются рандомизированные контролируемые эксперименты (RCT), или, как их называют в народе — A/B-тесты. На практике часто возникают ситуации, когда провести A/B-тест невозможно — в основном это происходит по этическим или техническим причинам. Однако бывают кейсы, когда рандомизация невозможна потому, что treatment-ом является определённое действие пользователя. Например, treatment-ом может быть оформление платной подписки или отмена бронирования на сервисе. Давайте назовём такой вид воздействия добровольным.
В русскоязычном пространстве, и в частности на Хабре, достаточно много статей, посвящённых таким методам Causal Inference, как DiD, PSM и Causal Impact. Тем не менее, к моему удивлению, практически нет статей, посвящённых методам на основе ортогонализации и regression adjustment, хотя, на мой взгляд, именно эти методы являются самыми удобными для оценки эффекта от добровольного treatment-а. Пришло время исправить это недоразумение и разобрать метод Double/Debiased Machine Learning (DML) и Partial Linear Regression для задач Causal Inference!
ИИ уже меняет разработку, поддержку, аналитику и офисную рутину. Но тезис “больше продуктивности, меньше людей” слишком удобный. На практике корпоративный ИИ часто не убирает расходы, а переносит их в токены, инфраструктуру, безопасность, интеграции, ревью, ошибки и зависимость от поставщиков.
Представьте: вы наконец посчитали, сколько денег утекает из дома через плохую теплоизоляцию. Пришли к владельцу с цифрой в 200 тысяч в год на отоплении. Он посмотрел, кивнул и сказал: «Ну окей, запишем в убытки».
Примерно так выглядит разговор про техдолг с бизнесом. Пока это «у нас легаси» – руководство кивает и говорит «разберитесь», а стоит принести конкретные рубли вообще тему закрывают. Парадокс в том, что цифра без плана погашения – это не аргумент, а счёт, и на счёт без понятного ROI у CFO всегда один ответ: списать и забыть.
Мы потратили какое-то время на то, чтобы разобраться, почему так происходит. В процессе нашли три методики, которыми на западе считают техдолг в деньгах – у каждой свои допущения, слепые пятна и сценарии, в которых она врёт. И отдельно поняли, что сама по себе цифра это только половина задачи. Вторая половина упаковка, без которой CFO скажет «спишем» при любой методике.
Об этом и поговорим.
На одной из ИТ конференций по бизнес-анализу я проводил мастер-класс «Моделируем IT архитектуру предприятия». Участники были разбиты на группы, и было дано одно из заданий из нашего Курса аналитика 1С:
Функциональный архитектор 1С — это не «аналитик посильнее» и не человек, который просто рисует красивые схемы. Это специалист, который держит в голове бизнес, ограничения платформы, логику процессов, риски внедрения и границы проекта.
Разбираемся, чем на самом деле занимается архитектор 1С, кому стоит идти в эту роль и почему на крупных проектах без него быстро начинается хаос.