Эдвард Йордон - Путь камикадзе [Смертельный марш]

В данной главе я исхожу из предположения, что вы так или иначе участвуете в переговорах по поводу безнадёжных проектов, планов и т.д. Если вы технический специалист, то ваше участие может и не быть непосредственным – например, вы можете консультировать менеджера проекта и готовить для него необходимую информацию с тем, чтобы он мог проводить переговорные баталии на более высоком уровне. Однако, как напомнил мне недавно Doug Scott, даже менеджер проекта может оказаться на вторых ролях, поскольку все переговоры проводятся от его имени менеджером более высокого уровня.

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

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

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

Я не собираюсь долго обсуждать различные методы оценки; если у менеджера проекта нет никакой квалификации или опыта в оценке, то безнадёжный проект – совсем неподходящее место, чтобы начинать обучение таким методам. Позволю себе все же отметить некоторые полезные и доступные ресурсы, которые имеются в данной области:

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

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

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

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

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