Как аналитику проводить интервью с заказчиком: чек-лист

Если в команде нет бизнес-аналитика, интервью с заказчиком часто проводит системный аналитик. Важно не просто записать пожелания, а понять задачу, контекст, ограничения и критерии результата. Ниже — рабочий алгоритм, которым можно пользоваться перед встречей и сразу после неё.

Шаг 1: Подготовка

1.1 Изучи доступную информацию:

• собери доступные материалы: описание продукта, текущие процессы, спецификации, метрики и решения по предыдущим этапам;
• посмотри историю проекта и список стейкхолдеров, если они уже зафиксированы;
• отдельно выпиши факты, предположения и вопросы, которые пока остаются открытыми.

1.2 Сформулируй цель интервью:

• определи, какое решение должна приблизить встреча;
• составь список тем и вопросов: текущий процесс, желаемый результат, пользователи, ограничения, приоритеты и риски;
• выбери реалистичный объём разговора. За одну встречу редко удаётся качественно разобрать весь продукт.

1.3 Подготовь материалы:

• подготовь заметки, схему процесса или прототип, если они помогут предметному разговору;
• запись включай только с явного согласия участников и с учётом правил компании по работе с данными.

Шаг 2: Проведение интервью

2.1 Задай рамку разговора:

• коротко представь участников, объясни цель встречи и ожидаемый результат;
• уточни, кто принимает решения, а чьё мнение нужно дополнительно проверить после интервью.

2.2 Слушай и отделяй потребность от решения:

• дай заказчику описать проблему своими словами;
• если звучит готовое решение, уточни, какую задачу оно должно решить и как сейчас измеряется проблема.

2.3 Задавай уточняющие вопросы:

• начни с открытых вопросов, затем переходи к конкретике;
• разбери основной, альтернативные и ошибочные сценарии;
• уточни данные, интеграции, нефункциональные требования, зависимости, сроки и критерии успеха там, где они относятся к задаче.

2.4 Фиксируй договорённости:

• записывай решения, ограничения, приоритеты и открытые вопросы;
• у каждого следующего шага укажи ответственного и срок;
• в конце кратко перескажи услышанное и попроси участников поправить неточности.

Шаг 3: Анализ полученной информации

3.1 Структурируй материал:

• отдели цели и потребности от требований к решению;
• свяжи требования со сценариями, ограничениями и источниками;
• не превращай каждую реплику в задачу для разработки: часть информации потребует проверки.

3.2 Проверь полноту и противоречия:

• найди расхождения между участниками, неясные термины и скрытые зависимости;
• отметь риски, допущения и вопросы к другим экспертам;
• проверь, можно ли однозначно понять и протестировать ожидаемый результат.

Шаг 4: Обратная связь и подтверждение

4.1 Подтверди понимание:

• отправь краткий протокол: решения, открытые вопросы и следующие шаги;
• отдельно согласуй требования, которые влияют на объём, архитектуру, сроки или обязательства перед пользователями.

4.2 Обнови рабочие артефакты:

• перенеси подтверждённые данные в принятый командой формат: backlog, спецификацию, модель процесса или журнал решений;
• сохрани связь между потребностью, требованием, критерием приёмки и дальнейшей задачей;
• убедись, что материалы доступны тем, кто будет проектировать, разрабатывать и проверять решение.

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

Один запрос и четыре уточняющих вопроса

Предположим, заказчик говорит: «Нужен AI-ассистент, чтобы сотрудники меньше отвлекали экспертов». Здесь уже названа технология, но ещё не определена задача. Я бы последовательно уточнил:

Вопрос	Что он помогает выяснить
Покажите три последних обращения к эксперту	Какие реальные сценарии повторяются
Где сотрудник искал ответ перед обращением?	Проблема в доступе, поиске, качестве документации или решении
Что произойдёт, если ответ будет неверным?	Где допустима подсказка, а где нужно подтверждение
Как поймём, что пилот полезен?	Какой результат сравним с исходным процессом

После такого разговора решение может остаться AI-ассистентом. Но может выясниться, что сотрудникам недоступен нужный раздел, документы противоречат друг другу или каждый вопрос требует полномочий эксперта. Это разные задачи, и модель не устраняет их автоматически.

Что остаётся после встречи

Хороший протокол помещает рядом подтверждённый факт, его источник и открытый вопрос. Например: «Сотрудники спрашивают о порядке оформления; примеры предоставил руководитель поддержки; частоту и затраты времени ещё предстоит измерить». Такая запись точнее, чем «все тратят много времени на поиск».

Следующий шаг тоже должен проверять конкретное допущение: собрать обезличенные обращения, сверить доступы, провести пробный поиск. Тогда интервью заканчивается не обещанием разработать всё услышанное, а понятным движением к обоснованному решению.

---

Из моего Telegram-канала @it_underside.

Ваш ДПУПП