Перейти к содержимому

Трек: аналитик

Работа аналитика — это превращение разрозненной информации в структуру: заметки со встреч в требования, вопросы бизнеса в отчёты по данным, договорённости в задачи для разработки. Агент (agent) берёт на себя первый, самый трудоёмкий проход: собрать, переструктурировать, оформить черновик. За вами остаётся то, что делает аналитика аналитиком: понимание бизнеса, проверка фактов и решения о том, что важно, а что нет.

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

Есть и новая обязанность — верификация. Агент пишет гладко и уверенно вне зависимости от того, прав он или нет. Аналитик, который отправляет черновик агента стейкхолдерам не проверив цифры и факты, рискует репутацией сильнее, чем тот, кто медленно пишет сам. Базовые приёмы описаны в разделе Проверка результатов.

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

Как поставить агенту:

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

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

2. Исследование предметной области и конкурентов

Заголовок раздела «2. Исследование предметной области и конкурентов»

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

Как поставить агенту:

Я готовлю требования к функции рассрочки в интернет-магазине.
Найди через веб-поиск, как устроена рассрочка у трёх крупных
российских маркетплейсов: лимиты, сроки, комиссии, процесс
одобрения. По каждому факту давай ссылку на источник. Если
информации нет в открытых источниках — так и пиши, не оценивай.

Как проверить. Откройте источники по ключевым фактам и убедитесь, что там написано именно это, а не «примерно это». С цифрами и датами будьте особенно осторожны: их агент путает чаще всего. Факты без ссылки на источник считайте непроверенными.

Задача. Ответить на вопрос бизнеса цифрами: написать запрос, посчитать метрику.

Как поставить агенту:

Вот схема таблиц orders, customers и payments (ниже). Напиши SQL:
доля заказов, оплаченных с первого раза, по месяцам за последний
год, в разрезе регионов. Поясни каждый JOIN и почему выбран такой
способ определить «первую попытку оплаты». Если по схеме что-то
неоднозначно — спроси, прежде чем писать.
[схема таблиц]

Как проверить. Запустите запрос на данных, где ответ известен заранее, или сверьте итог с уже посчитанной метрикой за прошлый период. Проверьте краевые случаи: заказы без оплат, дубли платежей. Правдоподобная цифра из неверного запроса — самая опасная ошибка этого сценария.

4. Проверка требований на полноту и противоречия

Заголовок раздела «4. Проверка требований на полноту и противоречия»

Задача. Документ требований готов; перед передачей в разработку нужно найти дыры.

Как поставить агенту:

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

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

Задача. Из согласованных требований сделать задачи в трекере, единообразно оформленные под стандарт команды.

Как поставить агенту. Разовый промпт сработает, но лучше упаковать шаблон команды в скил (skill), и тогда агент будет применять его сам, без напоминаний (см. Скилы):

Используй наш скил постановки задач. Из согласованных требований
по функции возврата (файл requirements-returns.md) подготовь
задачи для бэкенда и фронтенда: контекст, что сделать, критерии
приёмки, зависимости между задачами. Одна задача — не больше
трёх дней работы; если получается крупнее, дели.

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

Задача. Задокументировать API по коду или описать процесс «как есть».

Как поставить агенту:

Изучи контроллеры в src/api/v2 и составь документацию эндпоинтов:
метод, путь, параметры, формат ответа, коды ошибок. Помечай
маркером [?] всё, что не удалось однозначно понять из кода,
вместо того чтобы угадывать. Формат — Markdown-таблица
на каждый эндпоинт.

Как проверить. Выборочно вызовите два-три эндпоинта и сравните реальный ответ с описанием. Все места с маркером [?] уточните у разработчиков: это ваши точки риска.

  • Выдуманные факты и цифры. Галлюцинация (hallucination) в аналитике выглядит как убедительный факт с конкретным числом: «у конкурента 40% рынка». Правило простое: факт без проверяемого источника не попадает в документ, который читают другие люди.
  • Устаревшие данные. У модели есть дата отсечки знаний (knowledge cutoff): о том, что случилось после неё, модель не знает, но охотно отвечает по старым данным. Всё, что меняется со временем (цены, версии, законы, конкуренты), проверяйте через веб-поиск с датой источника.
  • Конфиденциальность бизнес-данных. Прежде чем вставлять в промпт заметки со встреч, финансовые показатели, клиентские данные, убедитесь, что политика компании это разрешает и что выбранный инструмент не использует ваши данные для обучения. Подробнее см. раздел Безопасность.
  1. Что такое LLM и Токены и контекстное окно: откуда берутся ответы и почему длинный документ «не влезает».
  2. Что такое агент: чем агент отличается от чата.
  3. Промптинг и Контекст-инжиниринг: главные навыки для ваших сценариев.
  4. Проверка результатов и Безопасность: обязательный минимум перед работой с реальными данными.
  5. Скилы и MCP: как подключить агента к шаблонам команды и корпоративным системам.
  1. Возьмите заметки с последней встречи и попросите агента превратить их в черновик требований с отдельным списком открытых вопросов. Сравните с тем, что написали бы сами, и заметьте, что агент додумал.
  2. Прогоните действующий документ требований через проверку на полноту и противоречия (сценарий 4). Даже по хорошему документу обычно набирается несколько стоящих вопросов.
  3. Оформите шаблон постановки задач вашей команды как скил или текстовый файл-инструкцию и попробуйте поставить одну задачу через него. Про формат см. раздел Скилы.
  • Промптинг: как формулировать задачи, чтобы черновики требовали меньше правок.
  • Безопасность: что можно и что нельзя отправлять в модель.

Автор учебника — Шахматов Алексей