Вопросы для интервью по требованиям: 10 практичных вопросов и простой способ переводить ответы пользователей в список функций и задачи для ИИ.
Если просто попросить «список хотелок», вы почти всегда получите набор решений: «сделайте кнопку», «нужна интеграция», «добавьте фильтры». Это не требования, а догадки о том, как исправить боль. Обычно без контекста и без понимания, что именно считается успехом.
Интервью нужно всем, кто отвечает за результат: продакту, фаундеру, аналитику, разработчику. Даже если вы один в команде, разговор с пользователем помогает не строить продукт «по ощущениям». Вы собираете не мнения, а факты о работе человека.
В хорошем интервью вы вытаскиваете четыре вещи: проблему (где теряется время или деньги), контекст (кто делает задачу, как часто и где), ограничения (правила, безопасность, сроки, устройства, бюджет) и критерии успеха (как поймем, что стало лучше, и насколько).
Чтобы не увязнуть в споре про термины, начинайте не с «какие требования», а с «покажите, как вы делаете это сейчас». Например: менеджер ведет заявки в таблице, забывает про статусы, клиенты ждут ответа. Требование здесь не «нужна CRM», а «нужно быстро видеть, где застряла заявка, и не терять ни одну». Когда позже вы переведете это в задачи для ИИ (например, в TakProsto), такие формулировки дадут меньше переделок.
Хорошее интервью начинается до разговора. Если заранее решить, кого слушать и что фиксировать, вы получите материал, который реально превращается в список функций.
Не ограничивайтесь самым активным пользователем. Лучше собрать 5-10 человек с разными ролями: новичка (спотыкается на непонятных шагах), опытного исполнителя (знает обходные пути), руководителя или согласующего (видит риски и сроки). Если продукт влияет на поддержку или продажи, добавьте по одному представителю оттуда.
Проверьте, что люди работают с процессом сейчас, а не «когда-то давно». И почти всегда лучше несколько коротких интервью, чем одно большое совещание.
Запланируйте 30-45 минут. Предупредите про запись (аудио или экран) и получите согласие. Запись нужна не для контроля, а чтобы не потерять формулировки и цифры.
Попросите участника принести реальные артефакты: скриншоты, файлы, примеры отчетов, переписки, шаблоны писем. По ним быстро видно, где ручной труд и что именно считается «готово». Например, бухгалтер может показать таблицу, которую каждую неделю копирует и правит вручную, а руководитель - письмо с вечным «уточните, пожалуйста».
Перед встречей сформулируйте цель одним предложением: что улучшаете (процесс), что убираете (ручные операции), что ускоряете (согласование) и какую метрику хотите сдвинуть.
Для заметок удобно держать один шаблон: дословная цитата, факт (что происходит и как часто), боль, метрика (время, ошибки, деньги, задержки) и идея функции (без дизайна и деталей интерфейса). Так проще собрать требования в задачи, в том числе для TakProsto.
Цель интервью - понять реальную работу человека: что он делает, где спотыкается, что стоит денег и времени. Тогда из разговора легко получается список функций.
Начните с короткого разогрева: роль и типичный день. За что отвечает, какие задачи повторяются, какие инструменты использует, как часто происходит нужный процесс. Это задает контекст и быстро отделяет конкретику от общих слов.
Дальше держитесь за факты. Почти на любую фразу «обычно так» просите конкретный случай: «Вспомните последний раз. С чего начали? Что было дальше?» Так вы вытаскиваете шаги процесса, участников и реальные ограничения.
Фиксируйте формулировки дословно хотя бы ключевые. Цитаты пригодятся позже, когда будете писать функции и тексты интерфейса: «я не понимаю, какой счет оплачивать» точнее, чем «нужна ясность».
Всегда уточняйте числа, иначе приоритеты будут случайными: сколько времени уходит сейчас и сколько должно уходить, как часто это происходит, сколько людей вовлечено и кто принимает решение, что считается ошибкой и сколько она стоит, сколько вариантов и исключений есть на практике.
Полезный прием - разделять «как сейчас» и «как хочется». Сначала подробно разберите текущий путь, потом попросите описать желаемый результат и минимально приемлемое улучшение.
Пример: пользователь говорит «хочу, чтобы все само заполнялось». Вы уточняете последний случай и выясняете: данные берутся из двух источников, 30 заявок в день, 10% с ошибками, на проверку уходит 2 часа. Это уже измеримая проблема, из которой рождаются конкретные функции и критерии проверки.
Если держать под рукой один и тот же набор, разговор получается спокойнее: вы собираете факты о работе, а не абстрактное «хочу кнопку».
Сначала - цель и реальный сценарий:
Потом - измеримые вещи, которые легко превращаются в требования и промпт:
Простой пример: «я сверяю оплаты вручную 2 часа по пятницам, ошибки в номерах счетов, потом переделываю». Отсюда сразу видны будущие функции: импорт данных, сверка по правилам, подсветка расхождений, отчет и журнал исправлений. Такой список уже удобно отдавать ИИ (например, в TakProsto) как задачи.
После интервью часто остаются фразы вроде «это важно», «нужно удобно», «хочу как в X». Чтобы превращать их в функции, помогает рамка «П-К-В-ВЫХ-КР-О».
Держите рядом уточняющие вопросы. Если человек говорит «должно быть быстро», не спорьте о вкусах: спросите про цифры. Приемлемо 3 секунды, 10 секунд, минута? Для какой операции? Если звучит «нужна интеграция», уточните систему, частоту обмена и конкретные поля.
Небольшие примеры перевода:
На выходе из каждого ответа получается карточка функции: что сделать, для кого, как проверить и какие границы соблюдать. Ее уже легко отдавать ИИ (например, в режиме планирования в TakProsto).
После интервью обычно есть каша из фраз, догадок и хороших идей. Задача - отделить реальность от интерпретаций и превратить ответы в понятные функции, которые ИИ сможет разложить на продуктовые задачи.
Сначала разберите записи так, чтобы их можно было проверить. Выпишите дословные цитаты и факты отдельно: «согласование занимает 2 дня», «в Excel 5 вкладок», «ошибка случается раз в неделю». А рядом - ваши предположения: «значит, нужен чат», «нужна автоматизация». Предположения полезны, но это не требования.
Дальше собирайте материал по сценариям. Один сценарий = одна пользовательская задача с понятным началом и концом. Например: «менеджер получает заявку -> проверяет данные -> отправляет на согласование -> видит статус».
Рабочая последовательность:
Чтобы ИИ не додумывал, «приземляйте» формулировки. Не «сделать удобно», а «когда нажата кнопка “Отправить”, заявка получает статус “На согласовании”, и ответственному уходит уведомление». Входы и выходы здесь критичны: вход - заполненная форма, выход - запись в базе и видимый статус.
Приоритет отмечайте быстро, без долгих споров: как часто это происходит, насколько больно, сколько стоит, какой риск. Если два сценария равны, выбирайте тот, где выше риск.
Мини-проверка перед тем, как отдавать задачи ИИ:
Хорошее интервью часто заканчивается хаосом в заметках: деталей много, а непонятно, что именно делать. Помогает один стабильный формат фиксации и критерии приемки рядом.
Обычно достаточно выбрать один основной формат, а остальные держать как подсказку:
Например, из фразы «Я теряю заявки в переписках»: «Как менеджер, я хочу видеть все заявки в одном списке, чтобы ничего не пропускать». Коротко как функция: «Система позволяет менеджеру собирать заявки из чатов в список».
Без критериев требование звучит красиво, но каждый понимает его по-своему. Обычно хватает 3-5 простых пунктов.
Чтобы ИИ собрал экран, API или сценарии, рядом полезно фиксировать: входные данные, выход и формат (список, карточка, файл), роли и права, исключения и ошибки, границы (лимиты, сроки хранения, обязательные поля).
Пример критериев: «Заявка появляется в списке за 5 секунд», «Можно фильтровать по статусу», «Без права доступа пользователь видит сообщение об ошибке», «Пустой список показывает подсказку, что делать дальше».
Провалы чаще всего случаются не из-за «плохих вопросов», а из-за того, что вы записали не то. Интервью легко превращается в разговор про вкусы, а не про работу.
Первая ошибка - путать решение с проблемой. «Сделайте кнопку на главной» звучит конкретно, но почти ничего не говорит о ценности. Правильнее докопаться до боли: «не могу быстро найти отчет перед созвоном» или «каждый раз теряю 10 минут на поиск». Тогда вы сможете предложить варианты, а не один спорный ответ.
Вторая ловушка - собирать «список хотелок» без примера последнего реального случая. Если человек говорит «нужно удобнее», попросите вспомнить последний раз, когда было неудобно: что делал, где остановился, чем закончилось. Один свежий кейс дает больше, чем десять общих пожеланий.
Третья ошибка - не фиксировать ограничения и права доступа. Потом выясняется, что часть пользователей не видит нужные данные, а часть не может их менять, или что данные разнесены по системам. В каждом интервью проговорите: кто может смотреть, кто менять, какие поля чувствительные, что можно выгружать и куда.
Четвертая ловушка - слишком ранний спор о дизайне. «Где поставить фильтр?» быстро уводит разговор в пиксели. Держите фокус на сценарии: «когда вы ищете, какие шаги делаете, по чему понимаете, что нашли нужное». Дизайн обсуждайте позже.
Пятая - игнорировать редкие, но дорогие ошибки. «Редко бывает» не значит «неважно», если это ведет к штрафу, срыву сроков или возврату денег. Спросите прямо, что стоит компании денег или репутации.
Короткая самопроверка по ходу интервью:
Если вы собираете требования, чтобы потом отдать их ИИ (например, для генерации списка функций или user stories в TakProsto), эти ловушки особенно критичны: ИИ отлично развивает четко описанные сценарии и ограничения, но так же уверенно строит на расплывчатых «хотелках».
Перед тем как превращать заметки интервью в промпт для ИИ (или в задачу для команды), проверьте простую вещь: из текста должно быть понятно, что именно человек делает, с какими данными и как вы поймете, что получилось.
Пройдитесь по требованиям и убедитесь, что на каждый пункт можно ответить коротко и без догадок:
Если после этих проверок вы можете написать 3-5 предложений без слов «примерно», «как-нибудь» и «потом разберемся», требования готовы.
Практика: когда вы описываете задачу в TakProsto в формате «роль + шаги + входы/выходы + критерий», платформа быстрее собирает понятный список функций и экранов и меньше уточняет мелочи.
Если какая-то проверка провалилась, не усложняйте: вернитесь к одному уточняющему вопросу и закройте пропуск. Это почти всегда экономит часы переделок.
Ситуация: менеджер по продажам каждую неделю готовит коммерческие предложения. Данные разбросаны по CRM, письмам и Excel, а итоговый документ собирается в Word по шаблону. После интервью у вас уже есть факты, осталось перевести их в функции.
Вот что говорит пользователь (почти дословно):
«Я копирую цены из Excel и часто путаю строки».
«Реквизиты клиента то в письме, то в CRM, я трачу время на поиск».
«Перед отправкой я бегаю к руководителю за согласованием, а потом не могу понять, что именно поправили».
Переводим это в функции продукта - не в «сделайте удобно», а в действия и проверки:
Чтобы это было проверяемо, добавляем критерии: «подготовка КП не дольше 10 минут», «без ИНН документ не уходит», «видно все правки за последние 30 дней».
Что отдать ИИ (например, чтобы собрать прототип в TakProsto): краткий сценарий «от сделки до отправки», примеры входных файлов (Excel, типовая выгрузка), правила заполнения и проверки, а также исключения: «нет цены на позицию», «клиент без КПП», «скидка выше лимита».
После интервью важно быстро зафиксировать смысл, пока детали свежие. Иначе вы получите разрозненные цитаты, а не план действий.
Соберите результаты в короткий документ на 1-2 страницы: сценарии, список функций, критерии готовности и приоритет. Практичный порядок:
Дальше выберите 1-2 сценария для пилота и опишите «минимум». Минимум - это не «половина функции», а версия, на которой пользователь реально проходит путь до результата. Например: «заявка принята и видна в списке, статус меняется, уведомление отправилось». Остальное переносите в «позже».
Теперь подготовьте промпт для ИИ, чтобы получить черновик ТЗ и задач. Укажите цель пилота, выбранные сценарии, функции, критерии, роли пользователей и что точно не делаем. Добавьте формат вывода: «таблица задач», «user stories», «API и экраны».
Если вы работаете в TakProsto, удобно начать с режима планирования: попросите разложить функции на этапы, предложить структуру проекта (веб, сервер, база) и отметить зависимости. Для справки можно использовать и домен платформы как ориентир в команде: TakProsto, takprosto.ai.
Последний шаг - короткий цикл проверки. Соберите прототип, покажите пользователю 10-15 минут, уточните спорные места и повторите. Один такой круг часто полезнее, чем неделя дополнительных обсуждений.
Если спросить «что нужно», человек часто перечисляет решения вроде «кнопка» или «интеграция». Интервью помогает сначала понять проблему, контекст, ограничения и критерии успеха, а уже потом выбирать решение. Так вы снижаете риск сделать «правильно реализованную, но ненужную» функцию.
Зовите тех, кто делает работу руками, и тех, кто принимает результат или согласует. Хорошая минимальная выборка — несколько ролей: новичок, опытный исполнитель и руководитель/согласующий. Важно, чтобы они работали с процессом прямо сейчас, а не вспоминали «как было год назад».
Обычно хватает 30–45 минут на одного человека, если вы держитесь за конкретный кейс «последний раз». Лучше провести несколько коротких разговоров с разными ролями, чем один большой созвон, где люди спорят и обобщают.
Запись полезна, потому что сохраняет цифры, формулировки и реальные примеры, а не вашу интерпретацию. В начале просто объясните, что запись нужна для точности, и спросите явное согласие. Если человек против, фиксируйте больше дословных цитат в заметках.
Просите показать текущий процесс: «покажите, как вы делаете это сейчас», а затем разбирайте шаги по порядку. На любую фразу «обычно» уточняйте: «вспомните последний раз, что было сначала, что дальше, чем закончилось». Это переводит разговор из пожеланий в проверяемые факты.
Без чисел вы не поймете приоритет и не проверите результат. Уточняйте частоту, время, количество людей, цену ошибки и «сколько должно стать» после улучшения. Даже грубая оценка вроде «2 часа по пятницам» лучше, чем «долго».
Удобная рамка — П-К-В-ВЫХ-КР-О: проблема, контекст, важность, выход (наблюдаемый результат), критерии (как проверить), ограничения (что нельзя). Так вы превращаете фразу «нужно удобно» в конкретное поведение системы и измеримую проверку, без споров о вкусах.
Опишите задачу как «роль + шаги + входы/выходы + критерии + ограничения» и приложите примеры артефактов (файлы, шаблоны, скриншоты). В TakProsto это особенно полезно: когда вы даете четкий сценарий и границы, платформа проще раскладывает работу на экраны, логику и данные, и меньше задает уточняющих вопросов.
Чаще всего путают проблему с решением, рано уходят в дизайн и забывают про ограничения и права доступа. Еще одна частая ошибка — игнорировать редкие, но дорогие случаи, которые приводят к штрафам, срывам сроков или потере денег. Лечится это одним приемом: всегда просить последний реальный пример и стоимость ошибки.
Требование готово, если вы можете без догадок ответить: кто пользователь, что запускает действие, какие входные данные, какой результат считается успешным и что запрещено. Если в тексте остаются слова «примерно», «как-нибудь» и «потом решим», вернитесь к одному уточняющему вопросу и закройте пробел.
