Правила хорошего тона при планировании в MS Project

Можно выделить два существенно отличающихся друг от друга класса задач, которые можно решать с помощью MS Project:

а) Оценка проекта (обычно на стадии pre-sale)
б) Мониторинг текущего состояния проекта (естественно, на стадии выполнения проекта)

Следующие рекомендации относятся к задачам класса б):

1) Добавьте колонку Work и оценивайте задачи в терминах трудоемкости (человеко-часы или дни), но не в терминах длительности (просто часы или дни).

2) Назначайте на одну задачу одного исполнителя. По возможности избегайте назначать исполнителям загрузку, отличающуюся от 100%. По возможности.

3) Определите и придерживайтесь единого подхода к наименованию задач (например, начинайте все задачи со стандартных отглагольных существительных (типа "Разработка ...", "Определение ....")

4) ВСЕГДА используйте ОДНУ корневую задачу, суммирующую все работы по проекту

5) Определите и придерживайтесь однородной гранулярности задач (например, от 1 до 5 человеко-дней..). Использование для оценки человеко-дней (а не человеко-часов) загрубляет оценки в большую сторону, что, как правило, положительно сказывается на их реалистичности.

6) Добавьте колонку % выполнения перед колонкой Task

7) Не злоупотребляйте зависимостями маежду задачаими. На практике ситуация,когда задача 2 не может ДАЖЕ НАЧАТЬСЯ до ПОЛНОГО ЗАВЕРШЕНИЯ задачи 1 встречается КРАЙНЕ редко. Чаще задача 2 не может ЗАКОНЧИТЬСЯ до завершения задачи 1,но управлять такой зависимостью сложно. Посему. В хорошем плани зависимостей МАЛО.

7) Порядок же выполнения работ в хорошем плане В ОСНОСВНОМ определяется приоритетом задач. Соответственно,используйте колонку Priority.

8) Включите в опциях левелинга режим Automatic, правило "Priority, standard", запретите Проджекту переназначать ресурсы и разбивать задачи

9) ОПАСАЙТЕСЬ установки constraints на выполнение задачи типа "Starts not earlier then". Такие задачи редки. Установите бледно-серый серый цвет шрифта на колонки Start и Finish, чтобы подсознательно полагать их нередактируемыми и НИКОГДА не изменять значения в этих колонках вручную. ВЫ выставляете трудоемкость, ресурс, приоритет задачи (+ иногда зависимость). ПРОДЖЕКТ определяет даты старта и финиша.

10) После левелинга во вьюшке Resoursece usage не должно остаться ни одного ресурса,покрашенного красным (overallocation)

11) После левелинга хорошего плана трудоемкость распределяется между ресурсами in a meaningful manner. Если наша цель сделать работу поскорее, у нас есть 2 человека, но один по плану работает 100 часов,а другой 10,то это непонятно. Либо нужно постараться распределить работы 50-50,60-40 и т.п., т.е. почти поровну; либо иметь вменяемое объяснение, почему так делать нельзя или не следует

12) Если сегодня 26 мая, то все работы, дата старта которых <= 26 мая, должны иметь % выполнения > 0; все работы, дата завершения которых <= 26 мая, должны иметь % выполнения = 100. Если есть работы, не удовлетворяющие этому условию, значит план неактуален и требует обновления

13) Не должно, как правило, быть работ, на которые не назначены ресурсы.

14) Критический путь должен состоять из meaningfull tasks. Если в проекте по разработке ПО срок завершения определяется работой по созданию пользовательской документации, это выглядит странно.


А какие у вас правила хорошего тона?