Также мне интересно как вы себе представляете эстимейты Киберпанка, уже не говоря про легендарный Duke Nukem Forever

Это выглядит как неправильно построенная работа и низкая квалификация тимлидов отдельных команд.

Оценить время всё равно можно.

"А если мы нарушим эту клятву, то пусть суровая рука наших товарищей напишет нам другую" (с) одесская команда КВН.

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

Ну, если почитать Джейсона Шрейера про Cyberpunk 2077, то сотрудники компании планировали выпуск не раньше 2022 года. Это руководство ляпнуло о выходе игры в неправильное время. И люди там вменяемо оценивали сроки.

А как вы сделали вывод что «отвечать не обязательно»?

Я выше привёл пример когда пять команд проэстимейтили, а на месте где продукт вообще не запускался зашли в тупик.
Вы сказали что "Если у вас изменился объём работы, всплыли новые (не заложенные в оценку) риски или появилась новая информация, влияющая на задачу - это не делает эстимейты «фальшивыми», а вашу оценку враньём. "

Эта риторика в принципе рушит всё прогнозирование.

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

Давайте закопаем все табло про прибытие и отправление поездов и самолётов, потому что в реальности оно тоже может по миллиону разных факторов не придти.

У Гугла, я думаю, свой случай — они работают со своими продуктами, своими зависимостями, имеют много ресурсов, суровый отбор, планка, небось, держится. Но так везёт не только лишь всем.

Вы привели пример выше, когда люди по своей глупости (из-за отсутствия координации) профачили дедлайны.

Но проблема не в том, что они дали эстимейты и в них не уложились.
А в том, что не было координации.
В том, что не было заложено время на отладку и интеграцию.
Не было системного дизайна.


И эта ситуация не делает эстимейты бесполезными.
Чуваки нафакапили, спланировали работу по исправлению этих факапов, исправили.
Компания в это время теряет убытки, а людей которые отвечают за процессы и тимворк бьют плетями в переговорных комнатах или выгоняют на мороз.
Но это не проблема эстимейтов.

У поездов есть рельсы. У самолётов есть прогноз погоды, маршруты и более чем менее чистое небо.

Будут зависимости прочными и прямыми как рельсы — будут и точные эстимейты.

А пока что в реальности очередной нафакапленый джиэс фреймворк с кучей не всегда очевидных зависимостей.

+1

Так фризьте зависимости своего жс фреймворка.
Проведите ресерч и тратьте больше времени на планирование, что бы потом не огребать проблем в духе «ой, а мы не знали, что оно не взлетит».
Локализуйте и уменьшайте риски.

Пока что ваши тезисы звучат как «Эстимейт может быть ошибочным, поэтому эстимейты не нужны».
Это очевидно так не работает, потому что даже ошибочный эстимейт несёт больше пользы, чем никакого.

Случаи разные бывают. Кому полезны — пожалуйста. Кому нужны — пожалуйста. Мои тезисы о том что так бывает не всегда. Не всегда бывают нужны, и не всегда вообще даже начинают работать (после ресёрча или начального тестирования).

Кому-то несёт пользу и плацебо, кому-то любой эстимейт. Мне ошибочный эстимейт пользы не несёт, и оптимистическая вера в то что "они всегда возможны" не несёт тоже.  

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

И управляйте миром незаметно для санитаров.  Я уже приводил случай когда вы не можете даже начать ресёрч: для начала ресёрча нужно посмотреть что написала другая команда, и пока она это не начала, вы начать тоже не можете.

Ещё раз. Степень неопределенности очень сильно мешает давать точные и правильные эстимейты.
Чем она выше - тем больше шансов, что твои эстимейты - фигня.

Поэтому в большинстве случаев люди стараются сначала взять время на ресерч/детализацию/дизайн етк, что бы минимизировать степень неопределенности, а потом взять время на имплементацию.

Но, даже в ситуациях когда этого сделать по каким-то причинам невозможно.
Есть два кейса.
Первый - есть эстимейт "на это нужно два месяца".
Второй - нет эстимейта совсем.

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

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

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

А как тогда разрабатывать ПО в условиях жестко поставленных сроков? Например: "сделать Х, (см. ТЗ на Х) к 30 марта 2024 года. Вперед и с песней.

Падаждите.
А зачем вам смотреть "что написала другая команда"(которая ещё это не написала) до того, как начать писать своё?
Если вы параллельно делаете два (или более) модулей, которые должны работать вместе - вам не нужно садиться и смотреть, что они написали.
Вам нужно распланировать взаимодействие, стандартизировать контракт и пилить свой продукт исходя из него.

Нету тут никакого "надо сначала посмотреть в код, которого нет".
Потому что если вам действительно нужен этот код и это единственный способ начать делать эту задачу - то ваша задача, как говорят в этих ваших джирах BLOCKED BY.
И её не надо брать в работу ни с эстимейтом, ни без него.

И да, конечно, есть риски того, что ваш коллега придет в один прекрасный день на работу, сядет на кресло и отъедет в мир иной от инфаркта.

Так это часть ресёрча и умение в планирование и распределение задач. Если вторая команда начнёт делать что-то пока первая не закончит ресёрч, то возникает вопрос "Зачем она это сделала?".