ChatGPT prompts для бизнес-аналитика — это набор чётких запросов к модели, которые помогают быстрее собирать требования, проверять гипотезы, писать user story и снижать цену ошибки в документации; но работает это только если вы умеете задавать контекст, ограничения и критерии качества, то есть знаете, как писать prompts по-взрослому.

Если вы думаете «ну я же могу просто спросить у ChatGPT», вы уже на полпути к типичному BA-факапу: красивый текст вместо рабочих артефактов. Бизнес-аналитик живёт не в мире “мнений”, а в мире проверяемых формулировок: границы процесса, исключения, согласованные термины, трассируемость (когда понятно, откуда взялось требование и куда оно пошло в разработку).

На российском рынке BA сейчас часто ожидают странный коктейль: чуть системный аналитик, чуть product, чуть тестировщик, и всё это — в Яндекс Трекере, иногда ещё с 1С, интеграциями, API и вечной любовью к Excel. Поэтому prompts chatgpt — это не “чит”, а способ ускорить рутину. Но только если вы управляете моделью как стажёром: даёте входные данные, формат ответа и критерии «годно/в мусор».

Зачем бизнес-аналитику prompt engineering, а не “просто чатик”

Тезис: BA выигрывает не от “умного текста”, а от структуры

Обоснование: в работе BA результат — это артефакты: problem statement, stakeholder map (карта стейкхолдеров), user story, acceptance criteria (критерии приёмки), BPMN/UML-описания, спецификация API (часто в стиле OpenAPI), бизнес-правила, глоссарий. ChatGPT легко пишет “объяснялки”, но без правильного prompt’а почти всегда:

• дорисовывает несуществующие требования;
• путает термины (особенно предметку: финтех, логистика, 1С-учёт);
• не держит формат (вам нужен table/список/шаблон, а не эссе).

Практический вывод: prompts для BA — это в первую очередь “контроллер формата”: что дано, что нельзя выдумывать, в каком виде вернуть, какие вопросы задать, если данных не хватает.

Подводный камень: просить “сделай ТЗ” без контекста. Модель сделает, но вы принесёте на демо документ, который развалится от первого уточняющего вопроса разработчика.

Мини-формула хорошего BA prompt’а

Если коротко, “как писать prompts” для аналитики выглядит так:

1. Роль: “Ты — бизнес-аналитик/системный аналитик в проекте X”.
2. Контекст: отрасль, продукт, текущий процесс, ограничения (1С, Госуслуги, СБП, СМС-шлюз, 152‑ФЗ и т.д.).
3. Входные факты: только то, что реально известно (с примерами данных).
4. Задача: какой артефакт нужен (user story, критерии, сценарии, вопросы).
5. Формат: таблица/список/шаблон Confluence.
6. Качество: “Не выдумывай. Если не хватает — задай до 7 вопросов”.

Практикум: prompts chatgpt для типовых задач бизнес-аналитика

1) Сбор требований: превратить кашу из чата в список уточнений

Тезис: лучший выход ChatGPT для BA — вопросы, а не ответы.

Prompt:

Ты — бизнес-аналитик в проекте интернет-магазина. Ниже — сырой поток сообщений от заказчика. Твоя задача: (1) извлечь факты без догадок, (2) составить список уточняющих вопросов, (3) отметить риски и противоречия. Формат: таблица из 4 колонок [Факт/Гипотеза/Вопрос/Риск]. Ограничение: не добавляй новых функций, которых нет в тексте.

Практический вывод: вы экономите часы созвонов и уменьшаете шанс, что «а мы имели в виду другое» всплывёт на UAT (приёмке).

Подводный камень: не прикладывать исходник (чат/письмо/скрин). Модель не телепат.

2) User Story + Acceptance Criteria: чтобы разработка не “интерпретировала”

Тезис: бизнесаналитик выигрывает, когда критерии приёмки превращают хотелки в тестируемые условия.

Prompt:

Сформируй 3 user story в формате “Как [роль] я хочу [цель], чтобы [ценность]” по описанию ниже. Для каждой — acceptance criteria в стиле Given/When/Then (BDD), минимум 5 критериев, включая негативные сценарии и граничные значения. Если термин неоднозначен — добавь его в глоссарий и предложи вариант определения.

Практический вывод: QA получает основу для тест-кейсов, dev — понятные условия “готово”.

Подводный камень: критерии вида “должно быть удобно”. Удобно кому? Где метрика? Где условия?

3) Прототипирование текстом: экраны и состояния без Figma

Тезис: иногда быстрее описать интерфейс словами, чем собирать “красоту”.

Prompt:

Опиши прототип экрана “Оформление доставки” в виде: (1) список блоков сверху вниз, (2) поля с типами данных и валидациями, (3) состояния: пусто/загрузка/ошибка/успех, (4) тексты ошибок. Учитывай российский формат телефона +7, адрес (КЛАДР/ФИАС — если уместно), и 152‑ФЗ: где требуется согласие на обработку данных.

Практический вывод: дизайнеру и фронту легче стартовать, а вы быстрее ловите дырки в логике.

Подводный камень: не фиксировать “источник истины”: прототип в чате не заменяет согласованный артефакт в Confluence.

4) API и интеграции: черновик, который можно критиковать

Тезис: ChatGPT полезен как генератор “первого приближения” спецификации.

Prompt:

Сгенерируй черновик REST API для сущности “Заказ” (create/get/update/cancel). Верни в формате таблицы: [Endpoint, Method, Request fields, Validations, Response, Error codes]. Ограничение: не выдумывай поля — используй только перечисленные ниже. Отдельно: список вопросов к архитектору/разработчику.

Практический вывод: вы приносите на синк не пустой лист, а предмет для обсуждения.

Подводный камень: слепо копировать схемы. Интеграции — место, где фантазия дороже всего.

Таблица: “плохой prompt vs нормальный prompt” для BA

Два кейса из практики (как это бывает вживую)

Кейс удачный: “BA ускорился в 2 раза, но не потерял голову”

Аналитик в проекте на 1С:УТ + интернет-витрина использовал ChatGPT не для “написать документ”, а для конвертации: созвоны → факты → вопросы → backlog в Jira. Результат: меньше переоткрытий задач, QA перестал гадать, что имелось в виду, а глоссарий перестал быть декоративной салфеткой. Ключевой трюк — жёсткое правило “не выдумывай” и единый формат артефактов.

Кейс провальный: “сгенерили ТЗ, потом сгенерили виноватого”

Другой проект: маркетинг попросил “сделать ТЗ на личный кабинет”. BA нагенерил документ, принёс как готовое, без списка допущений и вопросов. Разработчики реализовали буквально, бизнес ожидал другое, сроки поехали, начались правки “а тут мелочь”. Итог — минус спринт и вечная фраза “аналитики опять не так написали”. Проблема была не в модели, а в том, что prompts chatgpt использовали как магию, а не как инструмент.

Коммерческие факторы: что важно, если вы учитесь prompt engineering под BA

На рынке РФ курсы по prompt engineering часто продают как волшебную кнопку, хотя для бизнесаналитика ценность в другом: в ускорении подготовки артефактов и снижении ошибок в требованиях. При выборе обучения смотрите не на “сколько промптов в подарок”, а на:

• есть ли практика на артефактах BA (user story, AC, BPMN-логика, API-таблицы);
• разбирают ли ограничения и риски (конфиденциальность, 152‑ФЗ, корпоративные данные);
• дают ли систему ревью качества (чек-листы, критерии готовности, примеры плохих формулировок);
• что входит в стоимость: разборы домашних/обратная связь/шаблоны для Jira/Confluence.

Ещё один трезвый пункт: если вы работаете с чувствительными данными (ФИО, телефоны, финансы), проговорите с работодателем политику использования внешних моделей. Иначе “я просто прогнал в чатик” может стать карьерным квестом с неожиданным финалом.

Экспертный вердикт и инструмент: чек-лист BA для prompts

Вместо рекламы — инструмент, который можно сразу утащить в работу (и да, за это обычно и любят материалы на https://itokno.ru):

1. Что я хочу получить? Артефакт, не “текст”: таблица, story, критерии, список вопросов, глоссарий.
2. Какие факты у меня есть? Примеры данных, бизнес-правила, ограничения системы (1С, интеграции, роли).
3. Что модели запрещено делать? “Не выдумывать”, “не добавлять фичи”, “если нет данных — спроси”.
4. Как я проверю качество? Тестируемость критериев, наличие негативных сценариев, отсутствие противоречий.
5. Где границы? In scope / out of scope + допущения (assumptions).

Если вы новичок, цель простая: научиться превращать хаос коммуникаций в структуру. Если вы уже Junior/Middle, ваша цель — стандартизировать prompts так, чтобы команда получала одинаковый по качеству результат, независимо от того, кто сегодня “пишет требования”.

Частые вопросы