В какой-то момент мы столкнулись с ситуацией, когда качество входящих требований от бизнеса заметно просело. Это произошло не из-за одной причины, а из-за сочетания факторов: изменения в командах, большое количество новых сотрудников, постоянные регуляторные изменения и, как следствие, отсутствие времени на полноценный онбординг. В быстро меняющейся среде это довольно типичная история, когда процессы не успевают адаптироваться с той же скоростью, с которой меняется сама организация.
Для функции бизнес-анализа такие изменения особенно чувствительны. Когда требования приходят сырыми, аналитики начинают тратить время не на проработку решений, а на базовую подготовку материала к работе: уточнение целей, сбор контекста, определение границ задачи, фиксацию сценариев и устранение противоречий.
Когда аналитика превращается в расшифровку задач
Именно это и начало происходить у нас. На вход от бизнеса мы всё чаще получали не требования, а скорее описание идеи и иногда перспективной, масштабной, но слабо структурированной. Такие запросы могли звучать примерно так: “Нужно улучшить уведомления”, “Пользователи где-то отваливаются, надо исправить”, “Давайте попробуем новый оффер”, “Нужно что-то поменять в процессе”. Иногда это выглядело еще проще: “Нужна интеграция с новой системой, документация во вложении” или “Нужно запустить новый эксперимент на сайте”.
Формально задача есть. По факту нет ни границ, ни сценария, ни критериев успеха, ни понимания того, что именно требуется реализовать.
Мы увидели проблему одними из первых, потому что именно на нашей стороне накапливалась вся неопределенность входящих задач. Значительная часть времени начала уходить не на анализ и проработку решений, а на приведение запросов в рабочий вид. Вместо содержательной аналитики команда всё чаще занималась расшифровкой задач: проводила встречи, собирала контекст по кускам, искала связанные процессы, изучала вложения и пыталась превратить сырую идею в понятный запрос для дальнейшей работы.
В какой-то момент стало очевидно, что проблема не в отдельных задачах, а в самой модели входа. Если ничего не менять, нагрузка на функцию бизнес-анализа будет только расти вместе с потоком новых запросов.
Внедрили свой инструмент в привычном интерфейсе
Мы начали искать способ разгрузить аналитиков от этапа первичного прояснения запросов и решили использовать AI там, где он дает наибольший эффект, а именно в первичной проработке запросов, когда идея еще не стала полноценной задачей.
Так появился внутренний ассистент, задачей которого стала первичная структуризация бизнес-запросов до их передачи в работу. Инициатор описывает задачу в свободной форме, после чего система задаёт уточняющие вопросы, помогает определить цель, выделить сценарий, зафиксировать ограничения и собрать недостающие детали. На выходе получается не готовое техническое задание, а структурированный черновик требований, с которым бизнес-аналитик может сразу работать предметно.
С технической точки зрения решение оказалось гораздо менее сложным, чем может показаться. Мы не выводили пользователей в набор разрозненных внешних инструментов и не перекладывали на сотрудников задачу самостоятельно подбирать подходящий сервис. Вместо этого был создан единый внутренний интерфейс с ассистентом под конкретный сценарий работы. Пользователь работает в привычной среде, где заранее определены логика взаимодействия, структура результата, правила уточняющих вопросов, используемые модели и отдельные сценарии под разные типы задач.
Это важный момент, потому что разница между “дать доступ к инструменту” и “встроить его в конкретный процесс” на практике огромная. В первом случае всё быстро превращается в набор разрозненных экспериментов, а во втором становится частью рабочей системы.
Архитектура решения позволяет выбирать подключённые модели, как локальные (например, Gemma 4 и Qwen 3-6), так и внешние, в зависимости от задач.
Почему здесь не достаточно обычного чата
Мы довольно быстро поняли, что ценность дает не сама модель, а то, как она встроена в процесс бизнес-анализа. Универсальный чат склонен давать слишком общие ответы. Специализированный ассистент, напротив, работает предсказуемо и последовательно. В нашем случае он был настроен на аналитический контекст. Концентрировался на логике задачи, не уходил в технические детали и приводил запрос к понятной структуре: контекст, цель, сценарий, ограничения, критерии приемки, риски и пробелы.
Для типовых направлений были вынесены отдельные шаблоны. Например, для интеграционных задач использовалась заранее подготовленная структура требований: описание участников процесса, схема обмена данными, ключевые сценарии, зависимости, открытые вопросы, риски, ссылки на документацию и связанные внутренние системы.
Пример с интеграциями: было и стало
Раньше задача могла приходить так:
“Провести интеграцию с новой внешней системой по документации партнера, файл во вложении”.
После этого обычно начинался привычный цикл бизнес-анализа: изучение документации, серия уточнений с инициатором, попытка понять цель интеграции, перечень необходимых доработок, поиск ответственных, сбор зависимостей и ручная сборка черновика требований.
Теперь тот же процесс выглядит иначе. Инициатор загружает документацию и кратко описывает цель. Дальше система уточняет недостающие детали и формирует структурированный черновик. На выходе создается страница во внутренней базе знаний с уже заполненным шаблоном интеграционной задачи.
В таком черновике сразу присутствуют разделы, которые раньше появлялись только после нескольких итераций: цели интеграции, участники процесса, основные сценарии взаимодействия, открытые вопросы, зависимости по доступам, риски, ссылки на внешнюю документацию и связанные внутренние инициативы.
По сути, задача попадает к аналитику уже не как “вложение с PDF”, а как оформленный предметный документ.
Как из неопределённости появляется структура задачи
Хорошо это видно и на задачах, связанных с запуском экспериментов. Например, запрос мог звучать так:
“Нужно запустить новый эксперимент с баннером для части пользователей сайта”.
На первый взгляд запрос понятный. Но при попытке запуска сразу возникал длинный список уточнений: кому именно показываем баннер, на каком экране, всем пользователям или части трафика, что считаем контрольной группой, как фиксируем вариант, сколько живет эксперимент, как считаем успех, что делать с уже действующими пользователями, куда ведет переход по клику.
Раньше все эти вопросы разбирались уже после постановки задачи на встречах, в чатах и в ходе дополнительного discovery.
Теперь инициатор заводит тот же запрос через ассистента, и задача на выходе выглядит принципиально иначе.
Появляется понятный бизнес-контекст: необходимо проверить влияние нового баннера на поведение пользователей и целевые метрики.
Сразу фиксируется структура эксперимента:
• сегмент пользователей;
• точка показа на сайте;
• контрольная и тестовая группы;
• схема распределения трафика;
• правило закрепления пользователя за вариантом;
• логика повторного показа.
Дополнительно автоматически выделяются пробелы и риски:
• отсутствует дизайн-макет;
• не определены тексты баннера;
• не согласованы правила закрытия;
• не определен сценарий перехода по клику;
• требуется аналитика и мониторинг результатов.
Итогом становится не абстрактная идея “запустить баннер”, а полноценный черновик эксперимента, который уже можно отдавать в оценку и дальнейшую проработку со стороны бизнес-аналитика.
Что происходит, когда исчезает хаос на входе
Если смотреть через загрузку команды, эффект был ощутимым. В среднем за двухнедельный спринт мы работаем примерно с пятнадцатью задачами. До внедрения ассистента на каждую приходилось несколько встреч, переписка и последующая фиксация. В сумме это давало около двадцати часов на этап, посвященный исключительно прояснению запросов. После внедрения инициатор проходил первичную проработку через систему, а дальше задача попадала к аналитику уже в структурированном виде. Время сократилось до точечной проверки и доработки до тридцати минут на задачу. В масштабах спринта это уже 7-8 часов вместо прежних двадцати.
Но важнее оказались не цифры, а изменения в самой роли бизнес-анализа внутри процесса. Задачи перестали зависать в состоянии неопределенности. Их стало проще оценивать, быстрее запускать в работу и легче обсуждать с разработкой. Вместо вопросов уровня “что вообще нужно сделать?” появились вопросы уровня “какой вариант решения берем?”, “на какой сегмент запускаем?”, “есть ли пересечения с текущим функционалом?”, “какие риски считаем критичными?” То есть аналитика сместилась от сбора исходных вводных к содержательной работе с решениями.
Если подвести итог, основной эффект оказался не в количестве сэкономленных часов и не в сокращении встреч. А в том, что качество требований начало формироваться раньше. В момент, когда идея только превращается в задачу. Когда задача становится понятной на входе, вся последующая цепочка работает быстрее и чище: проще оценка, меньше возвратов, выше скорость запуска изменений. Для нас это стало рабочим способом убрать из бизнес-анализа лишнюю рутину и вернуть фокус туда, где действительно нужна экспертиза.
Материал подготовлен на основе внутреннего опыта и процессов IT-команды СВОЙ Тех (входит в финтех-группу СВОЙ).
ссылка на оригинал статьи https://habr.com/ru/articles/1034272/