Материалы по стандарту CMMI и около него Основной документ стандарт SWCMMI на русском swcmmi.doc Неформальное введение, управление программистами pravilaashmanova1.doc Неформальное введение, правильные и неправильные проекты pravilaashmanova2…….

1. Подмена понятий. Заголовок гласит “MSP нельзя использовать для управления проектами”. Однако, статья относится только к проектам по разработке software. Некрасиво. Вы забыли, что существует целая куча других проектов.
2. Фраза “Лично не проверял, но могу предположить…” заставляет меня улыбнуться еще раз. Не проверяли – почему так уверенно говорите?
3. Вы правы, ID постоянно меняются. Конечно, Microsoft’у следовало назвать это поле “Номер строки”, как в Excel. Но весь мир давно пользуется WBS-кодами для идентификации задач. Это удобней, наглядней и помогает разбираться в большом объеме схожих задач. Вы просто не дочитали книжку по MS Project.
4. Жизненный цикл задач должен быть подробным, чтобы обеспечить управляемость. Понятие “громоздкость” известна только вам, как руководителю проекта. Участники проекта расписание в целом могут и не увидеть до конца проекта. “Громоздкое расписание” позволяет точно знать, в чьих руках сейчас находится “мячик” и когда это все закончится.
5. Взаимозаменяемость ресурсов. Просто хохма. Если вы как менеджер доверяете софту замену людей на задачах, то вы – просто технический администратор проекта. Прежде чем заменить одного сотрудника на другого, вы обязаны выполнить весьма трудоемкую процедуру по оценке трудозатрат “новых сотрудников”, добиться согласования их руководителя, убедиться, что расписание останется в рамках и т.п. И только потом нажать Alt+F10 и заменить сотрудников.
6. Процент выполнения нужен только тогда, когда вы не утруждаете себя “громоздким расписанием” (см.4). Тогда вы заранее должны определить, что означает 50-75-100% для конкретного проекта. Мой совет – детализируйте задачи до 1 недели и отмечайте выполнение по принципу 0-100%.
7. Длительность проекта – является следствием длительностей задач и сетевого графика. Если у вас по-другому, значит вы не управляете проектом. Попробуйте прийти к инвестору за деньгами и на вопрос “Когда вы рассчитываете закончить проект?” ответить “Не знаю”.
8. Совместная работа в Microsoft Project требует отдельного разговора. Все можно сделать, если захотеть. Скажу только, что никто не снимал с вас необходимости организовывать взаимодействие людей лично. Забудьте про программу. Займитесь людьми.
9. Серверная версия. То, что у вас не получилось поставить сервер не говорит, что он плохо работает.

очень жаль, что Алексей не разобравшись в функционале продукта утверждает, что в нем нет тех или иных функций.

Вот несколько самых вызывающих “ляпов”:

“Project рассчитан на меньшее количество задач, чем вам нужно.” Вообще-то он рассчитан на 1 млн задач, и для удобства Вы можете использовать вложенные проекты. У моих клиентов видел проекты по 10 000 строк – нормально работает.

“Project позволит вам случайно поменять ID задачи. ” Не позволяет, есть особое поле Unique ID, которое можно вывести в таблицу и которое не меняется программой.

“Исполнители взаимозаменяемы.” В Project Server есть возможность задать многоуровневую и многомерную модель компетенций для анализа возможности замены ресурсов друг другом.

“Для частично выполненной задачи можно правдоподобно оценить процент выполнения. ” Это вопрос не проджекта, а методики планирования. Я 2 года внедрял управление проектами и проджект в крупнейшем разработчике ПО в РФ и в сертификации процессов на уровень СММ 5.0 – могу сказать, что эти вопросы решаются более качественным планированием.

“ДеМарко пишет, что в абсолютном большинстве случаев срыв сроков вызван непредусмотренными в плане задачами, а не ошибками в оценке длительности предусмотренных.” – тут Автор противоречит сам себе, подтверждая, что его проблема в том, как он стоит декомпозицию работ. Если он забывает включтиь туда элементы, это не проблема программы ))

И так далее… Одним словом, проджект тут не причем, вопрос в том, как вы планируете и контролируете ход работ. А матчасть все-же надо учить (issue tracking есть в Project Server с 200-года, странно, что Автор это не заметил).

С уважением,
Вадим Богданов

Путаница между понятиями действительно есть, но от нее никуда не деться, потому что во многих случаев управление задачами и есть успавление проектом.

Приятно было читать ваши мысли по ссылке — сразу видно человека, хорошо разбирающегося в теме. Мое видение вопроса несколько отличается, изложу его в отдельной статье как только дойдут руки.