Что можно предложить команде, когда требования не описаны?

В моей практике на проекте с неполными требованиями я предложил и реализовал следующий подход:

1. Эксплораторное тестирование (Exploratory Testing): Немедленно начал сессии исследования продукта, фиксируя все обнаруженное поведение, предположения и вопросы в сессионных листах. Это дало быстрое понимание системы.
2. Создание «живой» документации: Вместо ожидания ТЗ, я начал составлять mind maps и чек-листы основных пользовательских сценариев в таких инструментах, как XMind или просто в Confluence, на основе обсуждений с продакт-менеджером и разработчиками. Этот документ стал общей точкой понимания для команды.
3. Прототипирование тестов на основе здравого смысла: Я написал базовые smoke-тесты, покрывающие очевидные для любого пользователя функции. Например, для веб-приложения:

   # Это не формальные требования, а наш консенсус
   Feature: Basic User Journey
     Scenario: User can access the main page
       Given I open the application
       Then I should see the login form or main dashboard

   И реализовал их в автотестах, помечая как @unstable или @exploratory.

4. Регулярные уточняющие встречи: Предложил проводить короткие (15-20 минут) ежедневные стендапы по требованиям с разработчиками и PO, где мы обсуждали найденные неясности и принимали решения, которые я сразу же документировал.
5. Анализ аналогов и предыдущих версий: Изучил поведение похожих продуктов или старых версий нашей системы, чтобы выявить ожидания пользователей и потенциальные edge-кейсы.

Главный результат — команда перестала ждать идеальных требований, а тестирование стало активным инструментом для их выявления и прояснения.