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

Подмена (или подстановка) атрибута — это когда мы вместо какого-то сложного явления, о котором энергозатратно или непонятно как думать, или оно сложнее доступно для наблюдения, подставляем явление более простое в понимании и доступное. Но другое. И происходит это для мозга незаметно.

Это, например, объясняет множество оптических иллюзий, связанных с оценкой размера объектов, показанных в перспективе (одинаковые по размеру объекты кажутся меньше или больше в зависимости от расположения). Мозг натренирован распознавать трехмерные объекты, он их и распознает, подставляя 3D-модель вместо 2D-рисунков.

В управлении происходит то же самое: нас ведь должны интересовать не отработанные часы, а число выполненных задач. Ну, вдумайтесь в эту фразу: "мы вам платим за отработанное время". Ну бред же. А ещё точнее — даже число успешно выполненных задач так себе показатель, по настоящему нас должна интересовать принесенная польза. Какое-то время назад велись даже разговоры про Agile Manifesto 2.1, с тезисом Business value over working software — Ценность для бизнеса важнее работающего ПО.

Поэтому разговоры о подсчете часов — это подмена непонятного и недоступного "числа задач" (список которых не ведется, да и что считать задачей?..) или, спаси и помилуй, некоей "бизнес-ценности", на простые и понятные часы. Часы легко измерить, очень просто понять и объяснить другим, что это такое, да и пронаблюдать проще простого: вот же, сидит человек, часы идут!

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

Лучше всего — не предсказывать, а экстраполировать. Начать с каких-то данных, и продолжить их в будущее. Когда-то давно я подсмотрел у Макса Дорофеева (Cartmendum) классный инструмент оценки сроков завершения проекта — Enhanced Burn-Down Chart, расширенная диаграмма сгорания работ. Идея очень простая: сравниваем, сколько задач выполнено, и сколько новых насыпалось. Где их линии трендов пересекутся — там проект и закончится, с большой вероятностью. А если не пересекутся — не закончится никогда. Применял его на нескольких проектах — работает, как часы. Против математики не попрёшь!