Как написать промпт для ИИ
За последние годы ИИ повернулся лицом к пользователям, и понимает нас буквально с полуслова. Однако качественный запрос (промпт) позволяет получить более предсказуемый результат:
• с меньшей двусмысленностью и «галлюцинациями»;
• с нужным уровнем детализации через примеры;
• с самопроверкой и форматом результата.
Запомнить мнемонически все нужные элементы промпта помогает фреймворк «КОМПОЗИТОР», который делит задачу на блоки и усиливает результат пошагово.
Элементы КОМПОЗИТОРа
«К О М» — основа
• К — Кто ты? Роль задаёт рамку экспертизы. Примеры: «Ты финансовый аналитик в банке», «Ты бизнес аналитик в проекте по логистике».
• О — Обстановка. «Где мы? Какая предыстория?» Контекст отсекает лишние допущения. Примеры: «Фаза инвестиционной оценки проекта», «Миграция ERP на облако».
• М — Миссия. «Что должно получиться в конце?» Фиксирует целевой артефакт. Примеры: «Опиши процесс возврата», «Подготовь функциональные требования к системе».
«П О З И» — фокус и качество
• П — Позитивный пример: эталонный фрагмент ответа. Примеры: «Система проверяет статус “Доставлено”», «Запрос возвращает ≤ 50 элементов».
• О — Отрицательный пример: почти то же, но с ключевой ошибкой. Примеры: «Система отвечает медленно», «Пользователь недоволен».
• З — Зона работы: допустимые данные и границы. Примеры: «Опирайся на отчетность», «Не добавляй новые статусы», «Если данных не хватает — укажи TO DO».
• И — Инспекция: чек лист самопроверки. Примеры: «проверь нумерацию шагов», «проверь корректность вычислений».
Финальный аккорд «Т О Р»
• Т — Тон: фиксируем стиль (деловой, разговорный).
• О — Окружение: инструменты, источники, единицы.
• Р — Результаты: формат вывода, метрики, дедлайн.
Советы по составлению промптов
• Давайте короткие примеры — они задают требуемую детализацию быстрее запретов.
• Жёстко ограничивайте «Зону работы» и добавляйте «Инспекцию» — это уменьшает ошибки и повышает воспроизводимость.
• Для экономии своего времени делайте промпты, универсально
Дата-аналитику, как и в принципе любому другому, тоже нужно работать с требованиями. Особенно это умение ценится у начинающих специалистов
Есть классная, но не очень распространенная методика приема требований в работу: ЛЮСТРА
1️⃣Л - легитимность. Имеет ли право этот человек выставлять нам требования, является ли он нашим стейкхолдером
2️⃣Ю - юзер. Какая роль у этого человека в системе?
3️⃣С - стори. Описанная в формате User story или Job story
4️⃣Т - требование. Понятно ли вообще, что необходимо делать?
5️⃣Р - решение/ресурс. Понятно ли, как решить задачу, каких вводных не хватает? Хватает ли времени/денег на решение этой задачи, точно ли её нужно решать сейчас?
6️⃣А - а потом всё остальное
Стажировки на проектах для НКО
Я сейчас запустил работу с НКО по консалтингу в сфере бизнес-процессов, оргразвития и автоматизации
В воронке есть заявки от 10 НКО.
Собираю команды волонтёров аналитиков-проектировщиков для стажировки на таких проектах, в каждом проекте нужно 1-3 специалиста.
Ожидаемый срок проектов — 3 месяца до конца года.
Какие компетенции нужны сейчас:
— Event Storming, BPMN
Что ещё можно будет прокачать:
— Применение ИИ
— Разработку требований
— Проектирование архитектурных и интеграционных решений,
отдельно при желании — менеджмент.
От вас нужно минимум 10 часов в неделю, из них минимум 2 раза по часу в рабочее время.
Если интересно, пишите рассказ о себе в личку
Путь СЕРДЦА Бескова и Богачёвой: как подобрать способ реализации любой задачи
Сначала выясняем драйвер проекта
С — сбой, который тянет нас назад ИЛИ
Е — ещё: всё хорошо, но хотим сделать ещё лучше
Р — результат. Определяем результат, который должен обеспечивать бизнес или любая другая система. При сбое это результат, который не выполняется, а если хотим ещё лучше — определиться, что именно?
Доступные ресурсы на этот проект
Цель проекта
Альтернативы: составляем список вариантов решений, которые позволяют выполнить результаты при доступных ресурсах, чтобы достичь цели
Технология проектирования архитектуры
Основатель Systems.Education Денис Бесков впервые выступил на конференции ArchDays и поделился результатами исследования того, как современные архитектурные практики можно уложить в целостную технологию проектирования:
1. Что сложного в архитектурном процессе?
2. Вопросы исследования и источники
3. Последовательный обзор 11 практик в порядке внедрения
4. Ещё 5 практик для корпоративного контекста
5. Инсайты исследования
6. Выводы и оценка технологии
7. Планы развития
8. Источники исследования
Технология может быть использована как для построения плана развития процесса в конкретном проекте или отделе, так и для планирования собственного развития кандидатов в архитекторы и начинающих архитекторов.
Слайды: https://se.ink/db4ard
#архитектура@systems_education
Видео Видео_Денис_требования_меньше_размер.mp4 · 29.0 МБ · нажмите — покажем
Я пишу и учу про требования не как про «документацию», а как про способ управления рисками.
Если требования сделаны правильно, вы можете:
— вовремя сказать go / no-go
— выбрать класс решения или вендора по делу (а не по маркетингу)
— удержать scope
— снизить риск «строим не то» и ROI<0
Что делаем за 2 недели (20 часов):
— соберём требования ровно той глубины, которая нужна вашему проекту (не больше и не меньше);
— пройдём 3 итерации: от целей/границ до критериев приёмки;
— отдельно покажу, как применять GenAI: генерация + проверки полноты/согласованности.
Февральский поток курса:
— Zoom
— 2 недели, 20 часов
— будни утро 9:00–11:00
— старт 09.02 пнд
— только 6 мест (потому что будет разбор/фидбек)
Стоимость: 60 000 ₽ частным лицам / 70 000 ₽ компаниям
———
Кому подойдёт:
— системным/бизнес-аналитикам, архитекторам, продактам и руководителям, кто отвечает за результат ИС;
— если вы сейчас выбираете решение / запускаете проект / хотите остановить «плохой» проект вовремя.
Кому НЕ подойдёт:
— если вам нужен «шаблон ТЗ» без привязки к решениям и рискам;
— если не можете участвовать в 9–11.
———
Анкета предзаписи откроется 23.01 (на 48 часов).
Если хотите — можете уже сейчас написать мне: @beskov
Чужой против Хищника: как ИИ разбирает российские законы
Строгость российских законов смягчается необязательностью их исполнения — попробуйте объяснить эту крылатую фразу системе, в которой должны быть зашиты правила, проверки и статусы.
7 апреля в 19:00 на бесплатном вебинаре Алина Богачёва и Денис Бесков покажут, как переводить юридический на язык системных и бизнес-аналитиков.
Как из фразы, после которой хочется закрыть ноутбук и уйти в лес, получить понятное бизнес-правило и нормальное требование к системе. И нет, промт «ИИ, нормально сделай мне анализ закона» не работает.
Будем использовать ИИ как ассистента, который помогает разложить текст по цепочке: норма → логика → бизнес-правило → требование. Отработаем на реальных примерах.
Допустим, возьмём 152-ФЗ, статья 18, часть 5 (не пытайтесь это прочитать самостоятельно без помощи профессионала):
При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети "Интернет", запись, систематизация, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся за пределами территории Российской Федерации, не допускаются, за исключением случаев...
Для бизнеса: переходим с Google Forms на Яндекс формы.
Для системы: если в контуре есть внешний IdP, CRM, SaaS-форма или сервис авторизации, они не должны быть первичной точкой записи персональных данных граждан РФ.
Или, скажем, 63-ФЗ, статья 11 (уберите детей от экрана):
Квалифицированная электронная подпись признается действительной, если квалифицированный сертификат действителен на момент подписания электронного документа (при наличии достоверной информации о моменте подписания электронного документа) или на день проверки действительности указанного сертификата, если момент подписания электронного документа не определен...
Для бизнеса: короче, используйте Госключ и живите спокойно.
Для системы: проверка КЭП должна быть не булевым полем is_s
Почему я не верю в запросы вида
«извлеки требования из закона»
Zero Shot отлично создаёт ощущение, что задача уже решена: вы даёте модели закон, получаете аккуратный список в стиле «система должна» и кажется, что аналитика закончена.
Но в реальности такой ответ чаще даёт не требования, а текст, похожий на требования.
В статье разбираю, почему это происходит:
— закон не равен готовому backlog
— модель смешивает определения, ограничения и действия
— не выбирает, для кого вообще строятся требования
— не показывает, что потеряла по дороге
— и слишком рано создаёт видимость завершённого анализа
Если вы работаете с нормативкой, ИИ и проектированием систем, это как раз тот случай, где красивый ответ может стоить дорого:
https://habr.com/ru/articles/1020406/
Во второй статье покажу, как разбирать закон так, чтобы ИИ реально ускорял работу, а не производил правдоподобный мусор.
NB: Напоминаю, что сегодня в 7 проводим с Алиной вебинар, где представим свою пошаговую методику https://t.me/denis_beskov/693
Вчера провели вебинар, к нам пришли 90 человек, очень интересно было пообщаться, ответить на вопросы и обсудить методику.
Если вы пропустили — ничего страшного.
Во-первых, можете посмотреть презентацию
Во-вторых, в это воскресенье проводим мастер-класс:
▫3000 руб. — вместе с нами попрактиковаться в методике, получить готовые инструкции и промты
▫12000 руб. — разложим на требования именно тот закон, который нужен вам
Зарегистрироваться на мастер-класс
Я радикально обновил свой курс по разработке требований, сделал его AI-driven и сам буду его вести по выходным с 16 по 31 мая:
https://systems.education/sard
Сделал курс для аналитиков, которым нужен не ИИ-аттракцион, а рабочая инженерная практика:
— как извлекать требования из интервью, документов, тикетов и регламентов;
— как с помощью ИИ формировать критерии выбора решения;
— как связывать требования с процессами, интеграциями и архитектурой;
— как доводить требования до уровня, с которым может работать разработка;
— как использовать ИИ не только для генерации, но и для критики, проверки и поиска пробелов;
— как работать без галлюцинаций, не теряя скорость и глубину анализа.
Курс про то, как перейти от старой модели
— «аналитик оформляет документы»
к новой:
— «аналитик с помощью ИИ извлекает, синтезирует, проверяет и связывает требования в систему».
В программе:
— проблема, цели, границы и процессный контекст;
— источники требований и критерии выбора решения;
— процессный анализ: события, решения, автоматизация;
— требования для архитектурного проектирования;
— подготовка требований к разработке: детализация и проверка;
— трассировка, изменения и анализ влияния.
Для кого:
— системные и бизнес-аналитики;
— product owners и product managers;
— solution designers;
— архитекторы и тимлиды, которым важно качество требований.
Формат: 6 занятий по 4 часа, практика на каждом модуле, домашние задания между занятиями.
Если вам важно не просто «использовать ИИ», а встроить его в серьёзную аналитическую работу — этот курс для вас.