Промт-инжиниринг для системных и бизнес-аналитиков по фреймворку КОМПОЗИТОР

Аннотация

Системные и бизнес‑аналитики ежедневно пишут десятки требований, юскейсов и спецификаций. На каждый документ уходит 2–3 часа: собрать факты, договориться об уровне детализации, причесать стиль. Акроним КОМПОЗИТОР превращает ChatGPT, GigaChat, Deepseek и другие чат-боты на основе больших языковых моделей из капризного собеседника в штатного аналитика: он раскладывает промт на 10 чётких блоков, которые добавляются итерациями, или «слоями», и автоматически устраняют типичные ошибки — размытые формулировки, «галлюцинации» и несогласованность. Час на настройку шаблона экономит 6–7 часов в первом же спринте и до 78 000 рублей на блоке из 12 похожих задач.

Введение: почему эта статья важна

ИИ‑ассистенты уже умеют помогать в аналитических задачах, но «из коробки» они отвечают обтекаемо: теряют роли, смешивают контексты, выдают лишние допущения. Для системных и бизнес‑аналитиков, работающих со сложными процессами, такое «творчество» оборачивается десятками доработок и риском пропустить критичные детали.

1. Сложный домен требует точности. Ошибка в формулировке превращается в потенциальный дефект. Нужен промт, который заранее удерживает рамки.

2. Большинство готовых фреймворков англоязычны. Акронимы вроде PROMPT или FEARS звучат умно, но плохо ложатся в русскоязычную практику и забываются через пару дней.

3. Промт можно улучшать итерациями. Часто мы бросаемся писать идеальный запрос целиком, а потом переделываем. Гораздо продуктивнее начать с ядра и постепенно наращивать детали, проверяя, как ИИ корректирует ответ.

Именно поэтому мы предлагаем фреймворк «КОМПОЗИТОР» — русскоязычную мнемонику, которая:

• делит промт на логически завершённые блоки («Кто ты», «Обстановка», «Миссия» и т.д.),

• усиливает результат пошагово: сначала ядро «К-О-М» (промт «Кто ты — Обстановка — Миссия»), затем уточняющие слои в середине промта «П‑О‑З‑И» (промт «Позитивный пример — Отрицательный пример — Зона работы — Инспекция»), потом финальный аккорд «Т-О-Р» (промт «Тон — Окружение — Результат»).

• позволяет быстро адаптировать один и тот же шаблон под разные типы артефактов — от user story до BPMN‑процесса.

В этой статье мы расскажем, как пройти путь от первого «сырого» запроса («первый блин — комом») до выверенного промта, который минимизирует итерации, делает ответы ИИ предсказуемыми и фиксирует нужный формат выдачи. Всё это — через визуализации: блины, робот‑повар в космосе, удар молота Тора и, конечно, реальный кейс из практики аналитиков — про заявку от клиента на возврат заказа.

Глоссарий

Термины, связанные с ИИ

Термин	Определение
Большая языковая модель (LLM) или просто «модель»	Алгоритм машинного обучения, обученный на терабайтах текстов. Прогнозирует вероятность следующего токена, благодаря чему создаёт связный текст, отвечает на вопросы и обобщает знания.
ChatGPT, GigaChat, DeepSeek	Чат‑боты на основе больших языковых моделях: принимают текстовый запрос, генерируют осмысленный ответ, поддерживают диалог и могут выполнять прикладные задачи (перевод, анализ, написание кода).
Промт (Prompt)	Запрос к модели, содержащий роль, контекст и задачу
Промт-инжиниринг (Prompt‑engineering)	Практика конструирования промтов для получения стабильных результатов
ИИ‑ассистент	Программный помощник, использующий ИИ (часто LLM) для автоматизации когнитивной работы: составление документов, поиск информации, подсказки при кодировании.
«Из коробки» (out‑of‑the‑box)	Характеристика решения, показывающая, как оно работает сразу после установки без дополнительной настройки. В контексте статьи — ChatGPT без специально сформулированного промта.
Галлюцинации (в контексте ИИ)	Ситуации, когда модель уверенно генерирует факты или детали, которых нет в источниках данных. Возникают из‑за статистической природы LLM и устраняются блоком «Зона работы», позитив/негатив‑примером и чек‑листом «Инспекция» из фреймворка КОМПОЗИТОР.
Fine‑tuning (дообучение)	Дополнительное обучение уже готовой большой языковой модели на корпоративных данных. Позволяет специализированному ИИ лучше понимать доменную лексику, но требует времени и вычислительных ресурсов — в статье мы заменяем его тонкой настройкой промта через фреймворк «КОМПОЗИТОР».
Фреймворк	Структурированный набор правил, этапов или блоков, который помогает решать типовую задачу предсказуемым способом. В статье это «КОМПОЗИТОР» — десять букв-блоков, формирующих промт.
Иностранные фреймворки (PROMPT, FEARS, RAIL)	Популярные англоязычные схемы для работы с LLM: PROMPT (Preview-Root-Objective-Must-Persona-Tone), FEARS (Few-shot-Examples-Analyze-Reason-Solve), RAIL (Role-Action-Input-Layout). Хорошо зарекомендовали себя, но труднее запоминаются русскоязычной команде.

Термины, связанные с кейсом системного анализа

Термин	Определение
Юскейс / Use case	Формальное описание взаимодействия актора с системой, методика А. Коберна (Cockburn)
Discovery‑фаза	Этап проекта, когда собираются требования и подтверждается бизнес‑ценность
Диаграмма состояний возврата	Графическое описание жизненного цикла заявки на возврат со статусами: Draft («Черновик») → Approved («Одобрен») → Refunded («Возврат выполнен») / Rejected («Отказано») и правилами переходов между ними. Служит контрактом для процессов и проверки сценариев.
UML‑классы «ReturnRequest», «Payment», «Customer»	Фрагмент предметной модели: каждый класс фиксирует сущность (атрибуты, связи, ограничения). Это эталон терминов и полей, на которые ссылаются требования и будущий журнал событий.
«ReturnRequest» («Заявка на возврат»)	Класс доменной модели, фиксирующий параметры обращения клиента: ID заказа, причину, дату подачи, текущий статус («Draft», «Approved», «Rejected», «Refunded»).
«Payment» («Платёж»)	Сущность, описывающая информацию об оплате: способ, сумму, валюту, дату авторизации и связь с «ReturnRequest» для оформления возврата средств.
«Customer» («Клиент/Покупатель»)	Класс, хранящий идентификатор пользователя, контактные данные и историю заказов. Связывается с «ReturnRequest» для верификации права на возврат.
SLA‑таблица (Service Level Agreement — «Соглашение об уровне сервиса»)	Документ с измеримыми нормами: например, «доступность ≥ 99,95 %» и «право на возврат — ≤ 14 календарных дней после статуса «Delivered». Эти цифры переносим в «Миссию» и позитивные примеры промта.
Git	Система контроля версий кода и документов
Pre‑commit	Сценарий, который Git выполняет до фиксации изменений (проверки качества)
Pull request	Запрос на включение изменений в основную ветку проекта
Feature‑банк	Очередь будущих функций продукта, из которых команда забирает работу
Lead Time	Время от создания задачи до одобрения результата без замечаний

Глава 1. Что скрывается за буквами «КОМПОЗИТОР»

«КОМПОЗИТОР» — это не только человек с партитурой, но и мнемоника, которая помогает системным и бизнес‑аналитикам «сочинять» точные промты. Каждая буква отвечает за один логический блок запроса. В совокупности они задают три уровня управления ответом ИИ: ядро, тон и контроль качества.

1.1. Ядро: «К-О-М» — основа, без которой ничего не сыграет

Буква	Вопрос, который мы задаём	Почему это важно	Примеры
К — Кто ты?	«Какую роль сейчас играет ассистент?»	Роль задаёт рамку экспертизы. ИИ‑“робот‑юрист” формулирует иначе, чем ИИ‑“UX‑писатель”.	— «Ты бизнес‑аналитик в проекте по логистике» — «Ты системный аналитик в банке» — «Ты UX‑исследователь в e‑commerce‑стартапе»
О — Обстановка	«Где мы? Какая предыстория?»	Контекст отсекает лишние допущения: discovery‑фаза ≠ support.	— «Discovery‑фаза финтех‑приложения» — «Post‑release support интернет‑магазина» — «Миграция ERP на облако»
М — Миссия	«Что должно получиться в конце?»	Чёткая финальная цель (use case, BPMN, чек‑лист) — якорь для всего диалога.	— «Составь юскейс “Отмена заказа”» — «Опиши BPMN процесса возврата» — «Подготовь нефункц‑требования к API»

Методичка

Начинайте любой запрос с «К-О-М». Представьте, что вы хотите быстро уговорить друга посмотреть с вами фильм и рассказываете только суть: герой, ситуация, цель. Всё остальное — детализация.

1.2. Фокусировка: «-П-О-» — примеры, которые направляют

Буква	Сущность	Почему это важно	Примеры
П — Позитивный пример	Эталонный фрагмент ответа	Показывает, какой стиль и детализация нужны.	— «Система проверяет статус “Delivered”» — «Запрос возвращает ≤ 50 элементов» — «Задержка в 95% ≤ 200 мс»
О — Отрицательный пример	Почти то же, но с ключевой ошибкой	ИИ быстрее учится «на контрасте», чем на абстрактном запрете.	— «Система проверяет, что статус корректный» — «API отвечает быстро» — «Пользователь доволен»

Два коротких примера экономят абзацы инструкций. Главное — выбрать ошибку, способную испортить результат (например, бесконечный цикл в BPMN).

1.3. Безопасная сцена: «-З-И-» — охрана периметра

Буква	Сущность	Почему это важно	Примеры
З — Зона работы	Допустимые данные и границы темы	Предотвращает «галлюцинации» о несуществующих интеграциях или регламентах.	— «Опирайся на стенограммы» — «Не добавляй новые статусы» — «Используй Swagger v1» — Если требуемых данных не хватает — укажи TODO со ссылкой на отсутствующий объект.
И — Инспекция	Чек‑лист самопроверки для ИИ	Заставляет ассистента прогнать результат через встроенный контроль качества (целостность диаграммы, согласованность терминов).	— «Проверь нумерацию шагов» — «Каждый gateway имеет 2 исхода» — «Нет петель в диаграмме»

1.4. Финальный аккорд: «-Т-О-Р» — ставим точку громко

Буква	Сущность	Почему это важно	Примеры
Т — Тон	Манера подачи (деловой, дружелюбный, gdb‑режим)	Помогает вписать текст в корпоративный стиль без ручного переписывания.	— «Деловой, лаконичный» — «Дружелюбный FAQ‑формат» — «Техническая справка»
О — Окружение	Для кого пишем (роль и уровень читателя)	Архитектор ждёт одни детали, CEO — другие.	— «PO и разработчики» — «Финансовый директор» — «Команда QA»
Р — Результат	Формат вывода (таблица, список, DSL)	Делает ответ пригодным для копипаста в Confluence или PlantUML без доп. правок.	— «Таблица Confluence» — «JSON‑snippet» — «PlantUML‑диаграмма»

1.5. Как запомнить порядок

1. К‑О‑М — как «первый блин комом»: стартуем с роли, контекста и цели.

2. П‑О — «Покажи‑Ошибись»: хороший и плохой варианты.

3. З‑И — «Зона работы — Инспекция»: ограничиваем и проверяем.

4. Т-О-Р— удар молота: закрепляем стиль, адресата и формат.

Через эту последовательность промт растёт «слоями». Вы можете остановиться на «К-О-М», получить быстрый черновик, а затем наращивать детали до полноформатного «КОМПОЗИТОР» — ровно столько, сколько требует задача. В следующих главах мы увидим, как это работает на практике: сначала попробуем «комом», а потом будем улучшать промт, добавляя каждый новый слой и наблюдая, как ИИ эволюционирует от «сырого теста» к «готовому продукту».

Глава 2. Начинаем с промта «Кто ты? — Обстановка — Миссия»: «первый блин — КОМом»

2.1 Три блина — три «К-О-М»-сцены

Метафора

Для того чтобы проверить рецепт, достаточно трёх блинчиков. Точно так же для отработки структуры промта нам нужны три короткие сцены — разный Кто, разная Обстановка, одна Миссия.

№	К — Кто ты?	О — Обстановка	М — Миссия	Что меняется в ответе ИИ
1	Начинающая хозяйка	Хай‑тек кухня в open‑space, много гаджетов	Испечь первые блины для друзей‑коллег	ИИ советует простые рецепты, учитывает доступ к «умной» сковороде, минимизирует риски («первый блин — тестовый»).
2	Опытная хозяйка	Туристический привал, костёр на природе	Накормить 8 человек блинами за 15 минут	ИИ предлагает опустить лишние приборы, фокусируется на жаре костра и скорости подачи.
3	Космический робот‑повар	Открытый модуль орбитальной станции	Приготовить блины в невесомости	ИИ переводит рецепт в регламент НК‑систем, прописывает фиксацию посуды и воздушные фильтры.

Вывод: даже без дополнительных блоков промта одно только «КОМ» радикально меняет советы ChatGPT — потому что меняются роль и контекст.

2.2 Перенос на анализ: промт «Кто ты — Обстановка — Миссия» для BA/SA‑кейса

Мы возьмём типовую совместную задачу бизнес‑ и системного аналитика — формулировку use case «Оформление возврата товара».

Промт «Кто ты — Обстановка — Миссия»

Кто ты? Ты — системный и бизнес‑аналитик в одной роли, отвечающий за описание процессов e‑commerce.
Обстановка: Стартовая discovery‑фаза проекта «Возврат товара»; есть стенограммы пользовательских интервью, диаграмма классов, диаграмма состояний возврата, SLA‑таблица.
Миссия: Составь первоначальный юскейс «Оформление возврата» по шаблону Кокберна, без диаграмм, только текст.

Ответ ИИ

Юскейс: Оформление возврата
Primary Actor: Клиент
Scope: E‑commerce система …

Основной сценарий:
1. Клиент инициирует запрос возврата…
2. Система запрашивает номер заказа…
3. …

Расширения:
1a. Клиент не помнит номер заказа … система предлагает поиск по email
3a. Срок возврата истёк … система уведомляет об отказе

Типичные проблемы, если использовать только промт «Кто ты — Обстановка — Миссия»:

• Слишком общий стиль: нет ссылок на реальные SLA, статусы или роли службы поддержки.

• Игнорирует ограничения (например, существующий API OMS).

• Нет формата вывода: Markdown‑список придётся вручную переносить в Confluence‑шаблон.

• Отсутствуют критерии проверки — ИИ «полагается на слово».

2.3 Плюсы и минусы промта «К-О-М»

Плюсы «К-О-М»‑подхода (промт «Кто ты — Обстановка — Миссия»)	Минусы, которые устраним дальше
✅ Ответ уже структурирован: актор, сценарии, альтернативы.	⛔️ Допущения не проверены на реальных данных (зона работы).
✅ Формулировки ближе к профессиональным терминам BA/SA.	⛔️ Нет позитивного/отрицательного примера: ИИ не видит образца качества.
✅ Не нужно объяснять, зачем нужен use case.	⛔️ Нет настройки тона и формата вывода — придётся дорабатывать вручную.

Итого: «К-О-М» (промт «Кто ты — Обстановка — Миссия») — быстрый способ получить черновик, но без дальнейших слоёв фреймворка «КОМПОЗИТОР» ответ останется тем самым «первым блином». В следующей главе мы «ударим молотом Тора» — добавим промт Т-О-Р («Тон — Окружение — Результат») и посмотрим, как сразу исчезнет половина проблем.

Глава 3. Завершаем промтом «Т-О-Р» («Тон — Окружение — Результат»): как положить «молот Тора» на стол

Мы вынесли эту часть промта сразу после начала, так как можно использовать только две части фреймворка:

• начало — «К-О-М» (промт «Кто ты — Обстановка — Миссия»)

• конец — Т-О-Р («Тон — Окружение — Результат»)

И результат уже может быть завершённым. Но для сложных промтов понадобятся детали из «середины» фреймворка — о них расскажем в следующей главе.

Образ

Молот Мьёльнир громко бьёт по наковальне — хаос превращается в форму.

В промте: слой Т-О-Р («Тон — Окружение — Результат») задаёт тон ответа, адресата и формат, превращая черновик «К-О-М» в готовый артефакт, который можно сразу вставить в Confluence или Jira.

3.1 Расшифровка «Т-О-Р»

Буква	Что настраиваем	Типовая формулировка	Что меняет
Т — Тон	Манера подачи	«деловой, но дружелюбный, короткие активные фразы»	Убирает лишние прилагательные, сокращает вводные слова.
О — Окружение	Для кого пишем	«читатели: продукт‑оунер и разработчики»	Подсвечивает детали, важные именно этой роли (например, статусы API для разработчика).
Р — Результат	Формат вывода	«оформи в таблицу Confluence» или «DSL‑блок Cockburn»	Экономит копипаст и ручное форматирование.

3.2 Апгрейд BA/SA‑промта: добавляем «Т-О-Р»

Промт «Кто ты — Обстановка — Миссия» + «Тон — Окружение — Результат»

Кто ты? Ты — системный и бизнес‑аналитик в одной роли, отвечающий за описание процессов e‑commerce.
Обстановка: Стартовая discovery‑фаза проекта «Возврат товара»; есть стенограммы пользовательских интервью, диаграмма классов, диаграмма состояний возврата, SLA‑таблица.
Миссия: Составь первоначальный юскейс «Оформление возврата» по шаблону Кокберна, без диаграмм, только текст.

Тон: деловой, лаконичный, каждое действие с новой строки.
Окружение: читатели — продукт‑оунер и команда разработки.
Результат: выведи результат в таблицу с колонками: Шаг, Актор, Действие, ID альтернативного потока

Ответ ИИ (фрагмент)

Шаг	Актор	Действие	ID альтернативного потока
1	Клиент	Запрашивает номер заказа	—
2	E‑com Core	Проверяет право на возврат, сверяя дату заказа и статус «Delivered» в OMS (≤ 14 дней)	2a
3	OMS	Выдаёт этикетку возврата (REST /return/v2/label)	—

3.3 Ответы ИИ до и после «удара молота»

Параметр	Без «Т-О-Р» (только промт «К-О-М» — «Кто ты — Обстановка — Миссия»)	С промтом «Т-О-Р» («Тон — Окружение — Результат»)
Стиль	Смешивает канцелярит и разговорные фразы.	Короткие императивы. Нет «лишнего воздуха».
Фокус на аудитории	Не уточняет коды API, статусы.	Добавляет колонки «System Action», «Alt Flow ID».
Формат	Markdown‑список, нуждается в ручном переносе.	Готовая таблица — достаточно вставить в Confluence.

3.4 Что изменилось — короткие выводы

• Минус две итерации ревью. Роли и формат заданы сразу, продукт‑оунер вчитался без вопросов.

• Ноль ручного форматирования. Таблица Confluence вставляется «как есть».

• Уменьшение когнитивной нагрузки. Тон единообразен, не нужно причесывать стиль под гайдлайн.

Ключевая мысль: слой Т-О-Р («Тон — Окружение — Результат») — это не «косметика», а механика доставки ценности. Он фокусирует ответ под конкретных читателей и избавляет вас от ручных правок.

В следующей главе мы подключим П‑О‑З‑И (промт «Позитивный пример — Отрицательный пример — Зона работы — Инспекция»), чтобы ассистент учился на примерах, соблюдал границы задачи и сам проверял качество результата.

Глава 4.Нарастающее улучшение: подключаем «П‑О‑З‑И» (промт «Позитивный пример — Отрицательный пример — Зона работы — Инспекция»)

Задача главы

Показать, как поочерёдное добавление четырёх новых блоков превращает «хороший» промт уровня К-О-М + Т-О-Р (промты «Кто ты — Обстановка — Миссия» + «Тон — Окружение — Результат») в «безошибочный» промт уровня КОМПОЗИТОР.

Посмотрим на фрагмент ответа ИИ, который он дал на предыдущем шаге:

Шаг	Актор	Действие	ID альтернативного потока
1	Клиент	Запрашивает номер заказа	—
2	E‑com Core	Проверяет право на возврат, сверяя дату заказа и статус «Delivered» в OMS (≤ 14 дней)	2a
3	OMS	Выдаёт этикетку возврата (REST /return/v2/label)	—
4	E‑com Core	Проверяет: если всё ок — возврат, иначе — отказ	—

Что заметили

• Шаг 2 оформлен чётко — будущий позитивный пример.

• Далее идёт общий текст: «Система проверяет, если всё ок— возврат…» — это идеальный негативный пример.

4.1 Шаг 1 — добавляем Позитив и Отрицание

Что делаем

Добавляем фрагмент ответа, который максимально похож на желаемый результат, и антипример, на который не стоит ориентироваться

Добавляем «Позитивный пример» и «Отрицательный пример»

Позитивный пример идеального шага основного сценария:
«Система проверяет право на возврат, сверяя дату заказа и статус "Delivered" в OMS (не более 14 дней)».

Отрицательный пример — «Система проверяет, если всё ок — возврат, иначе — отказ». Избегай размытых формулировок.

Новый ответ ИИ (фрагмент)

Шаг	Актор	Действие	ID альтернативного потока
2	E‑com Core	Проверяет право на возврат, опираясь на статус «Delivered» или «Picked‑Up»	2a
4	E‑com Core	Создаёт тикет в Service Desk «Return Request»	—

Выявленные проблемы

• Появился несуществующий статус «Picked‑Up»

• Создан Service Desk‑тикет — в исходных данных такого сервиса нет.

→ нужен блок, который ограничит воображение модели.

4.2 Шаг 2 — вводим Зону работы

Решаем проблему предыдущего этапа

Добавляем рамки, в которых модель должна генерировать ответ, для того чтобы ограничить её воображение.

Добавляем «З» — «Зону работы»

Зона работы: используй только факты из интервью и источников: UML‑классы ReturnRequest, Payment, Customer, диаграмма состояний возврата, SLA‑таблица. Запрещено придумывать новые статусы и связи. Если требуемых данных не хватает — укажи TODO со ссылкой на отсутствующий объект.

Новый ответ ИИ (фрагмент)

Шаг	Актор	Действие	ID альтернативного потока
2	E‑com Core	Проверяет право на возврат, сверяя дату заказа и статус «Delivered» в OMS (≤ 14 дней)	2a
2a	E‑com Core	Если статус не «Delivered» — отказ в возврате	—
5	—	Переходит к шагу 2	—

Новая проблема

• Возникла петля: шаг 5 отправляет процесс назад к шагу 2 без шлюза — классическая логическая ошибка.

• → добавляем блок самопроверки.

4.3 Шаг 3 — включаем Инспекцию

Решаем проблему предыдущего этапа

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

Добавляем «И» — «Инспекцию»

Инспекция. Перед финальным ответом проверь:

• Все шаги нумеруются по порядку без петель.

• Каждый Alt Flow ссылается на существующий шаг.

• У каждого шага есть Actor и System Action.

Если условие не выполнено — исправь ответ, затем выведи.

Финальный ответ ИИ (фрагмент)

Шаг	Актор	Действие	ID альтернативного потока
1	Клиент	Запрашивает номер заказа	—
2	E‑com Core	Проверяет право на возврат, сверяя дату заказа и статус «Delivered» в OMS (≤ 14 дней)	2a
3	OMS	Генерирует этикетку возврата (REST /return/v2/label)	—
…	…	…	…
2a	E‑com Core	Если статус не «Delivered» — уведомление клиента об отказе в возврате	—

4.4 Итого: эволюция промта

Ревизия	Что добавили	Какая ошибка ушла
К-О-М	Ядро промта: «Кто, Обстановка, Миссия»	Ответ остаётся сырым, ошибки ещё не устранены
+ П‑О	«П‑О» — Позитивный и Отрицательный пример	Уходит размытая лексика, шаги становятся конкретными
+ З	«Зона работы»: Ограничения на источники данных, запрет фантазий	Пропадают «галлюцинации» о новых сервисах и статусах
+ И	«Инспекция» — Чек‑лист самопроверки: нумерация, петли, Actor/System Action	Устраняются петли, пропуски и несогласованности
+ Т-О-Р	Фокусировка результата: «Тон, Окружение, Результат»	Исчезает смешанный стиль и нужда в ручном форматировании

Главный результат: всего три коротких улучшения в середине промта  —  и мы перешли от «приемлемого» черновика к «готовому» артефакту, который можно сразу вложить в Confluence без дополнительного ревью.

Глава 5. Многоразовый промт: один шаблон

5.1 Шаблон, который не меняется

После шага 4 у нас появился промт фреймворка КОМПОЗИТОР. Он уже содержит:

• роль, контекст и миссию;

• позитивный и отрицательный примеры;

• жёсткие границы данных (интервью + журнал событий за 6 месяцев);

• чек‑лист самопроверки, тон, целевую аудиторию и формат вывода.

Теперь этот шаблон можно использовать для создания остальных юскейсов на проекте с теми же исходными данными (интервью + журнал событий за 6 месяцев)

Промт по фреймворку КОМПОЗИТОР

Кто ты? Ты — системный и бизнес‑аналитик в одной роли, отвечающий за описание процессов e‑commerce.
Обстановка: Стартовая discovery‑фаза проекта «Возврат товара»; есть стенограммы пользовательских интервью, диаграмма классов, диаграмма состояний возврата, SLA‑таблица.
Миссия: Составь юскейс «Оформление возврата» по шаблону Кокберна, без диаграмм, только текст.

Позитивный пример идеального шага основного сценария:
«Система проверяет право на возврат, сверяя дату заказа и статус "Delivered" в OMS (не более 14 дней)».
Отрицательный пример — «Система проверяет, если всё ок — возврат, иначе — отказ». Избегай размытых формулировок.
Зона работы: используй только факты из интервью и источников: UML‑классы ReturnRequest, Payment, Customer, диаграмма состояний возврата, SLA‑таблица. Запрещено придумывать новые статусы и связи. Если требуемых данных не хватает — укажи TODO со ссылкой на отсутствующий объект. Допустимые статусы доставки: «Delivered», «Returned».
Инспекция. Перед финальным ответом проверь:

• Все шаги нумеруются по порядку без петель.

• Каждый Alt Flow ссылается на существующий шаг.

• У каждого шага есть Actor и System Action.

Если условие не выполнено — исправь ответ, затем выведи.

Тон: деловой, лаконичный, каждое действие с новой строки.
Окружение: читатели — продукт‑оунер и команда разработки.
Результат: выведи результат в таблицу с колонками: Шаг, Актор, Действие, ID альтернативного потока

Единственное, что меняем от задачи к задаче — строку М (Миссия). Всё остальное остаётся неизменным.

5.2 Пример 1.Юскейс «Инициировать возврат»

М (миссия): «Составь юскейс „Инициировать возврат“ по шаблону Кокберна».

Ответ ИИ (фрагмент)

Шаг	Актор	Действие	ID альтернативного потока
1	Клиент	Запрашивает номер заказа	—
2	E‑com Core	Проверяет срок и статус («Delivered», ≤ 14 дней)	2a
3	OMS	Создаёт заявку возврата (/return/v2/request)	—

Результат: Вся нумерация ровная, ни одного придуманного статуса.

5.3 Пример 2. Юскейс «Получить ярлык возврата»

М (миссия): «Составь юскейс „Получить ярлык возврата“ по шаблону Кокберна».

Ответ ИИ (фрагмент)

Шаг	Актор	Действие	ID альтернативного потока
1	Клиент	Валидирует ID заявки возврата	1a
2	OMS	Генерирует PDF‑этикетку (/return/v2/label)	—
3	Notification Service	Отправляет ссылку на email	—

Результат: ни одной «галлюцинации»: сервисы и эндпоинты совпадают с журналами вызовов.

5.4 Пример 3. Юскейс «Отказать в возврате»

М (миссия): «Составь юскейс „Отказать в возврате“ по шаблону Кокберна».

Ответ ИИ (фрагмент)

Шаг	Актор	Действие	ID альтернативного потока
1	E‑com Core	Проверяет срок (> 14 дней)	—
2	E‑com Core	Формирует отказ с кодом RETURN_EXPIRED	—
3	Notification Service	Уведомляет клиента (/notify/v1/send)	—

Результат: Снова без пропусков и петель — чек‑лист «Инспекции» удерживает логику.

5.5 Что даёт многоразовый промт

Показатель	Разовая задача (только промт «Кто ты — Обстановка — Миссия)	Полный фреймворк «КОМПОЗИТОР»
Время на формулировку запроса	10–15 мин	1 мин (подставить новую миссию)
Неявные допущения в ответе	3–5 на юскейс	0–1 (редкость)
Итерации ревью	2–3 круга	0–1 короткая правка
Повторяемость формата	ненадёжна	100 % — одна таблица, один стиль

5.6 Вывод главы

• Один тщательно собранный промт масштабируется на любые под‑задачи внутри проекта «Возврат v2».

• Качество держится без ручного микроменеджмента: примеры, зона и инспекция автоматически «выправляют» ответ.

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

Таким образом, потраченный час на сборку полного КОМПОЗИТОР‑промта окупается после первых же трёх‑четырёх юскейсов и остаётся полезным на всём протяжении discovery‑фазы.

Глава 6. Экономика внедрения:«КОМПОЗИТОР» vs ручная работа без ИИ

В предыдущих главах мы сравнивали разные уровни промтов. Здесь рассмотрим самый привычный для команд сценарий — документы пишутся целиком вручную, ИИ вообще не используется. Именно с такой «нулевой» базы и имеет смысл считать выгоду от шаблона «КОМПОЗИТОР».

6.1 Метрики, на которые смотрим

Метрика	Как измерить	Почему важна
Lead Time	Время от постановки задачи «описать юскейс» до одобренного документа без замечаний	Чем меньше — тем быстрее фича уходит в разработку
Раунды ревью	Сколько раз архитектор/тим‑лид возвращает документ на доработку	Показывает качество на первом выходе
Дефекты на этапе разработки	Баг‑репорты, где причина — «неясное требование»	Именно такие дефекты самые дорогие

6.2 До и после внедрения фреймворка «КОМПОЗИТОР»(в рублях и часах)

Показатель	Без ИИ (ручной Word/Confluence)	С шаблоном КОМПОЗИТОР
Среднее время на юскейс	2,5 ч	20 мин ≈ 0,33 ч
Раунды ревью	2‑3	0‑1
Дефекты «требование неясно»	3‑5 на спринт	0‑1 разовые уточнения

Экономия в часах:2,5 ч → 0,33 ч (20 мин)

• 2,5 ч — усреднённый опыт команд: 1,5 ч пишет аналитик, ещё час уходит на комментарии и правки.

• 0,33 ч (20 мин) — фактическое время, чтобы подставить одну новую строку «Миссия» в готовый шаблон, запустить ИИ и просмотреть таблицу.

Экономия в деньгах

Для оценки возьмём среднюю ставку аналитика и тим-лида, который проверяет работу — 3 000 руб./ч

Экономия на одном юскейсе:
(2,5 − 0,33) ч × 3 000 руб./ч ≈ 6 500 руб.

Если в discovery‑фазе «Возврат v2» мы оформили 12 юскейсов:
6 500 руб. × 12  = 78 000 руб. чистой экономии только на писательском труде, не считая снижения количества багов.

6.3 Как внедрять ИИ с фреймворком «КОМПОЗИТОР» в процесс

1. Выберите пилот. Подойдёт блок задач, где паттерны повторяются. Такое место в бэклоге часто называют «фича‑банк» — список будущих функций (features), из которого команда регулярно «достаёт» работу.

2. Зафиксируйте шаблон. Создайте страницу с промтом, созданным по фреймворку КОМПОЗИТОР. Единственное поле, которое меняет аналитик — Миссия.

3. Автоматизируйте чек‑лист с «Инспекцией».

   • Сохраните ответы ИИ в .md‑файлах репозитория.

   • Добавьте git pre‑commit‑скрипт (например, на Python), который:

   • проверяет, что таблица содержит нужные колонки

   • убеждается, что нумерация шагов 1, 2, 3... без пропусков;

   • если есть петли или пропущенные колонки — отклоняет commit, и pull‑request не попадёт в review.

   • Такое правило держит качество даже тогда, когда шаблоном пользуются разные люди.

4. Проведите 30‑минутный мастер‑класс. Дайте три примера миссий (например, инициировать возврат, получить ярлык, отказать в возврате). Пусть участники вставят их в шаблон и увидят одинаково чистый результат.

5. Проверьте эффекты через спринт. Сравните фактический Lead Time и число ревью‑кругов с данными из § 6.1. Если время не упало минимум на 50 % — посмотрите, не забыт ли в промте блок «З» (Зона работы) или «И» (Инспекция). Именно их отсутствие чаще всего даёт скачок ошибок.

6.4 Когда внедрение шаблона не окупится

• Уникальная одноразовая задача. Экономия повторяемости отсутствует.

• Новый домен без данных. Если нет ни расшифровок интервью с заказчиками, ни созданных артефактов, то нечего положить в «Зону работы», и ИИ будет фантазировать.

• Среда без wiki или git. Вы теряете бонусы от блока «Результат» (формат) и проверки pre‑commit.

Или можно прибегнуть к простому правилу: есть минимум три схожие задачи — шаблон окупится.

6.5 Главные выводы

• Фреймворк «КОМПОЗИТОР» — это управляемое сокращение затрат: время падает в 5‑7 раз, деньги — на десятки тысяч рублей уже в первом спринте.

• Экономия достигается не «магией ИИ», а системной рамкой: примеры, зона, инспекция.

• Чем больше повторяющихся юскейсов, тем сильнее кумулятивный эффект: один раз собрали — дальше лишь подставляете новую миссию.

Заключение

ИИ‑ассистент может быть либо бесполезным собеседником, либо настоящим коллегой — всё решает промт.

Фреймворк «КОМПОЗИТОР» переводит работу чат-ботом из импровизации в технологию:

1. К-О-М (промт «Кто ты — Обстановка — Миссия»)даёт прочный каркас роли, контекста и цели.

2. П‑О‑З‑И (промт «Позитивный пример — Отрицательный пример — Зона работы — Инспекция») вводят обучение на примерах, защиту от «галлюцинаций» и самопроверку.

3. Т-О-Р («Тон — Окружение — Результат») фиксирует стиль, адресата и формат, превращая черновик в готовый артефакт.

Попробуйте уже сегодня: возьмите первую задачу, опишите «КОМ», затем шаг за шагом нарастите до полного «КОМПОЗИТОР». К моменту, когда появится вторая похожая задача, вы почувствуете разницу во времени, качестве и спокойствии команды.

Приложение A. Фреймворк «КОМПОЗИТОР» для копирования

Инструкция: скопируйте и заменяйте только содержимое после двоеточий.

• Если задача маленькая — оставьте «К-О-М».

• Если нужна точность — добавляйте блоки по порядку до полного фреймворка «КОМПОЗИТОР», основываясь на ответах ИИ

• Если важен формат вывода, но допустима креативность — используйте «К-О-М» + «Т-О-Р»

Промт по фреймворку КОМПОЗИТОР

Кто ты? Ты — … (роль ИИ или человека).
Обстановка: … (контекст, история, фаза проекта).
Миссия: … (чёткая цель/артефакт, например: «Составь юскейс ...»).

Позитивный пример: "…"(пример идеального фрагмента).
Отрицательный пример: "…"(пример плохого фрагмента).

Зона работы: Используй только … (источники, допускаемые данные). Не придумывай … Если требуемых данных нет, укажи TODO со ссылкой на объект.
Инспекция: Перед ответом проверь:

• [ ] … (чек‑лист нумерации, ссылок, петель).

Если условие не выполнено — исправь ответ, затем выведи.

Тон: … (тон: деловой, дружелюбный, gdb и т.д.).
Окружение: … (для кого пишем: разработчики, CEO).
Результат: Выведи результат в … (таблица Confluence, JSON, PlantUML и пр.).

Приложение Б. Фреймворк «КОМПОЗИТОР» для запоминания

• Инструкция: Распечатайте таблицу или добавьте на видное место на экране — одного взгляда хватит, чтобы вспомнить порядок блоков и видеть сквозной пример.

Запомнить	Роль в промте	Пример для BA/SA
К — Кто ты?	Определи роль ассистента	— «Ты бизнес‑аналитик в проекте по логистике» — «Ты системный аналитик в банке» — «Ты UX‑исследователь в e‑commerce‑стартапе»
О — Обстановка	Опиши контекст	— «Discovery‑фаза финтех‑приложения» — «Post‑release support интернет‑магазина» — «Миграция ERP на облако»
М — Миссия	Сформулируй цель	— «Составь юскейс “Отмена заказа”» — «Опиши BPMN процесса возврата» — «Подготовь нефункц‑требования к API»
П — Позитивный пример	Показать, как надо	— «Система проверяет статус “Delivered”» — «Запрос возвращает ≤ 50 элементов» — «Задержка в 95% ≤ 200 мс»
О — Отрицательный пример	Показать, как не надо	— «Система проверяет, что статус корректный» — «API отвечает быстро» — «Пользователь доволен»
З — Зона работы	Очертить границы	— «Опирайся на стенограммы» — «Не добавляй новые статусы» — «Используй Swagger v1» — Если требуемых данных не хватает — укажи TODO со ссылкой на отсутствующий объект.
И — Инспекция	Чек‑лист самопроверки	— «Проверь нумерацию шагов» — «Каждый gateway имеет 2 исхода» — «Нет петель в диаграмме»
Т — Тон	Стиль ответа	— «Деловой, лаконичный» — «Дружелюбный FAQ‑формат» — «Техническая справка» — «GDB-режим»
О — Окружение	Для кого пишем	— «PO и разработчики» — «Финансовый директор» — «Команда QA»
Р — Результат	Формат вывода	— «Таблица Confluence» — «JSON‑snippet» — «PlantUML‑диаграмма»

Автор — Алина Богачёва

■ Исполнительный (CEO) и финансовый (CFO) директор школы Systems.Education

■ Архитектор бизнес-решений в области финансов

■ Проектировала финансовые системы для Деловых Линий, Concept Club и Айсберри

■ Опыт управления отделами до 30 человек

■ Член Федеральной палаты налоговых консультантов