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

• Название: Путь камикадзе [Смертельный марш]
• Автор: Эдвард Йордон
• Издательство: Лори
• Жанр: Деловая литература
• Год: 2003
• ISBN: 0-13-748310-4, 5-85582-085-8

Книга Эдварда Йордона «Путь камикадзе» представляет собой полное руководство по выживанию в безнадёжных проектах, предназначенное для разработчиков программного обеспечения. Практически каждому разработчику ПО и менеджеру приходится сталкиваться с проектами, характеризующимися никуда не годными персоналом, планом и бюджетом, т.е. проектами, обречёнными на неудачу. В условиях реинжиниринга корпораций безнадёжные проекты становятся «стилем жизни» многих организаций. Книга Эдварда Йордона является руководством по решению следующих проблем: выживание в проектах, обречённых на неудачу; достижение оптимальных соглашений во время переговоров; управление персоналом и расстановка приоритетов; выбор средств и технологий; определение момента, когда уже пора выйти изпроекта. Эдвард Йордон применяет свою уникальную технологию и интуицию менеджера к наихудшим вариантам софтверных проектов, показывая, как максимально повысить шансы на успех, или, по крайней мере, вывести вашу карьеру из-под удара. Шаг за шагом Йордон проходит все стадии жизненного цикла проекта, учит менеджеров и разработчиков правильно вести себя с заказчиками и оптимально использовать доступные ресурсы, включая людей, средства, процессы и технологию. Учитесь проявлять необходимую гибкость при проведении переговоров, расставлять осмысленные приоритеты и… вовремя выходить из проекта. Если вам когда-либо требовалось совершить невозможное, «Путь камикадзе» – ваша книга.

---

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

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

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

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

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

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

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

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

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

2.4 Заключение

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

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

ГЛАВА 3. ПЕРЕГОВОРЫ

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

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

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

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

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

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

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

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