Собирал ли требования напрямую от заказчиков

Взаимодействие с заказчиками и сбор требований

Собеседовательский вопрос о soft skills разработчика.

Опыт работы с требованиями

Собирал ли требования напрямую

Да, несколько раз были ситуации:

Сценарий 1: Недостаток в документации

Ситуация: На проекте была неясность в требованиях к функции поиска.

Действие:

• Организовал встречу с Product Manager
• Задал уточняющие вопросы: какие фильтры, как считается релевантность, как ведет себя при спецсимволах?
• Нужна ли фасетная навигация?

Результат: получил четкий набор требований, избежали переделок.

Сценарий 2: Сложная бизнес-логика

Ситуация: Расчет комиссий в платежной системе был неясен в документации.

Действие: провел звонок с Finance Manager, записал примеры расчетов, согласовал с заказчиком.

Результат: сделал тесты которые служат как документация требований.

Как правильно собирать требования

Задавай вопросы, а не предполагай

Плохо: прочитал требования про "аутентификация", сразу начал писать OAuth 2.0, потом выяснилось что нужна базовая auth.

Хорошо: спросил какой тип, нужна ли 2FA, как работают recovery codes.

Документируй требования в коде

public class OrderService {
    /**
     * Требование 2.3.1: Если заказ меньше 500 рублей, добавить доставку
     * Доставка НЕ добавляется если есть промокод
     * Граница включает 500 (т.е. доставка при меньше 500)
     */
    public Order createOrder(OrderRequest request) {
        // логика
    }
}

Создавай примеры (acceptance criteria)

Вместо: "Реализовать фильтр по цене"

Лучше:

• Если выбран диапазон 100-500: показываются товары от 100 до 500 (включительно)
• Сортировка по цене работает вместе с фильтром
• Количество результатов обновляется

Когда требования противоречат техническим ограничениям

Пример:

Заказчик: нужна выдача результатов поиска за 100ms для 10 млн товаров, ищем по 15 полям.

Мой подход:

1. Спросил: для всех запросов или только популярных?
2. Предложил решение: Elasticsearch, Redis кеш, таймауты
3. Обсудил trade-offs: быстро, но нужен отдельный сервис
4. Заказчик согласился

Культура коммуникации

Что работает:

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

Чего не делать:

• Не спорь с заказчиком о том как ему нужно
• Не молчи если что-то непонятно
• Не игнорируй требования потому что они сложные

Документирование решений

# Требование: Уведомления пользователей

## Обсудили с заказчиком

### Вопросы:
1. Какие события генерируют уведомления?
   Ответ: Заказ готов, отменён, возврат

2. В какое время отправлять?
   Ответ: Сразу, но не ночью (00:00-08:00)

3. Как контролировать?
   Ответ: Выбирать канал, отписаться от категории

### Решения:
- Использовать очередь (RabbitMQ)
- История в БД (7 дней)
- Retry: 3 попытки с задержкой

### Acceptance criteria:
- Уведомления отправляются в течение 5 минут
- Email отправляется даже если другой канал упал
- История видна в профиле

На собеседовании

Сильный ответ:

"Да, несколько раз возникали ситуации когда требования были неясны.

Една из значимых — реализация платежной интеграции. Документация имела пробелы в расчете налогов для разных стран. Я:

1. Организовал встречу с Product Manager и Finance
2. Записал примеры расчетов в spreadsheet
3. Согласовал edge cases
4. Документировал решение в коде и комментариях
5. Написал тесты с этими примерами

Результат: функция работает правильно, все edge cases покрыты, разработчики которые придут после меня поймут логику из кода."

Ключевые выводы

• Soft skills важны как technical skills
• Вопросы вперед — лучше спросить один раз
• Документируй требования в коде и тестах
• Предлагай альтернативы когда требования конфликтуют с реальностью
• Слушай заказчика, но предложи лучшее решение
• Записывай всё что обсудили
• Тесты = требования, когда тесты проходят, требование выполнено