2.1.2 Заказчики

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

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

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

2.1.3 Акционеры

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

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

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

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

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

2.1.4 Заинтересованные лица

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

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

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

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

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

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

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

2.1.5 Защитники

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

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

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

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

2.2 Определение сущности проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 Отношение участников к проекту

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

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

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

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

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

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

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

2.4 Заключение

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

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

ГЛАВА 3.

ПЕРЕГОВОРЫ

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

Лорд Байрон, Письмо, 14 июля 1821 года.

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

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

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

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

3.1 Нормальные переговоры

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

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

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

13) Средстваоценки,являющиесякоммерческимипродуктами – такие, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates) и CHECKPOINT (Software Productivity Research (SPR) ). Глава SPR Capers Jones, «гуру» в области метрик ПО, оценивает рынок средств оценки проектов примерно в 50 продуктов. Эти продукты нельзя назвать совершёнными, и все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип «мякину заложишь – мякину получишь»). В лучшем случае с помощью таких продуктов можно получить оценку с точностью с точностью ±10%. Даже если точность будет ±50%, чем иметь дело только с продиктованными политикой требованиями, с которыми приходится справляться менеджеру проекта и которые на 1000% выходят за пределы возможностей проектной команды.

14) Динамические модели систем – разработано множество имитационных моделей, которые позволяют исследовать нелинейные зависимости между различными факторами, влияющими на динамику проектных процессов. Например, если частью стратегии безнадёжного проекта является требование сверхурочной работы участников проекта со стороны менеджера, каков будет эффект через несколько недель или месяцев? Естественно предположить, что по сравнению с нормальным восьмичасовым рабочим днём «отдача» увеличится, однако наиболее опытный менеджер проекта также отметит, что производительность (измеряемая в количестве функциональных точек в день, строках кода в час и т.д.) по мере накопления усталости будет постепенно снижаться. Кроме того, возрастёт количество ошибок, что, очевидно, повлияет на трудоёмкость тестирования и отладки. И, если сверхурочная работа будет продолжаться достаточно долго, то проектная команда просто окажется на грани истощения. Из всех имитационных моделей, которые я видел, наилучшей представляется модель, описанная в [1], которая реализована на языках DYNAMO и iThink.

15) На тему об оценке проектов написано множество книг. Лучше всего начать с книги Барри Боэма [2]; отметим также, что его модель COCOMO, разработанная в начале 80-х годов, была позднее модифицирована в модель COCOMO-2 [3]. Другой классической работой является книга Фреда Брукса [4], также недавно переизданная с учётом современной технологии и практики разработки ПО. Ещё одна новая книга, которую можно рекомендовать – это работа Джима Маккарти [5].

16) Сам процесс оценки достаточно изучен и документирован, и организации, подобные Software Engineering Institute (SEI), уже опубликовали различные руководства и отчёты [6,7], которые могут помочь при выполнении оценки проектов.

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

3.2 Допустимые компромиссы

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

Как отметил автор и консультант John Boddie, очень важно, чтобы все согласились с наличием более чем одного возможного «сценария» для проекта. Для проведения переговоров нелишними будут такие вопросы, как «обанкротится ли организация, если система будет готова не к 1-му сентября, а к 5-му?» или «все хотят, чтобы работа была сделана хорошо, быстро и дёшево. Все знают, что реально можно выполнить только два требования из трех. Какие именно два для вас важнее?».

Если контрпредложение со стороны высшего руководства или заказчика содержит только одну «переменную», менеджер проекта может оценить влияние остальных переменных. Например, если первоначальная оценка менеджера проекта заключается в том, что проект потребует 12 месяцев на реализацию, трех разработчиков и бюджет 200.000$, вполне вероятно, что первой реакцией руководства будет: «Вздор! Нам нужно, чтобы система была готова и работала через шесть месяцев!» На первый взгляд, очевидный способ сделать это заключается в увеличении штата и/или бюджета (например, увеличить зарплату, чтобы привлечь более продуктивных программистов).

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

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

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

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

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

19) Если изменение одной переменной выходит за пределы 10%, следует исходить из предположения, что обратное воздействие на какую-либо одну из оставшихся переменных будет квадратичным. Так, предположим, что руководство хочет наполовину уменьшить срок разработки, с 12 месяцев до 6. Вместо того, чтобы удваивать состав проектной команды, менеджеру следует увеличить егов 4 раза – или увеличить в 4 раза бюджет, чтобы нанять суперпрограммистов, которые умеют кодировать одновременно обеими руками. В отсутствие формальной модели оценки невозможно определить, насколько эта грубая эвристика будет соответствовать конкретной ситуации, но во всяком случае это лучше, чем оказаться в ловушке или придерживаться линейной зависимости между временем и людьми. К сожалению, «квадратичный» вариант достаточно трудно отстоять, и, скорее всего, «наглые» требования менеджера проекта будут отвергнуты, однако в случае хотя бы минимальной удачи менеджер все равно может оказаться в лучшем положении, чем при «линейном» варианте.

3.3 Переговорные игры

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

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

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

Консультант в области менеджмента Rob Thomsett в своей замечательной статье [8] определил наиболее общие варианты переговорных игр; наиболее распространённые из них приведены ниже:

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

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

22) «Угадай число, которое я задумал» – такую игру я освоил в одном из моих первых проектов, когда был ещё молодым программистом. У пользователя или руководителя высокого уровня есть своя «приемлемая» оценка для сроков, бюджета и/или других аспектов переговоров, но они отказываются чётко её сформулировать. Когда менеджер проекта предлагает свою оценку сроков и бюджета, пользователь или руководитель попросту качает головой и говорит: «Нет». Такой ответ подразумевает: «Это слишком много – попробуй угадать ещё раз». Незадачливый менеджер в конце концов (иногда после полудюжины попыток!) приходит с нужной оценкой, но поскольку теперь это его оценка, ему впоследствии и придётся отвечать за неё.

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

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

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

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

27) Китайская пытка водой – в отличие от предыдущей игры ва-банк, связанной с высоким риском, данная игра заключается в том, что плохие новости преподносятся заказчику и/или высшему руководству маленькими порциями. Вообразите, например, такую ситуацию, когда разумная оценка срока выполнения проекта, сделанная менеджером, составляет 12 месяцев; по его мнению, при помощи сверхурочной работы и разного рода чудес проект можно попытаться закончить за 6 месяцев, однако руководство настаивает на 4-х месяцах. Менеджер нехотя уступает и устанавливает для проекта последовательность «контрольных точек» – например, новая версия прототипа системы должна предъявляться заказчику каждую неделю. Первое предъявление окажется опоздавшим на один день, однако менеджер докажет, что для данной работы задержка может составлять от 14 до 20% (в зависимости от того, сколько дней в неделю работает команда – 5 или 7) ; отсюда, по его мнению, следует, что срок разработки заключительной версии системы также может быть отодвинут на 14-20%. На такой ранней стадии проекта руководство отказывается пойти на уступки, но когда вторая контрольная точка также окажется сдвинута на день (что означает общую задержку в два дня в течение двух недель), менеджер вновь повторит свои аргументы. Кап, кап, кап; это похоже на китайскую пытку водой – одной единственной плохой новости недостаточно, чтобы сразить вас, но все вместе могут оказаться роковыми.

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

29) Спрятанное качество – это одна из наиболее хитрых игр, в ней могут участвовать (в конструктивной или деструктивной манере) хорошо информированные менеджеры проектов, менеджеры высокого уровня по информационным технологиям и/или заказчики. На самом деле все очень просто: как менеджер проекта, я могу предоставить пользователю бесконечно большое количество программ за нулевое время, пока их не нужно реально эксплуатировать. Разумеется, было бы глупо предлагать такой экстремальный сценарий, однако, суть заключается в том, что качество ПО (выражаемое в количестве ошибок, переносимости, сопровождаемости и т.д.) – это одно из «измерений» проекта, которое нужно учитывать во время переговоров по срокам, затратам, персоналу и другим ресурсам. Некоторые заказчики слишком неопытны, чтобы понимать это, а другие не собираются принимать в расчёт длительную перспективу: «Мне все равно, будет ли система работоспособна через два года, поскольку за это время возможности для бизнеса могут кардинально измениться, да и я сам, в любом случае, буду другим. Что меня действительно беспокоит – это чтобы система была готова через три месяца и работала после этого 12 месяцев». Если политика оказывает достаточно сильное давление на принимаемые решения, то нетрудно обнаружить IT-менеджеров и менеджера проекта, готовых согласиться с такой позицией; гораздо менее вероятно, чтобы с ней могли соглашаться технические специалисты. В самом лучшем варианте такая «игра» отражает стратегию «достаточно хорошего» (good-enough) ПО, которую я описал в [9]; в худшем виде она носит такой же жульнический характер, как и некоторые другие упомянутые выше политические игры.

3.4 Стратегии переговоров

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