Переговоры в «безнадежном» проекте

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

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

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

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

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

Консультант в области менеджмента Роб Томсет определил общие варианты переговорных игр. Наиболее распространенные из них приведены ниже:

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

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

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

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

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

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

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

«Спрятанное качество» — это одна из наиболее хитрых игр. В ней могут участвовать (в конструктивной или деструктивной ма­нере) хорошо информированные менеджеры проектов, менедже­ры высокого уровня по информационным технологиям и/или за­казчики. Менеджер проекта может предоставить пользователю бесконечно большое число программ за нулевое время, пока их не нужно реально эксплуатировать. Разумеется, было бы глупо предлагать такой экстремальный сценарий. Однако суть заклю­чается в том, что качество ПО (выражаемое в количестве ошибок, переносимости, сопровождаемое™ и т.д.) — это одно из «измере­ний» проекта, которое нужно учитывать во время переговоров по срокам, затратам, персоналу и другим ресурсам. Некоторые за­казчики слишком неопытны, чтобы понимать это, а другие не со­бираются принимать в расчет длительную перспективу. В самом лучшем варианте такая «игра» отражает стратегию «достаточно хорошего» (good-enough) ПО, которая описана ниже. В худшем виде она носит такой же жульнический характер, как и некото­рые другие упомянутые выше политические игры.

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

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

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

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

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

7.5.