44. Отношение руководителя проекта и разработчиков к бп различных типов.

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

Аналогично, в «отвратительном» проекте отношение его участников диктуется менеджером проекта, или, по крайней мере, сильно зависит от его требований.

Что же касается проектов «камикадзе» и «невыполнимая миссия», а также безнадежных проектов, которые вообще невозможно отнести к какой-либо одной определенной категории, то для них очень важно, чтобы у менеджера проекта было реалистичное представление о тех пределах, в которые укладывается отношение участников команды к проекту; Самое лучшее, если каждый участник проекта честно и объективно оценит свои возможности. К сожалению, далеко не каждый способен запланировать все, что может повлиять на его участие в проекте. Обычный участник команды может пообещать 100-процентное участие в проекте, однако если его ребенок заболеет и попадет в больницу, все обещания будут нарушены. Кстати, это хорошая причина для формирования небольших проектных команд и краткосрочных планов. Команда из 5 человек, работающая над 6-месячным проектом, гораздо меньше подвержена воздействию всяких непредвиденных событий, чем команда из 30 человек, работающая 3 года.. Бессмысленно требовать от кого-либо предвосхищения всех возможных ситуаций, но для менеджера проекта вполне по силам составить себе реалистичное представление относительно ожидаемой степени участия в проекте для каждого его участника.

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

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

45. Оценка сложности проекта. Переговоры. Допустимые компромиссы.

Один из аспектов безнадежного проекта – переговоры по поводу выделения ресурсов под проект и определения хоть каких то реальных сроков. Йодан утверждает, что результат переговоров фатален: руководитель проекта проиграет. Но наш опыт показывает, что на правильно проведенных переговорах можно решить многие проблемы, которые, конечно, не выводят проект из категории безнадежных, но облегчают его выполнение. Здесь играет роль и демонстрация результатов предпроектного обследования, и использование оценок, диаграмм, сетевых графиков, моделей, прототипов. Решение получается как результат разумных компромиссов. В частности, полезно будет задать, например, такой вопрос: «Все хотят, чтобы работа была сделана хорошо, быстро и дешево. Реально можно выполнить только два требования. Какие важны для вас?» Если переговоры зашли в тупик, от проекта следует отказаться или уволиться.

Оценки сложности проекта:

• Средства оценки, являющиеся коммерческими продуктами (в луч случ 10)

1. SLIM (Quantitative Systems Management),

2. ESTIMACS (Computer Associates)

3. CHECKPOINT (Software Productivity Research (SPR)).

• Динамические модели систем - разработано множество имитационных моделей, которые позволяют исследовать нелинейные зависимости между различными факторами, влияющими на динамику проектных процессов. Естественно предположить, что по сравнению с нормальным восьмичасовым рабочим днем «отдача» увеличится, однако наиболее опытный менеджер проекта также отметит, что производительность (измеряемая в количестве функциональных точек в день, строках кода в час и т.д.) по мере накопления усталости будет постепенно снижаться. Кроме того, возрастет количество ошибок, что, очевидно, повлияет на трудоемкость тестирования и отладки. И, если сверхурочная работа будет продолжаться достаточно долго, то проектная команда просто окажется на грани истощения. Из всех имитационных моделей, которые я видел, наилучшей представляется модель, которая реализована на языках DYNAMO и iThink.

• Книги об оценке проектов. ( Барри Боэм, COCOMO-2;. Фреда Брукса, Джим Маккарти).

• Сам процесс оценки достаточно изучен и документирован, и организации, подобные Software Engineering Institute (SEI), уже опубликовали различные руководства и отчеты [6,7], которые могут помочь при выполнении оценки проектов.

• Прототипирование - это быстрая «черновая» реализация базовой функциональности для анализа работы системы в целом.

Допустимые компромиссы Предположим, что проектная команда подготовила «разумную» оценку плана, бюджета и персонала, требуемых для безнадежного проекта, и руководство готово пойти на некоторые переговоры перед тем, как принять окончательное решение. Наиболее вероятно, что руководство объявит первоначальную оценку «неприемлемой» и выдвинет свои требования, которые окажутся гораздо более жесткими. Как в этом случае следует поступить менеджеру проекта.

Допустимы компромиссы:

• Компенсировать изменение одной переменной проп. изм. другой(=<10%)) Если требования пользователей или высшего руководства включают изменение одной из переменных проекта в пределах 10%, его можно компенсировать пропорциональным изменением одной из остальных переменных. Так, например, если руководство хочет сократить срок разработки на 10%, следует увеличить на 10% состав проектной команды. Вряд ли это будет точной компенсацией, но достаточно хорошо в первом приближении, и, как правило, это все, что вам удастся сделать в процессе переговоров.

• Если изменение одной переменной выходит за пределы 10%, следует исходить из предположения, что обратное воздействие на какую-либо одну из оставшихся переменных будет квадратичным.