Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард

Безнадёжные проекты нередко предоставляют возможность обойти некоторые, если не все, бюрократические рогатки – и этого достаточно, чтобы раздражённые бюрократией разработчики ПО принимали участие в таких проектах. В крайнем случае проектная команда даже перебирается в отдельное здание, где они могут выполнять свою работу, не отвлекаясь на обычную бюрократию. Даже в менее экстремальной ситуации безнадёжный проект зачастую даёт возможность свои собственные средства и языки программирования, осваивать новые технологии наподобие объектно-ориентированного программирования, а также сокращать большинство громоздких процедур и объём документации, которые в обычных условиях требуются в полном объёме. Не менее важно, что менеджер проекта зачастую получает гораздо большую свободу действий в подборе участников проектной команды, чем в обычных условиях.

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

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

1.4.8 Месть

Месть может показаться не слишком разумным объяснением участия в безнадёжном проекте, но, тем не менее, это обстоит именно так. Успех безнадёжного проекта может оказаться достаточным для того, чтобы выбить власть из рук некомпетентного вице-президента компании, или утереть нос критиканам, которые все время уверяли вас, что в рамках ограниченных сроков и бюджета такой проект выполнить немыслимо. Месть – это весьма сильное чувство, и оно играет особенную роль на уровне высшего руководства в крупных организациях, где обиды запоминаются на всю жизнь, и хитрые политики могут месяцами и годами дожидаться возможности отомстить своим противникам.

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

Если вашим личным мотивом является месть, то я могу сказать только одно – это ваши личные проблемы. Но если вы собираетесь участвовать в проекте, в котором менеджер или вся команда из чувства мести готовы согласиться с совершенно неразумными для «нормального» проекта планом и бюджетом, то следует быть особенно осмотрительным. «Вице-президент – кретин», – может сказать вам менеджер проекта, – «и если мы завершим этот проект за шесть месяцев, то он будет выглядеть таким дураком перед Советом Директоров, что ему придётся подать в отставку!» Хорошо, все это замечательно – может быть, вице-президент и в самом деле кретин. Однако, стоит ли ради его отставки жертвовать своей личной жизнью в течение двух ближайших лет? В конце концов, следующий вице-президент может оказаться ещё большим кретином, чем прежний.

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

1.5 Заключение

Как бы цинично или пессимистично ни звучало сказанное в этой главе, это не поможет избавиться от безнадёжных проектов. Компании (как крупные, так и небольшие) переполнены политикой, там работают менеджеры и технические специалисты, страдающие безудержным оптимизмом и испытывающие полную гамму эмоций – страха, беззащитности, самонадеянности и жестокости. Сочетание таких факторов, как реинжиниринг, даунсайзинг, аутсорсинг и глобальная конкуренция – в совокупности с возможностями, предоставляемыми новыми технологиями, такими, как объектно-ориентированное программирование, клиент-сервер и Internet – приводит меня к выводу, что в ближайшие годы безнадёжные проекты будут, вероятно, всеобщим явлением.

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

Между прочим, все это не означает, что я против любых безнадёжных проектов; я согласен с мнением моего коллеги Rick Zahniser, что такие проекты даже в случае неудачи могут дать очень полезный опыт:

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

1) провести ночь в тюрьме;

2) напиться в стельку;

3) вырастить сына;

4) вырастить дочь;

5) начать свой собственный бизнес;

6) подняться на гору Фудзи.

(Японцы по этому поводу говорят: «Кому не удалось подняться на гору Фудзи – тот дурак. Тот, кто поднялся на гору Фудзи дважды – ещё больший дурак».)

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

Литература к главе:

1) John Boddie. Crunch Mode. Englewood Cliffs, NJ: Yourdon Press/Prentice Hall, 1987.

2) Scott Adams. The Dilbert Principle. New York: HarperBusiness, 1996.

ГЛАВА 2.

ПОЛИТИКА

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

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