Всем привет! В предыдущих двух статьях нашего цикла – шесть основ бизнес-анализа мы с вами разобрали первые два базовых понятия Бизнес-анализа – Заинтересованные стороны (Stakeholders) и Потребность (Need).  Мы выяснили, что аналитик начинает любой проект с определения «кто в игре» для создания рабочей группы проекта и первым делом «ставит диагноз», т.е. определяет истинную потребность заказчика. Но когда потребность сформулирована и решение найдено начинается самая недооценённая часть работы бизнес-аналитика. Потому что даже идеально спроектированное решение может провалиться, если не управлять тем, что происходит между «сейчас» и «потом» — то есть самим изменением.

По данным McKinsey & Company, около 70% инициатив по организационным изменениям не достигают поставленных целей. Причина почти всегда одна и та же: техническая часть выполнена, а человеческая — проигнорирована. Новая система работает, процесс описан, инструкции написаны. Но люди продолжают работать по-старому.

Чтобы не наступить на эти грабли, разберём третье базовое понятие BABOK — Изменение (Change).

Привет! Меня зовут Евгений, я работаю в БКС Мир инвестиций владельцем сервиса «Портфель».

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

Для клиента это обычный экран в приложении или личном кабинете. Открыл, посмотрел, что происходит с деньгами, принял какое‑то решение.

Но внутри компании за этим экраном стоит много всего. Backend‑сервисы, frontend, интеграции, биржевые данные, банковские продукты, сетевой путь, мониторинги, SLA, обращения клиентов в контактный центр, поддержка, аналитика, релизы и ожидания бизнеса.

На стыке всего этого и появляется роль Service Owner.

Привет! Это вторая статья из цикла о 6 базовых понятиях бизнес-анализа по BABOK.

В прошлой статье мы разобрали первое базовое понятие BABOK — Заинтересованные стороны (ЗСт) Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» / Хабр. Мы выяснили, что каждый проект начинается с вопроса «кто в игре?». Но как только мы собрали нужных людей в рабочую группу проекта, перед нами встает следующий, не менее критичный вызов: что на самом деле нужно бизнесу?

По данным исследований PMI (Pulse of the Profession, 2023), около 37% проектов терпят неудачу именно из-за неточно сформулированных требований, в основе которых лежит непонимание истинной потребности бизнеса. Иными словами, проблема системная и дорогостоящая.

Бизнес-аналитик может идеально собрать требования, разработчик написать код, а тестировщик протестировать его, но в итоге получится решение, которое не удовлетворяет ни одну из потребностей бизнеса. Чтобы не наступить на эти грабли, разберем второе базовое понятие BABOK в этой статье — Потребность (Need).

Меня зовут Пелых Виталий, я корпоративный архитектор в «БКС Финтех». Разберу тему, которая звучит просто, но в крупных организациях регулярно «выстреливает» в неожиданных местах: как позиционировать архитектуру так, чтобы она помогала бизнесу и командам, а не превращалась в формальность или «бутылочное горлышко».

Сразу зафиксирую рамку. Под «позиционированием» я понимаю не место на оргсхеме, а то, как устроены правила принятия решений, кто за что отвечает и как мы удерживаем целостность ландшафта, не превращая архитектуру в узкое горлышко. По сути это про архитектурную способность (architecture capability) и архитектурное управление (architecture governance), встроенные в повседневный delivery.

Финтех — среда, где изменения идут непрерывно: продукты, регуляторка, каналы, интеграции. Поэтому архитектура здесь либо помогает меняться быстро и управляемо, либо становится тормозом и источником рисков. Дальше — как это устроено у нас: continuous architecture, около 75% архитектурных решений в командах, корпоративная архитектура как ограничение и контроль. И где у такого подхода границы и риски.

Меня зовут Даниил, я Android-разработчик в «БКС Мир инвестиций».

В первой статье мой коллега рассказывал, как мы использовали Kotlin IR Compiler Plugin, чтобы автоматически добавлять testTag и semantics в Compose-компоненты: Kotlin IR Compiler Plugin в дизайн-системе: автотесты с Compose без ручной разметки.

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

Kubernetes-операторы стали краеугольным камнем современного управления инфраструктурой. Операторы автоматизируют сложные жизненные циклы — развертывание, конфигурацию, масштабирование, резервное копирование и восстановление.

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

Данная статья рассматривает практические аспекты развёртывания Kubernetes-операторов в корпоративных условиях, уделяя особое внимание трём ключевым направлениям: механизмы информационной безопасности, проектирование процесса развёртывания и реализация шлюзов согласования.

Меня зовут Максим, я Android-разработчик в команде дизайн-системы «БКС Мир инвестиций». В 2025 году у нас шёл большой редизайн: компонентная библиотека росла, команды подключали новые Compose компоненты, а вместе с этим быстро рос и объём UI-тестов.

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

Эта статья про то, как мы решили задачу через Kotlin IR Compiler Plugin. Снаружи решение выглядит почти незаметно: разработчик ставит одну аннотацию, а на этапе компиляции компонент автоматически получает стабильный testTag и тестовые semantics, собранные из его state. В результате у команды стало меньше бойлерплейта в компонентах, меньше риска рассинхронизации между state и тестами, а экранные UI-тесты получили более устойчивый контракт работы с дизайн-системой.

Если бизнес-анализ — это искусство превращать потребность заказчика в приносящее ценность решение то его основа — не методологии и не инструменты, а 6 базовых понятий, заложенных в BABOK (Business Analysis Body of Knowledge).

Именно поэтому мы запускаем цикл статей — «Шесть основ бизнес-анализа». В данных статьях мы разберем каждое из 6 базовых понятий отдельно: дадим определение, разберем типовые ловушки, рабочие техники, примеры «из жизни» и то, как применять BABOK прагматично, а не «по учебнику».

Я — Станислав Харьков, руководитель управления бизнес-анализа компании «БКС Мир инвестиций», и на собственном опыте знаю, насколько критично не упустить ключевых участников на ранних этапах. Поэтому начнём с понятия, которое чаще всего «ломает» проекты ещё до формулирования требований: заинтересованные стороны (ЗСт) или стейкхолдер.

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

Меня зовут Гайнутдинов Роман, я старший инженер по автоматизированному тестированию в компании «БКС Мир инвестиций». За плечами построение автоматизации с нуля, поддержка готовых решений и оптимизация уже раздутых регрессионных наборов.

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

Привет! Меня зовут Потешина Елена, я старший UX‑исследователь геймификации в «БКС Мир инвестиций». С января лидирую исследования в 3 продуктовых командах, основная — Геймификация

Я часто в своей практике сталкивалась с тем, что исследования воспринимались командами как «опция». Их можно не делать вовсе или, что еще хуже, сделать «для галочки».

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

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

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

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

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

Каждый UX-исследователь в своей жизни сталкивался со сложностями при наборе статистически  значимого количества участников в опросах: кто-то не проходит дальше первого вопроса, кто-то бросает на полпути. Может ли исследователь повлиять на конверсию прохождения опроса? Наш ответ — да!
В данной статье мы поделимся итогами регрессионного анализа и дадим лайфхаки по составлению опроса на основе такой модели.

Всем привет! Меня зовут Алексей Пронский, я отвечаю за архитектуру в AI-департаменте группы компаний БКС. Мы строим агентные системы, AI-ассистентов, OCR-системы, речевую аналитику и Classic ML модели. Поскольку мы работаем по принципам enterprise разработки, за каждым таким проектом стоит архитектурное решение (далее — арх.решение) — документ, который проходит согласование с бизнесом, корпоративной архитектурой, ИБ и владельцами смежных систем. Арх. решения мы ведём в Confluence, диаграммы рисуем в Draw.io. Типичный цикл от получения бизнес-требований до согласованного арх.решения в среднем занимает две-три недели.

За последний год LLM-ассистенты произвели настоящую революцию в написании кода. В этой статье я покажу, как добиться такого же эффекта в архитектуре — перейти на подход Architecture as Code и передать рутину LLM. Мы используем Structurizr для описания архитектуры и Claude Code как LLM-ассистента. Буду показывать примеры на их основе, демо-репозиторий можно будет посмотреть на GitHub.

Всем привет, меня зовут Двенадцатова Таня. Я руководитель команды исследователей в «БКС Мир инвестиций». Почти 2 года назад у нас в БКС появились Прожарки. Это мероприятие придумала не я. Более того, его концепция и идея мне изначально не нравились и не были на 100% понятны. Встреча называлась дерзко «Поясни за UX», и явка для всей команды исследователей на нее была строго обязательной.

Как «Поясни за UX» превратилось в Прожарку, зачем мы стали собираться и что обсуждать, а также как Прожарка стала регулярным и востребованным ритуалом, я и поделюсь в этой статье. Возможно, такую практику задумаетесь внедрить и вы, а возможно она у вас и так есть (просто называется иначе), но вы сможете подсмотреть что-то из моих лайфхаков.

Всем привет! Меня зовут Ульяна Айкович, я исследователь. И мы продолжаем цикл статей в блоге от продуктовой команды «БКС Мир инвестиций». Сегодня я расскажу, как мы можем глубже анализировать время выполнения заданий, а также, как измерить группы респондентов в немодерируемых UX-тестах. В данной статье я разберу не только медиану и процентили для оценки времени, но и критерий Манна–Уитни — простой способ статистически сравнить две группы респондентов.

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

Всем привет! На связи Ульяна Айкович и Даниил Гурин — исследователи «БКС Мир инвестиций». Сегодня мы хотим поделиться результатами нашего небольшого, но довольно смелого эксперимента — попытки предсказать конверсию в прохождение опросов.

Каждый исследователь знает, как трудно удержать внимание респондентов. Особенно в опросах. Один лишний вопрос, одна лишняя картинка в анкете или лишняя минута времени для заполнения опроса — и человек закрывает вкладку. А ведь каждый ответ на вес золота. Поэтому мы решили разобраться: что именно определяет, дойдет ли человек до конца опроса или бросит его на полпути? Можем ли мы заранее это предсказать?

В статье более подробно рассказали о первой итерации нашего эксперимента!

На связи Ульяна Айкович, UX-исследователь и адепт статистики из БКС Мир Инвестиций. Сегодня я расскажу, в каких случаях применять статистические тесты, как легко реализовать их в гугл-таблицах, а также, как интерпретировать результат этих тестов. Не бойтесь, будет много практики и совсем немного важной теории.

В статье детально расскажем, как и когда применять биноминальный и χ²-тесты на наших кейсах.

Привет! Я Даня Платонов - руководитель группы UX-исследований в «БКС Мир инвестиций». Это первая статья нашей команды, мы начинаем делиться интересным и познавательным из нашей работы. И начать я хочу с самых начал. А именно — с вопроса «кто я?», который каждому продуктовому исследователю не лишне себе иногда задавать.

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

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

Давайте сначала представимся. Мы - команда управления тестирования и контроля качества в БКС Мир Инвестиций. Наш продукт - это приложения и сайты, созданные для удобства всех желающих окунуться в мир ценных бумаг и инвестиций. Конкретно в нашем “ведомстве” приложения на IOS  и Android, сайт личного кабинета, инвест стратегии Fintarget, новостной портал BCS-Express, сайт ФГ БКС и прочее.

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

Конечно же, автоматизация наших процессов важна, ведь без этого невозможно построение действительно сильного QA отдела. Безусловно, мы встретились с множеством разнообразных проблем.

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

Начать эти рассказы мы решили с повести о становлении мобильного автотестирования. Первым “попался под руку” Android, про него и начнем.

Уже три года, как мы постепенно передаем солюшн-архитектуру в команды разработки. Приходится часто объяснять, как сделать архитектурное решение коллегам, которые раньше подобными вещами не занимались. Отсюда родилась идея этой статьи – поделиться опытом, который сложился у меня и моих коллег за 10 лет практики. Важная часть этого опыта – шаблон архитектурного решения с пояснениями как его заполнять и почему именно так. По сути, шаблон - это структура необходимых знаний. Если вы нашли ответы на все вопросы шаблона, значит вы продуманно подошли к созданию архитектуры. А еще, сделали хороший документ, с которым удобно работать.

Статья расскажет, как правильно оформить ваши мысли, и что должно содержать качественное архитектурное решение. Статья не научит делать архитектуру.

Статья будет полезна:

• Аналитикам, тимлидам, программистам, которые уже делают или собираются делать архитектурные решения;

• Архитекторам, чтобы улучшить качество выпускаемых документов;

• Главным архитекторам с целью посмотреть «а как там у них».