Жанр: Учеба
Смертельный марш
...езработица
Поскольку мы действительно работаем в индустрии молодых оптимистов, и наша
индустрия непрерывно (и временами довольно быстро) развивается по крайней
мере последние 30-40 лет, я всегда удивлялся, когда участники безнадежных
проектов приводили мне этот довод.
С другой стороны нужно учитывать, что в таких условиях профессиональные
знания довольно быстро обесцениваются. В самом деле, за последнее
десятилетие произошли такие огромные изменения, что наша профессия, как и
многие другие профессии "белых воротничков", накопила значительный опыт
даунсайзинга, реинжиниринга и аутсорсинга. В целом уровень занятости в
индустрии ПО постоянно растет, но при этом не надо забывать, что спрос на
программистов С++ растет быстрее, чем падает спрос на программистов КОБОЛа
(правда, мои коллеги напомнили мне, что такой спрос еще существует в связи
с проблемой 2000 года и необходимостью преобразования множества программ,
написанных на КОБОЛе. Тем не менее, я уверен, что после 1-го января 2000
года перспективы программистов КОБОЛа существенно ухудшатся). Кроме того,
большие IS/IT-организации, которые превратились в огромные бюрократические
монстры с тысячами сотрудников, оказались частично подверженными
реинжинирингу и даунсайзингу; их высшее руководство может быть не готовым
к сокращению технических специалистов, но зачастую сокращает менеджеров
среднего звена, администраторов и обслуживающий персонал.
Все это приобретает особое значение в безнадежных проектах. Вполне
возможно, что нехватка людей в проектной команде является следствием
общего сокращения штатов разработчиков ПО, предпринятого руководством. И,
аналогично, сокращение вдвое срока разработки может быть следствием
реинжиниринга под лозунгом: организация должна работать вдвое
продуктивнее, чем прежде (что в переводе на командный язык означает
"Работать усерднее! Работать быстрее!"). Кстати, эта ситуация гораздо
более характерна для Северной Америки, чем для стран Западной Европы, где
мне удалось побывать. Только в Северной Америке увлекаются таким
"радикальным" реинжинирингом, что масса сотрудников увольняется с работы.
По этим же причинам (с учетом культурных традиций, социальной политики и
законов) количество безнадежных проектов в этих странах существенно
меньше. Служащие, особенно в Западной Европе, гораздо больше защищены от
сверхурочной работы и ревностно отстаивают свои права на отпуск, выходные,
личное время и др. Хорошо это или плохо - это тема для отдельного
разговора.
Поскольку реинжиниринг не является темой данной книги, мне не хотелось бы
давать какие-либо комментарии по поводу стратегий реинжиниринга,
предпочитаемых менеджментом. В данном случае важно то, что многие
технические специалисты и менеджеры ощущают скрытую угрозу, когда проекты
выполняются в такой обстановке. Довольно часто бывает, что несогласие с
какими-либо установками проекта означает для них увольнение с работы. Для
22-летнего неженатого программиста в этом нет ничего страшного, а для
35-летнего менеджера проекта, обремененного семьей и долгами, увольнение
может стать серьезной проблемой. Что же касается 45-летнего программиста,
вся квалификация которого - КОБОЛ и CICS, то проблема еще серьезнее.
Несмотря на молодость нашей индустрии, она существует достаточно долго для
того, чтобы было найти даже 55- и 60-летних программистов, которые
вынуждены изо всех сил держаться за свою работу, пока не получат законное
право на пенсию.
Для людей среднего возраста и более старших характерна привязанность к
своему месту жительства, поскольку их супруги работают в том же городе,
либо дети могут учиться только в местных школах, либо совесть не позволяет
покинуть своих старых родителей и других членов семьи. Это не является
проблемой, если рынок труда достаточно велик, однако каждый, кто сегодня
живет в Пукипси, Нью-Йорк, хорошо знает, о чем я говорю. Люди, живущие в
Редмонде, Вашингтон, вероятно, могли сталкиваться с такими же неприятными
проблемами 5, 10 или 20 лет назад.
Я очень сочувствую профессионалам-разработчикам среднего и более старшего
возраста, которые оказались сегодня в сложном положении, хотя я весьма
удивлен, что технические специалисты усиленно игнорировали тот факт, что
это может случиться именно с ними, несмотря на то, что разнообразные
мероприятия по реинжирингу/даунсайзингу проводятся уже достаточно долго.
Но это также предмет для отдельной книги; я уже обсуждал эти проблемы в
своих книгах "Decline and Fall of the American Programmer" и "Rise and
Resurrection of the American Programmer", и я ограничиваю свои соображения
здесь только тем, что непосредственно касается безнадежных проектов.
Если вам говорят открытым текстом или намекают, что если не согласитесь
участвовать в проекте со смехотворным графиком, бюджетом и ресурсами, то
останетесь без работы, то что вам остается делать? Очевидно, это зависит
от того, как вы оцениваете свое финансовое, физическое, эмоциональное и
психологическое состояние; но, кроме этого, вы должны точно оценить
положение дел в вашей компании. В некоторых случаях реальная опасность
заключается в том, что ваше продвижение по службе, премии или рост
зарплаты будут остановлены, если вы откажетесь участвовать в проекте (ниже
я отдельно остановлюсь на этой проблеме). Однако, даже если вам угрожает
потеря работы, в больших компаниях обычно невозможно претворить эту угрозу
в жизнь немедленно; у вас может быть два или три месяца в запасе до
увольнения, и этого может оказаться достаточно для поиска новой работы.
Но что если угроза гораздо ближе и ощутимее? Например, ваш босс заявляет:
"Немедленно ставь свою подпись под согласием участвовать в проекте, или
собирай свои вещи и выметайся отсюда!" Непостижимо, чтобы разумный человек
мог предпочесть работать в такой обстановке, однако давайте предположим,
что до сих пор обстановка была вполне дружелюбной, пока последняя
реинжиниринговая мания не сделала вашего босса неуправляемым лунатиком.
Итак, вам предстоит выбор: подписаться, уйти или быть уволенным. Что вы
предпочтете?
Если это возможно, я советую уйти сразу, потому что потом будет еще хуже.
Возможно, придется несколько месяцев посидеть на мели, пока не приобретете
опыт в какой-либо новой технологии, однако впоследствии вы, скорее всего,
увидите, что это гораздо лучше, чем, подчинившись обстоятельствам,
продолжать работу без какой-либо надежды на улучшение ситуации. В
принципе, можно согласиться добровольно участвовать в проекте и
одновременно, обновив свое резюме, начать поиск новой работы, хотя при
этом может возникнуть проблема этического характера, если вы понимаете,
что уход в середине проекта может поставить остальных участников команды в
трудное положение.
Если же вам некуда деваться - близится уход на пенсию, ваша квалификация
не пользуется спросом на рынке или во всем городе один-единственный
работодатель, а семейные обстоятельства не позволяют никуда уехать, вам
следует убедить себя выработать более позитивное отношение к безнадежному
проекту. "Черт возьми, я докажу им, что этот старый пес еще способен
лаять", - скажет среднего возраста ветеран. "Я покажу начальству, что мы
ничуть не хуже этих сопливых мальчишек, и мы сделаем проект в срок!"
Конечно, смелость и позитивный взгляд на вещи просто замечательны, но не
забывайте при этом одно обстоятельство: если безнадежный проект закончится
успешно, за ним последует еще один. Не забывайте о том, что было сказано в
начале книги: безнадежные проекты являются нормой, а не исключением.
1.4.5 Возможность будущей карьеры
Как было сказано выше, бывают ситуации, когда "приглашение" участвовать в
безнадежном проекте сопряжено с опасностью поставить будущее продвижение
по службе в зависимость от успеха проекта и того признания, которое он
получит. Зачастую это связано с реинжинирингом - например, "Только те
люди, которые возглавят этот невероятно сложный проект реинжиниринга Total
System 2000, возглавят и сам Мега-Банк в XXI столетии!" Если вы оказались
в подобной ситуации, помните, что ключевым фактором здесь является
политика. Те люди, которые в конечном счете делают ставку на успех
безнадежного проекта, могут сами в нем и не участвовать. Тот менеджер,
который инициирует безнадежный проект реинжиниринга, может рассматривать
его просто как возможность сделать себе карьеру, наплевав на судьбу,
которая ожидает участников проектной команды.
Если вы помните каждое слово из "Принца" Маккиавелли, и если политические
игры доставляют вам удовольствие, то такие безнадежные проекты как раз для
вас. Однако большинство профессиональных разработчиков ПО вряд ли читало
"Принца" после окончания колледжа (или вообще никогда) и, помимо своей
неискушенности в политике, они просто испытывают отвращение к ней самой и
абсолютное неуважение к тем людям, которые увлекается политикой. Если это
так, почему же тогда находятся люди, готовые участвовать в проекте Total
System 2000 Мега-Банка? Единственный правдоподобный ответ: они искренне
верят, что других таких проектов больше не будет и что этот проект надолго
обеспечит им успешную карьеру в Мега-Банке. Если вы на самом деле верите в
это, то вы, должно быть, верите также, что свиньи умеют летать.
В большинстве ситуаций, которые мне приходилось наблюдать, угроза для
карьеры является неотъемлемым свойством обсуждаемой ранее культуры
"Морского Корпуса". Хорошо это или плохо, в данный момент не имеет
значения; важно то, что это непреложный факт. Если такая угроза имеет
место в вашем первом безнадежном проекте, то, вероятно, то же самое будет
во втором, третьем и четвертом. Когда вы только начали работать в
какой-либо компании, вы еще слишком простодушны, чтобы всерьез задуматься
над долгосрочными последствиями такой политики, но рано или поздно вам
придется с ними столкнуться. В этой ситуации у вас только две возможности:
принять все как есть или уйти.
1.4.6 Альтернатива - банкротство или прочие разные бедствия
Как я уже объяснял, причиной некоторых безнадежных проектов являются
решения относительно реинжиниринга, даунсайзинга и аутсорсинга,
принимаемые высшим руководством, которые, в свою очередь, зачастую
продиктованы глобальной конкуренцией, неожиданными решениями правительства
и т.п. Независимо от причины, результат всегда один и тот же: сотрудники
компании соглашаются участвовать в проекте, поскольку верят, что
альтернативой является банкротство или какие-нибудь другие ужасные
бедствия. Нередко ситуация дополнительно усугубляется провокационными
заявлениями руководства, которое предлагает всем, не желающим участвовать
в проекте, немедленно освободить свое место, дабы не мешать тем, кто
остается, сосредоточиться на спасении компании.
Мы не обсуждаем здесь, правильно или неправильно действует руководство в
подобной ситуации, пытаясь заранее упредить надвигающийся кризис. Суть
дела в том, что поскольку кризис наступил и руководство затевает
безнадежный проект, вам предстоит принять взвешенное решение - участвовать
в нем или нет. Когда писалась эта книга, Apple как раз являла собой
хороший пример компании, переполненной безнадежными проектами, поскольку
она вела борьбу за выживание (хотя лично мне ничего не известно о
каких-либо ультиматумах руководства вроде "соглашайся или уходи").
Учитывая ранее сказанное, вы можете предвидеть, каким будет мой совет:
отступите на шаг и спросите себя, является ли этот безнадежный проект
исключением, или все еще только начинается. Даже если вы выиграете свое
сражение, компания может проиграть войну; в самом деле, ваш успех в
проекте может оказать компании медвежью услугу, оттянув ее крах на срок,
достаточный для того, чтобы затеять второй безнадежный проект.
Еще раз повторюсь, что ваше решение является сугубо личным, и к нему могут
примешиваться такие соображения, как преданность компании, сочувствие или
желание показать всему миру, что вы и ваша компания не собираетесь
сдаваться без борьбы. И кто знает, может быть, значительный успех
безнадежного проекта сумеет в корне изменить ситуацию. Именно так
произошло в 1995 году с фирмой Borland, выпустившей на рынок свой продукт
Delphi. Ни у кого из нас нет хрустального шара, чтобы предсказать будущее
безнадежного проекта; мы не можем также точно предсказать, каковы будут
последствия успеха или неудачи проекта. Некоторые компании умирают быстро,
другие терпят долгий затяжной крах, а некоторые успевает кто-нибудь
купить, пока они окончательно не вступили в полосу неудач.
Поскольку вы консультируетесь со своим собственным хрустальным шаром,
поинтересуйтесь мнением как можно большего количества людей - особенно
тех, кто не имеет своей доли в доходах компании. Может быть, вам удастся
побеседовать с честными и беспристрастными руководителями, которые
искренне готовы обсуждать последствия неудачи или успеха безнадежного
проекта; но вам следует также помнить, что те же руководители делают свои
карьеры и заботятся о своей зарплате; эгоизм и политическое чутье могут не
позволить им сообщить вам какую-либо информацию, жизненно важную для
принятия правильного решения.
1.4.7 Возможность победить бюрократию
Технические специалисты и менеджеры проектов часто жалуются, что их
корпоративная бюрократия снижает продуктивность работы и вносит ненужные
задержки в процесс разработки ПО. Чем крупнее организация, тем сильнее
пускает в ней бюрократия свои корни - особенно в тех организациях, где
служба стандартов требует строгого соблюдения требований SEI-CMM или
ISO-9000. Аналогично, департамент персонала может использовать процедуры
скрупулезной проверки каждого вновь принимаемого на работу сотрудника или
стороннего разработчика, привлекаемого к участию в проекте.
Безнадежные проекты нередко предоставляют возможность обойти некоторые,
если не все, бюрократические рогатки - и этого достаточно, чтобы
раздраженные бюрократией разработчики ПО принимали участие в таких
проектах. В крайнем случае проектная команда даже перебирается в отдельное
здание, где они могут выполнять свою работу, не отвлекаясь на обычную
бюрократию. Даже в менее экстремальной ситуации безнадежный проект
зачастую дает возможность свои собственные средства и языки
программирования, осваивать новые технологии наподобие
объектно-ориентированного программирования, а также сокращать большинство
громоздких процедур и объем документации, которые в обычных условиях
требуются в полном объеме. Не менее важно, что менеджер проекта зачастую
получает гораздо большую свободу действий в подборе участников проектной
команды, чем в обычных условиях.
В лучшем случае все эти перемены могут сделать безнадежный проект своего
рода цивилизованным экспериментом, поскольку отвергается или смягчается
целый ряд ограничений на процедуры, технологии или людские ресурсы,
которые обычно угрожают превратить проект в безнадежный. И, если
безнадежный проект будет иметь шумный успех, он может послужить
катализатором процесса внедрения используемых технологических и
управлеченских новшеств во все другие проекты, выполняемые в организации.
И наоборот, если проект проваливается, это может послужить подтверждением
того, что "стандартные" бюрократические процедуры, в конце концов, не так
уж и плохи.
В любом случае, подобная ситуация является вполне благовидным предлогом
для участия в проекте. В некоторых организациях ряд разработчиков считает
своим долгом всегда участвовать в подобных проектах, поскольку это
единственный способ избежать бюрократических ограничений.
1.4.8 Месть
Месть может показаться не слишком разумным объяснением участия в
безнадежном проекте, но, тем не менее, это обстоит именно так. Успех
безнадежного проекта может оказаться достаточным для того, чтобы выбить
власть из рук некомпетентного вице-президента компании, или утереть нос
критиканам, которые все время уверяли вас, что в рамках ограниченных
сроков и бюджета такой проект выполнить немыслимо. Месть - это весьма
сильное чувство, и оно играет особенную роль на уровне высшего руководства
в крупных организациях, где обиды запоминаются на всю жизнь, и хитрые
политики могут месяцами и годами дожидаться возможности отомстить своим
противникам.
Месть может быть очень мощным личным мотиватором, но обычно не так просто
внушить это чувство всей проектной команде. Если это случается, то
возникает ситуация, когда проектная команда перестает видеть "официальную"
цель разработки, которая была запланирована в проекте - их первым и высшим
приоритетом становится месть.
Если вашим личным мотивом является месть, то я могу сказать только одно -
это ваши личные проблемы. Но если вы собираетесь участвовать в проекте, в
котором менеджер или вся команда из чувства мести готовы согласиться с
совершенно неразумными для "нормального" проекта планом и бюджетом, то
следует быть особенно осмотрительным. "Вице-президент - кретин", - может
сказать вам менеджер проекта, - "и если мы завершим этот проект за шесть
месяцев, то он будет выглядеть таким дураком перед Советом Директоров, что
ему придется подать в отставку!" Хорошо, все это замечательно - может
быть, вице-президент и в самом деле кретин. Однако, стоит ли ради его
отставки жертвовать своей личной жизнью в течение двух ближайших лет? В
конце концов, следующий вице-президент может оказаться еще большим
кретином, чем прежний.
С другой стороны, если в глазах всех вице-президент выглядит воплощением
темных сил, а менеджер проекта предстает этаким героем-освободителем, то
это придает безнадежному проекту дополнительные силы. В этом случае весь
проект предстает в виде битвы Господа с Дьяволом, и этого достаточно,
чтобы люди добровольно принесли огромные жертвы на алтарь проекта.
1.5 Заключение
Как бы цинично или пессимистично ни звучало сказанное в этой главе, это не
поможет избавиться от безнадежных проектов. Компании (как крупные, так и
небольшие) переполнены политикой, там работают менеджеры и технические
специалисты, страдающие безудержным оптимизмом и испытывающие полную гамму
эмоций - страха, беззащитности, самонадеянности и жестокости. Сочетание
таких факторов, как реинжиниринг, даунсайзинг, аутсорсинг и глобальная
конкуренция - в совокупности с возможностями, предоставляемыми новыми
технологиями, такими, как объектно-ориентированное программирование,
клиент-сервер и 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.
ГЛАВА 2. ПОЛИТИКА
Политика играет вполне определенную роль в любом софтверном проекте, хотим
мы этого или нет; отличительной чертой безнадежных проектов является
настолько сильное влияние политики, что она может свести на нет все усилия
выполнить хотя бы какую-нибудь работу. Поскольку процессы, связанные с
политикой, в особенности процесс переговоров, будут обсуждаться в
отдельной главе, здесь важно просто обозначить наличие политики и
предложить некоторые общие рекомендации.
Многие разработчики ПО считают, что поскольку политики не избежать, они
предпочли бы держаться подальше от всей этой грязи. Это вполне понятное
желание - многие из нас, кто всерьез поглощен разработкой ПО, социально
инертны и политически наивны: мы не только считаем политические игры
тошнотворными, но и уверены, что попытки играть в политические "игры"
ничем хорошим для нас кончиться не могут. Все это хорошо до тех пор, пока
кто-нибудь (обычно менеджер проекта) в состоянии держать политиков в
руках. Однако, если все участники безнадежного проекта полагают, что
"поскольку данный проект так важен, они оставят нас в покое и избавят от
грязных политических игр", такой проект имеет весьма мало шансов на успех.
В данной главе будут обсуждаться три аспекта политики:
* идентификация политических "игроков", вовлеченных в проект;
* определение сущности проекта;
* отношение участников к проекту.
2.1 Идентификация "игроков", вовлеченных в проект
Главное, что я хочу здесь отметить, это что ваши шансы на успех в
безнадежном проекте будут равны нулю до тех пор, пока участники проектной
команды не узнают ключевых "игроков". Некоторые из них производят больше
шума, чем другие, некоторые будут друзьями и сторонниками; в то же время
некоторые будут крикливыми оппонентами проекта, а другие будут ждать
удобного момента, чтобы нанести менеджеру удар в спину. Обо всем этом
легко забыть среди тысячи других административных и технических проблем,
но это очень важно.
Я убежден, что каждый участник проекта обязан знать ключевых "игроков" -
даже если постоянное взаимодействие с ними входит в обязанность только
менеджера проекта. В редких случаях "особо важных" команде удается
отгородиться от всего остального мира на время выполнения проекта, но это
не типично. На самом деле в современном мире даже такие проекты не могут
быть полностью изолированы, поскольку все взаимодействуют друг с другом
посредством электронной почты и Internet. В нормальной рабочей обстановке
каждый участник проекта взаимодействует со своими коллегами - техническими
специалистами, а также с вышестоящим руководством и различными
представителями сообщества пользователей. Это неизбежно - мы сталкиваемся
с ними в коридоре, кафетерии или в комнате отдыха.
Поэтому, если участник проекта сталкивается с совершенно невинным, на
первый взгляд, телефонным звонком, почтовым сообщением или как бы
случайным вопросом типа "Как движется проект?", который задает дружелюбным
тоном один из менеджеров среднего звена, для участника проекта важно
знать, кто к нему обращается - друг или враг, и не содержит ли в связи с
этим вопрос политический подтекст. Что бы вы не ответили на такой вопрос,
ответ, скорее всего, станет достоянием всей организации, и ничего
удивительного, если содержащаяся в нем информация будет утрирована,
искажена или скрыта.
Типичными "игроками" в безнадежном проекте являются следующие:
* владелец;
* заказчик;
* акционер;
* заинтересованное лицо;
* защитник.
Каждая из этих ролей будет обсуждаться ниже.
2.1.1 Владелец
Традиционно владелец - это человек, который принимает, санкционирует или
финансирует систему и/или результаты проекта. Чрезвычайно важно
идентифицировать этого человека и сделать все возможное, чтобы он был
удовлетворен ходом проекта.
Удивительно, как много проектов выполняются без малейшего представления их
участников о том, кто является владельцем; это особенно типично для
организаций, где проекты порождаются честолюбием и сверхэнергией
IT-профессионалов, которые стремятся перещеголять друг друга утверждениями
вроде "держу пари, что отдел маркетинга придет в экстаз, когда увидит эту
новую систему, которую мы разрабатываем для них". Очевидно, в организациях
с грамотным руководством такие проекты никогда не смогут начаться - но
главное, что я хотел здесь сказать - можно с трудом найти такие
безнадежные проекты, которые начались бы без четкого распоряжения со
стороны владельца. Причина очевидна: такие проекты чрезвычайно дороги
и/или рискованны и/или ограничены по срокам. Невероятно, чтобы
IS/IT-подразделение выдумало такой проект по собственной инициативе, и
нормальные бюрократы в организации не позволят включить его в план и
финансировать до тех пор, пока не получат четкое и недвусмысленное
указание от того, кто имеет на это право.
Отсюда следует одно интересное соображение: владелец безнадежного проекта
зачастую является руководителем гораздо более высокого уровня, чем в
случае "нормального" проекта. В самом деле, владельцем может быть
президент или исполнительный директор, поскольку проект может затрагивать
жизненно важные интересы организации. Даже если это всего лишь
вице-президент, заметим, что владелец безнадежного проекта обычно имеет
гораздо больше полномочий в вопросах дополнительных расходов или
исключения бюрократических ограничений, чем в "нормальном" проекте.
С другой стороны, это не означает, что вся руководящая иерархия куда-то
исчезла; наоборот, одна из проблем во многих б
...Поділитися у соцмережах
