TL;DR
LENS — техника, которая вытаскивает из текста интервью не только то, что сказано прямо, но и то, что осталось между строк. Работает в два шага: сначала собирает явные запросы, затем смотрит на те же слова через призму «а какие инструменты у нас уже есть?» — и генерирует скрытые возможности, которые собеседник не сформулировал.
Главная находка: люди описывают боль, но не просят решение. Говорят «мы вручную слушаем записи звонков два часа в месяц» — и молчат. LLM без контекста тоже промолчит: она не знает, что у вас есть чат-бот, который умеет транскрибировать. Но если дать модели список ваших инструментов — она сложит 2+2 и предложит автоматизацию, которую никто не додумался попросить.
Как это работает: Шаг 1 — извлечь явные запросы из текста (что прямо сказано). Шаг 2 — подать тот же текст вместе с описанием доступных инструментов и попросить вывести скрытые возможности с обоснованием: что за проблема, как решить существующим стеком, какой эффект.
Схема метода
ШАГ 1 (отдельный запрос): Извлечение явных потребностей
Вход: транскрипт/текст
→ Список user stories: "Как [роль], я хочу [цель], чтобы [причина]"
→ Ссылка на источник в тексте
ШАГ 2 (отдельный запрос): Вывод скрытых потребностей
Вход: транскрипт/текст + явные потребности из Шага 1 + список доступных инструментов
→ Список новых user stories (не повторяют Шаг 1)
→ Обоснование для каждой: проблема → инструмент → ожидаемый эффект
Два отдельных запроса. Результат Шага 1 идёт на вход Шага 2.
Пример применения
Задача: Вы — продакт в российском HR-SaaS стартапе (например, аналог Huntflow или Talantix). Провели серию кастдев-интервью с HR-менеджерами. Хотите вытащить не только явные просьбы, но и возможности, которые клиенты не сформулировали, — зная, что у вас уже есть интеграция с Telegram, встроенный парсер резюме и аналитика воронки.
Промпт (Шаг 1):
Ты — аналитик продуктовых требований. Твоя задача — извлечь явные потребности
из транскрипта интервью с пользователем.
Явная потребность — это то, что человек прямо сформулировал как запрос,
желание или проблему, которую хочет решить. Не интерпретируй и не додумывай.
Для каждой потребности сформулируй user story по шаблону:
"Как [роль], я хочу [конкретное действие/возможность], чтобы [причина/польза]."
После каждой user story укажи цитату из текста, из которой она извлечена.
Если встречаешь одно из следующего — НЕ создавай user story:
- Описание текущей ручной работы без намерения автоматизировать
- Описание того, что уже сделано/автоматизировано
- Уточняющие вопросы в стиле "это уже работает, да?"
Транскрипт:
{вставить текст интервью}
Промпт (Шаг 2):
Ты — продуктовый аналитик. Твоя задача — найти скрытые возможности для автоматизации,
которые пользователь не сформулировал, но которые следуют из описанных им процессов и болей.
Контекст: доступные нам инструменты и возможности:
{список инструментов с кратким описанием — например: "Telegram-бот: умеет отправлять
уведомления и собирать ответы. Парсер резюме: извлекает структурированные данные из hh.ru.
Аналитика воронки: считает конверсию по этапам."}
Явные потребности, уже выявленные на предыдущем шаге:
{вставить результат Шага 1}
Транскрипт интервью:
{вставить тот же текст интервью}
Для каждой скрытой возможности:
1. Сформулируй user story: "Как [роль], я хочу [действие], чтобы [польза]."
2. Добавь обоснование по шаблону:
"Автоматизация [действие] помогает решить [проблема/неэффективность] в [контекст].
Сейчас это делается [вручную / частично / с помощью другого инструмента].
Автоматизацию можно реализовать через [доступный инструмент] путём [как именно].
В результате [ожидаемый эффект — время, качество, нагрузка]."
Не повторяй явные потребности из предыдущего шага.
Предлагай только то, что реально реализовать имеющимися инструментами.
Результат:
Шаг 1 вернёт список user stories с прямыми цитатами — только то, что HR явно попросила. Шаг 2 покажет 3-7 скрытых возможностей с обоснованием для каждой: что автоматизировать, через какой ваш инструмент, сколько времени это сэкономит. Формулировки будут привязаны к вашему стеку, а не абстрактные.
Почему это работает
LLM хорошо смотрит вперёд — генерирует связи между тем, что есть, и тем, что может быть. Но без контекста «что есть» она работает вслепую. Описание инструментов — это не просто список. Это ограничительная рамка: модель не фантазирует про идеальный мир, а ищет возможности внутри реального стека.
Явный и латентный шаги разделены не случайно. Если попросить всё сразу, модель смешивает буквальное с умозаключением — и теряется граница между "клиент попросил" и "я додумал". Два отдельных запроса сохраняют эту границу: Шаг 1 фиксирует факт, Шаг 2 строит гипотезу.
Шаблон обоснования — отдельный сильный ход. Когда модель вынуждена заполнить структуру «проблема → инструмент → механизм → эффект», она не может написать расплывчатое «это было бы полезно». Структура принуждает к конкретности — и делает скрытые предложения проверяемыми, а не абстрактными идеями.
Рычаги управления: - Список инструментов — чем точнее описания возможностей каждого, тем конкретнее предложения - Правила для Шага 1 — три паттерна ложных срабатываний из исследования (ручная работа без намерения, описание существующей автоматизации, уточняющие вопросы) — их стоит явно перечислить в промпте - Шаблон обоснования — можно адаптировать: убрать секцию «как реализовать» если нужны только идеи, или добавить «приоритет» если нужен бэклог
Шаблон промпта
Шаг 1 — Явные потребности
Ты — аналитик продуктовых требований.
Извлеки явные потребности из текста ниже. Явная потребность — только то,
что {роль собеседника} прямо сформулировал как запрос или желание.
Формат каждой потребности:
User story: "Как [роль], я хочу [действие], чтобы [польза]."
Источник: [цитата из текста]
НЕ создавай user story если в тексте:
— описывается ручная работа без намерения автоматизировать
— описывается то, что уже работает/автоматизировано
— задаётся уточняющий вопрос ("это уже так, да?")
Текст:
{транскрипт или заметки интервью}
Шаг 2 — Скрытые возможности
Ты — продуктовый аналитик. Найди скрытые возможности для улучшения,
которые не были названы явно, но следуют из описанных процессов и болей.
Доступные инструменты и возможности:
{название инструмента 1}: {что умеет}
{название инструмента 2}: {что умеет}
...
Уже выявленные явные потребности (не повторяй их):
{результат Шага 1}
Для каждой скрытой возможности:
1. User story: "Как [роль], я хочу [действие], чтобы [польза]."
2. Обоснование:
"Автоматизация {действие} помогает решить {проблема} в {контекст}.
Сейчас это делается {как делается сейчас}.
Автоматизацию можно реализовать через {инструмент} путём {как именно}.
В результате {ожидаемый эффект}."
Предлагай только то, что реализуемо через перечисленные инструменты.
Текст интервью:
{тот же транскрипт}
Плейсхолдеры:
- {роль собеседника} — HR-директор, клиент, тимлид и т.д.
- {транскрипт или заметки интервью} — текст любого формата: стенограмма, краткие заметки, переписка
- {название инструмента}: {что умеет} — перечисли кратко: "CRM: хранит историю сделок и умеет автоматически менять статусы"
- {результат Шага 1} — скопировать вывод первого запроса
🚀 Быстрый старт — вставь в чат:
Вот шаблон двухшагового метода для извлечения требований из интервью.
Адаптируй под мою задачу: {твоя задача — например: "хочу проанализировать
заметки с встреч с клиентами нашего сервиса доставки"}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про роль собеседников, формат текста и список доступных инструментов — потому что без этого контекста Шаг 2 даст абстрактные рекомендации вместо конкретных.
Ограничения
⚠️ Температура: Исследование показало, что слишком низкая температура (0.0) даёт много лишнего, слишком высокая (1.0) — теряет точность. Оптимум — средние значения. В ChatGPT и Claude температура в чате обычно фиксирована, но можно компенсировать явным указанием: "Не додумывай, опирайся только на текст" (Шаг 1) и "Будь конкретен, опирайся на список инструментов" (Шаг 2).
⚠️ Ложные срабатывания в Шаге 1: Модель склонна превращать в требования три типа фраз — описание ручной работы ("мы вручную делаем X"), описание существующей автоматизации ("у нас уже есть X"), риторические уточнения ("это же уже автоматизировано, да?"). Стоит явно прописать эти исключения в промпте — и проверять результат.
⚠️ Качество зависит от описания контекста: Скрытые возможности (Шаг 2) настолько хороши, насколько точно описан список инструментов. Скудный контекст → банальные предложения.
⚠️ Предварительное исследование: Протестировано на 12 интервью в одной компании (кибербезопасность). Результаты перспективные, но данных пока мало.
Как исследовали
Команда из Университета Оттавы совместно с канадской кибербезопасной компанией eSentire взяла 12 реальных рабочих интервью — около часа каждое, в среднем ~9 000 слов, три участника. Не синтетические данные, не академические примеры — живые разговоры про аналитику производительности, расследование угроз, рутинные процессы SOC.
LENS прогнали на Claude Sonnet 4.5 при четырёх уровнях температуры: 0.0, 0.35, 0.7 и 1.0. Интересная находка: крайние значения проигрывают середине. При температуре 0.0 модель вытащила много лишнего (50% точность). При 1.0 — ещё хуже (41%). Оптимум оказался на 0.7: точность 73%, полнота 100%, F1 = 84.4%. Это красивый аргумент в пользу того, что детерминизм в LLM — не всегда добродетель.
Скрытые требования оценивали два независимых эксперта из eSentire — люди, которые знают инструменты и процессы изнутри. Оценивали по шкале "сэкономит ли это время, если реализовать". 75% предложений получили положительную оценку. Два эксперта совпали умеренно (κ = 0.54) — что говорит о реальной субъективности оценки "полезности", а не о слабости метода.
Адаптации и экстраполяции
🔧 Адаптация: анализ отзывов вместо интервью
Метод работает не только с транскриптами. Входом может быть любой текст, где люди описывают процессы — отзывы в App Store, тикеты поддержки, сообщения в Telegram-чате с клиентами, ретроспективы команды.
Пример: Соберите 20-30 отзывов о вашем продукте. Прогоните Шаг 1 — получите явные жалобы и пожелания. Подайте их вместе с описанием вашего стека на Шаг 2 — получите идеи автоматизаций и улучшений, которые пользователи не просили, но которые решат их боли.
🔧 Адаптация: выявление скрытых рисков вместо возможностей
Шаг 2 не обязан искать возможности — можно переориентировать его на угрозы и риски.
Замените инструкцию Шага 2: "Найди скрытые возможности" → "Найди неозвученные риски и потенциальные проблемы"
Шаблон обоснования адаптируется: "Риск {ситуация} возникает из-за {причина}. Сейчас это не отслеживается / решается вручную. Митигировать можно через {инструмент} путём {механизм}. Без этого {последствие}."
Применимо для анализа интервью с сотрудниками перед запуском нового процесса, или разбора звонков с клиентами перед крупным внедрением.
Ресурсы
Работа: LLM-Based Discovery of Latent Requirements from Stakeholder Conversations: Preliminary Results from Industry
Авторы: Mithila Sivakumar, Martin Lochner, Shiva Nejati, Mehrdad Sabetzadeh
Организации: EECS, University of Ottawa (Canada); eSentire, Inc. (Canada)
Связанные концепции: Conversational RE (Requirements Elicitation), User Story формат [Cohn, 2004], Few-shot prompting