Что делаешь, когда задача не сформулирована четко?

Мой подход к работе с нечетко сформулированными задачами

В моей практике нечетко сформулированные задачи — это скорее правило, чем исключение, особенно при работе с бизнес-заказчиками или на ранних этапах проектов. Мой подход систематичен и состоит из нескольких ключевых этапов.

1. Анализ и декомпозиция имеющейся информации

Первым делом я стараюсь выделить из размытого описания конкретные ядра требований. Даже в самом хаотичном ТЗ обычно есть:

• Бизнес-цель (что хочет получить заказчик в итоге)
• Ключевые сущности (пользователи, заказы, товары и т.д.)
• Ограничения (сроки, бюджет, технологические рамки)

// Пример: даже из фразы "нужна корзина для интернет-магазина"
// можно выделить конкретные подзадачи:
class ShoppingCartRequirements {
    public $coreFunctions = [
        'add_item',
        'remove_item', 
        'update_quantity',
        'calculate_total',
        'apply_discounts',
        'save_for_later'
    ];
    
    public $businessRules = [
        'tax_calculation',
        'inventory_check',
        'price_validation'
    ];
}

2. Активное задавание вопросов по методологии "5 почему"

Я использую технику глубинного интервьюирования заказчика или продукт-менеджера:

1. "Какую бизнес-проблему мы решаем?" (вместо "какую фичу делаем")
2. "Кто основные пользователи этой функциональности?"
3. "Какие сценарии использования будут наиболее частыми?"
4. "Какие есть ограничения и зависимости?"
5. "Как будем измерять успешность реализации?"

3. Создание прототипов и уточнение через код

Для backend-задач я часто создаю минимальные рабочие прототипы API или схемы данных, которые становятся основой для обсуждения:

// Прототип endpoint'а для обсуждения
class CartControllerPrototype {
    /**
     * Вопросы к заказчику:
     * 1. Нужна ли валидация количества на стороне API?
     * 2. Как обрабатывать отсутствующие товары?
     * 3. Нужна ли поддержка разных валют?
     */
    public function addItem(Request $request) {
        // Базовая структура для обсуждения
        $requiredParams = [
            'product_id' => 'int',
            'quantity'   => 'int|min:1',
            'user_id'    => 'int|optional' // или из сессии?
        ];
        
        // Возвращаемые коды ошибок для согласования
        $errorCodes = [
            'INVALID_PRODUCT' => 404,
            'INSUFFICIENT_STOCK' => 409,
            'PRICE_CHANGED' => 422
        ];
    }
}

4. Документирование допущений и рисков

Я обязательно фиксирую все предположения, на которых строится текущее понимание задачи:

## Документ допущений по задаче "Корзина покупок"

### Предположения:
1. Пользователь авторизован при добавлении в корзину
2. Цены фиксируются на момент добавления товара
3. Налог рассчитывается по ставке региона пользователя

### Открытые вопросы:
1. Нужна ли анонимная корзина для неавторизованных?
2. Как долго хранить заброшенные корзины?
3. Интеграция с системой промокодов?

### Риски:
- Сложность синхронизации остатков при параллельных покупках
- Производительность при 10k+ товаров в корзине

5. Итеративная разработка с частыми демонстрациями

Я применяю короткие итерации (1-3 дня) с обязательным показом результатов заказчику. Это позволяет:

• Быстро получать обратную связь
• Корректировать направление разработки
• Постепенно уточнять требования
• Снижать риск создания ненужного функционала

6. Использование User Stories и Acceptance Criteria

Даже для внутренних технических задач я формулирую критерии приемки:

Как: Покупатель
Я хочу: Добавлять товары в корзину
Чтобы: Совершить покупку позже

Критерии приемки:
- [ ] Товар сохраняется после закрытия браузера
- [ ] Отображается актуальная цена и наличие
- [ ] Можно изменить количество перед оплатой
- [ ] Система предупреждает об изменении цены

7. Коммуникация с командой и стейкхолдерами

Я регулярно провожу краткие sync-встречи с вовлеченными сторонами, где:

• Демонстрирую текущий прогресс
• Обсуждаю вновь обнаруженные edge-кейсы
• Согласовываю приоритеты доработок

Ключевой принцип: лучше потратить дополнительный час на уточнение требований, чем неделю на переделку функционала. Нечеткая задача — это не проблема, а возможность проявить аналитические навыки и проактивность. Самые успешные проекты в моей карьере начинались именно с "размытых" требований, которые мы вместе с заказчиком превращали в эффективные технические решения через постоянную коммуникацию и итеративную разработку.