Фраза «хочу автоматические напоминания» легко превращается в задачу для разработки. Но человек мог говорить о единственном сорванном согласовании, о неудобном чате или о ситуации, которую уже решил другим способом. Если оставить в отчёте только пожелание, команда потеряет обстоятельства, при которых оно возникло.
Ниже — рабочий способ разобрать интервью о потребностях и опыте клиентов, которые часто называют custdev. Он подходит для продуктового исследования с сопоставимыми вопросами. Для оценки размера рынка, распространённости проблемы или будущих продаж нужны дополнительные данные: такую оценку нельзя получить простым подсчётом ярких цитат.
· Редакция AI Заметок. Все реплики и участники учебного примера вымышлены.
Подготовьте исходник, к которому можно вернуться
Перед чтением сформулируйте исследовательский вопрос. Например: «Как руководители небольших команд узнают, что согласование задержалось?» С таким вопросом вы ищете недавние эпизоды, действия и последствия. Формулировка «нужны ли людям наши напоминания» заранее сужает разбор до оценки одной функции.
Для каждого интервью сохраните код респондента, дату, его роль и исходную запись в разрешённом хранилище. В рабочей таблице используйте код вроде R01; доступ к сведениям, связывающим его с человеком, организуйте отдельно. До передачи файла сервису проверьте согласованный способ обработки исследовательских материалов. Руководство GOV.UK о записи исследовательских сессий отдельно рассматривает согласие, приватность и привязку заметок к участнику и сессии.
Сначала прочитайте разговор целиком, затем возвращайтесь к фрагментам. У цитаты оставляйте соседний вопрос, уточнение после ответа и указатель на источник. Время можно поставить вручную по проигрывателю. Если реплики не разделены, установите говорящего по аудио; при сомнении пометьте его как неустановленного.
Сверьте цитируемые места со звуком. Особенно внимательно проверьте отрицания, числа и слова «обычно», «однажды», «иногда»: от них зависит масштаб утверждения. Не превращайте «один раз отправил вечером» в «регулярно работает по вечерам». Неразборчивый фрагмент так и отметьте, сохранив вопрос для уточнения.
Цитата, контекст, наблюдение и гипотеза: пример разбора
Это синтетический учебный пример, придуманный редакцией. Он не описывает клиента AI Заметок и не является результатом проведённого исследования. Представим интервью с R01 — руководителем небольшой проектной команды. Его спрашивают о последнем случае, когда согласование задержалось.
Интервьюер: «Что вы сделали, когда ответа не было?»
R01: «Во вторник отправил макет в общий чат. В пятницу поискал по слову “макет”, нашёл сообщение и написал ещё раз. Уведомления мне не нужны, я их отключаю. Мне бы видеть, на что ещё не ответили».
Такую реплику хочется сократить до «клиенту нужен список согласований». Это уже интерпретация исследователя. Сохраните переход к ней так, чтобы коллега мог проверить каждый шаг:
| Слой | Запись в таблице | Граница утверждения |
|---|---|---|
| Цитата | «В пятницу поискал по слову “макет”, нашёл сообщение и написал ещё раз». | Дословный фрагмент учебного ответа R01 |
| Контекст | Вопрос о последнем задержавшемся согласовании; макет отправлен в общий чат во вторник | Обсуждается один эпизод, другие процессы ещё не изучены |
| Наблюдение по интервью | R01 рассказал, что нашёл прежнее сообщение поиском и повторно обратился за ответом | Зафиксирован рассказ о действии; само действие исследователь не наблюдал |
| Гипотеза | Обзор запросов без ответа поможет R01 контролировать согласования без дополнительных уведомлений | Польза такого решения ещё не проверена |
Различие между рассказом и наблюдаемым действием здесь существенно. Если респондент на демонстрации экрана открыл поиск и нашёл сообщение, это отдельное основание. Если только описал прошлую пятницу, пишите «рассказал», а не «мы увидели». Подтверждённая по записи цитата подтверждает, что человек это сказал; она сама по себе не доказывает все события его рассказа.
В методике разбора сессий GOV.UK наблюдения, выводы и действия записывают раздельно. Сначала фиксируют услышанное или увиденное, потом объединяют материалы по смыслу и обсуждают, что из них следует. Четыре колонки выше — наша рабочая адаптация этого принципа для интервью, а не стандартизированный тест.
Продолжите карточку вопросом: «Как R01 сейчас отличает запросы, где ответ ещё нужен, от уже закрытых?» Он поможет выяснить устройство процесса. Вопрос «Вам был бы удобен наш список?» проверит реакцию на предложенную идею, но не восполнит пропущенные сведения о текущей работе.
Сравнивайте ситуации и сохраняйте контрпримеры
После первого разбора заведите короткие метки: «поиск прежнего запроса», «повторное обращение», «отключение уведомлений». В качественном анализе такую метку называют кодом. Она помогает собрать относящиеся к вопросу фрагменты. Название «проблемы коммуникации» слишком широко: под него попадут и потерянный файл, и конфликт, и недоступный коллега.
Для сравнения нескольких интервью удобна матрица: строки — респонденты, колонки — темы, внутри — краткое содержание и ссылка на фрагмент. Так устроен один из основных результатов Framework Method, который описывают Nicola Gale и коллеги в методологической статье 2013 года. Работа посвящена исследованиям в здравоохранении; здесь мы используем принцип организации материала, не переносим медицинские выводы на продуктовый custdev.
Не заполняйте пустую ячейку догадкой. «Не спрашивали», «не вспомнил случай» и «сказал, что такого не бывает» — разные данные. Сравнивать отсутствие проблемы можно только там, где обсуждался подходящий опыт. Для каждой новой метки запишите, какие фрагменты к ней относятся; если смысл изменился, пересмотрите уже размеченные интервью.
Контрпример меняет рекомендацию
Продолжение того же вымышленного примера. R02 тоже ищет старые сообщения, но поясняет: «Список ожидающих ответов у меня уже есть. Просто клиент подтверждает по телефону, а дизайнер об этом не узнаёт».
Внешне похожее действие — поиск — связано с другой трудностью. Для R01 мы пока предполагаем потребность видеть незакрытые запросы. В рассказе R02 уже есть список, а проблема возникает при передаче результата согласования. Один общий вывод «всем нужен список» потерял бы это различие.
Разделите темы: видимость запросов без ответа и передача полученного решения. Проверьте, что происходит после телефонного подтверждения и кто обновляет статус. Если такое объяснение лучше соответствует данным, измените гипотезу. Контрпример стоит оставить рядом с выводом, чтобы команда видела, где предложенное решение может не помочь.
При подсчёте различайте людей и упоминания. Несколько повторов одной жалобы в длинном разговоре не становятся несколькими независимыми интервью. В отчёте можно указать, сколько респондентов описали ситуацию и кому задавали соответствующий вопрос. Превращать это число в долю всех клиентов без подходящей выборки нельзя.
Сформулируйте вывод, по которому команда сможет действовать
Соберите краткую карточку: что узнали, у кого и при каких обстоятельствах, на каких фрагментах основан вывод, что ему противоречит, какой вопрос остаётся. В рекомендациях GOV.UK по представлению результатов предлагается связывать формулировку вывода с фактами, значением для работы и иллюстрацией, например цитатой. Наша карточка добавляет явное место для ограничений.
Для учебного случая получится: «R01 описал ручной поиск запроса без ответа; R02 — поиск подтверждения, которое пришло по другому каналу. Проверим отдельно, помогает ли обзор незакрытых запросов в первом сценарии и как передают итог согласования во втором».
Это основание для следующего исследования. Чтобы превратить его в решение о разработке, команде ещё нужно сопоставить проблему с целевым сегментом, существующими обходными способами и ценой изменения продукта. Назначьте владельца следующей проверки и заранее запишите, какой результат заставит отказаться от идеи. Одного согласия респондента с описанием будущей функции для этого недостаточно.
Если разбор помогает делать ИИ, проверяйте ссылки на реплики
Проверенную и разрешённую к передаче расшифровку можно разбирать во внешнем AI-клиенте. В AI Заметках описанный выше путь заканчивается получением и ручной правкой текста; встроенный автоматический custdev-анализ здесь не обещается.
Для внешнего клиента подойдёт такой авторский запрос:
Разбери текст по вопросу: [исследовательский вопрос]. Для каждого наблюдения приведи код респондента, дословную цитату и соседний вопрос. Отдели рассказ о прошлом действии от поведения, которое наблюдали во время сессии. Гипотезы помести в отдельную колонку. Найди противоречащие фрагменты. Если основания нет, напиши «нет данных». Не дополняй цитаты, не придумывай время и не оценивай долю рынка.
Сам запрос не гарантирует точности. Найдите каждую предложенную цитату в исходнике, проверьте её автора и контекст. Затем перечитайте интервью целиком: наличие верных цитат ещё не показывает, что разбор учёл неудобные для гипотезы ответы. Если сервису нельзя передавать материал исследования, используйте ту же таблицу для ручной работы.
Шаблон анализа custdev-интервью
Скачать шаблон в Markdown. В нём есть карточка интервью, таблица фрагментов, сравнение респондентов и лист следующей проверки. Это редакционный рабочий шаблон, который можно менять под свой исследовательский вопрос.
Начните с одной записи: внесите один значимый эпизод, сверьте цитату и подпишите, где заканчиваются сведения респондента и начинается ваше объяснение. Затем найдите фрагмент, который заставляет это объяснение уточнить. Так коллега сможет проверить вывод по источнику до того, как он превратится в задачу для продукта.
Частые вопросы
Можно ли анализировать интервью без полной расшифровки?
Да, если подробные заметки и запись позволяют проверить нужные фрагменты. Для дословной цитаты вернитесь к аудио и выпишите сказанное. Если записи нет, обозначьте материал как заметку интервьюера и не выдавайте пересказ за точную цитату.
Сколько custdev-интервью достаточно для вывода?
Универсального числа для любого вопроса нет. Учитывайте различия участников, конкретность вопроса и оставшиеся противоречия. Количество интервью само по себе не делает вывод о доле рынка обоснованным; укажите границы собранных данных и то, что ещё нужно проверить.
Как работать, если два исследователя по-разному понимают ответ?
Сохраните обе интерпретации и вместе перечитайте фрагмент с соседними вопросами. Уточните значение меток и основания каждого вывода. Если исходник не позволяет выбрать объяснение, оставьте неопределённость и сформулируйте вопрос для следующей проверки.