Как проверяешь правильность понятого при общении с заказчиком?

Проверка понимания требований от заказчика

Верификация понимания — критический навык BA, так как неправильно понятое требование стоит дорого. Вот мой систематический подход:

1. Technique: Active Listening (Активное слушание)

Во время общения с заказчиком:

• Не перебиваю, даю человеку закончить мысль
• Делаю заметки параллельно (не отвлекаю)
• Наблюдаю за языком тела и эмоциями (они подсказывают неуверенность)
• Избегаю сразу прыгать на решение — сначала понимаю проблему

Вопросы для уточнения:

• "Если я правильно понимаю, вы имеете в виду..."
• "Помогите уточнить: это означает, что...?"
• "А может ли быть такой сценарий...?" (проверяю граничные случаи)

2. Техника: Rephrasing (Переформулирование)

После описания требования переформулирую своими словами:

Плохо:

• Заказчик: "Нам нужна фильтрация по датам"
• Я: "Окей, добавим фильтр по датам"

Хорошо:

• Заказчик: "Нам нужна фильтрация по датам"
• Я: "Если я правильно понимаю, вам нужно, чтобы пользователи могли выбрать диапазон дат (например, с 1 января по 31 марта) и система показала только записи в этот период? И это должно работать в реальном времени с обновлением таблицы?"

Это позволяет заказчику сразу поймать неточности.

3. Документирование и Sharing Back

После встречи создаю:

Requirements Summary:

Исходный запрос: "Фильтрация по датам"

Внеджение моего понимания:
- Функционал: фильтр диапазона дат
- Применимо к: таблице на странице "Отчёты"
- Типы данных: дата создания, дата обновления, дата доставки
- Граничные случаи: пропущенные даты, будущие даты, одна и та же дата
- UI: календарь с выбором с/по или текстовое поле?
- Сохранение фильтра: должен ли сохраняться при refresh?

Расшариваю с заказчиком и прошу review. Это отличная точка для ловли misunderstandings.

4. Техника: Scenario Testing (Проверка сценариев)

Берусь и описываю конкретные user stories с примерами:

"Давайте проверим на реальных примерах:

1. Пользователь приходит 1 февраля и хочет видеть отчёты за январь. Как это должно работать?
2. Что если диапазон дат выходит за границы доступных данных (например, запрашивает 2024 год, а данные только с 2025)?
3. Может ли пользователь выбрать одну и ту же дату (например, с 15.03 по 15.03)?
4. Если заказчик выбрал даты, потом обновил страницу — фильтр остаётся или сбрасывается?"

Это помогает выявить неучтённые edge cases и решить их вместе.

5. Mock-ups и Prototypes

Для сложных требований создаю:

• Wireframes (Figma sketches) — показываю расположение элементов
• Prototypes (Figma interactive) — пользователь может кликать
• User flows — диаграммы переходов между состояниями

"Представьте, что вот так выглядит фильтр. Это то, что вы имели в виду? Что бы вы изменили?"

Визуальная проверка намного эффективнее словесной.

6. Письменное Соглашение (Sign-off)

Когда требования согласованы, убеждаюсь в финальном buy-in:

Requirements Document содержит:

• Business Goal (зачем это нужно)
• User Stories (кто, что, зачем)
• Acceptance Criteria (как мы проверим, что работает)
• Out of Scope (чего точно НЕ будет в первой версии)
• Dependencies (что это затрагивает)
• Timeline & Effort (примерная оценка)

Заказчик подписывает (буквально или в email: "Согласен"). Это юридическая защита обеих сторон.

7. Техника: Question Audit Trail

Ведаю документ "Questions & Answers", куда записываю все вопросы, которые задавал, и ответы:

Q: Фильтр по датам — это обязательное поле при каждом запросе?
A: Нет, можно оставить пусто, и система покажет все записи

Q: Какой формат даты предпочитаете — DD.MM.YYYY или YYYY-MM-DD?
A: DD.MM.YYYY (это стандарт для РФ)

Q: Сохранять ли выбранный диапазон в localStorage между сеансами?
A: Да, но только для авторизованных пользователей

Это документ становится истиной при спорах позже: "Посмотри, мы согласовали, что..."

8. Continuous Verification

Проверка понимания — не одноразовый процесс:

• На стартовой встречи — уточняю исходный запрос
• Во время анализа — задаю уточняющие вопросы
• На review требований — заказчик проверяет мою интерпретацию
• Во время разработки — разработчики могут найти неясности
• На UAT — заказчик проверяет, то ли они получили

Если на UAT выясняется "Это не то, что я просил", это означает, что я где-то не проверил понимание.

Инструменты

• Notion — живой документ требований с комментариями
• Figma — shared mockups где заказчик может оставлять feedback
• Slack threads — историю обсуждений
• Loom — видео-запись демонстрации требований

Главное правило

"Лучше потратить 2 часа на уточнение требований, чем 2 недели на переделку неправильно понятого функционала."

Верификация понимания экономит бешеные деньги и нервы всей команде.