AI: как превратить интервью со стейкхолдерами в структурированные требования

Вы провели часовое интервью. На диктофоне 57 минут записи. Стейкхолдер эмоционально рассказывал про боли пользователей, попутно перепрыгивая с отчётности на безопасность, а под конец вспомнил, что «ещё бы интеграцию с SAP добавить, ну чисто на будущее». Теперь из этого нужно достать требования. Если вы садитесь и переслушиваете запись, делая пометки в блокноте — готовьтесь потратить 3–4 часа. LLM справляется за минуты. Но есть нюанс.

Интервью — не переписка в чате. В чате люди пишут коротко и (иногда) по делу. В интервью они говорят. С оговорками, эмоциями, уходом в сторону и фразами «ну вы меня поняли». LLM без контекста прочтёт это как поток сознания — и выдаст поток сознания в ответ. В этой статье — pipeline, который превращает эмоциональный монолог стейкхолдера в структурированные ФТ, НФТ, User Story и, что немаловажно, список конкретных вопросов для второго раунда. Плюс промпты, которые я обкатал на полутора десятках реальных встреч.

Если вам нужна база по извлечению требований из любого источника (чаты, документы, письма) — начните с общей статьи про AI в системном анализе. А если финальный документ требований — это то, что вы должны положить разработчику на стол, то вот структура ТЗ без воды. Теперь — к специфике.

graph LR
  AUDIO["Аудиозапись<br/>интервью"]
  TRANSCRIBE["Транскрибация<br/>Whisper / API"]
  CLEAN["Очистка<br/>транскрипта"]
  STAKEHOLDER["Список<br/>стейкхолдеров"]
  AGENDA["Повестка<br/>встречи"]
  EXTRACT_STRUCT["Извлечение<br/>структуры: роли,<br/>цели, ограничения"]
  EXTRACT_FT["Извлечение ФТ<br/>функциональные<br/>требования"]
  EXTRACT_NFT["Извлечение НФТ<br/>нефункциональные<br/>требования"]
  DETECT["Поиск<br/>противоречий и<br/>неоднозначностей"]
  CLARIFY["Генерация<br/>вопросов для<br/>уточнения"]
  STORIES["Формирование<br/>User Story<br/>по шаблону"]
  OUTPUT["Структурированные<br/>требования: ФТ + НФТ<br/>+ User Story + вопросы"]

  AUDIO --> TRANSCRIBE
  TRANSCRIBE --> CLEAN
  CLEAN --> EXTRACT_STRUCT
  AGENDA --> EXTRACT_STRUCT
  STAKEHOLDER --> EXTRACT_STRUCT
  EXTRACT_STRUCT --> EXTRACT_FT
  EXTRACT_STRUCT --> EXTRACT_NFT
  EXTRACT_FT --> DETECT
  EXTRACT_NFT --> DETECT
  DETECT --> CLARIFY
  CLARIFY --> STORIES
  STORIES --> OUTPUT

  style AUDIO fill:#e0e0e0,stroke:#999,color:#333
  style TRANSCRIBE fill:#f0a500,stroke:#c88400,color:#fff
  style CLEAN fill:#f0a500,stroke:#c88400,color:#fff
  style STAKEHOLDER fill:#e0e0e0,stroke:#999,color:#333
  style AGENDA fill:#e0e0e0,stroke:#999,color:#333
  style EXTRACT_STRUCT fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style EXTRACT_FT fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style EXTRACT_NFT fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style DETECT fill:#7b68ee,stroke:#5a4db2,color:#fff
  style CLARIFY fill:#f0a500,stroke:#c88400,color:#fff
  style STORIES fill:#7b68ee,stroke:#5a4db2,color:#fff
  style OUTPUT fill:#50c878,stroke:#3a9a5c,color:#fff

На схеме — полный маршрут: аудиозапись (серая) проходит транскрибацию и очистку (жёлтые этапы). Параллельно поступают метаданные — список участников и повестка встречи. Из очищенного текста LLM извлекает структуру: роли, цели, ограничения (синий), а оттуда параллельно — ФТ и НФТ (синие). Оба потока уходят в блок поиска противоречий (фиолетовый), который генерирует вопросы для уточнения у стейкхолдеров (жёлтый). После ответа на вопросы требования собираются в User Story (фиолетовый) и выходят готовым пакетом (зелёный).

Примечательно, что без повестки модель работает значительно хуже. Ей нужно понимать, к какому продукту или модулю относится разговор. Без этого контекста LLM либо обобщает до бесполезности, либо фантазирует.

Почему интервью сложнее, чем переписка

В чате люди пишут: «надо сделать кнопку экспорта». В интервью они говорят: «ну вот смотрите, у нас менеджеры, они каждый месяц выгружают отчёты, и это занимает два дня, потому что Эксель не тянет. Можно как-то автоматизировать? И ещё чтобы в PDF красиво, и с графиками. У конкурентов же есть».

Разница принципиальная. В переписке требование сформулировано — осталось его оформить. В интервью требование завёрнуто в боль, а боль завёрнута в эмоцию. LLM нужно два прохода, чтобы сначала отделить боль от эмоции, а потом из боли вытащить требование.

Транскрипт интервью — это неструктурированный текст с низкой плотностью требований. На 10 000 слов приходится 10–15 реальных требований. В переписке плотность в 3–4 раза выше.

Специфические ловушки интервью

Псевдо-требования. Стейкхолдер говорит: «нам нужно, чтобы система работала быстро». Это не требование — это пожелание. Требование: «время загрузки отчёта по 200 000 позициям не должно превышать 5 секунд». LLM склонна записывать пожелания как требования — её надо явно просить переформулировать.

Перескакивание контекста. За 20 минут интервью стейкхолдер может затронуть 4–5 разных тем, перебивая сам себя. LLM может «сплющить» этот контекст — приписать ограничение из темы А к требованию из темы Б. Решение — разбивать транскрипт по темам перед анализом.

Эффект «старшего по званию». На встрече кто-то один доминирует. Его требования модель считает более важными просто потому, что они занимают 70% текста. Это искажение нужно снимать явной инструкцией: «не ранжируй по частоте упоминания».

Молчаливое согласие. Фраза «возражений нет» не означает «требование валидно». Это может означать «я устал» или «мне всё равно, пусть аналитик разбирается». LLM читает это как подтверждение. Ваш явный промпт должен требовать маркировать молчаливое согласие отдельно.

sequenceDiagram
  participant A as Аналитик
  participant LLM as LLM-модель
  participant S as Стейкхолдеры

  A->>LLM: Загружает транскрипт<br/>интервью и повестку
  LLM->>LLM: Извлекает ФТ, НФТ,<br/>роли, ограничения
  LLM->>A: Возвращает черновик<br/>требований и список<br/>противоречий
  A->>LLM: Уточняет контекст,<br/>добавляет глоссарий<br/>домена
  LLM->>LLM: Перегенерирует<br/>требования с учётом<br/>контекста
  LLM->>A: Возвращает уточнённый<br/>список + вопросы<br/>стейкхолдерам
  A->>S: Направляет список<br/>вопросов для уточнения
  S->>A: Присылает ответы<br/>и уточнения
  A->>LLM: Загружает ответы<br/>стейкхолдеров
  LLM->>LLM: Интегрирует ответы,<br/>разрешает противоречия
  LLM->>A: Возвращает финальный<br/>документ требований<br/>в формате User Story
  A->>A: Проверяет, правит<br/>приоритеты, готовит ТЗ

Диаграмма показывает итеративный характер работы: это не одноразовый запрос к LLM, а цикл из нескольких раундов. Первый проход даёт черновик и список противоречий. Аналитик добавляет доменный контекст — глоссарий, бизнес-правила, известные ограничения — и получает уточнённый список плюс вопросы для стейкхолдеров. Ответы на эти вопросы загружаются обратно в LLM, противоречия разрешаются, и на выходе — финальный документ. Без этих итераций модель не даст качественного результата; она не волшебная палочка, а инструмент, который работает ровно настолько хорошо, насколько качественно его направляют.

Промпты: от записи до готовых требований

Шаг 0. Подготовка к интервью

Да, промпт пишется ДО встречи. Не чтобы модель интервью провела (пока рано), а чтобы она помогла вам к нему подготовиться.

1
Ты — системный аналитик, который готовится к интервью со
2
стейкхолдерами. Известна тема встречи и список участников
3
с ролями. Составь:
4

5
1. План интервью: 5–7 ключевых тематических блоков в логическом
6
   порядке. Не «поговорить про отчёты», а «какие данные нужны
7
   в отчёте, откуда они берутся, в каком формате нужен экспорт».
8
2. Для каждого блока — 3–4 конкретных вопроса, на которые
9
   нельзя ответить «да» или «нет».
10
3. Чек-лист «что может пойти не так»: какие противоречия
11
   вероятны между требованиями разных участников (исходя
12
   из их ролей).
13
4. Список нефункциональных аспектов, которые нужно затронуть
14
   (производительность, безопасность, отказоустойчивость),
15
   даже если стейкхолдеры про них не вспомнят.
16

17
Тема встречи: [тема]
18
Участники: [список с ролями]
19
Контекст продукта: [краткое описание]

Модель выдаст список вопросов, которые действительно двигают интервью вперёд. Я проверял: когда идёшь без подготовки — это разговор на 40 минут, из которых 15 — вода. С подготовкой через промпт — 30 минут плотного разговора и 0 минут «ну что ещё спросить».

Шаг 1. Первичная обработка транскрипта

После интервью у вас есть запись. Whisper (через API или локально) превращает её в текст. Дальше — очистка: убрать междометия, повторы, «э-э-э», фразы вроде «можно следующий слайд».

1
Ниже — транскрипт интервью. Очисти его:
2

3
1. Убери междометия, слова-паразиты, оговорки и самоисправления
4
   (когда человек начал фразу и переформулировал — оставь
5
   только итоговый вариант).
6
2. Убери обсуждение технических деталей демонстрации
7
   («переключите на следующий экран», «у вас звук пропал»).
8
3. Разбей текст на тематические блоки с заголовками. Каждый
9
   блок — одна тема обсуждения.
10
4. Для каждого блока укажи, кто из участников высказывался
11
   и какова была его позиция.
12
5. В конце каждого блока добавь резюме из 2–3 предложений:
13
   что именно обсуждалось и к какому выводу пришли (если
14
   пришли).
15

16
Не добавляй информацию, которой нет в транскрипте.
17

18
[текст транскрипта]

После этого шага у вас не 57-минутный поток сознания, а структурированный документ на 5–8 тематических блоков. С ним уже можно работать дальше.

Шаг 2. Извлечение требований из структурированного транскрипта

Это основной промпт. Он идёт после очистки — потому что грязный транскрипт модель прочитает, но требования из него вытащит с шумом. Очищенный — выдаст на порядок чище.

1
На основе очищенного транскрипта интервью ниже извлеки
2
все требования. Строго следуй правилам:
3

4
## Функциональные требования
5
Для каждого укажи:
6
- ID: FR-001, FR-002, ...
7
- Название: до 12 слов
8
- Описание: что система должна делать, для кого и при каких
9
  условиях
10
- Actor: роль, которая инициирует действие
11
- Предусловие
12
- Основной поток
13
- Альтернативные потоки (минимум 1, если применимо)
14
- Источник в транскрипте: процитируй фрагмент
15

16
## Нефункциональные требования
17
Для каждого укажи:
18
- ID: NFR-001, NFR-002, ...
19
- Категория: Производительность / Безопасность / Надёжность /
20
  Масштабируемость / Удобство использования / Интеграция /
21
  Регуляторное
22
- Описание
23
- Метрика (если можно извлечь из текста)
24
- Источник в транскрипте
25

26
## Особые правила для интервью
27
- Если требование сформулировано как пожелание (фразы «хорошо
28
  бы», «неплохо было бы», «в идеале», «на будущее») — извлеки
29
  его, но пометь как «Пожелание — [ТРЕБУЕТ КОНКРЕТИЗАЦИИ]».
30
- Если в транскрипте упоминается действие системы, но не указан
31
  actor — пометь «[НЕ УКАЗАН ACTOR]». Не додумывай.
32
- Если стейкхолдер говорит «как сейчас», «как раньше делали» —
33
  это описание текущего состояния, не требование к новой системе.
34
  Не включай это в ФТ. Если оно важно как контекст — вынеси
35
  отдельным блоком «Текущее состояние».
36
- Не ранжируй требования по частоте упоминания. Стейкхолдер,
37
  который говорит больше, не обязательно важнее.
38

39
## Поиск противоречий
40
Отдельным блоком выведи все найденные противоречия:
41
- Какие требования конфликтуют друг с другом?
42
- Какие требования одного участника противоречат требованиям
43
  другого?
44
- Где есть неоднозначность — ситуация, в которой можно понять
45
  требование двумя разными способами?
46

47
Для каждого противоречия укажи оба варианта интерпретации.
48

49
[очищенный транскрипт]

На этом этапе вы получите: 10–20 ФТ, 3–8 НФТ и 2–5 противоречий. И, что немаловажно, будете знать, что именно нужно уточнить. Это уже не абстрактное «надо бы ещё раз встретиться и поговорить», а конкретный список вопросов.

Шаг 3. Генерация вопросов для уточнения

Промпт превращает сырой список противоречий и пометок «[ТРЕБУЕТ УТОЧНЕНИЯ]» в вопросы, которые можно отправлять стейкхолдерам. Это важно: вопросы должны быть такими, чтобы на них ответил занятой человек. Не «раскройте, пожалуйста, ваше видение архитектуры» — а «валидация промокода должна быть синхронной или асинхронной?».

1
Ниже — список требований с пометками «[ТРЕБУЕТ УТОЧНЕНИЯ]»
2
и список противоречий. Сформулируй вопросы стейкхолдерам.
3

4
Правила для вопросов:
5
1. Каждый вопрос — одно предложение.
6
2. Каждый вопрос должен предполагать конкретный ответ:
7
   цифру, да/нет, выбор из вариантов. Никаких «расскажите
8
   подробнее».
9
3. Если возможных ответов несколько — перечисли их явно.
10
   Пример: «Валидация промокода: синхронно на бэкенде или
11
   асинхронно через очередь?»
12
4. Сгруппируй вопросы по адресатам. Отдельно — вопросы
13
   продакту, отдельно — разработчику, отдельно — безопаснику.
14
5. В начале каждого списка вопросов кратко объясни, зачем
15
   они задаются. Контекст для стейкхолдера: «Эти вопросы
16
   помогут определить, какой тип интеграции с CRM нам нужен».
17

18
Противоречия и требования:
19
[вывод шага 2]

Шаг 4. Финальная сборка после ответов

Стейкхолдеры ответили. Теперь нужно интегрировать ответы в требования — и перегенерировать User Story. Это финальный промпт, после которого вы получаете документ, пригодный для ТЗ.

1
Ниже — список требований (версия 1), список противоречий
2
и ответы стейкхолдеров на вопросы по уточнению. Выполни:
3

4
1. Разреши все противоречия на основе ответов стейкхолдеров.
5
   Если ответа недостаточно — оставь пометку
6
   «[ПРОТИВОРЕЧИЕ НЕ РАЗРЕШЕНО]» с объяснением, чего не
7
   хватает.
8
2. Удали или переформулируй требования, которые были
9
   отвергнуты в ответах стейкхолдеров.
10
3. Обнови все требования с пометками «[ТРЕБУЕТ УТОЧНЕНИЯ]»
11
   на основе ответов.
12
4. Сгенерируй User Story для каждого ФТ по шаблону:
13
   Как `<роль>`, я хочу `<действие>`, чтобы `<ценность>`.
14
5. Для каждой User Story напиши критерии приёмки
15
   в формате Given/When/Then (3–5 пунктов).
16
6. В финале выведи сводную таблицу: ID требования,
17
   User Story, статус (подтверждено / требует уточнения /
18
   отклонено).
19

20
Требования v1:
21
[вывод шага 2]
22

23
Противоречия:
24
[вывод шага 2, блок противоречий]
25

26
Ответы стейкхолдеров:
27
[текст ответов]

Что LLM ловит, а что пропускает — и что с этим делать

Главное правило: LLM не слышит интонацию. «Да, конечно, сделаем» может означать энтузиазм, а может — «я устал спорить, делайте что хотите, потом всё равно переделаете». Это различие модель не улавливает. Слушайте запись сами в спорных местах.

Пример из практики: интервью для интеграции платёжного шлюза

Кейс из финтеха. Задача — подключить нового платёжного провайдера. Одно интервью: 40 минут, три участника — продакт, техлид, безопасник. На выходе получили:

• 18 ФТ — от выбора провайдера на форме оплаты до обработки возвратов и chargeback
• 7 НФТ — включая PCI DSS-ограничения (безопасник напомнил дважды)
• 6 противоречий — самое острое: продакт хотел редирект на страницу провайдера, безопасник требовал собственный iframe
• 14 вопросов для уточнения — разосланы по трём адресатам на следующий день
• Финализированные требования — через два дня после ответов стейкхолдеров, готовые к передаче в разработку

Весь цикл занял 4 рабочих дня (с учётом ожидания ответов стейкхолдеров). Активное время аналитика — около 2 часов. Без LLM тот же объём занял бы минимум полтора дня чистого времени.

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

Заключение

Интервью со стейкхолдерами — это, наверное, самый недооценённый use case для LLM в работе аналитика. Все говорят про «AI сгенерирует код» и «AI напишет документацию», а про то, что модель может вытащить из часового разговора структурированные требования, ищет противоречия и формулирует вопросы — почему-то молчат.

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

Попробуйте на одном интервью. Запишите, очистите, прогоните через промпты. Если результат сырой — докрутите промпты. Ко второму-третьему разу вы получите инструмент, который сокращает цикл «встреча → требования» с дней до часов. А освободившееся время потратьте на то, ради чего вы в профессии: на проектирование решений.

P.S. Единственное, что LLM не сделает за вас — это не пойдёт на встречу вместо вас. Хотя, если честно, я бы посмотрел на попытку. Представьте: Zoom, в окне — окно терминала, и модель ведёт интервью, периодически выдавая: «Уточните, пожалуйста, какой именно перцентиль времени ответа вас устроит». Боюсь, после такого стейкхолдеры перестанут приходить на встречи. А может, и наоборот.