Как убеждаешься в том, что клиент тебя понял?

Как убеждаюсь что клиент (стейкхолдер) меня понял

Это критически важный скилл для BA. Плохая коммуникация — главная причина провала проектов. Расскажу как я убеждаюсь что мои требования правильно поняты.

Проблема

Клиент говорит "я понял" — но часто он просто вежлив. На самом деле:

• 50% услышали только половину
• 30% услышали но по-своему интерпретировали
• 15% вообще не слушали
• 5% действительно поняли

Статистика мрачная, поэтому нужна активная валидация.

Метод 1: Техника Feynman (объяснение простым языком)

Я прошу клиента объяснить мне его понимание назад.

Я: "Мы добавляем фичу X. Ты понял?"
Клиент: "Да, я понял."
Я: "Отлично! Расскажи мне как ты это видишь. Что ровно будет делать пользователь?"
Клиент: "Ну... он будет нажимать кнопку..."
Я: "И что дальше? Что произойдёт?"
Клиент: "Ах, стоп... я не совсем понял про уведомления."

Эта техника работает всегда. Если клиент не может объяснить — он не понял.

Метод 2: Живая демонстрация

Я показываю прототип или мокап и прошу клиента пройти юз-кейс:

Я: "Представь что ты покупатель. Тебе нужно добавить товар в wishlist. Что ты сделаешь?"
Клиент: "Я нажму на сердечко."
Я: "А где оно? (показываю макет)"
Клиент: "Ах! Я ожидал что оно будет слева, а не справа."

Сразу видны проблемы с удобством.

Метод 3: Вопросы о граничных случаях

Я задаю вопросы о ситуациях которые не очевидны:

Требование: "Пользователь может отменить заказ"

Мой вопрос: "А если заказ уже доставляется? Можно ли отменить?"
Клиент: "Хм... я не думал об этом. Наверное нет."
Я: "Тогда нужно добавить в требования: 'Заказ можно отменить только до статуса In Transit'"

Граничные случаи выявляют неполноту требований.

Метод 4: Письменное подтверждение

Я всегда высылаю summary email после встречи:

Subject: Clarification from today's meeting

Hi [Client],

Thank you for the meeting today. Let me summarize what I understood:

1. Feature X will allow users to do Y
2. Users can access it from the Z page
3. The priority is HIGH and we need it by April 1
4. Success metric: 30% of users should use this feature in first week

Please confirm if my understanding is correct or let me know what I missed.

Best regards,
[BA]

Почему письмо важно:

• Клиент видит всё in writing
• Есть письменное подтверждение (или коррекция)
• Избегаю ситуации "ты же сказал"

Метод 5: Документирование с примерами

Я создаю requirement document с:

• Описанием
• Примерами
• Скриншотами
• Контрпримерами (что НЕ должно работать)

Пример документа:

## Requirement: Users can add items to wishlist

### Description
Users should be able to save items for later purchase

### User Story
As a customer
I want to add items to my wishlist
So that I can remember them for later

### Acceptance Criteria
✓ Item can be added from product page
✓ Item can be removed from wishlist
✓ Wishlist persists across sessions (saved in DB)
✓ User can see their wishlist in profile
✓ Wishlist is private (not visible to others)
✓ Maximum 100 items in wishlist

### Examples

✅ SHOULD WORK:
- User adds laptop to wishlist
- User removes keyboard from wishlist
- User opens wishlist on different device

❌ SHOULD NOT WORK:
- Guest user cannot add to wishlist (they must log in first)
- Adding same item twice creates duplicate (no, should show existing one)
- Wishlist shows other users' items (no, only own)

### Edge Cases

1. What if item is deleted from store?
   → Show item but mark as "No longer available"

2. What if user deletes account?
   → Wishlist is deleted too

3. What if item price changed?
   → Show current price, not original

Так клиент видит не только что хочу, но и почему и что НЕ хочу.

Метод 6: Создание decision log

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

## Decision Log: Wishlist Feature

| Decision | Options | Choice | Reason |
|----------|---------|--------|--------|
| Wishlist limit | No limit / 50 / 100 | 100 | Balance between UX and DB load |
| Sharing | Private / Shareable | Private | User privacy first |
| Deleted items | Remove / Hide | Hide | Show purchase history |
| Item limit per day | No limit / 10 / 5 | No limit | No business reason to limit |

Approved by: [Client name]
Date: [Date]

Все решения в одном месте, с обоснованием. Если клиент позже возьмётся спрашивать "почему мы не позволяем шерить wishlist" — я покажу decision log.

Метод 7: Iterative feedback cycles

Я не жду финального одобрения. Я делю требование на малые итерации:

Спринт 1:

• MVP: пользователь может добавить товар
• Пользователь видит wishlist
• Шеринг wishlist (следующий спринт)
• Рекомендации на основе wishlist (спринт 3)

Так клиент видит результат быстро и может дать feedback раньше.

Метод 8: Зеркалирование (mirroring)

Я повторяю то что слышу но своими словами:

Клиент: "Нам нужна система рекомендаций"
Я: "Если я правильно понял, вы хотите показывать каждому пользователю товары которые похожи на то что он уже покупал? Верно?"
Клиент: "Ну, не совсем... мы хотим показывать то что покупали ПОХОЖИЕ пользователи"
Я: "Ах, collaborative filtering, а не content-based. Спасибо за уточнение!"

Миррoring помогает выявить неточности в коммуникации.

Метод 9: Создание прототипа / демо

Для крупных фич я создаю clickable prototype в Figma:

Figma links клиенту → он кликает → видит flow
Клиент тут же видит проблемы:
"Ой, это слишком много кликов!"
"А где кнопка назад?"
"Почему здесь нет фильтра?"

Прототип заменяет 10 встреч.

Метод 10: Регулярные синхро-встречи

Я планирую еженедельные 15-минутные check-ins:

Монолог → Обсуждение → Уточнение → Согласование

Лучше 10 коротких встреч чем 1 длинная. В коротких встречах клиент более сосредоточен.

Признаки что клиент НЕ понял

Я слежу за этими red flags:

• ❌ Молчание (когда я объясняю)
• ❌ "Да, да, конечно" (слишком быстро согласился)
• ❌ Вопросы о вещах которые я уже объяснил
• ❌ Требование на спринте которого я не прогнозировал
• ❌ "Я думал было иначе" (в конце спринта)
• ❌ Отсутствие уточняющих вопросов (все молчат)

Признаки что клиент ХОРОШО понял

✅ Задаёт умные вопросы (о граничных случаях) ✅ Может объяснить requirement назад ✅ Предлагает улучшения ✅ Находит потенциальные проблемы ✅ Согласился с decision log ✅ Нет surprises на демо

Практический совет

Всегда предполагай что клиент не понял, даже если он говорит что понял. Твоя работа — убедиться, а не верить.

Лучше потратить лишние 30 минут на валидацию, чем 2 недели разработчики будут делать не то.

Мой approach

1. Объясню (simple language, примеры)
2. Попрошу объяснить назад (validate understanding)
3. Покажу прототип или примеры (visual)
4. Напишу summary email (written confirmation)
5. Создам decision log (reference)
6. Буду регулярно синхронизировать (check-ins)

Этот многоуровневый подход практически исключает недопонимание.