Во многих организациях непосредственный результат перечисленных ограничений заключается в том, что от проектной команды требуют работать вдвое интенсивней и/или тратить в два раза больше часов в неделю, чем в «нормальном» проекте. При том, что нормальная рабочая неделя составляет 40 часов, команде безнадёжного проекта зачастую приходится работать по 13-14 часов в день и 6 дней в неделю. В такой обстановке, естественно, возрастает напряжённость и количество стрессов.
Другой способ охарактеризовать безнадёжный проект заключается в следующем: беспристрастная, объективная оценка риска такого проекта (включая риск, связанный с техническими проблемами, человеческим фактором, законами, политикой и т.д.) определяет вероятность провала свыше 50%.
Безусловно, даже если перечисленные ограничения отсутствуют, риск неудачи проекта все равно может быть высоким, например, из-за конфликтов между IT-подразделением и пользователями. Однако, в общем случае, причиной высокого риска является сочетание указанных мной факторов.
1.2 Категории безнадёжных проектов
Далеко не все безнадёжные проекты одинаковы; помимо ограничений в планах, штатах, бюджете и функциональности, они могут иметь различные масштабы, формы и другие особенности.
Исходя из моего опыта, наиболее важной отличительной характеристикой безнадёжного проекта является его масштаб. В зависимости от масштаба можно выделить четыре категории проектов:
* небольшие проекты – проектная команда включает менее 10 человек, работает в исключительно неблагоприятных условиях и должна завершить проект в срок от 3 до 6 месяцев;
* средние проекты – проектная команда включает от 20 до 30 человек, протяжённость проекта составляет 1-2 года;
* крупномасштабные проекты – проектная команда включает от 100 до 300 человек, протяжённость проекта составляет 3-5 лет;
* гигантские проекты – в проекте участвует армия разработчиков от 1000 до 2000 человек и более (включающая, как правило, консультантов и соисполнителей), протяжённость проекта составляет от 7 до 10 лет.
По различным причинам, небольшие проекты являются наиболее распространённой категорией проектов в тех организациях, где мне удалось побывать, и, к счастью, их шансы на успешное завершение наиболее высоки. Компактная и сплочённая команда не более, чем из 10 человек, скорее всего не распадётся, несмотря на все препятствия, в течение короткого шестимесячного периода; в случае высокой степени заинтересованности её участники, вероятно, будут готовы пожертвовать своей личной жизнью (но не здоровьем!) в течение 3-6 месяцев, поскольку они знают, что бессонные ночи, потерянные выходные и отсроченные отпуска через считанное время закончатся.
Шансы на успешное завершение средних проектов заметно ниже, а для крупномасштабных проектов почти равны нулю. В больших проектных командах более трудно поддерживать чувство сплочённости и высокий командный дух; резко возрастает вероятность, что кого-нибудь переедет грузовик или он станет жертвой одной из многочисленных опасностей, подстерегающих людей в современном обществе. Причём решающее значение имеет не только количество участников проекта, но и временная протяжённость: 80-часовую рабочую неделю в течение 6 месяцев ещё можно вытерпеть, но если работать так в течение двух лет, скорее всего, возникнут проблемы. Даже если менеджер способен убедить небольшую группу технарей принести такую жертву, это практически невозможно сделать для больших проектных команд; по статистике, очень вероятно, что некоторые из них женятся или выйдут замуж или найдут себе ещё какое-нибудь занятие на стороне.
Что касается гигантских проектов, может показаться непонятным, как они вообще существуют. Возможно, разработка системы, связанной с проектом NASA высадки человека на Луну в 1969 году, может считаться примером успешного завершения безнадёжного проекта; однако, подавляющее большинство таких проектов с самого начала обречено на провал.
Естественно, проект может вовсе не задумываться как гигантский, и перспектива его провала может быть совсем не очевидна. Об этом мне недавно напомнил один из участников неудачного совместного проекта Apple и IBM под названием Taligent. Этот проект ранее фигурировал в Apple под кодовым названием Pink, а ещё раньше был известен как SNARC (Sexy New Architecture – Новая Сексуальная Архитектура). Самое замечательное заключалось в том, что в любой момент его семилетнего жизненного цикла и в любой из его ипостасей он всегда воспринимался как двухлетний проект. Такое ощущение было в первый день проекта, и в это свято верило большинство менеджеров после семи лет безумной работы, когда проект был прекращён.