Кажется, что на задачу просто забивают и хватаются в последние дни, когда начинает подгорать. А это рушит всю технологию и баги ползут сверх нормального состояния. Разраб точно тратит на задачу больше времени чем оценивал? Или он делает все-все-все и немного того, что насыпали сверху? Контроль нужен или разраб выгорел и клал он на релизы и продакта.

Ровно так же как и научить их летать) это не возможно просто по техническим причинам.

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

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

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

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

Это позволит, со временнм, добиться хорошей точности в оценке, лучше декомпозировать задачи.

Конечно и задачи должны ставится в полном объеме, SMART, как наиболее известный вариант проверки достаточности описания задачи. А не просто название тикета, а дальше пусть сам разработчик угадывает, что надо сделать.

Это не разработчика надо заставлять, а исправлять процессы. Или переоценить важность попадания в срок, может это не так уж и важно.

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

Для того, чтобы это хорошо работало, важно, чтобы за срывы сроков не было наказания, чтобы никто не пытался через овертаймы закрыть вовремя, скрывая реальный объем работы. Так же важно понять сколько реально сотрудники могут посвящать задачам. Соотвественно, если сотрудник полдня участвовал во встречах, то и в потраченном времени на задачу в этот день надо указать 4 часа. При этом время на процессы так же относящиеся к задаче так же должны в ней учитываться. До нескольких часов в день может, съедаться побочными активностями - правильное заполнение тикета, оформление пулл-реквеста, разрешение конфликтов слияний и т.п. А так же просто встать сходить в туалет, налить воды.

Далеко не все компании и сотрудники готовы к этому, особенно руководители, если увидят, что на саму задачу сотрудник потратил часа 4, а остальное время он был то на встречах, то помогал кому-то, то ещё что-то делал. При этом, всё это рабочие тоже часть работы.

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