Путь камикадзе

* Динамические модели систем – разработано множество имитационных моделей, которые позволяют исследовать нелинейные зависимости между различными факторами, влияющими на динамику проектных процессов. Например, если частью стратегии безнадёжного проекта является требование сверхурочной работы участников проекта со стороны менеджера, каков будет эффект через несколько недель или месяцев? Естественно предположить, что по сравнению с нормальным восьмичасовым рабочим днём «отдача» увеличится, однако наиболее опытный менеджер проекта также отметит, что производительность (измеряемая в количестве функциональных точек в день, строках кода в час и т.д.) по мере накопления усталости будет постепенно снижаться. Кроме того, возрастёт количество ошибок, что, очевидно, повлияет на трудоёмкость тестирования и отладки. И, если сверхурочная работа будет продолжаться достаточно долго, то проектная команда просто окажется на грани истощения. Из всех имитационных моделей, которые я видел, наилучшей представляется модель, описанная в [1], которая реализована на языках DYNAMO и iThink.

* На тему об оценке проектов написано множество книг. Лучше всего начать с книги Барри Боэма [2]; отметим также, что его модель COCOMO, разработанная в начале 80-х годов, была позднее модифицирована в модель COCOMO-2 [3]. Другой классической работой является книга Фреда Брукса [4], также недавно переизданная с учётом современной технологии и практики разработки ПО. Ещё одна новая книга, которую можно рекомендовать – это работа Джима Маккарти [5].

* Сам процесс

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

* Такие распространённые методы, как прототипирование, также могут использоваться для оценки критичности тех или иных проектных ограничений для всей разрабатываемой системы в целом. Этот подход ни в коем случае не может служить «защитой от дурака», но, тем не менее, он позволяет привнести немного здравого смысла в проектную команду и окружающих её менеджеров и заказчиков. Если руководство хочет, чтобы команда из трех разработчиков написала миллион строк кода за 12 месяцев, то следовало бы в течение первого месяца разработать небольшой прототип будущей системы, который, по крайней мере, позволит грубо оценить производительность проектной команды, а также реализуемость проекта в целом.

3.2 Допустимые компромиссы

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

Как отметил автор и консультант John Boddie, очень важно, чтобы все согласились с наличием более чем одного возможного «сценария» для проекта. Для проведения переговоров нелишними будут такие вопросы, как «обанкротится ли организация, если система будет готова не к 1-му сентября, а к 5-му?» или «все хотят, чтобы работа была сделана хорошо, быстро и дёшево. Все знают, что реально можно выполнить только два требования из трех. Какие именно два для вас важнее?».

Если контрпредложение со стороны высшего руководства или заказчика содержит только одну «переменную», менеджер проекта может оценить влияние остальных переменных. Например, если первоначальная оценка менеджера проекта заключается в том, что проект потребует 12 месяцев на реализацию, трех разработчиков и бюджет 200.000$, вполне вероятно, что первой реакцией руководства будет: «Вздор! Нам нужно, чтобы система была готова и работала через шесть месяцев!» На первый взгляд, очевидный способ сделать это заключается в увеличении штата и/или бюджета (например, увеличить зарплату, чтобы привлечь более продуктивных программистов).

С другой стороны, Фред Брукс уже более 20 лет назад отмечал, что зависимость между количеством разработчиков и временем разработки носит нелинейный характер; поэтому термин «человеко-месяц» был объявлен мифом. Разумеется, практическивсе зависимости между ключевыми переменными проекта являются нелинейными и зависящими от времени. Вследствие эффекта «обратной связи», возникающего в результате многих решений руководства, изменение одной переменной (например, увеличение штата) повлияет со временем не только на другие переменные (такие, как продуктивность), но и на собственное первоначальное значение – например, увеличение штата может отрицательно повлиять на моральное состояние команды, что, в свою очередь, может увеличить текучесть рабочей силы в проекте и в конечном счёте снизить численность персонала.