Про фейк немного поясню - стабильно выдерживать такие сроки во всех ситуациях можно только скрывая информацию об актуальном состоянии разработки, иными словами - через ложь. Если вам важно коммуницировать - говорите честно. Иначе действуйте как крупный корп, который сам себе на уме, фидбек идет 3 года и фичи появляются в паблике только тогда, когда под ними уже все подписи поставили.
Иными словами, лишний раз "называтся груздем" такая себе стратегия, как по мне. Тем более наверняка острой потребности по превращения себя в гриб нет (но тут я предполагаю только).

Fake it till you make it?

Ты прав: мой вопрос изначальный был как раз в том а есть ли лайфхаки как сделать публичный роадман не +- квартал и при этом не повысить накал страстей до неприемлимого

А почему это высший пилотаж? Это же сходящийся процесс, которому можно научить кого угодно. Даёшь оценку фичи, через несколько дней её корректируешь, повторяешь до релиза фичи. После релиза, когда оценка не сошлась, делаешь короткую ретроспективу, основанную на логе корректировки сроков, отвечающую на вопросы "почему не угадал" и "что можно сделать, чтобы лучше угадывать".

Оцениваешь следующую фичу, повторяешь процесс. Смотришь, стал ли промах меньше.

Смыть, повторить. По идее любой более-менее вменяемый человек с пятого-шестого раза должен начать попадать в оценку с точностью 2-3 дня в 90% случаев.

Это работает в случае +- однотипных задач на стабилизированном проекте. Пытаться в коррекцию в ситуации, когда ты двигаешься в разные стороны с разной сложностью конечно можно, но выйдет из этого скорее-всего фигня.

Более лучше декомпозировать?

Там есть другие аспекты задачи, совершенно не относящиеся к проблеме. И там нужен этот канал от сервера к клиентам. Но по проблеме - я неправильно понимал вебсокеты и теперь надо просто посмотреть, а есть ли у нас тот боттлнек про который мы думали, если ноды кластера выставить наружу напрямую

Более лучше декомпозировать это опять про стабильные проекты, а не про бутстрап по сути. В начале (и достаточно долго) обычно отчаяно не хватает экспертизы, или ситуация меняется непредсказуемым образом (новые вводные, коррекции планов и т.д). Пока она нарастет - проект или сдохнет, или вырастет и стабилизируется.

А потом у тебя уйдут неск разработчиков и сроки с ними.

А ещё троих автобус собьёт.

И минус репутация как сроко-просирателя ненадежного.

а дайте им движение тикетов, полная прозрачность и в реалтайме видно когда ожидать фичу

а еще можно не коммитится и показывать стек фич которые в работе

а сроки будет видно по релизам готовых

Высший пилотаж делать это до начала работ я имел ввиду, реальное понимание требований сроков и вообще снижение неопределенности происходит только в процессе

Новые вводные и коррекции планов автоматически приводят к денонсации всех оценок и старту процесса с начала (возможно использовать в новом раунде планирования части уже выполненной работы со словами "это у нас уже есть и переделки не потребует").

А теперь представь, что тебе надо все это делать публично и переписывать роадмап. И вот так ты начинаешь медленно превращаться в CD Project Red.

Да, но неопределённость перед началом работ не является бесконечно большой величиной. Просто в начале мы говорим "плюс-минус неделя", а за несколько дней переходим к "плюс-минус день".

Я не спорю, что внутри, особенно на определенном этапе зрелости, можно иметь достаточно устойчивые планы при очень многих "если" (одно из них - хороший запас в изначальном плане).

Неопределенность достаточно легко свести от бесконечной до +- 70% от точки. Дальше итеративно ты можешь перейти хоть к +-5% за пару недель до релиза. Но утверждать, что в процессе разработки нового продукта можно более-менее выдерживать умеренно оптимистичный график без треша и кранчей - ох, я б не решился, я работал в геймдеве, слава богу не разрабом:)