Как оценивать сроки?

Если вы знакомы с проектом и разобрали что за баг, то оценить время на его устранение не проблема.
Если вы не знаете что это за баг, то это еще не баг а production issue, и происходит его investigation до того момента, пока вы не придумаете временный workaround, чтобы пользователи могли работать, потом вы найдете root issue, заведете баг и уже тогда оцените время на его исправление.

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

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

Agile в этом плане удобен не только тем, что можно накидать себе задач на 2-3 недели и их решать, а тем, что каждые 2-3 недели можно посмотреть назад, и понять насколько хорошо ты оценил свои естимейты, и нужно ли в следующем спринте увеличивать или наоборот уменьшать время. И так каждый спринт - смотришь и улучшаешь навыки планирования и эффективность работы.

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

Невозможно в разработке планировать какие-либо сроки. Тут автор прав.

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

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

Я по себе знаю, когда от меня требовали сроки. Последний раз был вообще трешачок в одной московской компании - от меня требовали сроки на 2 день после назначения задачи на меня, при этом я вообще не понимал ничего в задаче - в её бизнес-логике, т.к. работал в этой компании от силы недели три. Через буквально несколько дней меня вызвали "на ковер", мол, почему так долго. Жалею, что прямо тогда не послал их прямым текстом на три известные буквы, а продолжил работать. Ничего хорошего из этого, конечно же, не вышло.
Сейчас я работаю в таком месте, где ВООБЩЕ нет никакого понятия сроки, где разработка проектов в корпорации длится годами - IT работает не на внешнего заказчика, а на внутреннего - на саму же корпорацию. Последний проект, в котором я участвовал, занял около 2-х лет. И бОльшая часть была не программинг, а взаимодействие разных отделов, нахождение багов, форсмажорных ситуаций после запуска и т.д. Работать в таких условиях сплошное удовольствие. Никаких стрессов, никаких менеджеров, изображающих бурную деятельность.

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

рекомендую освоить и запомнить
https://www.artlebedev.ru/kovodstvo/sections/167/

сколько фиксятся критичные баги у корпораций - смотри по новостям, тому же Хабру: от 1-2 недель до 3 месяцев (тут спитч про велосипед, костыль и красивый, но уже не нужный к часу Х код)

в остальном - или всю жизнь подаешь ключи (с), или учишь архитектуру / паттерны / тесты / микросервисы и набиваешь руку: сроки даются всегда. Не всегда сразу, можно после ресерча, но всегда.

Да, начальство заявленное умножает на 1,5-3 тоже практически всегда

Чтоб никого не задеть за чувства и не перевозбудить — просто менеджеры не программисты :-) А те, кто им всё точно оценивают — все огребают потом.

Вообще, чтобы что-либо оценивать заранее — надо иметь чёткую узкую фокусировку на чем-то одном, нууу, чтоб баги были типовыми)))

Если кто хочет — могу в комменте написать всю правду про этих манагеров)