Вопрос определения большой задачи и разбега точности оценки. Декомпозиция и оценка - да, прокачивается, но есть всякие состояния типа "вот тебе непонятная задача, дай декомпозицию и эстимейт", а там по факту пока RnD не сделаешь или просто в время в попытки не сольешь ничего дельного не родишь в плане эстимейтов.

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

Вроде в каких-то древних книжках первых называли "программисты", а вторых "архитекторы"/"бизнес-аналитики"...

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

А о чём спор-то? Какая разница — "склад ума" или "мотивация развивать скилл"?

"склад ума" — это про то, что вот просто человек такой, и ничего не сделать

Для примера случай приведу, я когда лабы студентам выдумывал (когда они сами не могли), я порой придумывал жесткие вещи, типа DHT хранилища с автодискавери нодов и т.д. Рассчитаны они были на команду из 3-5 человек (потому что их много а я одна). Так вот за несколько лет никто за DHT хранилище не брался, потому что там ну поебаться надо, оттестить, и поработать в команде. И вот почти в дедлайн ко мне приходит студент, из которого вообще ничего не вытянуть было на зачете и приносит полностью работающую систему, сделанную без команды. Потому что  блин ну вот такой человек :). И все отдебажено, с деплоем и докой.

куда-то в FAANG  он уехал сразу почти как закончил

но неизвестно же, как он работал над задачей, может быть декомпозировал и потом пилил)

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

Просто невозможно же работать программистом без навыка декомпозиции. Ну никак:)

ну я хз, а не пробовали с людьми поговорить?

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

они ж не инопланетяне

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

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

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

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

качество в итоге не сильно лучше, чем у похожих по объему фич, запиленных в рамках спринта

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