• Главная
• Контакты
• Нашёл ошибку
• Прислать материал
• Добавить в избранное

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

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

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

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

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

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

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

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

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

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

4) владелец;

5) заказчик;

6) акционер;

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

8) защитник.

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

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

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

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

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

Об этом важно помнить, поскольку изначальные требования владельца проекта могут быть легко искажены, пока достигнут менеджера проекта. Наиболее часто тем аспектом безнадёжного проекта, по которому не удаётся достичь соглашения, является конечный срок: новая Супер-Система однозначно и безусловно должна быть закончена к 1 января, иначе наступит конец света! Однако, пока это указание доберётся вниз по иерархической лестнице до менеджера, оно с помощью бюрократии обрастёт целым слоем дополнительных требований, например: в качестве языков программирования использовать только Ada и RPG; в проектную команду нужно обязательно включить Джорджа, Харриет и Мелвина (потому что они настолько некомпетентны, что их не берут ни в один проект; в проекте должна использоваться вновь созданная (но никогда не использовавшаяся ранее) объектно-ориентированная методология; проектная команда должна еженедельно проверяться на предмет того, правильную ли методологию она использует; каждый участник проектной команды должен в конце каждого рабочего дня заполнять 17-страничную форму XJ13 в трех экземплярах; … и так можно продолжать до бесконечности.

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

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

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

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

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

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

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

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

Консультант Dave Kleist в недавнем письме ко мне определил любопытную разновидность акционера:

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

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

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

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

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

Другими словами, если вы хотите иметь дело с г-ном Клинтоном, то вам не стоит ссориться с г-жой Клинтон.

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

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

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

Постольку, поскольку существуют потенциальные противники безнадёжного проекта, существуют и сторонники – включая таких, которые обладают столь большой властью и готовностью оказать помощь, что их называют защитниками. Нет ничего лучшего во всей вселенной, чем защитник, который одновременно является и владельцем проекта; защитниками могут также быть заказчики, акционеры и заинтересованные лица. Тем не менее, защитники обычно оказываются вне традиционного круга политических игроков проекта. Защитник может быть заинтересован в успехе молодого менеджера проекта – своего протеже; его интерес может быть также связан с успехом всего проекта в целом ввиду того влияния, который это оказывает на репутацию и доверие к IS/IT-подразделению или всей организации. Гораздо чаще защитник бывает заинтересован в новой технологии типа «серебряной пули», с помощью который менеджер безнадёжного проекта надеется сотворить чудеса – то ли это Java, объектно-ориентированная технология или новое средство разработки приложений «клиент-сервер», защитник мог ранее посещать презентации этой технологии или даже быть одним из тех, кто предложил использовать её в безнадёжном проекте.

У каждого проекта могут быть один или два защитника, но только безнадёжным проектам они действительно необходимы. Это следует, очевидно, из предыдущего обсуждения: у подобных проектов и без того хватает критиков и противников, не считая тех, кто будет пытаться предвосхитить каждое решение менеджера проекта. Во время работы над проектом не раз будут возникать ситуации, когда кто-нибудь на совещании у руководства вздумает пожаловаться, что «эти чокнутые из Проекта Титаник уже заказали семь копий Visual Basic Enterprise в обход принятого порядка заказов. Но мало этого, так менеджер проекта ещё истратил в последнюю пятницу целых 32,98$ на гамбургеры и жареный картофель для своей команды. С какой стати я в своём офисе должен был нюхать, как пахнет этот картофель?! Мы не можем позволить им с таким вопиющим пренебрежением относиться к принятым в компании правилам!» Защитник в такой ситуации способен прервать эту чепуху и сказать: «Поверьте мне, может быть, эти ребята и чересчур смелые, однако они сделают свою работу. Оставим их в покое.»

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

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

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

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

Рис. 2.1 Квадрант безнадёжных проектов

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

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

9) Проекты «Невыполнимая миссия» – этот вид проектов воспет старыми телесериалами и новым (1996 года) фильмом с участием Тома Круза. Кажется, что все тёмные силы на свете объединились против проекта, все злодеи и изменники жаждут его провала. Но менеджер проекта – великолепный голливудский супермен, его хакеры – интеллектуальные гении, и на стороне команды сам Бог. Участники команды фанатически преданы друг другу (несмотря на все препятствия и капризы судьбы, как в фильме), крепнут с каждым ударом, их возбуждает «ходьба по лезвию ножа». В реальных проектах такого рода их команды обычно мечтают о славе, почестях и богатстве в случае успеха проекта. В конце концов, их миссия должна закончиться успешно; они убеждены, что сочетание интенсивной работы с профессиональной виртуозностью сделает это возможным.

10) «Отвратительные» проекты – это такие проекты, в которых участники команды – это жертвенные агнцы, которые будут зарезаны хладнокровным менеджером ради успеха проекта. Проекты такого рода обычно обладают менталитетом «Морского Корпуса», который обсуждался в главе 1 – то есть менеджер проекта будет постоянно произносить перед своей командой речи на тему «настоящие программисты не нуждаются в сне!». При этом также подразумевается, что «настоящим» программистам нет необходимости бывать дома со своими семьями, навещать своих престарелых родителей в больнице, и вообще заниматься чем-либо, что хотя бы на минуту может отвлечь от проекта. Для таких проектов неудивительны случаи, когда один или двое участников команды падают от изнеможения, страдают от язвы или нервных припадков или разводятся. Когда такое происходит, менеджер проекта только посмеивается и заявляет остальным участникам команды, что такие люди – неудачники и слабаки, которые заслуживают своей судьбы.

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

11) «Самоубийственные» проекты – в таких проектах все выглядят несчастными и обречёнными. Участники команды и менеджер проекта обычно бывают вынуждены согласиться работать над таким проектом только потому, что альтернатива – увольнение; они с самого начала знают, что нет никаких шансов на успех. Они не могут позволить себе выйти из проекта, у проекта нет владельца, все карты складываются против них…

12) Проекты «камикадзе» – такие проекты также обречены на неудачу, но все согласны с тем, что это будет почётный провал, и они впоследствии будут гордиться своей причастностью к проекту. Технические специалисты проектной команды могут быть счастливы от возможности поработать с передовой технологией, которую они никогда ранее не использовали и которую, как они полагают, им больше никогда не придётся увидеть после того, как проект будет свернут. Менеджер проекта надеется, что проект послужит хорошим уроком будущим менеджерам. Иногда такие проекты затеваются обречёнными компаниями, чьё славное прошлое объясняет такую неистовую преданность некоторых участников команды, что они почитают за честь и привилегию право пожертвовать собой в обречённом проекте, провал которого станет последним «ура» компании. Разумеется, существует небольшая вероятность того, что проект закончится успешно, и компания сможет выжить ; даже если при этом участники проектной команды истощат себя до крайности, пытаясь совершить чудо, они все равно будут счастливы.

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

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

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

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

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

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

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

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

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

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

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

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

Самое лучшее, если каждый участник проекта честно и объективно оценит свои возможности. Может случиться так, что кто-то скажет: «Я готов работать на все 100%, но моя сестра собирается выйти замуж в июне, как раз перед завершением проекта, и мне придётся взять отпуск на три недели. Я очень сожалею, но её свадьба – самое важное событие в моей жизни.» Поскольку остальные участники проекта даже не знакомы с его сестрой, они могут счесть такое исчезновение в критический заключительный период разработки чересчур легкомысленным, но по крайней мере этот участник команды честно сказал о своих намерениях. Однако, менеджер «отвратительного» проекта может крайне негативно отнестись к такому заявлению, и сказать, что такой вариант неприемлем. Что ж, это тоже в порядке вещей – если происходит в самом начале проекта. Участнику проектной команды при этом необходимо выбрать одно из двух: если свадьба сестры для него важнее, то лучше сразу и без особого ущерба выйти из проекта, чем позже оказаться в критическом положении.

К сожалению, далеко не каждый способен запланировать все, что может повлиять на его участие в проекте. Обычный участник команды может пообещать 100-процентное участие в проекте, однако если его ребёнок заболеет и попадёт в больницу, все обещания будут нарушены. Кроме того, разумеется, у каждого участника есть шанс выиграть главный приз какой-нибудь лотереи и получить раз в жизни уникальный шанс отправиться всей семьёй на Таити, … и кто знает, какие ещё непредвиденные события могут заставить нарушить данные обещания? Кстати, это хорошая причина для формирования небольших проектных команд и краткосрочных планов. Команда из 5 человек, работающая над 6-месячным проектом, гораздо меньше подвержена воздействию всяких непредвиденных событий, чем команда из 30 человек, работающая 3 года. Многие люди вступают в брак, у них есть дети и другие многочисленные заботы; если связанные с этим проблемы и можно иногда отодвинуть на несколько недель или даже месяцев, то уж никак не на три года. Бессмысленно требовать от кого-либо предвосхищения всех возможных ситуаций, но для менеджера проекта вполне по силам составить себе реалистичное представление относительно ожидаемой степени участия в проекте для каждого его участника. Если двухнедельное отсутствие на работе из-за свадьбы вашей сестры будет рассматриваться как государственная измена, то лучше всего знать об этом заранее.

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

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

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