Лекция 24. Переговоры с вышестоящим руководством

1. Предварительные переговоры

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

Сказанное вовсе не означает, что не надо прилагать никаких усилий к получению «разумных» оценок, которые можно было бы использовать во время предварительных переговоров по проекту. Крайне важно, чтобы менеджер проекта избежал соблазна пойти по пути наименьшего сопротивления и принять любые начальные условия безнадежного проекта как указ свыше. Одним из общих признаков того, что проектная команда приняла стиль поведения «самоубийственного» проекта является позиция, выражаемая менеджером проекта (и разделяемая участниками команды), которая заключается в следующем: «Мы не имеем представления, сколько времени реально потребует этот проект, да это и не имеет значения, поскольку нам уже сообщили конечный срок. Таким образом, нам придется работать семь дней в неделю и 24 часа в день, пока мы не свалимся от изнеможения. Пускай нас ругают и колотят, но мы не в состоянии прыгнуть выше головы...»

Существуют некоторые полезные и доступные ресурсы, которые имеются в данной области:

Средства оценки, являющиеся коммерческими продуктами - такие, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates) и CHECKPOINT (Software Productivity Research (SPR)). Глава SPR Capers Jones, «гуру» в области метрик ПО, оценивает рынок средств оценки проектов примерно в 50 продуктов. Эти продукты нельзя назвать совершенными, и все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип «мякину заложишь - мякину получишь»). В лучшем случае с помощью таких продуктов можно получить оценку с точностью с точностью 10%. Даже если точность будет 50%, чем иметь дело только с продиктованными политикой требованиями, с которыми приходится справляться менеджеру проекта и которые на 1000% выходят за пределы возможностей проектной команды.

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

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

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

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