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

Как убедиться, что ты правильно понял потребности заказчика

Это один из критичнейших навыков Business Analyst. Неправильное понимание требований приводит к дорогостоящим ошибкам, переработкам и конфликтам со стейкхолдерами. Вот проверенные методы.

1. Техника подтверждения (Confirmation)

Переформулирование своими словами

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

Запись и обратное предоставление

• Во время встречи записывай ключевые моменты
• После встречи отправь письмо с резюме: "На встречу мы обсудили следующее..."
• Попроси подтверждение в письме
• Это создаёт письменный след соглашений

2. Задавание уточняющих вопросов

Вопросы открытого типа

• "Расскажите подробнее о текущих болевых точках"
• "Какой идеальный процесс должен выглядеть с вашей точки зрения?"
• "Какие ограничения у вас есть: бюджет, сроки, технология?"

Вопросы закрытого типа (уточнение деталей)

• "Это должно быть интегрировано с Salesforce?"
• "Сколько пользователей будет работать с этой системой?"
• "Какой объём данных мы обрабатываем ежедневно?"

Вопросы на исключение

• "Это точно НЕ нужно делать?"
• "Какие функции из предложенного списка вам не нужны?"
• Часто исключение того, что НЕ нужно, проще чем перечисление всего нужного

3. Проверка через сценарии (Use Cases)

Описание сценариев использования

• Напиши конкретные сценарии: "Клиент входит в систему, он видит dashboard, нажимает на отчёт..."
• Покажи их заказчику и спроси: "Это именно так должно работать?"
• Таким образом проверяются реальные workflow-ы

Примеры типичных дней

• "Как выглядит типичный день вашего пользователя?"
• "Что делает пользователь в первую очередь после открытия приложения?"
• Конкретные примеры выявляют скрытые требования

4. Прототипирование и визуализация

Эскизы и wireframes

• Даже простой набросок на доске помогает
• Пока обсуждаешь, рисуй макет интерфейса
• Заказчик сразу видит, что ты имеешь в виду
• Можно быстро итерировать: "А может быть кнопка здесь?"

Mockups и прототипы

• Для более сложных решений создай кликабельный прототип
• Это даёт заказчику гораздо лучше понимание, чем описание в слова

5. Проверка приоритизации

Must have vs Nice to have

• "Какое из требований самое критичное?"
• "Если бы нам нужно было выбрать три самых важных фичи, какие бы это были?"
• "Что случится, если мы не реализуем эту функцию?"
• Приоритизация показывает истинные потребности vs желаемое

6. Проверка через стейкхолдеров

Встречи с разными ролями

• Встреться не только с основным контактом, но и с конечными пользователями
• Их видение может отличаться от видения управления
• Пример: руководитель хочет детальные отчёты, а рядовой сотрудник просто хочет выполнять работу быстрее

Консенсус

• Убедись, что требования согласованы между всеми стейкхолдерами
• Разные люди могут иметь противоречивые потребности — их нужно примирить

7. Документирование требований

Создание Requirements Document

• Формальный документ с чёткой структурой
• Функциональные и нефункциональные требования
• Критерии приёмки (Acceptance Criteria)
• Это становится договором между заказчиком и разработчиками

Матрица требований (Requirements Traceability Matrix)

• Связывает требования с тестами и документацией
• Помогает отследить, всё ли реализовано

Красные флаги, которые показывают неправильное понимание:

• Заказчик часто меняет требования
• Во время демонстрации заказчик говорит "это не то, что я 想"
• Разные стейкхолдеры описывают разные видения проекта
• Требования расплывчаты: "красивый дизайн", "быстрая система"
• Нет критериев приёмки

Итог

Правильное понимание требований достигается через:

• Активное слушание — не просто слышание, а понимание
• Переформулирование — своими словами
• Задавание вопросов — пока не будет полной ясности
• Визуализацию — через эскизы и прототипы
• Письменное закрепление — документирование и подтверждение
• Проверку через сценарии — реальные use cases

Запомни: лучше потратить лишний день на понимание требований, чем три недели на переделку неправильно реализованного функционала.