Бизнес-аналитик вытаскивает требования из расшифровок встреч, переписывает «хотелки» в user stories и собирает ТЗ — до самой аналитики. Искра снимает эту рутину: превращает заметки в структуру BRD, пишет user stories с критериями приёмки, сводит протоколы. Схемы и дашборды она не строит, SQL не исполняет — финальные требования и решения за вами.
Подборка типовых задач аналитика, где Искра снимает рутину. 9 задач — для соло-работы (одинаково полезны и фрилансеру, и единственному аналитику на проекте), задача 10 — про общую базу знаний команды: о ней подробнее в блоке ниже. Кратко так: для команды сила Искры — общая база знаний, откуда все берут единый стандарт требований; для соло — скорость черновиков и память проекта, которая держит ваши файлы и историю под рукой. Ни один режим не «лучше» — выбираете по тому, как устроена ваша работа. Не нужно делать всё сразу: проще всего начать с задачи 05 (протокол встречи из расшифровки) или 02 (user story по фиче) — это самая лёгкая точка входа. Тайминги в карточках — ориентир, черновик за минуты, доводка за вами; зависят от объёма данных. Везде Искра работает с текстом и файлами: итоговые требования вы сверяете с источником и согласуете со стейкхолдерами.
На входе: Сырые заметки или расшифровка встречи с заказчиком, переписка, набор «хотелок» текстом.
На выходе: Структурированный черновик BRD/SRS: цели, заинтересованные стороны, функциональные и нефункциональные требования, открытые вопросы. BRD — документ бизнес-требований; если структура незнакома, Искра распишет обязательные разделы.
~15 минут вместо нескольких часов (черновик; доводка за вами)
На входе: Описание фичи или бизнес-потребности словами, контекст ролей пользователей.
На выходе: User stories в формате «Как… я хочу… чтобы…» с критериями приёмки (Given/When/Then) и негативными сценариями. Формулировки сверяете с заказчиком.
~10 минут вместо часа
На входе: Как процесс устроен сейчас (по шагам, текстом) и какую цель хотите достичь.
На выходе: Текстовое пошаговое описание AS-IS, узкие места и черновик TO-BE: что меняется, кто участник, какие развилки. Это текст для проработки и обсуждения, а не готовая BPMN-диаграмма-картинка — схему рисуете в своём инструменте.
~15 минут вместо полудня (черновик; доводка за вами)
На входе: Запрос на изменение, контекст текущего поведения системы и желаемого результата.
На выходе: Структура ТЗ: цель, область изменений, требования, ограничения, влияние на смежное. Останется уточнить детали реализации с разработкой.
~15 минут вместо часа
На входе: Расшифровка созвона или текстовые заметки обсуждения (можно файлом).
На выходе: Протокол: принятые решения, задачи с ответственными и сроками, открытые вопросы, договорённости. Ответственных и сроки сверяете с участниками.
~5 минут вместо 40
На входе: Выгрузка в XLSX/CSV (заявки, обращения, метрики процесса) и вопрос, который проверяете.
На выходе: Свод по данным текстом: что видно, где аномалии, какие гипотезы стоит проверить дальше. Важно: модель НЕ считает надёжно агрегаты и суммы — используйте свод для гипотез и направления, а финальные цифры берите из источника или считайте в Excel.
~10 минут вместо часа
На входе: Два-три варианта реализации или сервиса и критерии выбора (стоимость, сроки, риски, интеграции).
На выходе: Таблица сравнения по критериям с плюсами и минусами; при включённом веб-поиске — со ссылками на источники. Решение по выбору — за вами.
~10 минут вместо часа
На входе: Документы и заметки проекта, в которых разбросаны термины и сокращения.
На выходе: Черновик глоссария с определениями в контексте проекта и список уточняющих вопросов к заказчику — что осталось непонятным или противоречивым.
~10 минут вместо часа
На входе: Бизнес-формулировка требования (или, наоборот, техническая) и для кого её нужно переложить.
На выходе: Та же мысль на языке другой стороны: бизнес-«хотелку» — в технические требования для команды, технический ответ — в понятное заказчику объяснение. Смысл сверяете сами.
~5 минут вместо 30
На входе: Команда один раз загрузила в общую базу знаний организации реестр требований, ТЗ и глоссарий проекта. Аналитик спрашивает, как оформить user story по стандарту проекта.
На выходе: Черновик user story или протокола по правилам именно вашего проекта — со ссылкой на пункт реестра или ТЗ; формулировки единые для аналитика, разработки и тестирования. Новый человек держит стандарт, не дёргая ведущего.
~5 минут вместо получаса сверки «а что мы решили по этой фиче»
Работаете соло — аналитик-фрилансер или один на проекте?
Начните с соло-задач: протокол встречи (05), user story с критериями приёмки (02) и BRD из заметок (01). Блок ниже — про общую базу знаний команды — пригодится, когда подключите разработку и тестирование; пока работаете один, его можно спокойно пропустить.
Этот раздел — для команд
Работаете соло — спокойно листайте дальше, ваш сценарий выше (скорость черновиков и память проекта). Здесь — про то, что появляется, когда над требованиями работают несколько человек.
Когда над проектом работает команда, особенно полезна общая база знаний организации: реестр требований, ТЗ и глоссарий загружаются один раз, и каждый участник получает ответы по единому стандарту. У каждого свой личный ИИ, но отвечает он по правилам именно вашего проекта. Это снимает частую боль команд: требования живут в десятке разрозненных файлов и личных переписок, а «последнюю версию» никто не может найти. Как это выглядит на практике:
Ведущий аналитик спрашивает Искру: «Собери черновик user story по отмене заказа на основе реестра требований из базы знаний, с критериями приёмки и негативными сценариями».
— Искра: Готов черновик: история «Клиент отменяет заказ до сборки», 3 критерия приёмки в Given/When/Then, 2 негативных сценария (нет прав, заказ уже собран). Отметила 3 допущения, которых не было в реестре, — вынесла их в «Вопросы заказчику». Уточнить про возврат оплаты?
Разработчик отдельно уточняет: «Как это ляжет на текущую модель статусов из ТЗ?»
— Искра: По файлу «ТЗ v2» в базе знаний граница сборки — статус «Передан на комплектацию». Привязала критерий 2 к нему. Финальную привязку статусов подтвердите с разработкой — это влияет на скоуп.
Что это даёт проектной команде: черновик user story или протокола собирается за минуты — на основе общей базы знаний, единой для всех (грубая оценка, замерьте на своём процессе). Реестр требований, ТЗ и глоссарий живут в базе как актив команды: ответ «а что мы решили по этой фиче» приходит из ваших же файлов, одинаковый для аналитика, разработки и тестирования. Новый человек на проекте онбордится по тем же документам, не дёргая коллег.
Прикидка экономии в часах (не в деньгах — посчитайте под свою ставку)
Возьмите команду из, скажем, 4 аналитиков. Если на сведение версий ТЗ, сборку протоколов и «а где последняя редакция требований» уходит хотя бы 2–3 часа в неделю на человека, то общая база знаний с реестром требований может снять порядка 30–50 часов в месяц на команду — за счёт того, что черновик собирается из единого источника и не теряется. Это ориентир, а не обещание: на разных процессах цифра гуляет в разы.
Самый честный способ проверить — замерить на пилоте за 2 недели: засеките, сколько часов команда сейчас тратит на сведение требований и протоколов, и сравните после. Цены и тарифы здесь не приводим намеренно — посчитайте экономию в часах под свою ставку.
Помимо самих требований у вас есть управленческие задачи — держать картину в целом. Их Искра тоже снимает текстом по тем же файлам проекта:
Про доступ к общей базе знаний — честно, без выдумок. Общая база знаний организации на то и общая: загруженные в неё реестр требований и ТЗ доступны участникам как единый стандарт. Тонкой ролевой настройки «этот человек видит только эти файлы» внутри одной базы ожидать не стоит — мы это не гарантируем. Поэтому если нужно изолировать подрядчика или чувствительный кусок требований, самый надёжный приём — отдельная база знаний под него, а не попытка спрятать часть внутри общей. Для закрытого контура и тонкой настройки доступов под корпоративные требования — вариант on-premise и корпоративный тариф, запрос через mail@iskrabot.ru.
Опытному аналитику мало «складного текста» — нужно, чтобы каждое требование было прослеживаемо к источнику и не противоречило остальным. Языковая модель здесь даёт реальную пользу, но и реальный риск: она охотно достраивает «разумные» детали, которых заказчик не говорил, — статусы, роли, граничные условия. Если принять их за требования, всплывёт на приёмке. Поэтому встроенный приём — заставить Искру разделить «что сказали» и «что я додумала»:
Продвинутый приём для длинного проекта: попросите Искру вести журнал открытых допущений и вопросов с пометкой версии — например: «Веди список открытых допущений и вопросов к требованиям. При каждом обновлении ставь версию (v1, v2…) и помечай, что изменилось с прошлой». Так у вас в чате копится трассируемая история того, что было допущением, а что — согласованным требованием. Но помните про следующий пункт: Искра не держит весь длинный разговор целиком, поэтому журнал лучше периодически просить пересобрать из приложенного файла-источника.
Важная честность про границы: Искра не нарисует BPMN- или UML-схему-картинку, не построит дашборд, не выполнит SQL и не интегрируется с Jira или BI. Она работает с текстом, файлами и анализом. Описание процесса, критерии приёмки, реестр требований, разбор выгрузки — текстом; а саму диаграмму вы собираете в своём инструменте, SQL пишете и запускаете сами, задачи заводите в трекер руками. Это ассистент по формулировкам и структуре, а не исполнитель и не система требований. И, как любая модель, Искра ошибается — поэтому требования всегда сверяйте с источником и согласуйте со стейкхолдерами.
Память контекста не бесконечна. Искра не держит весь длинный разговор целиком: в очень длинной переписке ранние детали могут «выпадать» из её внимания. Поэтому «реестр требований прямо в чате» на длинной дистанции ненадёжен как единственное хранилище — держите источник в приложенном файле и периодически просите Искру пересобрать сводку допущений и требований из этого файла, а не из памяти диалога. Так вы возвращаете её к актуальной версии, а не к тому, что она «помнит».
Веб-поиск может уводить контекст в поисковые запросы. Если при работе с закрытыми требованиями включён веб-поиск, учитывайте: чтобы что-то найти, формулировка запроса уходит во внешний поиск. Поэтому для данных под NDA не вставляйте конфиденциальные формулировки в запросы на поиск — обезличивайте их или отключайте веб-поиск на время работы с чувствительным. Для полностью закрытого контура надёжнее вариант on-premise (см. FAQ ниже).
Один шаблон под любую задачу вашей профессии. Замените [плейсхолдеры] на свои данные.
Я бизнес-аналитик, работаю в [отрасль / тип проекта], аналитиком в команде / на стороне заказчика.
Мне нужна помощь с [задача — сбор требований / user story / описание процесса AS-IS и TO-BE / ТЗ на доработку / протокол встречи / анализ выгрузки / глоссарий].
Источник: [вставьте заметки встречи, расшифровку, описание фичи или приложите файл XLSX/PDF/DOCX].
Контекст: [система / продукт, роли пользователей, что уже есть, ограничения].
Формат результата: [BRD-структура / user stories с критериями приёмки Given-When-Then / пошаговое описание процесса / структура ТЗ / протокол с задачами].
Учитывай: финальные требования я сверю с источником и согласую со стейкхолдерами — мне нужен черновик и структура, а не готовое решение. Для каждого требования покажи, откуда оно взято, и отдельно отметь, что ты додумала. Найди противоречия и неописанные негативные сценарии. Диаграмму-картинку, дашборд и SQL делать не нужно — только текст и анализ.Под частые задачи — три готовых под-примера. Берите ближайший и подставляйте свои данные.
1. User story из «хотелки» заказчика
Из этого описания фичи собери user story в формате «Как [роль] я хочу [цель], чтобы [ценность]».
Добавь критерии приёмки в формате Given/When/Then, включая 2-3 негативных сценария (ошибка, нет прав, пустые данные).
Отдельным блоком выпиши допущения, которые ты ввела сама, и вопросы заказчику на уточнение.
Описание: [вставьте текст].2. Процесс AS-IS / TO-BE словами
Опиши процесс [название] текстом по шагам в состоянии AS-IS из моих заметок ниже: участники, действия, развилки, узкие места.
Затем предложи TO-BE: что меняем, кто участвует, какие шаги уходят. Отметь риски перехода.
Это текстовое описание для проработки, не рисуй диаграмму-картинку.
Заметки: [вставьте].3. Протокол встречи из расшифровки
Из приложенной расшифровки встречи собери протокол: принятые решения, задачи с ответственными и сроками, открытые вопросы, договорённости.
Если ответственный или срок в расшифровке не прозвучал — пометь «не определён», не придумывай.
Ответственных и сроки я сверю с участниками.Для команды — общая база знаний. Загрузите реестр требований и ТЗ в базу знаний организации, и каждый участник получит ответ по единому стандарту:
Собери черновик user story по фиче [название] на основе реестра требований и ТЗ из базы знаний организации, с критериями приёмки Given/When/Then и негативными сценариями.
Свяжи требования со статусами из файла «ТЗ» в базе знаний. Отметь допущения и вопросы заказчику отдельным блоком.
Это черновик — команда сверит и согласует.Попробуйте прямо сейчас
Вставьте свои заметки с последней встречи (можно обезличенные) — Искра соберёт черновик user story или протокол за минуту. Ничего секретного загружать не нужно: хватит безобидного фрагмента, чтобы оценить, насколько ответ полезен. Если вы аналитик-фрилансер и ведёте несколько проектов — заведите отдельный проект под каждого заказчика и снимайте рутину со сбора требований и протоколов, чтобы успевать брать больше работы.
Аналитик скидывает сырые тезисы со встречи с заказчиком — Искра собирает user story с критериями приёмки и вопросами на уточнение. Формулировки вы доводите сами.
Это пример. Откройте Искру и попробуйте на своём запросе — ответ придёт за минуту.
Расшифровать встречу и вытащить внятные требования — час-полтора, переписать сырые «хотелки» в user story с критериями приёмки — ещё столько же, а ещё описание AS-IS / TO-BE, ТЗ на доработку, протоколы, глоссарий, перевод «бизнес ↔ разработка» и выгрузки XLSX — всё это отъедает время до самой аналитики и проектирования. Искра работает с текстом, файлами и анализом как ассистент: из заметок собирает структуру требований и вопросы на уточнение, из фичи — черновик user story, из расшифровки — протокол с решениями и задачами. Любая модель может что-то упустить или придумать деталь, которой не было, поэтому требования вы сверяете с источником и согласуете со стейкхолдерами, а решение остаётся за вами.
Если вы джуниор-аналитик или только пришли на проект
Не пытайтесь освоить всё сразу. Начните с трёх задач, на которых трудно ошибиться: протокол встречи из расшифровки (задача 05), user story с критериями приёмки (02) и глоссарий и вопросы стейкхолдерам (08). Искра заодно объяснит незнакомый термин или методику прямо в контексте вашей задачи.
Черновик от Искры не стыдно показать наставнику или ведущему аналитику: вы приходите не с пустым листом, а с собранной структурой требований и понятными вопросами — наставнику остаётся проверить, а вам — научиться на его правках.
Готовый мини-промпт под протокол встречи — скопируйте целиком, ничего не придумывая. Прикрепите расшифровку или вставьте заметки и отправьте как есть:
Я джуниор бизнес-аналитик. Из приложенной расшифровки встречи собери протокол по структуре:
1) Участники и тема. 2) Принятые решения. 3) Задачи — с ответственным и сроком. 4) Открытые вопросы. 5) Договорённости.
Если ответственного или срока в расшифровке нет — пиши «не определён», ничего не выдумывай.
Отдельно отметь, что ты додумала сама. Объясни простыми словами любой термин, если он встретится.
Я сверю ответственных и сроки с участниками.А вот как выглядит заполненная строка [Контекст: система / роли / ограничения] из универсального промпта ниже — для примера, чтобы было понятно, что туда писать:
Контекст: интернет-магазин на нашей CRM; роли — клиент, оператор поддержки, склад; ограничение — отменять заказ можно только до статуса «Передан на комплектацию».
Главный навык аналитика с ИИ — не принимать формулировку на веру, а уметь поймать, где модель «дорисовала» требование, которого в источнике не было. Это встроенный приём, а не лишний шаг. Просите Искру не только сформулировать, но и показать связь с источником:
Так вы превращаете «черновик от нейросети» в проверяемую спецификацию: ответственность и финальное согласование со стейкхолдерами остаются за вами, но структура и костяк требований уже собраны.
Заметки встречи, переписка, «хотелки» заказчика превращаются в BRD/SRS, user stories с критериями приёмки и список вопросов на уточнение — текстом, а не схемой-картинкой.
XLSX-выгрузки, PDF и DOCX регламентов, ТЗ и положений, CSV. Выбирает нужное, отвечает по тексту документа и собирает выводы и гипотезы текстом.
Сравнивает вендоров и готовые решения, ищет отраслевые стандарты и подходы — с источниками, которые вы проверяете перед тем, как сослаться на них в обосновании.
Без VPN, оплата в рублях, серверы в России — важно, когда требования и документы проекта нельзя выносить за периметр через зарубежный сервис.
Команда загружает реестр требований, ТЗ и глоссарий в общую базу знаний организации — аналитик, разработка и тестирование получают ответы по единому стандарту. Личный ИИ каждому, оплата за общий пул токенов.
Искра отдаёт черновики требований, протоколов и ТЗ; финальная формулировка, согласование со стейкхолдерами и ответственность за скоуп остаются на аналитике.
Искра — текстовый ассистент: она структурирует требования из ваших заметок, пишет черновики user stories и критериев приёмки, собирает протоколы и ТЗ. Это помощник, а не аналитик и не система управления требованиями. Любая модель может упустить деталь или, наоборот, «дорисовать» требование, которого не было, — поэтому формулировки сверяйте с источником, согласуйте со стейкхолдерами, а решение о скоупе принимаете вы.
Нет. Искра работает с текстом, файлами и анализом: возвращает описание процесса, требования и выводы в чате. Она не рисует диаграммы-картинки (BPMN, UML), не строит дашборды, не исполняет SQL и не интегрируется с Jira, Confluence или BI. Процесс она опишет словами по шагам — а саму схему вы соберёте в своём инструменте; SQL и задачи в трекере остаются за вами.
Серверы и хранение данных — в России, без VPN. Загруженные файлы и переписка не используются для обучения моделей — это закреплено в политике конфиденциальности и пользовательском соглашении (ссылки в подвале сайта), а не просто заявлено на словах. Файлы хранятся в вашем проекте, пока вы их не удалите. Если требования под NDA или содержат коммерческую тайну — обезличьте данные перед загрузкой (уберите названия, имена, конкретику) или согласуйте порядок работы со службой безопасности. Для закрытого контура есть вариант on-premise: Искра разворачивается на серверах вашей компании, и данные физически не покидают её периметр; такой контур доступен на корпоративном тарифе — запросить можно через mail@iskrabot.ru или раздел «Для крупного бизнеса».
Искра работает в РФ-юрисдикции: серверы в России, оплата в рублях, интерфейс на русском, без VPN. Веб-поиск возвращает ответ со ссылками на источники — удобно сравнивать вендоров и подходы. Для команды есть общая база знаний организации: реестр требований, ТЗ и глоссарий загружаются один раз, и каждый участник получает ответы по единому стандарту.
При этом мы не утверждаем, что Искра «умнее ChatGPT»: как любая языковая модель, она тоже ошибается и может придумать требование, которого не было. Поэтому относитесь к ней как к толковому помощнику, который снимает рутину и собирает черновик, — а требования всегда сверяйте с источником и согласуйте со стейкхолдерами.
BRD — документ бизнес-требований (что и зачем нужно бизнесу). SRS — спецификация требований к ПО (как это должно работать). AS-IS — процесс «как есть сейчас», TO-BE — «как должно стать». User story — требование от лица пользователя в формате «Как… я хочу… чтобы…». Критерии приёмки (часто в формате Given/When/Then) — условия, при которых история считается выполненной. НФТ — нефункциональные требования (производительность, безопасность, доступность). Искра умеет объяснять такие термины простыми словами в контексте вашей задачи.
Искра читает DOCX и PDF (ТЗ, регламенты, положения), XLSX и CSV (выгрузки, реестры требований), а также текст и расшифровки встреч. Можно вставить заметки прямо в чат. Чем понятнее вы зададите контекст — систему, роли, ограничения — тем точнее результат. Большие документы и выгрузки лучше присылать файлом, а не текстом.