Жанр: Учеба
Смертельный марш
...й команды
испытывают такое истощение и отвращение к своей работе, что по завершении
проекта (если не раньше) дружно уходят всей командой, а менеджер проекта
наживает так много врагов, что у него также не остается другого выбора,
как упаковать свои чемоданы и перебраться в другой безнадежный проект.
Такая роль идеально подходит для Клинта Иствуда, и лучше поостеречься,
если кто-либо похожий на его героев въезжает в ваш городок, чтобы
захватить власть в проекте, в котором вы только что согласились
участвовать.
Один такой менеджер, которого я имел счастье наблюдать, работая в сфере
финансовых услуг на Уолл-Стрит, имел любопытную стратегию для испытания
физической выносливости и силы духа своей команды: в самом начале проекта
он создавал "искусственный" кризис и немедленно бросал всю команду на его
ликвидацию, заставляя при этом работать с удвоенной энергией. При этом он
наблюдал происходящее из-за кулис; один или двое из участников команды
могли уволиться, один или двое могли заработать нервный срыв, и один или
двое "скромных героев" могли проявить себя и ликвидировать кризис за счет
сверхинтенсивной работы или удачного технического решения. Испытав таким
образом свою команду, этот хладнокровный менеджер мог затем ослабить
давление и приступить к реальной работе над проектом, будучи уверен, что в
случае возникновения настоящего кризиса (который рано или поздно наступит
в безнадежном проекте) он будет хорошо знать, на что способна его команда.
О такой перспективе лучше всего иметь представление до начала проекта; в
процессе формирования проектной команды менеджеру следует оценить, с
какого рода проектом он ожидает иметь дело, и затем спросить у
предполагаемых участников команды, (а) как они оценивают проект, и (б) что
они думают относительно принадлежности проекта к одному из четырех
квадрантов на рис. 2.1. Как будет далее сказано в главе 4, я твердо
уверен, что менеджер безнадежного проекта должен иметь свободу выбора
участников своей команды; и помимо учета их профессиональной квалификации,
не менее важно подбирать людей, имеющих сходное представление относительно
"категории" проекта.
Разумеется, совсем другое дело, если вы сами являетесь предполагаемым
участником команды безнадежного проекта, и вас интервьюирует менеджер
проекта. Как уже было сказано ранее в главе 1, у вас может просто не быть
никакого выбора, и, в противоположность тому, что было сказано в
предыдущем абзаце, менеджер может также не иметь выбора решения
относительно вашего участия в проекте; в такой ситуации по крайней мере
полезно выяснить, как оценивает проект ваш менеджер. Но если вы можете
позволить себе отказаться от участия в проекте, тогда гораздо важнее
убедиться, что ваша оценка проекта сходна с оценкой вашего менеджера. Как
было сказано выше, это вдвойне важно, если намечается "отвратительный"
проект; вы должны спросить себя, не может ли так случиться, что вы станете
одной из жертв этого проекта.
Не забывайте также, что ситуация может резко измениться в ходе самого
проекта в зависимости от прогресса (или его отсутствия), достигнутого
командой, в зависимости от политического климата вокруг самой команды, в
зависимости от физического или эмоционального истощения некоторых
участников проекта и т.д.
2.3 Отношение участников к проекту
Последняя тема, которую следует обсудить: то отношение к работе, на
которое готовы и способны различные участники проектной команды.
Характер отношения участников команды сильно зависит от того, к какой
категории из ранее обсуждавшихся принадлежит проект; например, если всем
становится ясно, что они участвуют в "самоубийственном" проекте, вряд ли
они будут физически и эмоционально напрягаться больше, чем это необходимо.
Даже если руководство настаивает на необходимости длительной сверхурочной
работы, можно будет обнаружить, что участники команды проводят вечерние
часы и выходные (то самое время, когда высшее руководство, навязавшее
сверхурочную работу, само отсутствует), звоня приятелям по телефону,
строча письма своим семьям или сидя вокруг кофейного автомата и
обмениваясь последними сплетнями.
Аналогично, в "отвратительном" проекте отношение его участников диктуется
менеджером проекта, или, по крайней мере, сильно зависит от его
требований. Мой опыт говорит, что менеджер такого проекта сам должен
проявлять такое же отношение к работе, какое он требует от остальных; если
проектная команда все субботы и воскресенья проводит в офисе, он должен
быть вместе с ними и пощелкивать кнутом при необходимости.
Что же касается проектов "камикадзе" и "невыполнимая миссия", а также
безнадежных проектов, которые вообще невозможно отнести к какой-либо одной
определенной категории, то для них очень важно, чтобы у менеджера проекта
было реалистичное представление о тех пределах, в которые укладывается
отношение участников команды к проекту; и, кроме того, важно, чтобы любой
участник проекта, которому в перспективе придется пожертвовать своей
личной жизнью на ближайшие несколько месяцев, знал, может ли он
рассчитывать на такое же отношение к работе со стороны своих коллег.
Самое лучшее, если каждый участник проекта честно и объективно оценит свои
возможности. Может случиться так, что кто-то скажет: "Я готов работать на
все 100%, но моя сестра собирается выйти замуж в июне, как раз перед
завершением проекта, и мне придется взять отпуск на три недели. Я очень
сожалею, но ее свадьба - самое важное событие в моей жизни." Поскольку
остальные участники проекта даже не знакомы с его сестрой, они могут
счесть такое исчезновение в критический заключительный период разработки
чересчур легкомысленным, но по крайней мере этот участник команды честно
сказал о своих намерениях. Однако, менеджер "отвратительного" проекта
может крайне негативно отнестись к такому заявлению, и сказать, что такой
вариант неприемлем. Что ж, это тоже в порядке вещей - если происходит в
самом начале проекта. Участнику проектной команды при этом необходимо
выбрать одно из двух: если свадьба сестры для него важнее, то лучше сразу
и без особого ущерба выйти из проекта, чем позже оказаться в критическом
положении.
К сожалению, далеко не каждый способен запланировать все, что может
повлиять на его участие в проекте. Обычный участник команды может
пообещать 100-процентное участие в проекте, однако если его ребенок
заболеет и попадет в больницу, все обещания будут нарушены. Кроме того,
разумеется, у каждого участника есть шанс выиграть главный приз
какой-нибудь лотереи и получить раз в жизни уникальный шанс отправиться
всей семьей на Таити, ... и кто знает, какие еще непредвиденные события
могут заставить нарушить данные обещания? Кстати, это хорошая причина для
формирования небольших проектных команд и краткосрочных планов. Команда из
5 человек, работающая над 6-месячным проектом, гораздо меньше подвержена
воздействию всяких непредвиденных событий, чем команда из 30 человек,
работающая 3 года. Многие люди вступают в брак, у них есть дети и другие
многочисленные заботы; если связанные с этим проблемы и можно иногда
отодвинуть на несколько недель или даже месяцев, то уж никак не на три
года. Бессмысленно требовать от кого-либо предвосхищения всех возможных
ситуаций, но для менеджера проекта вполне по силам составить себе
реалистичное представление относительно ожидаемой степени участия в
проекте для каждого его участника. Если двухнедельное отсутствие на работе
из-за свадьбы вашей сестры будет рассматриваться как государственная
измена, то лучше всего знать об этом заранее.
Для каждого участника проекта также очень важно знать, как относятся к
своей работе все остальные участники. Как сделать информацию об участии и
личном вкладе каждого в проект общедоступной - это забота менеджера
проекта.
2.4 Заключение
Сказанное в данной главе отнюдь не является каким-либо конкретным
руководством по управлению, планированию или выполнению безнадежных
проектов. Затронутые здесь проблемы достаточно сложным образом пронизывают
многие аспекты нашей жизни. Даже если безнадежный проект будет следовать
всем правилам, касающимся проектирования, кодирования и тестирования
систем ПО, эти проблемы вполне могут похоронить его.
Итак, если мы уже идентифицировали ключевых игроков в проекте, определили
категорию проекта и степень возможного участия в проекте каждого члена
команды, то теперь самое время перейти к реальной работе над проектом. Она
начинается с решения такой большой проблемы, как переговоры, которая будет
обсуждаться в следующей главе.
ГЛАВА 3. ПЕРЕГОВОРЫ
"Сделка - это сама сущность соглашения между неприятелями... разве все
люди не стараются снизить цену того, что они приобретают? Я утверждаю, что
даже дружеская сделка - это объявление войны".
Лорд Байрон, Письмо, 14 июля 1821 года.
Если вы являетесь менеджером безнадежного проекта, то очень легко
предсказать результат переговоров относительно бюджета, срока и ресурсов:
вы проиграете. Это практически неизбежно, поскольку такие переговоры имеют
место в самом начале проекта (или даже до его официального начала), когда
владелец проекта/заказчик ни интеллектуально, ни эмоционально, ни
политически не расположен воспринимать те неприятные для него
контрпредложения, с которыми выступает менеджер. Более разумные переговоры
могут иметь место за месяц или два до срока завершения проекта, когда
новый менеджер проекта может в качестве обязательного условия своего
назначения потребовать, чтобы все трезво оценили невозможность выполнения
первоначальных планов и бюджета и реализации требуемой функциональности.
Никто из нас, видимо, не хотел бы оказаться в таком малоприятном
положении. Поэтому, несмотря на сосредоточенность данной главы на разумных
переговорных стратегиях, я, тем не менее, стараюсь не уходить от решения
проблемы, с которой сталкивается большинство из нас: каким образом в самом
начале проекта добиться нормальных условий его выполнения? Увы, но в этой
главе вы не найдете никаких волшебных секретов; мрачная реальность такова,
что в результате переговоров вы, скорее всего, окажетесь в проигрыше.
Однако все же полезно разбираться в некоторых хитростях политических игр и
уметь извлекать из них выгоду, а также в тех возможностях, которые следует
изучить, если вы столкнулись с совершенно нереальными сроками, бюджетом
и/или ограничениями на формирование проектной команды.
В данной главе я исхожу из предположения, что вы так или иначе участвуете
в переговорах по поводу безнадежных проектов, планов и т.д. Если вы
технический специалист, то ваше участие может и не быть непосредственным -
например, вы можете консультировать менеджера проекта и готовить для него
необходимую информацию с тем, чтобы он мог проводить переговорные баталии
на более высоком уровне. Однако, как напомнил мне недавно Doug Scott, даже
менеджер проекта может оказаться на вторых ролях, поскольку все переговоры
проводятся от его имени менеджером более высокого уровня.
Единственной и самой большой помехой для меня в безнадежных проектах было
мое собственное руководство. Необходимо знать, какую позицию оно обычно
занимает в переговорном процессе, и если руководство чересчур увлекается
политическими играми, лучше держать его подальше от проекта.
3.1 Нормальные переговоры
Заявление о том, что мы в самом деле знаем, как точно оценить сроки,
бюджет и ресурсы какого-либо нетривиального проекта, наверняка вызовет
бурные дебаты между различными группами софтверных профессионалов и
менеджеров. Наши результаты, полученные в течение ряда лет, вряд ли будут
слишком убедительными; с другой стороны, многие могут заметить, что
проблемы, возникающие при оценке, являются результатом политических игр,
связанных именно с безнадежными проектами, которые мы обсуждаем в данной
книге. Однако, в большинстве крупных организаций могут припомнить
дюжину-другую проектов, в которых команда разработчиков сама планировала,
составляла бюджет и твердо обещала создать в этих условиях функционально
полную систему; потом все эти обещания лопались как мыльный пузырь, и в
результате не получалось вообще ничего. Поэтому нет ничего удивительного,
что во многих таких организациях пользователи и высшее руководство, не
отвлекаясь на переговорные процессы, просто навязывают жесткие сроки и
бюджеты типа "сделай-или-умри". Таково происхождение многих безнадежных
проектов.
Сказанное вовсе не означает, что мы не должны прилагать никаких усилий к
получению "разумных" оценок, которые можно было бы использовать во время
предварительных переговоров по проекту. Крайне важно, чтобы менеджер
проекта избежал соблазна пойти по пути наименьшего сопротивления и принять
любые начальные условия безнадежного проекта как указ свыше. Одним из
общих признаков того, что проектная команда приняла стиль поведения
"самоубийственного" проекта (который обсуждался в предыдущей главе)
является позиция, выражаемая менеджером проекта (и разделяемая участниками
команды), которая заключается в следующем: "Мы не имеем представления,
сколько времени реально потребует этот проект, да это и не имеет значения,
поскольку нам уже сообщили конечный срок. Таким образом, нам придется
работать семь дней в неделю и 24 часа в день, пока мы не свалимся от
изнеможения. Пускай нас ругают и колотят, но мы не в состоянии прыгнуть
выше головы..."
Я не собираюсь долго обсуждать различные методы оценки; если у менеджера
проекта нет никакой квалификации или опыта в оценке, то безнадежный проект
- совсем неподходящее место, чтобы начинать обучение таким методам.
Позволю себе все же отметить некоторые полезные и доступные ресурсы,
которые имеются в данной области:
* Средства оценки, являющиеся коммерческими продуктами - такие, как SLIM
(Quantitative Systems Management), ESTIMACS (Computer Associates) и
CHECKPOINT (Software Productivity Research (SPR)). Глава SPR Capers Jones,
"гуру" в области метрик ПО, оценивает рынок средств оценки проектов
примерно в 50 продуктов. Эти продукты нельзя назвать совершенными, и все
они требуют от пользователя высокого уровня квалификации (здесь, как и в
других областях деятельности, действует принцип "мякину заложишь - мякину
получишь"). В лучшем случае с помощью таких продуктов можно получить
оценку с точностью с точностью (10%. Даже если точность будет (50%, чем
иметь дело только с продиктованными политикой требованиями, с которыми
приходится справляться менеджеру проекта и которые на 1000% выходят за
пределы возможностей проектной команды.
* Динамические модели систем - разработано множество имитационных моделей,
которые позволяют исследовать нелинейные зависимости между различными
факторами, влияющими на динамику проектных процессов. Например, если
частью стратегии безнадежного проекта является требование сверхурочной
работы участников проекта со стороны менеджера, каков будет эффект через
несколько недель или месяцев? Естественно предположить, что по сравнению с
нормальным восьмичасовым рабочим днем "отдача" увеличится, однако наиболее
опытный менеджер проекта также отметит, что производительность (измеряемая
в количестве функциональных точек в день, строках кода в час и т.д.) по
мере накопления усталости будет постепенно снижаться. Кроме того,
возрастет количество ошибок, что, очевидно, повлияет на трудоемкость
тестирования и отладки. И, если сверхурочная работа будет продолжаться
достаточно долго, то проектная команда просто окажется на грани истощения.
Из всех имитационных моделей, которые я видел, наилучшей представляется
модель, описанная в * На тему об оценке проектов написано множество книг.
Лучше всего начать с книги Барри Боэма * Сам процесс оценки достаточно
изучен и документирован, и организации, подобные Software Engineering
Institute (SEI), уже опубликовали различные руководства и отчеты * Такие
распространенные методы, как прототипирование, также могут использоваться
для оценки критичности тех или иных проектных ограничений для всей
разрабатываемой системы в целом. Этот подход ни в коем случае не может
служить "защитой от дурака", но, тем не менее, он позволяет привнести
немного здравого смысла в проектную команду и окружающих ее менеджеров и
заказчиков. Если руководство хочет, чтобы команда из трех разработчиков
написала миллион строк кода за 12 месяцев, то следовало бы в течение
первого месяца разработать небольшой прототип будущей системы, который, по
крайней мере, позволит грубо оценить производительность проектной команды,
а также реализуемость проекта в целом.
3.2 Допустимые компромиссы
Предположим, что проектная команда подготовила "разумную" оценку плана,
бюджета и персонала, требуемых для безнадежного проекта, и руководство
готово пойти на некоторые переговоры перед тем, как принять окончательное
решение. Наиболее вероятно, что руководство объявит первоначальную оценку
"неприемлемой" и выдвинет свои требования, которые окажутся гораздо более
жесткими. Как в этом случае следует поступить менеджеру проекта?
Как отметил автор и консультант John Boddie, очень важно, чтобы все
согласились с наличием более чем одного возможного "сценария" для проекта.
Для проведения переговоров нелишними будут такие вопросы, как
"обанкротится ли организация, если система будет готова не к 1-му
сентября, а к 5-му?" или "все хотят, чтобы работа была сделана хорошо,
быстро и дешево. Все знают, что реально можно выполнить только два
требования из трех. Какие именно два для вас важнее?".
Если контрпредложение со стороны высшего руководства или заказчика
содержит только одну "переменную", менеджер проекта может оценить влияние
остальных переменных. Например, если первоначальная оценка менеджера
проекта заключается в том, что проект потребует 12 месяцев на реализацию,
трех разработчиков и бюджет 200.000$, вполне вероятно, что первой реакцией
руководства будет: "Вздор! Нам нужно, чтобы система была готова и работала
через шесть месяцев!" На первый взгляд, очевидный способ сделать это
заключается в увеличении штата и/или бюджета (например, увеличить
зарплату, чтобы привлечь более продуктивных программистов).
С другой стороны, Фред Брукс уже более 20 лет назад отмечал, что
зависимость между количеством разработчиков и временем разработки носит
нелинейный характер; поэтому термин "человеко-месяц" был объявлен мифом.
Разумеется, практически все зависимости между ключевыми переменными
проекта являются нелинейными и зависящими от времени. Вследствие эффекта
"обратной связи", возникающего в результате многих решений руководства,
изменение одной переменной (например, увеличение штата) повлияет со
временем не только на другие переменные (такие, как продуктивность), но и
на собственное первоначальное значение - например, увеличение штата может
отрицательно повлиять на моральное состояние команды, что, в свою очередь,
может увеличить текучесть рабочей силы в проекте и в конечном счете
снизить численность персонала.
Упомянутые выше динамические модели систем как раз отражают сущность этих
нелинейных и нестационарных зависимостей; их характер является, к тому же,
причиной использования различных коммерческих средств оценки, описанных
выше. Следует отметить, что математической основой этих динамических
моделей являются, как правило, нелинейные дифференциальные уравнения, в
которых большинство из нас не слишком хорошо разбирается. Аналогично,
коммерческие средства оценки выполняют сложные расчеты с учетом множества
параметров; попытка сделать такую работу на интуитивном уровне,
основываясь только на своем замечательном чутье, приведет, скорее всего, к
грубым ошибкам.
К сожалению, именно в таком положении оказывается большинство менеджеров
безнадежных проектов. Отчасти это объясняется самой природой переговорного
процесса (напоминающего игру под названием "Испанская инквизиция", которая
будет обсуждаться ниже); однако, причиной может быть отсутствие адекватных
средств оценки и соответствующего опыта во многих организациях. Если этой
проблемой ранее не занимались, то тем более бесполезно пытаться решать ее
во время безнадежного проекта. Если в организации привыкли к торопливости
и небрежности в количественной оценке проектов, то менеджеру безнадежного
проекта вряд ли удастся выбить 10.000$ на приобретение достаточно сложного
средства оценки.
Итак, что же делать в такой ситуации менеджеру? В крайнем случае,
менеджеру остается осознать тщетность усилий и отреагировать
соответственно; такая ситуация будет детально обсуждаться ниже в подразд.
3.5. Однако, в менее сложной ситуации существуют два возможных варианта
действий:
* Если требования пользователей или высшего руководства включают изменение
одной из переменных проекта в пределах 10%, его можно компенсировать
пропорциональным изменением одной из остальных переменных. Так, например,
если руководство хочет сократить срок разработки на 10%, следует увеличить
на 10% состав проектной команды. Вряд ли это будет точной компенсацией, но
достаточно хорошо в первом приближении, и, как правило, это все, что вам
удастся сделать в процессе переговоров.
* Если изменение одной переменной выходит за пределы 10%, следует исходить
из предположения, что обратное воздействие на какую-либо одну из
оставшихся переменных будет квадратичным. Так, предположим, что
руководство хочет наполовину уменьшить срок разработки, с 12 месяцев до 6.
Вместо того, чтобы удваивать состав проектной команды, менеджеру следует
увеличить его в 4 раза - или увеличить в 4 раза бюджет, чтобы нанять
суперпрограммистов, которые умеют кодировать одновременно обеими руками. В
отсутствие формальной модели оценки невозможно определить, насколько эта
грубая эвристика будет соответствовать конкретной ситуации, но во всяком
случае это лучше, чем оказаться в ловушке или придерживаться линейной
зависимости между временем и людьми. К сожалению, "квадратичный" вариант
достаточно трудно отстоять, и, скорее всего, "наглые" требования менеджера
проекта будут отвергнуты, однако в случае хотя бы минимальной удачи
менеджер все равно может оказаться в лучшем положении, чем при "линейном"
варианте.
3.3 Переговорные игры
Переговоры - это игра, она имеет место во всех софтверных проектах.
Переговоры в безнадежных проектах характерны тем, что ставки гораздо выше,
эмоции перехлестывают через край, а запросы противоположной стороны (в
терминах плана, бюджета и т.д.) обычно доходят до такой крайности, что
могут превысить любой "запас прочности". В обычном проекте, например,
самый очевидный запас прочности - это сверхурочное время. Даже если
менеджер проекта оказался вынужден принять под давлением жесткий график и
урезанный бюджет, успеха все равно можно будет добиться, уговорив
проектную команду работать сверхурочно от 10 до 20 часов в неделю в
течение нескольких заключительных месяцев проекта. Эти дополнительные
усилия никак не отражаются в официальной статистике, поскольку
программисты ничего не получают за сверхурочную работу, поэтому менеджер в
конце проекта выглядит героем.
Однако, в безнадежном проекте небольшого количества сверхурочного времени
обычно явно недостаточно, чтобы достичь тех впечатляющих результатов,
которые требует руководство. Кроме того, пользователи и высшее руководство
не столь наивны - они знают, что может потребоваться сверхурочная работа,
и учитывают ее в своих собственных оценках графика выполнения проекта -
лишая таким образом менеджера возможности использовать этот свободный
ресурс. Правда, менеджеры-ветераны подобных переговоров должны иметь
запасные карты в рукаве, которые могут пойти в ход в начале переговоров.
В самом плохом положении находится неопытный менеджер; в худшем случае он
даже не представляет, что его последний успех мог быть достигнут только
благодаря тому, что проектная команда добровольно согласилась на большую
сверхурочную работу, чтобы уложиться в сжатые до безобразия сроки. В свою
очередь, такой смехотворный план мог быть навязан проектной команде именно
из-за неопытности менеджера в области проектных оценок и переговоров.
Консультант в области менеджмента Rob Thomsett в своей замечательной
статье * Удвой и добавь еще - эта уловка используется в проектах, начиная
с египетских пирамид, если не раньше. Используйте любые методы оценки,
оказавшиеся под рукой, затем полученную "разумную" оценку удвойте и для
большей надежности добавьте еще три месяца (или три недели, или три года,
в зависимости от масштаба проекта). Главная проблема такой стратегии
заключается в том, что она прямиком ведет к самому жесткому ограничению,
связанному с безнадежными проектами: сжатым срокам.
* Обратное удвоение - как было отмечено ранее, руководство может быть
вполне осведомлено о попытках менеджеров проектов "раздуть" свои оценки,
используя предыдущую стратегию. Одна из причин такой проницательности
заключается в том, что высшее руководство во многих организациях - это
бывшие менеджеры проектов в области информационных технологий, поэтому они
хорошо разбираются в таких играх. В результате они берут те начальные
оценки, которые им дают менеджеры проектов, и автоматически урезают их
наполовину. Беда несчастному неопытному менеджеру, который даже не знает,
что его подозревают в удвоении своих начальных оценок!
* "Угадай число, которое я задумал" - такую игру я освоил в одном из моих
первых проектов, когда был еще молодым программистом. У пользователя или
руководителя высокого уровня есть своя "приемлемая" оценка для сроков,
бюджета и/или других аспектов переговоров, но они отказываются четко ее
сформулировать. Когда менеджер проекта предлагает свою оценку сроков и
бюджета, пользователь или руководитель попросту качает головой и говорит:
"Нет". Такой ответ подразумевает: "Это слишком много - попробуй угадать
еще раз". Незадачливый менеджер в конце концов (иногда после полудюжины
попыток!) приходит с нужной оценкой, но поскольку теперь это его оцен
...Поділитися у соцмережах
