Замечания принимаются. Я согласен, что в моем упрощении многое остается за кадром. Но когда на проекте всего 2-3 человека работают полгода-год, «полноценное» управление добавит слишком много эффорта, мало что дав в замен.
Безусловно, для проекта человек в 100 мое упрощение уже не сработает. Но и противоположное, мне кажется, будет верно — система, оптимальная для управления проектом из 100 человек, не будет лучшим выбором для управления проектом, где работают только двое.
Упрощенная реализация этого видения «вручную» мне реально помогала увидеть моменты, когда дата релиза отодвигалась. Также было полезным увидеть наиболее проблемные места по завершению, чтобы сделать выводы, где, что и почему пошло не так.
Время окончания — как максимум по завершению всех задач всеми людьми, исходя из remaining time по каждой задаче и предположению, что каждый человек работает по х часов в день.
Для множества небольших проектов, в которых задачи достаточно хорошо разделяемы, их порядок выполнения не является чем-то предопределенным и уж тем более чем-то жестко заданным. А если даже и требуется определенный порядок, то он часто является очевидным и не требует явного прописывания — предполагается, что имея две связанные друг с другом задачи, разработчик сам выберет правильный порядок их выполнения.
Диаграмма Ганта (да и много из управления качеством) пришли в ИТ из материального мира. В котором действительно нельзя покрасить стены до их возведения. В ИТ многие из ограничений реального мира снимаются. Отсюда, думаю, и растут все современные тенденции вроде agile development и т.п.
Так в том то и дело, что отчетность я хочу видеть предельно простой: в конце дня открыл форму, выбрал задачу из списка, внес, сколько сегодня на нее потратил часов, поправил remaining при необходимости. Именно с целью избежать «отбирает кучу времени впустую, на заполнение тупой отчётности по которой уходит больше времени, чем на саму работу».
Правда, иногда все же новые языки удаются, хоть тот же Python взять :)
Безусловно, для проекта человек в 100 мое упрощение уже не сработает. Но и противоположное, мне кажется, будет верно — система, оптимальная для управления проектом из 100 человек, не будет лучшим выбором для управления проектом, где работают только двое.
Для множества небольших проектов, в которых задачи достаточно хорошо разделяемы, их порядок выполнения не является чем-то предопределенным и уж тем более чем-то жестко заданным. А если даже и требуется определенный порядок, то он часто является очевидным и не требует явного прописывания — предполагается, что имея две связанные друг с другом задачи, разработчик сам выберет правильный порядок их выполнения.
Диаграмма Ганта (да и много из управления качеством) пришли в ИТ из материального мира. В котором действительно нельзя покрасить стены до их возведения. В ИТ многие из ограничений реального мира снимаются. Отсюда, думаю, и растут все современные тенденции вроде agile development и т.п.