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

Одна вещь, которую мы действительно можем сделать (как советует Thomsett в своей замечательной статье [8]) – это не попасть в ловушку «скоропалительных» оценок проекта. Наихудшую разновидность такой ловушки представляет собой игра «испанская инквизиция», однако существуют и не такие заметные ловушки, которые поджидают нас в безнадёжном проекте во время планирования и переговоров. Преднамеренно или нет, но менеджера проекта часто ставят в положение, когда от него требуется быстро дать «грубую оценку» времени и количеству персонала, требуемым для реализации каких-либо частей проекта; и достаточно один раз сболтнуть об этом окружающим, как эти оценки могут превратиться в жёсткие, не подлежащие изменению требования. Таким образом, в любой подобной ситуации менеджеру необходимо ответить что-либо наподобие: «Мне нужен один день (или неделя, или месяц – или даже час!), чтобы сделать необходимые расчёты, тогда я смогу дать оценку. Я отправлю её по электронной почте». Разумеется, если все расчёты будут выполнены заранее, и вы уже окажетесь готовы к таким вопросам, то это даст вам очевидное преимущество, но, к сожалению, не всегда возможно это сделать.

В такой же степени не всегда возможно избежать требования дать немедленную оценку. Представьте, что во время презентации ваш клиент поворачивается к вам и спрашивает: «О’кей, Гарри, допустим, мы исключим из системы интерактивный Web-броузер и добавим десять наших людей в твою команду. Сколько времени тебе потребуется на всю работу?» Все поворачиваются и смотрят на вас, и вы видите, что менеджер по маркетингу чувствует себя явно не в своей тарелке; из всех предыдущих дискуссий по этому вопросу вы, вероятно, знаете, что политически приемлемый ответ – «Три месяца – и никаких проблем!» Хватит ли у вас духа ответить: «Джо, я в самом деле не знаю; нам следует вернуться в офис и проиграть то, что ты сказал, на нашей оценочной модели. Кроме того, мне необходимо поговорить с твоими людьми и выяснить их квалификацию…»

В подобной ситуации – и во многих других ситуациях, когда у вас действительно имеется некоторое время на выполнение формальной оценки – очень важно выразить ваши оценки в терминах «уровней достоверности» или в некотором диапазоне «плюс-минус». Если у вас абсолютно отсутствуют данные для детальной оценки, и если в безнадёжном проекте будет использоваться совершенно новая технология и будет участвовать персонал неизвестной квалификации, то будет благоразумным сказать: «Проект, вероятно, потребует от трех до шести месяцев» или «Я думаю, что мы закончим проект через шесть месяцев плюс-минус 50%».

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

К сожалению, есть один довольно неприятный момент, связанный с использованием приближённой оценки: вас могут обвинить в неуверенности, слабости или даже в некомпетентности. Это особенно характерно для безнадёжных проектов с синдромом «Морского Корпуса», который обсуждался ранее. Чего на самом деле хочет от вас высшее руководство – это твёрдого обещания и обязательств, что проект будет закончен к точно определённой дате, его бюджет будет составлять определённое количество долларов, и персонал будет включать определённое количество людей. Им доставляет огромное удовольствие (а) не заботиться больше о проблемах, связанных с продолжительностью проекта, и (б) иметь козла отпущения, на котором можно отыграться, если обещания будут нарушены. Оценки, имеющие вид «Х месяцев ± 50%», «500.000$ ± 100%» и «10 человек ± 25%», никак не могут их удовлетворить.

Jim McCarthy в своей замечательной книге [5] утверждает, что менеджер проекта должен открыто идти навстречу этим проблемам, убеждая заказчиков и руководство, что они должны войти в положение проектной команды и разделить с ней то бремя неопределённости, под тяжестью которого она будет находиться ежедневно. Таким образом, менеджеру следует сказать заказчику или высшему руководству: «Послушайте, я не могу с абсолютной точностью сказать, когда закончится проект – но поскольку именно я являюсь менеджером проекта, я гораздо скорее, чем кто-либо ещё в этой организации, смогу оценить срок настолько точно, насколько это вообще возможно. Обещаю немедленно докладывать вам обо всем, что мне станет известно».

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

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

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

3.5 Что делать в случае провала переговоров

Выше я отметил, что если менеджер проекта оказался не в состоянии добиться от заказчика или высшего руководства понимания той неопределённости, которая связана с планом или бюджетом безнадёжного проекта, он должен всерьёз задуматься об отставке; то же самое касается и технических специалистов проектной команды. Но это только один аспект неудачных переговоров; как следует поступить менеджеру, например, если он на 100% уверен, что продиктованный политическими соображениями срок в шесть месяцев явно недостаточен? Как следует ему поступить, если он на 100% уверен, что проектная команда должна состоять как минимум из трех человек, а руководство даёт только двух?

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

Важно понимать, что я вовсе не рекомендую использовать отставку в качестве наказания или мести. Она является просто разумным действием, которое следует предпринять, столкнувшись с неразрешимой ситуацией и непримиримыми противоречиями на переговорах. Жизнь на этом не кончается, впереди будут ещё другие проекты и другие работы. Как отметила недавно Sue Peterson:

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

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

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

Профессионалы в больших компаниях также начали сталкиваться с этой проблемой, поскольку наступление эры даунсайзинга, аутсорсинга и реижиниринга повлекло за собой распад многих софтверных компаний и безработицу в нашей области. Эти явления особенно обострились благодаря слияниям и приобретениям компьютерных компаний, а также в отраслях экономики с высокой степенью конкуренции, где обработка информации играет ключевую роль. Например, когда пару лет назад объединились Chemical Bank и Chase Manhattan Bank, высшее руководство столкнулось с проблемой объединения двух совершенно различных системно-технических платформ и иерархий IT-менеджмента. Как я отмечал в главе 1, именно такая ситуация порождала многочисленные безнадёжные проекты, которые имели место в 90-х годах.

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

Тем не менее, эти обязательства лишаются всякого смысла, если работодатель аннулирует трудовое соглашение; в этом случае необходимо пересмотреть своё отношение к работе и решить, стоит ли её продолжать. Я вовсе не советую поступать неэтично или аморально, но я не вижу ничего плохого в том, чтобы ограничить свои обязательства по отношению к работодателю одним или двумя годами, или временем одного проекта. Работодатель, который заявляет проектной команде: «Если вы не сдадите систему к 31 декабря, я вас уволю», тем самым высказывает своё отношение к трудовому соглашению.

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

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

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

Любой умный человек найдёт способ обойти многие из бюрократических рогаток таким образом, что бюрократам потребуется шесть месяцев, чтобы обнаружить это и предпринять ответное наступление; к тому времени ваш проект может уже закончиться (или успеет провалиться). Если же бюрократия пойдёт в наступление, будьте готовы ответить тем же. В конце концов, работа находится в самом разгаре, и руководство, вероятно, не захочет сталкиваться с риском вашего ухода (и ухода всей команды) и необходимостью начинать все сначала. Если вы выбрали такой вариант действий, нужно помнить о двух вещах:

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

31) Вы должны быть готовы иметь дело с врагами, которые даже в случае успеха проекта будут иметь на вас зуб. Например, в описанном выше случае вы бросили вызов Большой Шишке и она этого не забудет. Вы спутали карты блюстителям методологии и тем самым облегчили жизнь их жертвам; они никогда не простят вам этого. В самом деле, вы могли сжечь так много мостов и нажить столько врагов, что вам (и, возможно, вашей команде тоже) придётся уйти к концу проекта.

Если отставка или жёсткая линия поведения на переговорах для вас неприемлемы, что же тогда остаётся делать, если переговоры приносят неудовлетворительные результаты? Все очень просто: надо переопределить сущность проекта (рис. 2.1, глава 2). В самом начале переговоров вам может казаться, что начинается проект «невыполнимая миссия». Действительно, имея достаточные ресурсы и талантливых исполнителей, вы готовы творить чудеса. Однако, если ресурсов окажется недостаточно, а программисты будут тупыми, то с чудесами ничего не выйдет.

Таким образом, более вероятно, что вас толкают в проект «камикадзе» или «самоубийство»; в лучшем случае, при достаточно жёсткой позиции на переговорах, может получиться «отвратительный» проект. В любом случае необходимо отметить, что менеджер проекта должен верить в возможность достижения поставленных целей (в частности, планов, требуемой функциональности и т.д.) и должен быть способен убедить участников проектной команды в их достижимости. Как отметил John Boddie в [10]:

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

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

В этом есть любопытный этический аспект. Как было отмечено выше, я вовсе не советую поступать неэтично или аморально, однако я также считаю, что те переговоры, которые имеют место в безнадёжном проекте, вынуждают менеджера проекта относиться к владельцу, заказчику и/или высшему руководству как к противникам. С другой стороны, участники проектной команды подобны одной семье. Помимо чисто деловых и профессиональных взаимоотношений с участниками команды, менеджер должен ощущать ответственность за них и заботиться о том, чтобы они не стали жертвами политических баталий. Я признателен John Boddie [10] за цитирование одного высказывания Наполеона, которое выражает эту мысль более убедительно, чем я смог бы это сделать:

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

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

1) Tarek Abdel-Hamid, Stuart Madnick. Software Project Dynamics. Englewood Cliffs, NJ: Prentice-Hall, 1993.

2) Barry Boehm. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, 1981.

3) Barry Boehm, Bradford Clark, Ellis Horowitz, Chris Westland, Ray Madachy, Richard Selby. The COCOMO 2.0 Software Cost Estimation Model. American Programmer, July 1996.

4) Frederick Brooks. The Mythical Man-Month. 20th anniversary edition, Reading, MA: Addison-Wesley, 1995.

5) Jim McCarthy. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995.

6) Robert E. Park, Wolfhart B. Goethert, J. Todd Webb. Software Cost and Shedule Estimating: A Process Improvement Initiative. Technical Report CMU/SEI-94-SR-03. Pittsburgh, PA: Software Engineering Institute, May 1994.

7) Robert E. Park. Checklist and Criteria for Evaluating the Cost and Shedule Estimating Capabilities of Software Organizations. Technical Report CMU/SEI-95-SR-005. Pittsburgh, PA: Software Engineering Institute, January 1995.

8) Rob Thomsett. Double Dummy Spit and Other Estimating Games. American Programmer, June 1996.

9) Edward Yourdon. Rise and Resurrection of the American Programmer. Upper Saddle River, NJ: Prentice-Hall, 1996.

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

ГЛАВА 4.

ЧЕЛОВЕЧЕСКИЙ ФАКТОР В БЕЗНАДЁЖНЫХ ПРОЕКТАХ

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

Наполеон Бонапарт

Генерал настолько хорош или настолько плох, каким его делают собственные солдаты.

Дуглас МакАртур

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

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

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

В любом случае, в этой главе я вовсе не ставлю перед собой задачу менять сложившуюся в организации культуру управления людскими ресурсами. На эту тему уже написано достаточно много, включая отдельные главы в моих книгах Rise and Resurrection of the American Programmer и Decline and Fall of the American Programmer (ряд ссылок содержится также в конце этой главы). Главный вопрос данной главы заключается в следующем: если вы уже знакомы с «основами» управления персоналом, что нового привносят безнадёжные проекты?

4.1 Кадровые вопросы

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

1) нанять суперпрограммистов и предоставить им свободу действий;

2) настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;

3) набрать команду из простых смертных, но при условии, что они будут знать, на что идут;

4) взять любых сотрудников, которых вам дают, и сделать из них команду «невыполнимой миссии».

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

Вторая стратегия почти наверняка будет идеальной для большинства организаций, поскольку она не требует привлечения суперпрограммистов; кроме того, такой тип проектной команды воспет телесериалом «Невыполнимая миссия». Однако, если ваша организация предпринимает свой самый первый безнадёжный проект, такой команды просто не существует. Если же такие проекты ранее имели место, и они носили характер «самоубийственных», «камикадзе» или «отвратительных» проектов, то их команды в дальнейшем, скорее всего, распались и прекратили своё существование. Таким образом, стратегия сохранения в целости проектной команды успешного безнадёжного проекта должна, как правило, планироваться заранее как корпоративная стратегия, исходя из предположения, что безнадёжные проекты могут снова иметь место в будущем (более детально это будет обсуждаться в главе 7).

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

Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет «самоубийственным». Такой тип команды также воспет Голливудом, особенно в таких фильмах, как Чёртова Дюжина ; их смысл заключается в том, что отверженных и неудачников может сплотить сильный, харизматический лидер и заставить их совершать чудеса, которые все считали невозможными. Все это хорошо, однако Голливуд ничего не рассказывает нам обо всех таких проектах с собранными из неудачников командами, которые закончились провалом. Мне думается, что если вы согласитесь руководить таким проектом (или участвовать в нем), то вас ждёт судьба самоубийцы.

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

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

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

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

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

Безнадёжные проекты к концу зачастую оказываются в таком отчаянном положении, что высшее руководство готово выбросить любые средства, например, чтобы нанять ещё 20 человек. В таких случаях я всегда соглашаюсь. Я поручаю этим субъектам менять перегоревшие предохранители у кофейного автомата и другие важнейшие задания, в то время как я занимаюсь своими лучшими сотрудниками. (Среди этих людей, если вдруг повезёт, тоже могут оказаться хорошие исполнители.) Затем вы можете способствовать уходу из проекта лишних людей и продолжать настаивать на их замене все новыми и новыми людьми. Например, в одном случае я сократил первоначальный персонал на 20% и, несмотря на это, получил нужный результат, причём гораздо более высокого качества. В этом нет ничего удивительного.

4.2 Лояльность, отношение, мотивация и вознаграждения

Вопросы отношения к безнадёжному проекту обсуждались мной в главе 2; оно является важным элементом политики в проектах такого рода, а также одной из ключевых характеристик команды, которой менеджер проекта должен уделять максимальное внимание. В идеальном случае (с точки зрения менеджера проекта) участники команды должны дать клятву верности и преданности безнадёжному проекту; для молодых и неженатых технарей это звучит не так уж дико, как может показаться. С другой стороны, отношение существенно зависит от таких факторов, как длительность проекта. Можно полностью посвятить себя 3-х или 6-ти месячному проекту, но вряд ли это возможно для трехлетнего проекта.

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

Конечно, можно возразить, что менеджер должен брать в свою команду только тех, кто проявляет высокую заинтересованность. Можно также утверждать, что данное обсуждение вообще бессмысленно, поскольку большинство разработчиков ПО и так обладает достаточной мотивацией, как отмечают в [1] Tom DeMarco и Tim Lister:

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

Существуют, однако, уровни или степени мотивации. Мы можем рассчитывать на то, что разработчик ПО проявит определённую степень мотивации в «нормальном» проекте, но безнадёжные проекты требуют более высокой степени, поскольку участникам команды месяцами придётся выдерживать изнурительную работу, политическое давление и технические трудности. Кроме того, в начале проекта менеджер сталкивается с такой проблемой, как отсутствие точного знания мотивации каждого из участников команды. Как отмечает Doug Scott:

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

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

4.2.1 Стимулирование участников проекта

Было бы здорово, если можно было бы решить проблему мотивации, посулив большие суммы денег каждому участнику проектной команды (и менеджеру, конечно!). Frederick Herzberg [2], тем не менее, полагает, что не всегда можно обойтись одними деньгами:

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

Эта оценка, по-видимому, достаточно точно характеризует «нормальные» проекты. Что же касается большинства безнадёжных проектов, то деньги все же играют в них важную роль. На самом деле, они могут являться главной целью всего проекта. Многие начинающие компании Силиконовой Долины предпринимают безумные и безнадёжные проекты в надежде на то, что им удастся разработать какое-нибудь совершенно «убойное» приложение для нового технического устройства и продать миллион его копий на сгорающем от нетерпения рынке. Если участники проектной команды являются акционерами и собираются поучаствовать в распределении прибыли, то денежное вознаграждение, очевидно, составляет весьма существенную часть мотивации их участия в проекте. Действительно, многие компании Силиконовой Долины намеренно придерживают зарплату на 20-30% ниже преобладающего на рынке уровня, заинтересовывая своих специалистов возможностью серьёзного участия в акционировании и других формах распределения будущей прибыли. Эта стратегия направлена не только на повышение мотивации, но также и на снижение расхода наличности, поскольку зарплаты сотрудников зачастую составляют единственные самые крупные затраты начинающей софтверной компании.

Разумеется, существуют такие из ряда вон выходящие безнадёжные проекты, в которых деньги не играют никакой роли. Разработчик ПО, получивший единственный в жизни шанс в проекте, подобном полёту Аполлона 11 на Луну, не нуждается в деньгах; он, безусловно, согласен с комментарием Стива Джобса по поводу проекта Macintosh: «Само путешествие – это награда».

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

Однако, как насчёт организации, располагающей необходимой гибкостью? Если безнадёжный проект достаточно важен для организации, для неё вовсе не является запредельной возможность зарезервировать значительный премиальный фонд для поощрения проектной команды, если ей удастся завершить проект в срок. Возможность премирования существует и для «нормальных» проектов, однако премии там обычно гораздо более умеренные. Приятно получить в конце проекта чек на 1,000$, однако третью часть этой суммы составят налоги, и того, что останется, явно недостаточно, чтобы заметно повлиять на жизненный уровень типичного разработчика ПО со средним уровнем доходов. Однако, в безнадёжных проектах дело обстоит иначе: премиального чека на 10,000$ может оказаться достаточно для покупки новой машины (пускай даже самой скромной по современным меркам!) или отдыха за границей. Чека на 100,000$ достаточно, чтобы заплатить за обучение ребёнка в престижном колледже или купить дом (или, по крайней мере, заплатить за него первый взнос). Наконец, чека на 1,000,000$ достаточно, чтобы обеспечить себе достойную пенсию.

Допуская возможность такого вознаграждения, сделаем некоторые замечания:

5) Не забывайте о том, что 20%-ное повышение зарплаты имеет гораздо большее значение для молодого программиста, зарабатывающего 25,000$ в год, чем для опытного и квалифицированного программиста, зарабатывающего 75,000$ в год. При более высокой зарплате предельная налоговая ставка обычно существенно выше и может достигать 50%, поэтому опытный программист приносит домой не намного больше молодого, и, следовательно, зарплата при этом рассматривается, скорее, как фактор гигиены. Что же касается молодого программиста, налоговая ставка при его зарплате достаточно низка, и этих 20% может вполне хватить для выплаты ежемесячных взносов за его первый автомобиль или переезда от родителей в арендованную квартиру.

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

7) Помните, что размер премии отнюдь не связан прямой, линейной зависимостью с продуктивностью или количеством времени, затрачиваемого проектной командой. Мне приходилось наблюдать, как в некоторых организациях высшее руководство пытается соблазнить проектную команду двойной премией – обычно при отставании проекта от графика – поскольку руководство, очевидно, верит, что двойная премия заставит людей работать вдвое больше. Однако, если участники команды уже работают по 18 часов в день, законы физики не позволят работать вдвое больше даже самым рьяным из них.

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

9) Проектная команда должна также верить, что распределение премии будет справедливым. Это вовсе не означает уравниловки; однако, если команда знает, что львиная доля вознаграждения достанется менеджеру проекта, а другим участникам останутся крошки со стола, то результат предсказуем. Такие вопросы необходимо обсуждать в самом начале проекта; вряд ли участников проекта могут успокоить такие заявления менеджера, как «доверьтесь мне и ни о чем не беспокойтесь – я приложу все усилия, чтобы каждому досталось по справедливости».

Что касается проектов, в которых большие премии невозможны или нежелательны, менеджеру проекта важно не забывать о том, что существуют достаточно разнообразные виды нематериального вознаграждения, с помощью которых можно так же серьёзно стимулировать участников проекта. Это также справедливо и для «нормальных» проектов, но для безнадёжных особенно важно. Важно также помнить, что пресс, под которым находится команда безнадёжного проекта, давит также и на членов их семей. Как отмечает Doug Scott:

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

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

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

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

10) Дополнительный отпуск – если проект закончится успешно, предоставьте его участникам отпуск такой же продолжительности, как и весь проект. Большинство из нас не знает толком, что делать с двухнедельным отпуском – однако, если бы нам предоставили шестимесячный оплачиваемый отпуск, мы могли бы отправиться в кругосветное морское путешествие, о котором всегда мечтали. Любопытный тест: выскажите эту идею своему менеджеру и посмотрите на его реакцию. Если вы услышите что-нибудь наподобие: «Что?!? Ты, наверное, спятил? Шестимесячный отпуск за шестимесячный проект?!? Мы дадим тебе пару дней и не вздумай больше искушать судьбу!», то это означает только одно: менеджер полагает, что разработчики ПО – это не более чем бессловесные рабы. Такая позиция многое говорит о том, какое отношение к трудовым соглашениям принято в данной организации.

11) Оплаченная свобода действий – когда безнадёжный проект завершится, привлеките участников команды к шестимесячной работе над «Проектом Х» (эту замечательную идею предложил Larry Constantine на конференции по программному обеспечению в Мельбурне в 1995 году). Вопрос: что такое «Х»? Ответ: все, что они пожелают. Вместо того, чтобы сразу же оказаться втянутыми ещё в один безнадёжный проект (или в скучный до безобразия «нормальный» проект, что на самом деле ничуть не лучше), участники команды получат хорошую возможность в течение шести месяцев осваивать Java, изучать новейшие объектно-ориентированные методологии или даже вернуться в колледж, чтобы получить свою степень магистра. Надо проявить некоторую изобретательность, придумывая «официальное» название для Проекта Х, чтобы поставить в тупик бюрократов; что-нибудь вроде «эвристической объектно-ориентированной клиент-серверной системы стратегического прогнозирования с возможностями Internet» может произвести необходимый эффект.

12) Создание полностью оснащённой домашней компьютерной системы – хотя ПК сегодня стали намного дешевле, и у каждого из нас есть дома какой-нибудь компьютер, он может быть необязательно самым суперсовременным. У многих из нас стоят медленные 486-е или даже древние 386-е ПК, в то время как остальной мир мчится вперёд на ПК Pentium с 200 Мгц. Один из интересных моментов, связанных с безнадёжными проектами, заключается в том, что они зачастую оснащаются самым совершённым компьютерным оборудованием, поскольку руководство готово раздуть бюджет до невообразимых размеров, свято веря, что передовая технология может спасти проект. Если к концу проекта какое-либо оборудование становится ненужным, отдайте его участникам команды в качестве премии; если же такой открытый подарок нарушает слишком много бюрократических правил, передайте его хотя бы во временное пользование.

4.2.2 Сверхурочная работа

В то время как премии и дополнительные отпуска являются положительным стимулом, необходимость сверхурочной работы во время проекта обычно считается отрицательным стимулом. Тем не менее, в безнадёжных проектах она почти всегда неизбежна; это единственный способ, дающий менеджеру проекта хоть какой-то шанс уложиться в жёсткий график. И, как отмечалось ранее, для неё зачастую не требуется никаких специальных просьб менеджера: молодые, холостые и фанатичные участники команды, которых возбуждает брошенный вызов и возможность использования в проекте самой передовой технологии, рады работать по 60, 80 или 100 часов в неделю.

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