Возможность победить бюрократию

Технические специалисты и менеджеры проектов часто жалуются, что их корпоративная бюрократия снижает продуктивность работы и вносит ненужные задержки в процесс разработки ПО. Чем крупнее организация, тем сильнее пускает в ней бюрократия свои корни - особенно в тех организациях, где служба стандартов требует строгого соблюдения требований SEI-CMM или ISO-9000. Аналогично, департамент персонала может использовать процедуры скрупулезной проверки каждого вновь принимаемого на работу сотрудника или стороннего разработчика, привлекаемого к участию в проекте.

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

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

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

Месть

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

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

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

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

Заключение

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

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

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

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

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

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

· вырастить сына;

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

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

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

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

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

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

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

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

Дата добавления: 2015-08-18