Интервью с заказчиком — ключевая техника выявления требований, в которой качество подготовленных вопросов напрямую определяет полноту и точность будущего решения. Особенно заметно это в банковской сфере, где к бизнес-контексту добавляются регуляторные, интеграционные и инфраструктурные ограничения. Ниже — структурированный перечень тем и вопросов, который аналитик может адаптировать под конкретную инициативу. О самой технике интервью и её отличиях от анкетирования см. 02.02.01 Интервьюирование и анкетирование, о приёмах ведения беседы — 09.01 Техники активного слушания и опросов.
1. Зачем нужен заранее подготовленный список вопросов
Импровизация в интервью с представителем банка рискованна: легко уйти в детали одной системы и не выяснить цели проекта, ограничения или критерии успеха. Подготовленный перечень решает три задачи:
- Полнота охвата — ни одна ключевая тема (цели, процессы, стейкхолдеры, регуляторика, интеграции, бюджет) не остаётся без внимания.
- Управляемость беседы — аналитик держит структуру и при этом свободно углубляется в ответы, как того требует полуструктурированное интервью.
- Проверяемость результата — ответы ложатся в основу требований, а не остаются «мы поговорили с заказчиком».
Список — это опора, а не сценарий: часть блоков расширяется, часть сокращается в зависимости от масштаба и стадии инициативы.
2. Базовые блоки вопросов
| Блок | Примеры вопросов |
|---|---|
| Цели проекта | Какие основные цели вы хотите достичь? Каковы ожидания от конечного результата? |
| Текущие процессы | Какие бизнес-процессы затронет проект? Какие проблемы и ограничения видите сейчас? |
| Заинтересованные стороны | Кто основные стейкхолдеры? Есть ли ограничения во взаимодействии с ними? |
| Технические требования | Какие технологии и системы используются? Есть ли предпочтения по стеку? |
| Регуляторика и право | Какие специфические регуляторные требования учесть? Какие меры безопасности и конфиденциальности ожидаются? |
| Интеграция | Нужна ли интеграция с существующими системами? Какие данные и системы ключевые? |
| Пользовательский опыт | Какие ожидания по интерфейсу? Какие группы пользователей и их потребности? |
| Финансы и ресурсы | Каков бюджет? Какие сроки и ресурсы доступны? |
| Оценка успеха | Как планируете оценивать успех? Какие метрики и KPI будут использоваться? |
| Риски и изменения | Какие основные риски и как ими управлять? Как предпочитаете управлять изменениями? |
Полезный приём — просить конкретику через пример: не «опишите процесс», а «почему счёт для ИП открывается два месяца — какие шаги дают такую длительность и где теряется время». Такой вопрос сразу вскрывает узкие места.
3. Уточнение домена и контекста
Прежде чем углубляться в детали, стоит зафиксировать предметную область. Для розничного и корпоративного банкинга диаграммы, процессы и требования будут принципиально разными, а требования информационной безопасности добавляют собственный слой ограничений. Полезно заранее уточнить, о чём именно идёт речь — например, о корпоративных рисках или о построении целевой инфраструктуры под конкретную модель (скажем, LGD в проекте ПВР). От ответа зависит и набор вопросов, и глубина проработки. Принцип прост: сначала домен, потом детали.
4. Формат клиентских приложений
Отдельный блок касается канала доставки сервиса конечному пользователю. Банки всё чаще развивают PWA — прогрессивные веб-приложения — по понятным причинам, поэтому имеет смысл выяснить, рассматривается ли такой формат и какие к нему предъявляются требования.
5. Процессы взыскания задолженности
Если проект затрагивает работу с задолженностью, стоит уточнить, знаком ли заказчик с процессом dunning — последовательностью действий по взысканию просроченной задолженности — и какие шаги этого процесса должны быть поддержаны системой.
6. Диаграммы и моделирование предметной области
Если предполагается моделирование, заранее обсудите, какие виды диаграмм уместны для выбранного домена: для розницы и корпоратов диаграммы классов будут принципиально разными, а требования ИБ добавляют собственные ограничения. Полезно также выяснить, есть ли у заказчика или в команде готовые примеры диаграмм классов по банковской тематике и на какие источники можно опереться при их построении.
7. Пример: вопросы по реализации налогового отчёта
Когда проект касается отчётности, набор вопросов сужается до конкретной задачи. Для налогового отчёта он может выглядеть так:
| Блок | Примеры вопросов |
|---|---|
| Требования к отчёту | Какие виды отчётов реализовать (НДС, налог на прибыль)? Каковы сроки сдачи каждого? |
| Данные | Какие источники данных используются? Какие данные нужны для каждого вида отчёта? |
| Формат и содержание | В каком формате предоставлять отчёт (PDF, Excel)? Какие разделы и поля включить? |
| Регуляторика | Какие нормативные акты регулируют составление? Как часто обновляются требования и кто отслеживает изменения? |
| Процессы и алгоритмы | Какие алгоритмы расчёта реализовать? Какие этапы проверки и утверждения предусмотрены? |
| Интеграция | Нужна ли интеграция с другими системами (ERP, бухгалтерскими)? Какие API или методы интеграции использовать? |
| Безопасность и доступ | Кто имеет доступ к отчётам? Какие меры защиты данных внедрить? |
| Тестирование и валидация | Какие сценарии тестирования провести для проверки корректности? |
Этот пример показывает общий принцип: чем уже домен, тем конкретнее формулировки и тем ближе вопросы к проверяемым требованиям.
8. Качество формулировок
Прежде чем задавать вопрос, полезно убедиться, что он конкретен и не перекладывает поиск ответа на собеседника. Вопрос «расскажите, как у вас всё устроено» уступает вопросу «какие шаги процесса дают такую длительность и где теряется время». Хороший вопрос сужает пространство неопределённости, а не расширяет его.
9. Как пользоваться списком
- Адаптируйте под проект. Часть блоков расширяйте, часть сокращайте в зависимости от масштаба и стадии инициативы.
- Держите связь с целями. Каждый блок должен работать на понимание целей, ограничений или критериев успеха.
- Переводите ответы в требования. Итог интервью — не протокол беседы, а основа для анализа и проектирования решения, соответствующего потребностям банка.
Такой набор вопросов позволяет собрать информацию, достаточную для проектирования решения, и одновременно оставляет пространство для углубления там, где это действительно нужно.