Текст книги "Путь камикадзе [Смертельный марш]"

Автор книги: Эдвард Йордон

сообщить о нарушении

Текущая страница: 8 (всего у книги 17 страниц)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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