И совершенно зря, на мой взгляд. Что произойдет, если задача будет решена не за 16, а за 18 рабочих часов?

Сломано было много копий здесь на форуме по поводу оценки сроков разработчиком. К консенсусу не пришли, мнения были по всему спектру, от "назвал срок - умри, но сделай" до "срок оценить нельзя".
Выскажу еще раз свою личную точку зрения. Разработчик способен дать только оптимистическую оценку затрат времени на задачу. В реале 95% задач укладываются в диапазон от 0,5Х до 3Х, где Х- оценка разработчика. Оставшиеся 5% занимают на порядки больше времени или вообще решения не имеют. Планировать надо диапазоны.
Поэтому, скорее всего, оценку срока "пара дней" следует понимать как "точно больше одного дня, вряд ли больше трех, но за неделю точно сделает". А теперь переведите в часы.

Теперь чисто мой субъективный опыт. За почти 30 лет в IT и 15 мест работы два из трех худших - те, где планирование (и соответственно, учет) велись в часах. Соответственно, срок работы был 2 и 7 месяцев. Наиболее комфортно работалось там, где явного планирования по срокам не было (т.е. был пул задач, раз в два-три месяца расставлялись приоритеты. Оценки, конечно, были, но для внутреннего использования - если задача с внутренней оценкой в неделю выпускалась через месяц, никого это не пугало) или срок выполнения задавался избыточным (сам удивился, когда столкнулся). Срок работы в одном из таких мест - 11 лет.
Так что сейчас на собеседованиях я задаю вопрос - "Какой самый мелкий квант планирования задач?". "Час" - стоп-слово. Если от тебя требуют оценить/выполнить задачу с точностью до часа - значит наличествуют микроменеджмент, избыточная отчетность, переработки.


Даете максимальную оценку (ОМ-оценка менеджера). Даете на оценку разработчику, получаете оценку разработчика (ОР). Берете МАХ(ОМ, 3*ОР). Делаете страховку на ошибку оценки - умножаете в три раза. Предъявляете оценку заказчику. Профит.