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

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

К сожалению, далеко не каждый способен запланировать все, что может повлиять на его участие в проекте. Обычный участник команды может пообещать 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 продуктов. Эти продукты нельзя назвать совершёнными, и все они требуют