Question backlog — зачем он вообще нужен

Question backlog я использую ровно в тех моментах, когда требования уже есть,
но доверия к ним — нет.

Это не список «вопросов к бизнесу».
И не сборник уточнений.
Это отдельный backlog открытых вопросов, которые влияют на решения, но пока не имеют надёжных ответов.

Ключевая мысль простая:
в условиях неопределённости мы не управляем знаниями —
мы управляем неизвестным.

Системного аналитика в этот момент обычно разрывает:
• либо притворяться, что всё понятно
• либо тормозить проект фразой «пока не разберёмся»

Question backlog позволяет сделать третье:
двигаться, не притворяясь, что ясность уже наступила.

Важный сдвиг мышления:
мы перестаём воспринимать вопросы как слабость проекта.
Вопросы — это его реальное состояние.

Если вопрос влияет на:
• архитектуру
• сроки
• SLA
• юридику
• пользовательский опыт

он обязан быть:
• видимым
• приоритизированным
• с владельцем
• и с планом движения

Иначе он всё равно выстрелит — просто позже и дороже.

Самый частый анти-паттерн, который я вижу:
вопросы живут в чатах, в головах, в «ну мы же это обсуждали».

Question backlog делает одну простую, но болезненную вещь:
он вытаскивает тревогу на доску.

В следующем посте — максимально приземлённо:
как я этот backlog завожу, веду и не даю ему превратиться в кладбище вопросов.