1) Если внесены фактические данные, то в MS Project на ганте в первом случае, вы увидите, что за 5 календарных дней разработчик реально внес в отчет по этой задаче к примеру 24 ч. работы. Это будет выглядеть в виде прерывистого прогресс индикатора на полосе ганта. Во втором случае вы увидите, что за 5 календарных дней выполнено работы на 5 человеко/дней. Индикатор потраченного времени будет сплошным.
2) Для того, чтобы использовать гант нет необходимости знать структуру работ на 100%. Проектирование не обязано быть огромным, но является must have практикой для waterfall проектов.
Teacher, я вообще-то отвечал на комментарий gandjustas. Но могу прокомментировать и сроки окончания проекта:
Если вы не любите кошек, значит вы просто не умеете их готовить :)
Диаграмма Ганта помогает рассчитать (и даже увидеть) критический путь проекта, а стало быть помогает рассчитать сроки окончания проекта. Более того, ее часто именно для этого и используют.
Диаграмма Ганта — это всего лишь средство визуализации. И описанные в статье проблемы заключается не в гантте, а в использовании мат. и стат. методов там, где лучше использовать экспертную оценку предстоящих объемов работ. Если есть история и статистика, то есть и специалисты, которые способны давать адекватные оценки. В оценках, разумеется тоже будут погрешности, но оценки не будут основываться на заведомо неверных предпосылках, что все 5 проектов будут одинаковыми и что все этапы каждого проекта будут одинаковой длительности.
В общем, когда проекты опаздывают, это происходит не из-за диаграммы Ганта. :) см. факторы успеха IT проектов.
1) Некоторые системы управления проектами, например MS Project позволяют учитывать и визуализировать на диаграмме Ганта время реально потраченное на эту конкретную задачу.
2) Структура работ вполне может появляться в начале проекта. Если она регулярно появляется только в конце, то лучше работать по agile и гант вообще не особо нужен. Кстати, диаграмма Ганта, построенная программно, легко меняется при необходимости.
Статья именно для тех, кому надо. Таких людей много. Их можно увидеть в т.ч. в комментариях ниже. Согласен, с тем, что не каждый человек создан продуктивным. Однако, слава богу, у людей есть способность к развитию. Эта же способность к развитию помогает взять контроль над рептильным мозгом, один из приоритетов которого — примитивная экономия энергии (прокрастинация) и больше пользоваться неокортексом.
Я бы не назвал это принципами, скорее правила. Стремлюсь к этому по возможности. Для управления реально большими и сложными проектами (которые являются не просто задачей с подзадачами) я использую специализированное программное обеспечение. В качестве альтернативы, как я написал можно для активного проекта настроить отдельную вкладку и работать с ним там.
У Стивена Кови в «First Things First» есть настоящее описание эволюции тайм-менеджмента. Возможно там вы увидите, что пытались использовать инструменты первых трех поколений тайм-менеджмента. Они повышают вашу продуктивность, но не дают вам удовлетворения жизнью. Это естественный вывод. Вам можно переходить на следующий уровень.
Без проектов все же не обойтись. Всегда есть задачи, включающие в себя подзадачи. Если проект имеет немного уровней вложенности и для него настроена отдельная вкладка — несложно с ним работать. В случае если задача относится к проекту, она разумеется, добавляется в него, а не в «Входящее».
Уточните, если не так понял вопросы.
Необходимость сделать максимально быстро задачи из проекта N — переключаюсь на вкладку этого проекта.
Как привязаться к срокам? — устанавливаем срок у задачи.
Куда добавлять заметки (задачи не требующие выполнения) — для этого у каждой задачи есть поле «заметки».
Если быть точным, у меня больше пяти контекстов. Я не стал в примере показывать все. Это индивидуально для каждого. Из тех, что должны быть у всех, помимо Inbox (если вы следуете GTD) — контекст типа «может быть когда-нибудь». Сроки у задач использую только в случаях, если по этому сроку есть обязательство.
Я не использую эту фичу. Прийдется вместе с названием задачи набирать название контекста. Это много лишних кнопок+вероятность ошибки. Для назначения часто используемых контекстов рекомендую использовать шорткаты. Они назначаются в свойствах контекста.
2) Для того, чтобы использовать гант нет необходимости знать структуру работ на 100%. Проектирование не обязано быть огромным, но является must have практикой для waterfall проектов.
Если вы не любите кошек, значит вы просто не умеете их готовить :)
Диаграмма Ганта помогает рассчитать (и даже увидеть) критический путь проекта, а стало быть помогает рассчитать сроки окончания проекта. Более того, ее часто именно для этого и используют.
В общем, когда проекты опаздывают, это происходит не из-за диаграммы Ганта. :) см. факторы успеха IT проектов.
2) Структура работ вполне может появляться в начале проекта. Если она регулярно появляется только в конце, то лучше работать по agile и гант вообще не особо нужен. Кстати, диаграмма Ганта, построенная программно, легко меняется при необходимости.
Необходимость сделать максимально быстро задачи из проекта N — переключаюсь на вкладку этого проекта.
Как привязаться к срокам? — устанавливаем срок у задачи.
Куда добавлять заметки (задачи не требующие выполнения) — для этого у каждой задачи есть поле «заметки».