"Эдвард Йордан "Смертельный марш" (Полное руководство для разработчика программного обеспечения по выживанию в безнадежных проектах)" - читать интересную книгу автора

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

Во многих организациях непосредственный результат перечисленных
ограничений заключается в том, что от проектной команды требуют работать
вдвое интенсивней и/или тратить в два раза больше часов в неделю, чем в
"нормальном" проекте. При том, что нормальная рабочая неделя составляет 40
часов, команде безнадежного проекта зачастую приходится работать по 13-14
часов в день и 6 дней в неделю. В такой обстановке, естественно,
возрастает напряженность и количество стрессов.
Другой способ охарактеризовать безнадежный проект заключается в следующем:
беспристрастная, объективная оценка риска такого проекта (включая риск,
связанный с техническими проблемами, человеческим фактором, законами,
политикой и т.д.) определяет вероятность провала свыше 50%.
Безусловно, даже если перечисленные ограничения отсутствуют, риск неудачи
проекта все равно может быть высоким, например, из-за конфликтов между
IT-подразделением и пользователями. Однако, в общем случае, причиной
высокого риска является сочетание указанных мной факторов.

1.2 Категории безнадежных проектов

Далеко не все безнадежные проекты одинаковы; помимо ограничений в планах,
штатах, бюджете и функциональности, они могут иметь различные масштабы,
формы и другие особенности.
Исходя из моего опыта, наиболее важной отличительной характеристикой
безнадежного проекта является его масштаб. В зависимости от масштаба можно
выделить четыре категории проектов:
* небольшие проекты - проектная команда включает менее 10 человек,
работает в исключительно неблагоприятных условиях и должна завершить
проект в срок от 3 до 6 месяцев;
* средние проекты - проектная команда включает от 20 до 30 человек,
протяженность проекта составляет 1-2 года;