Глава 1. Введение

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

Для многих закаленных ветеранов эти вопросы - чистая риторика. С точки зрения их опыта, каждый проект - это безнадежный проект. Почему так происходит? Поведение больших корпораций зачастую выглядит неразумным. Как отмечает эксперт Richard Sargent, «неразумное поведение корпораций заключается в том, что они делают одно и тоже снова и снова, каждый раз ожидая различных результатов». Почему мы участвуем в таких проектах? Как отмечает эксперт Dave Kleist:

Вряд ли можно где-нибудь увидеть объявление о найме для участия в безнадежном проекте. Какой смысл спрашивать: «Хотите ли вы работать сверхурочно без какой-либо прибавки к зарплате? Привлекает ли вас бесконечная работа по устаревшей технологии и тщетное ожидание участия в каком-нибудь замечательном проекте GUI/DSS/DWH/HTML? Каково будет узнать, что трехзвенная архитектура «клиент-сервер» позволит остальным участникам проекта обойтись без вашей помощи?»

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

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

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

1.1 Определение безнадежного проекта

Под безнадежным проектом (death march) я понимаю такой проект, параметры которого отклоняются от нормальных значений по крайней мере на 50%. По отношению к софтверным проектам это обычно означает одно или более из следующих ограничений:

• План проекта сжат более чем наполовину по сравнению с нормальным расчетным планом; таким образом, проект, требующий в нормальных условиях 12 календарных месяцев, приходится выполнять за 6 или менее месяцев. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной.

• Количество разработчиков уменьшено более чем наполовину по сравнению с действительно необходимым для проекта данного размера и масштаба; таким образом, вместо формирования проектной команды из десяти человек, менеджера проекта убеждают, что достаточно и пяти. Такое представление может быть результатом наивной веры в магические возможности новых CASE-средств или языков программирования удваивать производительность труда разработчиков - несмотря на то, что разработчики не обучались или не имеют практического опыта работы с новой технологией и, скорее всего, с ними никто не советовался по поводу решения использовать новую технологию. На сегодняшний день более общей причиной уменьшения количества разработчиков является сокращение штатов компании в результате реорганизации, реинжиниринга и т.д.

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

• Требования к функциям, возможностям, производительности и другим техническим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях. Например, проектной команде могут заявить, что они должны по сравнению с конкурентом выжать в два раза больше возможностей из фиксированного объема RAM или дискового пространства. Или, например, от них могут потребовать, чтобы система поддерживала вдвое большее количество транзакций по сравнению с любой сопоставимой системой. Требования, связанные с производительностью, могут и не повлечь за собой неудачу проекта; в конце концов, всегда можно использовать преимущества более дешевого и производительного оборудования, а также разработать более совершенный алгоритм или подход к проектированию, чтобы достичь повышения производительности (хотя, при сжатых сроках, могут не помочь и безграничные возможности человеческого мозга). С другой стороны, удвоение функциональных возможностей обычно означает удвоение необходимого объема работы, что обязательно приведет к неудаче проекта.

Во многих организациях непосредственный результат перечисленных ограничений заключается в том, что от проектной команды требуют работать вдвое интенсивней и/или тратить в два раза больше часов в неделю, чем в «нормальном» проекте. При том, что нормальная рабочая неделя составляет 40 часов, команде безнадежного проекта зачастую приходится работать по 13-14 часов в день и 6 дней в неделю. В такой обстановке, естественно, возрастает напряженность и количество стрессов.

Другой способ охарактеризовать безнадежный проект заключается в следующем: беспристрастная, объективная оценка риска такого проекта (включая риск, связанный с техническими проблемами, человеческим фактором, законами, политикой и т.д.) определяет вероятность провала свыше 50%.

Безусловно, даже если перечисленные ограничения отсутствуют, риск неудачи проекта все равно может быть высоким, например, из-за конфликтов между IT-подразделением и пользователями. Однако, в общем случае, причиной высокого риска является сочетание указанных мной факторов.