В Торонто недавно состоялась конференция, организованная Канадским обществом обработки информации (Canadian Information Processing Society), на которой Йордон представил свою новую книгу Death March Projects ("Проекты, обреченные на неудачу").

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

"Какая разница, что вы создали удачную систему, если у вас нервный срыв?"

Йордон определяет проект, обреченный на неудачу, как "проект, который должен быть выполнен за половину того срока, который любой разумный человек установил бы для него". Например, менеджер и участники проекта убеждены, что это 12-месячный проект, но на него дается только 6 месяцев, или в проекте, очевидно, должно работать 10 человек, а задействовано всего 5.

"Другое определение - это когда вероятность неудачи выше 50%. К несчастью, такие проекты встречаются сплошь и рядом, - сетует Йордон. - Это не исключение, это норма".

Так почему же компании продолжают заниматься проектами, обреченными на неудачу?

Часто существенную роль в этом играет политика. Бывает, что организации, которые занимаются маркетингом или продажами, дают обещания, не имея представления о реальном объеме работы. Разработчикам говорят: "Мы только что пообещали, что проект будет закончен через 6 месяцев. А сколько, по-вашему, это займет?" Или какая-нибудь консультационная фирма, разделяющая убеждения руководителей компании Klub Samoubiits, заявляет, что "для настоящего работника есть и спать необязательно, а если вам это так важно - можете убираться".

Однако Йордон не освобождает программистов от ответственности: "Эта индустрия еще молода, и многомиллионные проекты утверждаются ребятами, которые считают, что любая работа может быть сделана за пару дней".

По мнению Йордона, проекты, обреченные на неудачу, могут относиться к одной из четырех категорий.

? Невыполнимая задача: подразумевается, что хорошие люди, мастера своего дела, могут применить эффективную технологию и успешно выполнить задачу, а на следующей неделе прийти за новым заданием.

? Камикадзе: очевидно, что проект обречен. Но, чтобы поддержать репутацию компании, мы идем к поражению, не теряя достоинства.

? Грязное дело: у вас очень хладнокровный менеджер проекта, который заявляет: "Я собираюсь осуществить проект, даже если при этом пострадают несколько человек. С этими людьми придется расстаться, и они будут несчастны, но это ничего".

? Самоубийство: "Когда мне было 34, я был менеджером одного двухгодичного проекта и за все это время взял два выходных. Два года я работал семь дней в неделю, по 18-20 часов в день. Я думал, все хорошо, но через полтора года один парень очутился в сумасшедшем доме. Нам следовало назвать этот проект "Титаником". Но самое плохое не то, что проект провалился, а то, что жизнь того парня была разрушена".

Так почему кто-то все же стремится участвовать в проектах, обреченных на неудачу?

"Если вы работаете в Microsoft или Netscape, риск может быть велик, но и премиальные или возможная выгода могут оказаться достаточно большими, чтобы дело было стоящим", - читаем у Йордона.

Вторая причина - использование чего-то революционного, постановка пусть невыполнимой, но глобальной задачи. Недавно один менеджер в сфере информационных технологий рассказал мне, что некая автомобилестроительная компания приступила к реализации 200-миллионного Java-проекта. Этот проект, очевидно, обречен на неудачу, но он должен стать величайшей задачей во всей индустрии, и не так уж важно, что он закончится провалом.

Третья причина - работа в условиях, когда единственной альтернативой является безработица. Или даже крах всей компании. Например, можно представить, что большинство проектов, разрабатываемых в компании Apple, обречены на неудачу, и, вероятно, никого в Apple это не радует, но все сотрудники по-своему преданы компании.

"Интересно, что ни один участник подобного проекта на самом деле не верит в успех", - сказал Йордон. Если собрать всех разработчиков и менеджеров в конференц-зале и провести тайное голосование по проекту, легко выяснить, что ни один человек не верит, что работа будет закончена вовремя - ни менеджер, ни программисты, ни пользователи.

По Йордону, в случае с проектами, обреченными на неудачу, программисты могут использовать три зоны влияния: людские ресурсы, организацию процесса разработки и технологию.

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

Средства организации процесса разработки полезны, но для менеджера главным должно быть строгое следование методике.

Инструменты разработки приложений, последняя зона влияния, имеют некоторое значение, но, по мнению Йордона, они никогда не спасут плохо организованный проект.

"Люди могут вас спасти, методика может вас спасти, но одни только средства разработки вас не спасут, - уверен Йордон. - Когда я спрашиваю у одних менеджеров проектов, что бы они посоветовали другим менеджерам - купить новейшее средство автоматизированного проектирования или выбрать объектно-ориентированные средства - никто не высказывается в пользу более совершенных инструментов разработки. Так что производителям таких средств есть над чем задуматься".

"Самый важный вопрос, над которым стоит подумать, - убежден Йордон, - это как сделать сотрудников счастливыми".

Эд Йордон не освобождает программистов от ответственности: "Эта индустрия еще молода, и многомиллионные проекты утверждаются ребятами, которые считают, что любая работа может быть сделана за пару дней".

Поделитесь материалом с коллегами и друзьями