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

Работа с нереальными требованиями заказчика

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

Типы нереальных требований

1. Технически невозможные

• Требование, которое нарушает физические или технические законы
• Пример: "Сделать приложение, которое работает без интернета и при этом синхронизируется в реальном времени"

2. Требующие чрезмерных ресурсов

• Требование реально, но затраты несоизмеримы с результатом
• Пример: "Интегрировать с 50 внешними сервисами в течение месяца"

3. Противоречивые

• Несколько требований противоречат друг другу
• Пример: "Максимальная простота использования И максимальная функциональность"

4. Основанные на неверных предположениях

• Заказчик ошибочно предполагает, как работает система
• Пример: "Добавить функцию, которая будет давать 100% точное предсказание поведения пользователя"

5. Недостаточно детализированные

• Требование расплывчато и невозможно реализовать
• Пример: "Сделать систему красивой и удобной"

Методология работы с нереальными требованиями

Шаг 1: Выявление проблемы (Discovery Phase)

1. Слушай внимательно

   • Не перебивай заказчика
   • Понимай контекст и причину требования
   • Задавай уточняющие вопросы

2. Анализируй требование

   • Проверь техническую возможность
   • Оцени необходимые ресурсы
   • Выяви потенциальные конфликты

3. Проверь с командой

   • Обсуди с lead developer
   • Получи оценку затрат
   • Выясни технические ограничения

Шаг 2: Подготовка обоснованного ответа

Не говори просто "Это невозможно". Будь профессионален:

Плохо: "Это невозможно"

Хорошо: "Это требование связано с [техническое ограничение]. 
Мы можем предложить три подхода:
1. [Вариант 1 с плюсами и минусами]
2. [Вариант 2 с плюсами и минусами]
3. [Вариант 3 с плюсами и минусами]

Какой вариант вас интересует?"

Шаг 3: Переговоры и согласование

1. Объясни бизнес-влияние

   • Затраты (бюджет, время, ресурсы)
   • Риски (качество, стабильность, maintenance)
   • Альтернативные варианты

2. Предложи компромиссы

   • Упрощенная версия функции
   • Поэтапная реализация
   • MVP (Minimum Viable Product) для проверки

3. Документируй решение

   • Запиши, что было принято
   • Почему были отклонены другие варианты
   • Ответственность (кто за что отвечает)

Практические примеры

Пример 1: Требование "Сделать систему быстрой"

❌ Ошибочный подход:

BA: Это расплывчато
Заказчик: Просто сделай её быстрой!

✅ Правильный подход:

BA: Спасибо за требование. Давайте уточним, что означает "быстрая":
1. Какое время отклика вас устроит? (200ms? 500ms? 1s?)
2. Для какой операции это критично? (поиск? загрузка списка? платёж?)
3. Сколько пользователей одновременно?
4. На каких устройствах использовать? (мобильные? старые браузеры?)

На основе этого мы сможем дать точную оценку и план реализации.

Пример 2: "Реализуй за одну неделю то, что обычно занимает месяц"

❌ Неправильно соглашаться:

BA: Ок, постараемся!
[Дедлайн не соблюдён, качество страдает]

✅ Правильный подход:

BA: Я понимаю срочность. Давайте обсудим варианты:

1. MVP вариант (1 неделя):
   - Основной функционал
   - Ручная модерация
   - Базовый дизайн
   Риск: неполный функционал, требует доработок

2. Стандартный вариант (3-4 недели):
   - Полный функционал
   - Автоматизация
   - Оптимизированный дизайн
   Риск: время

3. Фазовая реализация (2 недели + 2 недели):
   - 1 фаза: критический функционал
   - 2 фаза: дополнительные функции

Какой вариант для вас приемлем?

Пример 3: Противоречивые требования

Заказчик: "Максимально простой интерфейс И максимально функциональный"

✅ Решение:

BA: Спасибо за требования. Я вижу потенциальный конфликт:
- Простота обычно требует скрытия функций
- Функциональность требует их доступности

Предлагаю варианты:
1. Simplicity First (простой для новичков, но требует обучения для продвинутых функций)
2. Power User первый (много функций доступно, но требует изучения)
3. Умная система (показывает функции по мере необходимости)

Давайте определим вашу целевую аудиторию и приоритеты.

Принципы общения с заказчиком

1. Соблюдай уважение

• Заказчик платит деньги, его потребности важны
• Не звучи как "умник", объясняй на его языке
• Признавай, что у него могут быть хорошие идеи

2. Будь честен и прозрачен

• Не скрывай проблемы
• Сообщай о рисках как можно раньше
• Давай точные оценки, не завышай обещания

3. Ищи win-win решения

• Цель не выиграть спор, а создать хороший продукт
• Слушай потребности, предлагай альтернативы
• Будь готов менять своё мнение на основе фактов

4. Документируй всё

• Email с согласованным решением
• Процесс принятия решения
• Кто, когда и почему согласился
• Это защищает обе стороны

Инструменты и техники

MoSCoW приоритизация

Must have (обязательно): базовый функционал
Should have (желательно): важные функции
Could have (можно): дополнительные функции
Won't have (не будет): отложенные функции

Это помогает сфокусироваться на действительно важном

RICE scoring

Reach: сколько пользователей затронет
Impact: какое влияние на бизнес
Confidence: насколько уверены в оценке
Effort: сколько времени и ресурсов требует

Score = (Reach * Impact * Confidence) / Effort
Помогает объективно выбрать приоритеты

Prototyping и Validation

• Создай быстрый макет/прототип
• Покажи заказчику
• Уточни требование на основе реакции
• Это дешевле, чем разработка неправильного функционала

Когда сказать "нет"

Часто BA может найти компромисс, но есть моменты, когда нужно сказать "нет":

1. Технически невозможно

• Требование нарушает физические законы или возможности платформы
• Пример: "Приложение на мобильном должно работать быстрее чем на серверах Google"

2. Крайне высокий риск

• Реализация может привести к потере данных
• Может скомпрометировать безопасность
• Пример: "Отключи все проверки безопасности для скорости"

3. Явное нарушение стандартов

• GDPR, законодательство
• Этические стандарты
• Пример: "Собирай и продавай данные пользователей"

Вывод

Работа с нереальными требованиями — это искусство. BA должен:

• Быть дипломатом — находить компромиссы
• Быть экспертом — знать технические ограничения
• Быть консультантом — советовать лучшие практики
• Быть защитником качества — отстаивать реальность
• Быть командным игроком — работать с разработчиками и заказчиком

Профессиональный BA не просто говорит "Это невозможно" — он предлагает решение, которое работает в рамках реальности и выполняет истинные потребности бизнеса.