Как раз в этом проекте у меня тоже была геймдизайнерская таблица для расчета баланса. Сначала делал ее в гугл-таблицах, но очень быстро она стала умирать по производительности, ровно так, как вы описываете. В результате перенес в Эксель — тот тянул нормально, но у меня, конечно, меньше 100 листов было.
В общем, это все к выбору оптимального инструмента под конкретную задачу.
Если совсем кратко, то потому, что меня в большей степени волнует, когда задача будет выполнена, а не сколько на нее времени было потрачено.
Если более развернуто, то тут есть интересный психологический момент, благодаря которому такой способ учёта более эффективен, чем учет потраченных часов.
Давайте представим, что мы организовали учёт времени потраченных часов. У нас есть задача, оцененная в 40 часов и разработчик каждый день на нее списывает по 8 часов. И вот на утро пятого дня вы видите, что на задачу было потрачено 32 часа. Означает ли это, что к вечеру он закроет эту задачу? Разумеется, нет. Он может списать на нее еще 8 часов, и еще 8 часов, а задача так и не будет выполнена (допустим, возникли какие-либо сложности).
Более того, если мы в середине этой задчи подойдем и спросим разработчика о ходе работ, то скорее всего мы услышим, что "все идет по плану, все под контролем", а проблема с задержкой сроков вылезет лишь в день сдачи задачи.
Совсем другое дело, когда мы просим ввести количество оставшихся часов. Во1, разработчику приходится задуматься о своем прогрессе и оценить оставшуюся трудоемкость, во2, ввод оставшихся часов это что-то вроде обещания, данного самому себе, что также стимулирует закончить работу в срок.
Но, кстати говоря, этот подход не является чем-то революционным: его поддерживают и Jira, и DevOs и даже MS Project Server. Все это можно настроить в свойствах проекта.
В общем, это все к выбору оптимального инструмента под конкретную задачу.
Если совсем кратко, то потому, что меня в большей степени волнует, когда задача будет выполнена, а не сколько на нее времени было потрачено.
Если более развернуто, то тут есть интересный психологический момент, благодаря которому такой способ учёта более эффективен, чем учет потраченных часов.
Давайте представим, что мы организовали учёт времени потраченных часов. У нас есть задача, оцененная в 40 часов и разработчик каждый день на нее списывает по 8 часов. И вот на утро пятого дня вы видите, что на задачу было потрачено 32 часа. Означает ли это, что к вечеру он закроет эту задачу? Разумеется, нет. Он может списать на нее еще 8 часов, и еще 8 часов, а задача так и не будет выполнена (допустим, возникли какие-либо сложности).
Более того, если мы в середине этой задчи подойдем и спросим разработчика о ходе работ, то скорее всего мы услышим, что "все идет по плану, все под контролем", а проблема с задержкой сроков вылезет лишь в день сдачи задачи.
Совсем другое дело, когда мы просим ввести количество оставшихся часов. Во1, разработчику приходится задуматься о своем прогрессе и оценить оставшуюся трудоемкость, во2, ввод оставшихся часов это что-то вроде обещания, данного самому себе, что также стимулирует закончить работу в срок.
Но, кстати говоря, этот подход не является чем-то революционным: его поддерживают и Jira, и DevOs и даже MS Project Server. Все это можно настроить в свойствах проекта.