пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ. MS PROJECT. пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ: пїЅпїЅпїЅпїЅпїЅ

сенькс!

�з того что сразу приходит в голову
- иная структура команд и системы мотивации;
- ограниченность размера не позволяет использовать комплексные системы контроля;
- цели проекта подчас нестабильны;
- короткие сроки проекта являются причиной большего внимания к тактическим задачам, отодвигая стратегии на задний план;
- малый проект может быть успешным даже при отутствии управления.

1. Про структуру команд.
Больших проектах без четкого распределения ролей - никуда. В маленьких - сплошь и рядом нет никаких ролей и все равно все ок.
2. Система контроля не может быть единой в силу разного характера проектов. Срочное затыкание дырок в работающей third-party системе и самостоятельная разработка приложения - это кардинально разные с точки зрения управления проекты. � измерение их одним лекалом обычно приводит к очень забавным результатам.
3. Цели проектов определяются заказчиками. В случае внутрикорпоративной разработки заказчики - это жутко нестабильные товарищи (почти всегда).
4. Половина проектов опять таки может делаеться не из стратегических, а тактических интересов. Пример - "срочное дополнение системы финансового учета для учета нового закона, регулирующего товарооборот".
5. Отсутствие необходимости в формализировнном управлении и есть основное отличие мелкого проекта от большого. � именно поэтому получается п.6:
6. Если руководство выросло из мелких проектов, то понять как управлять мультипроектом будет ему очень сложно. Поэтому необходимо искать простые и понятные методики, простые метрики и индикаторы. � в этом концепция мультипроекта, я надеюсь мне очень поможет, за что еще раз премного и искренне благодарю.

Скажи, пожалуйста, Вадим, сколько в этом случае было одновремено идущих проектов и сколько человек пришлось тренировать?

1-4. Согласен с вами по всем четырем пунктам. Вопрос в том что можно возразить людям которые говорят, "зачем это все нужно? оно же и так работает?"
3. "процедуры переброски ресурсов из проекта в проект" А вот тут у меня к вам лично вопрос - подскажите, пожалуйста, как это можно сделать инструментально? В MS Project это помнится было большой проблемой даже при включенном Auto-Leveling.

Процедура "Выдергивания" - это самое интересное. Как именно это можно сделать?
Я обычно могу найти свободный ресурс в течение 5 минут, но потом если действовать аккуратно мне придется полдня оббивать пороги, чтобы мне его выделили. А если делать неаккуратно, то провести потом это время по нужному проекту может быть очень непросто.

Сенькс. Буду думать.

правда не уверен что Resource Substitution Wizard, это то, что нужно.
Вот, например, вот такая задача:
Есть проект из трех тасков идущих подряд:
TaskA - 5 days
TaskB - 7 days
TaskC - 2 days
Нужно добавить четвертый TaskD, продолжительностью 1 день, с датой начала ровно в 9 день проекта. При этом в TaskB должен появиться однодневный Split и сроки проекта должны сдвинуться на 1 день.
Если включен Auto leveling и TaskB был выполнен хотя бы на 1%, то срабатывает просто супер (у меня MSP 2000).

А вот если я сперва добавил таск TaskD и потом пытаюсь разобраться со съезжающим TaskB, то проблем сразу куча.

Вопрос - в 2002-2003 версиях это лучше работает?

PS. К стати хорошая идея - надо поставить и попробовать.

Попробовал MSP 2003 Pro - все работает как часы.
Виват MS!

P.S. Вадим, я не говорил, что Spider работает плохо. Я его даже не видел. :-) Демо-версий нет - так что ой.

посмотрел.
Первое впечатление - интерфейс непростой. Т.е. не смотря на название Lite требуется куча времени, чтобы разобраться в том как в нем работать. Попробую завтра еще покопаться. Хотя видны уже сейчас приятные штуки.

Скажите, а как включить автоматический расчет расписания?

Логично. � даже хорошо.
Заставляет людей сперва создавать WBS и потом уже проставлять связи. Автокалькуляция - это действительно "развратная функция" :-)

А в Spider'е есть индикатор того что план был изменен после последнего расчета?

Как мне показалось Lite был сделан урезанием некоторых функций профессиональной. Не переработкой и упрощением интерфейса, а именно урезанием. Увы, концепции заложенные в профессиональную версию слижком сложны для быстрого ознакомления, а Lite версия - она же для чайников.

Так что я быстренько перелез на английскую версию Pro.

Завтра еще покопаюсь.

> покрывающий возможности западных конкурентов
С точки зрения ядра - верю.
С точки зрения ползовательского интерфейса - не сказал бы :-)

> почему английская версия prof, а не русская? Просто привычнее?

Да. Наверное это привычка. В русской версии я все время дергался от непривычных названий.

Плотник1 [50%]; Плотник2 [50%] ?

Я имею в виду подбор ресурсов по Skill-set, по набору требуемых навыков и умений.
Как мне кажется, часто ресурсы выбираются не по скорости работы, а именно по Skills'ам.

Вы все время скатываетесь на обсждение механизмов ERP в системах управления проектов. Я конечно понимаю, вы консультанты-внедренцы, и вам именно это важно. Но у обычных людей то совсем другие проблемы. Например, как не забивая голову сотней различных методик, особенностей и приемов создать "понятный" и "достаточно точный" план. А для этого обычно требуется максимально упрощать планирование, а не усложнять его различными стратегиями подбора ресурсов.

Не совсем так. Методологию можно и самим придумать, а инструментарий приходится покупать.

Я думаю о том во сколько обойдется обучение MSP и Spider'у + обучение правильным подходам в работе. Пока однозначного ответа у меня нет. :-)

А методология - я не думаю, что ее можно изобрести вот так вот в форуме. Для ее создания необходим work-shop на несколько рабочих дней.

Скажите, правильно ли я вас понял, что вы берете $1200 за одного слушателя?

Отдельные советы тут давать сложно - надо серьезно и комплексно копаться.

А недостатки на мой взгляд следующие:
1. Складывается впечатление (возможно ошибочное), что интерфейс делался, чтобы реализовать различные приятности для пользователя, а не для того чтобы ему было удобно. Могу привести для аналогии ребенка, которого можно кормить конфетами, а можно кашей. Так же и тут. Много ярких приятностей, но нет ясной и целостной картины. Впрочем это относится только к интерфейсу - ядро (как мне показалось) напротив понятнее и целостней чем у MSP.

2. Как следствие указанного имеется очень высокая когнитивная сложность. Пользователю может быть сложно понять где (в каком окне) он находится. Потому что их много и они все похожие. Порой сложно найти нужную функцию потому что визуально все смешивается. Впрочем этим и MS тоже страдает. Но там помогает опыт работы с офисными приложениями, а в Спайдере интерфейс другой и приходится учиться с нуля.

3. Я не считал, но похоже количество кликов на одно действие в спайдере заметно больше чем в MSP. Для одного и того же действия приходится гораздо больше щелкать, двигать мышкой и нажимать кнопки на клавиатуре. Если это верно, то это почти однозначный недостаток. Потому что 1 лишняя секунда в минуту, потраченая на размышления, в течение года может вылиться в сотни тысяч долларов.

А вот приятности все очень даже приятные.
� плавный зум, и радостные и солнечные цвета интерфейса, и иконки симпатичные.
Очень приятная фича - окно открытых проектов со списком доступных Views.
Суперская фича - организационная диаграмма.

Т.е. вы все таки согласны с тем что Spider оринтирован на большие и сложные проекты. Ну или корпоративные мульти проекты. :-)
Так ведь?

Маленькие проекты часто нормально выживают без формального планирования и управления.

Скажите, используется ли Spider хоть в одной Web-design студии или хоть в одном рекламном агентстве?