Microsoft Project Достоинства и недостатки.
#1
Отправлено 22 Август 2009 - 06:05
#2
Отправлено 30 Август 2009 - 22:31
Был опыт работы с однопользовательской версией. Крепкое решение, в котором разработчики попытались учесть всё, но как обычно с Microsoft - везде по чуть-чуть не доработали. По функциональности есть более крепкие работы - та же Primavera от Oracle. Очевидный плюс Project - интеграция в Microsoft Office. Это очень удобно именно в практической работе.
#5
Отправлено 01 Октябрь 2009 - 20:21
#6
Отправлено 06 Ноябрь 2009 - 16:13
Основные недостатки:
- более чем неэффективная модель данных;
- плохо реализована совместная работа.
Основное впечатление, которое осталось от работы с этим продуктом, это то, что MS Project не позволяет сосредоточиться на нужной информации и акцентирует ненужную
ps. Для IT-проектов рекомендовал бы TRAC - превосходное Open Source решение
#7
Отправлено 07 Ноябрь 2009 - 15:39
Microsoft же попытался сделать пакет, который бы удовлетворил наиболее распространенный спектр требований, не вдаваясь особенно в специфику. По функциональности это, конечно, далекий от идеала продукт.
#8
Отправлено 08 Ноябрь 2009 - 22:59
Fozy (07 ноября 2009 - 15:39):
Это не удивительно для софтового гиганта, который зарабатывает мировым девелопментом. Практически все свои продукты Microsoft пытается адаптировать под максимально возможный круг потребностей. Они вроде бы многофункциональные и многоотраслевые, но погоня за этим часто идёт во вред качеству. Ничего в этом нового и удивительного нет.
#9
Отправлено 15 Декабрь 2009 - 22:03
Fdsm (01 октября 2009 - 20:21):
Познакомился с новым MS Project. В целом пока сказать трудно, насколько он хорош по сравнению со своими предшественниками. Одной из новых функций стал планировщик команды (Team Planner). Идея планировщика заключается в попытке объединения диаграммы Ганта и календаря Outlook, что позволяет видеть задачи каждого члена команды проекта, распределенные по времени, и быстро выявлять проблемы с загрузкой ресурсов. Интересно, на мой взгляд
#10
Отправлено 16 Декабрь 2009 - 10:09
#11
Отправлено 17 Декабрь 2009 - 13:42
#12
Отправлено 03 Январь 2010 - 18:45
elephanta (16 декабря 2009 - 10:09):
Не обо всем сразу сложилось устойчивое мнение
#13
Отправлено 04 Январь 2010 - 06:31
#14
Отправлено 23 Март 2010 - 19:13
#16
Отправлено 08 Май 2010 - 01:57
Правила хорошего тона при планировании в 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. Если в проекте по разработке ПО срок завершения определяется работой по созданию пользовательской документации, это выглядит странно.
За годы своей работы пришел практически к таким же правилам. Есть отличия, но главным образом в нюансах. У каждого свои задачи, тем не менее, изложенная методика вполне позволяет их решать. Что думаете по поводу данных правил?
#17
Отправлено 09 Май 2010 - 18:30
#18
Отправлено 10 Май 2010 - 20:26
#20
Отправлено 15 Август 2010 - 22:43

Вход
Регистрация
Помощь



Цитата











