«Когда вопросы важнее требований: живой кейс из проекта»

Иногда самый честный артефакт проекта — это список вопросов, на которые никто не хочет отвечать.

Недавний кейс.
Интеграция с внешним источником данных. Ничего экзотического:
«данные будут»,
«доступ согласован»,
«API стандартное».

Документы есть.
Стороны уверены.
Проект стартовал.

И вот в какой-то момент я ловлю странное ощущение:
требования уже пишутся, архитектура рисуется, а ощущение такое, будто мы строим дом на фразе «ну, в целом там всё нормально».

Я сделал паузу и предложил простую вещь:
не обсуждать решения, а выписать вопросы, от которых реально зависит, взлетит ли всё это.

Вопросы получились неприятные:
• кто владелец данных в случае расхождений?
• что считается «актуальными» данными и кто это определяет?
• есть ли реальные лимиты, а не «как правило»?
• что происходит, если данные недоступны 15 минут? час? день?

И вот тут случилось важное.
Оказалось, что:
• часть ответов никто никогда не проверял
• часть — «договоримся по ходу»
• часть — вообще за пределами влияния команды

На этом месте проект либо начинает валиться,
либо взрослеет.

Мы выбрали второе — и завели Question backlog.
Не как формальность, а как основной инструмент работы с неопределённостью.

Почему это оказалось критично и как именно мы с этим работали — дальше, по шагам.