Ремонт принтеров, сканнеров, факсов и остальной офисной техники


назад Оглавление вперед




[8]

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

1.4.8 Месть

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

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

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

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

1.5 Заключение

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

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


ГЛАВА 2. ПОЛИТИКА

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

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

В данной главе будут обсуждаться три аспекта политики:

•идентификация политических «игроков», вовлеченных в проект;

•определение сущности проекта;

•отношение участников к проекту.

2.1 Идентификация «игроков», вовлеченных в проект

Главное, что я хочу здесь отметить, это что ваши шансы на успех в безнадежном проекте

Между прочим, все это не означает, что я против любых безнадежных проектов; я согласен с мнением моего коллеги 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.


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

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

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

Типичными «игроками» в безнадежном проекте являются следующие:

•владелец;

•заказчик;

•акционер;

•заинтересованное лицо;

•защитник.

Каждая из этих ролей будет обсуждаться ниже.

2.1.1 Владелец

Традиционно владелец - это человек, который принимает, санкционирует или финансирует систему и/или результаты проекта. Чрезвычайно важно идентифицировать этого человека и сделать все возможное, чтобы он был удовлетворен ходом проекта.

Удивительно, как много проектов выполняются без малейшего представления их участников о том, кто является владельцем; это особенно типично для организаций, где проекты порождаются честолюбием и сверхэнергией IT-профессионалов, которые стремятся перещеголять друг друга утверждениями вроде «держу пари, что отдел маркетинга придет в экстаз, когда увидит эту новую систему, которую мы разрабатываем для них». Очевидно, в организациях с грамотным руководством такие проекты никогда не смогут начаться - но главное, что я хотел здесь сказать -можно с трудом найти такие безнадежные проекты, которые начались бы без четкого распоряжения со стороны владельца. Причина очевидна: такие проекты чрезвычайно дороги и/или рискованны и/или ограничены по срокам. Невероятно, чтобы IS/IT-подразделение выдумало такой проект по собственной инициативе, и нормальные бюрократы в организации не позволят включить его в план и финансировать до тех пор, пока не получат четкое и недвусмысленное указание от того, кто имеет на это право.

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



[стр.Начало] [стр.1] [стр.2] [стр.3] [стр.4] [стр.5] [стр.6] [стр.7] [стр.8] [стр.9] [стр.10] [стр.11] [стр.12] [стр.13] [стр.14] [стр.15] [стр.16] [стр.17] [стр.18] [стр.19] [стр.20] [стр.21] [стр.22] [стр.23] [стр.24] [стр.25] [стр.26] [стр.27] [стр.28] [стр.29] [стр.30] [стр.31] [стр.32] [стр.33] [стр.34]