1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom
.pdfОсобенности современных проектов |
4 8 1 |
Однако в «безнадежном» проекте небольшого количества сверхурочного времени обычно недостаточно, чтобы достичь тех результатов, которые требует руководство. Кроме того, пользова тели и высшее руководство не столь наивны — они знают, что мо жет потребоваться сверхурочная работа и учитывают ее в своих собственных оценках графика выполнения проекта. Таким обра зом, они лишают менеджера возможности использовать этот сво бодный ресурс. Правда, менеджеры-ветераны подобных перего воров должны иметь запасные доводы, которые могут пригодить ся уже в начале переговоров.
Консультант в области менеджмента Роб Томсет определил общие варианты переговорных игр. Наиболее распространенные из них приведены ниже:
«Удвой и добавь еще» — эта уловка используется в проектах, начиная с египетских пирамид, если не раньше. Используются любые методы оценки, оказавшиеся под рукой, затем полученная «разумная» оценка удваивается и для большей надежности добав ляются еще три месяца (или три недели, или три года, в зависи мости от масштаба проекта). Главная проблема такой стратегии заключается в том, что она ведет к самому жесткому ограниче нию, связанному с «безнадежными» проектами: сжатым срокам.
«Обратное удвоение» — руководство может быть осведомлено о попытках менеджеров проектов «раздуть» свои опенки, исполь зуя предыдущую стратегию. Одна из причин такой проницатель ности заключается в том, что высшее руководство во многих ор ганизациях - это бывшие менеджеры проектов в области инфор мационных технологий, поэтому они хорошо разбираются в та ких играх. В результате они берут те начальные оценки, которые им дают менеджеры проектов, и автоматически урезают их напо ловину В незавидном положении оказывается неопытный ме неджер, который даже не знает, что его подозревают в удвоении своих начальных оценок.
«Угадай число, которое я задумал» - у пользователя или руко водителя высокого уровня есть своя «приемлемая» оценка для сроков, бюджета и/или других аспектов переговоров, но они отка зываются четко ее сформулировать. Когда менеджер проекта предлагает свою оценку сроков и бюджета, пользователь или ру ководитель попросту качает головой и говорит «нет». Такой ответ подразумевает: «Это слишком много — попробуй угадать еще раз». Незадачливый менеджер в конце концов (иногда после полудю-
482 |
Глава 7 |
жины попыток) приходит с нужной оценкой, но поскольку теперь это его оценка, ему впоследствии и придется отвечать за нее.
«Двойной плевок пустышкой» -- «пустышкой» (dummy) назы вается детская соска, а «выплюнуть пустышку» означает, что ре бенок настолько расстроен и рассержен, что выплевывает свою соску Томсет использует это как метафору, чтобы описать такую ситуацию в процессе переговоров: руководитель высокого уров ня впадает в буйное неистовство, когда менеджер проекта в пер вый раз докладывает свои предложения по плану и бюджету. Дис циплинированный менеджер поспешно удаляется, затем снова возвращается с пересмотренной оценкой, а руководитель снова закатывает истерику. Получается «двойной плевок пустышкой». Идея заключается в следующем: запугать и затерроризировать менеджера до такой степени, чтобы он согласился с чем угодно, лишь бы избежать еще одной вспышки гнева.
«Испанская инквизиция» - такое случается, когда менеджер проекта приходит на совещание руководителей высшего уровня, не зная, что от него потребуют дать «немедленную оценку» про екту. Представьте себе комнату, полную ворчливых вице-прези дентов, которые пристально смотрят на вас, в то время как дирек тор грозным тоном спрашивает: «Итак, когда же, по вашему мне нию, мы получим эту систему? Я уже доложил всему руководству, что она будет готова к середине марта, вы же не собираетесь под вести меня, не так ли?» Если у вас хватит смелости возразить, что более реальный срок — середина ноября, тогда инквизиторы об рушатся на вас с вопросами относительно вашего интеллекта, полномочий, лояльности и, возможно, даже религиозных убеж дений.
«Игра на понижение» - часто имеет место в ситуации, когда организация — разработчик ПО проигрывает своим конкурентам борьбу за право разработки системы для организации-клиента. Эта игра очевидна: заказчик (или в некоторых случаях представи тель службы маркетинга организации-разработчика) говорит ме неджеру проекта, что один из претендентов внес свои предложе ния о коротком сроке разработки и/или более скромном бюдже те. Это вынуждает менеджера проекта не только ответить на вы зов конкурента (который может быть вполне реальным, а может, и нет), но и превзойти его, чтобы повысить свои шансы на заклю чение контракта. Один из вариантов такой ифы — клиент дает понять, что он не исключает возможность, что проект вообще не
Особенности современных проектов |
483 |
состоится; при. этом организация-разработчик, которая во что бы то ни стало стремится заполучить этот проект, постарается выд винуть такие заманчивые для клиента предложения, от которых он не сможет отказаться.
«Китайская пытка водой» — данная игра заключается в том, что плохие новости преподносятся заказчику и (или) высшему руководству небольшими порциями. Допустим, разумная оцен ка срока выполнения проекта, сделанная менеджером, составля ет 12 месяцев. По его мнению, при помощи сверхурочной работы и разного рода чудес проект можно выполнить за 6 месяцев, од нако руководство настаивает на 4 месяцах. Менеджер нехотя ус тупает и устанавливает для проекта последовательность «конт рольных точек». Например, новая версия прототипа системы должна предъявляться заказчику каждую неделю. Первое предъ явление окажется опоздавшим на один день, однако менеджер докажет, что для данной работы задержка может составлять от 14 до 20% (в зависимости от того, сколько дней в неделю работает команда — 5 или 7); отсюда, по его мнению, следует, что срок раз работки заключительной версии системы также может быть ото двинут на 14-20%. На такой ранней стадии проекта руководство отказывается пойти на уступки, но когда вторая контрольная точ ка также окажется сдвинутой на день (что означает общую за держку в два дня в течение двух недель), менеджер вновь повто рит свои аргументы. Это похоже на китайскую пытку водой - од ной плохой новости недостаточно, но все вместе могут оказаться роковыми.
«Спрятанное качество» — это одна из наиболее хитрых игр. В ней могут участвовать (в конструктивной или деструктивной ма нере) хорошо информированные менеджеры проектов, менедже ры высокого уровня по информационным технологиям и/или за казчики. Менеджер проекта может предоставить пользователю бесконечно большое число профамм за нулевое время, пока их не нужно реально эксплуатировать. Разумеется, было бы глупо предлагать такой экстремальный сценарий. Однако суть заклю чается в том, что качество ПО (выражаемое в количестве ошибок, переносимости, сопровождаемости и т.д.) — это одно из «измере ний» проекта, которое нужно учитывать во время переговоров по срокам, затратам, персоналу и другим ресурсам. Некоторые за казчики слишком неопытны, чтобы понимать это, а другие не со бираются принимать в расчет длительную перспективу В самом
484 |
Глава 7 |
лучшем варианте такая «игра» отражает стратегию «достаточно хорошего» (good-enough) ПО, которая описана ниже. В худшем виде она носит такой же жульнический характер, как и некото рые другие упомянутые выше политические ифы.
Самый важный совет Томсета — не попасть в ловушку «скоро палительных» оценок проекта. Наихудшую разновидность такой ловушки представляет собой ифа «испанская инквизиция». Одна ко существуют и не такие заметные ловушки. Преднамеренно или нет, но менеджера проекта часто ставят в положение, когда от него требуется быстро дать «фубую оценку» времени и количеству пер сонала, требуемым для реализации каких-либо частей проекта, и эти оценки могут превратиться в жесткие, не подлежащие измене нию требования. В подобной ситуации, когда имеется некоторое время на выполнение формальной оценки, очень важно выразить оценки в терминах «уровней достоверности» или в некотором диа пазоне «плюс-минус». Если абсолютно отсутствуют данные для де тальной оценки и если в «безнадежном» проекте используется со вершенно новая технология и участвует персонал неизвестной квалификации, то будет благоразумным сказать: «Проект, вероят но, потребует от трех до шести месяцев» или «Я думаю, что мы за кончим проект через шесть месяцев плюс-минус 50%».
Если менеджер проекта оказался не в состоянии добиться от заказчика или высшего руководства понимания той неопреде ленности, которая связана с планом или бюджетом «безнадежно го» проекта, он должен всерьез задуматься об отставке; то же са мое касается и технических специалистов проектной команды. Но это только один аспект неудачных переговоров; как следует поступить менеджеру, если он на 100% уверен, что продиктован ный политическими соображениями срок в шесть месяцев явно недостаточен? Как следует ему поступить, если он на 100% уве рен, что проектная команда должна состоять как минимум из трех человек, а руководство дает только двух?
Если высшее руководство уфожает уволить менеджера в слу чае провала «безнадежного проекта» или он (что практически од но и то же) категорически не согласен с нереальными планами, следует в ответ проявить такое же хладнокровие и настойчивость в своих требованиях. Может быть, и не стоит сильно настаивать на изменении плана, однако следует проявить гораздо большую фебовательность, когда речь пойдет о формировании проектной команды. И, определенно, нужно быть настойчивым в том, что
Особенности современных проектов |
485 |
касается игнорирования или отмены административных и бю рократических правил и процедур, которые могут гарантировать провал «безнадежного» проекта.
Лидер проекта, который заботится о своих сотрудниках, не должен обещать им золотые горы и скрывать истинное положе ние вещей. Он честно скажет о том, какие усилия от них потре буются и каковы шансы на успех. Программисты вовсе не так уж глупы. Самые опытные из них прекрасно чувствуют, когда им «вешают лапшу на уши». Большинство из них не желают участво вать в разных играх вокруг проекта, зная, что в случае кризиса вся его тяжесть ляжет именно на них.
Если же менеджер проекта убедился, что цели проекта недос тижимы, но проект в любом случае должен продолжаться, то для него очень важно донести до остальных участников команды, что они оказались в «безнадежном» проекте. Некоторые могут согла ситься с любым вариантом, и менеджеру важно понимать причи ны, толкнувшие их на это; а другие могут отказаться от участия в проекте.
7.5. ЧЕЛОВЕЧЕСКИЙ ФАКТОР В «БЕЗНАДЕЖНЫХ» ПРОЕКТАХ
Джеральд Вейнберг, автор книги по психологии профаммирования, сказал, что у каждого проекта есть три проблемы: люди, люди и люди. Это как нельзя лучше характеризует «безнадежные» проекты: если имеются ограниченные средства, то большинство менеджеров проекта скажет, что для повышения шансов на успех в проекте их надо потратить на «человеческие ресурсы». Это не означает, что сплоченная команда талантливых людей всегда су меет справиться с несовершенными процессами, устаревшими инструментами, нерасположенными к сотрудничеству пользова телями, враждебно настроенными заинтересованными лицами, недостаточным бюджетом и крайне сжатыми сроками. Но скорее следует сделать ставку на такую команду, чем рассчитывать на то, что команда среднего уровня, вооруженная мощными средства ми программирования и передовой технологией, сможет спра виться со всеми этими проблемами.
В рекомендациях менеджеру проекта нет ничего нового. Будьте настойчивы в отстаивании права формировать собствен-
486 |
Глава 7 |
ную команду. Можно ожидать, что команда будет работать свер хурочно. Однако при этом надо помнить, что они участвуют в марафоне и могут пробежать в спринтерском темпе только пос ледние 100 метров. Если работа над проектом закончится успеш но, добейтесь для них щедрого вознаграждения. Но не дразните их обещаниями будущих экстраординарных нафад, потому что это только собьет их с толку. Приложите максимум усилий для создания спаянной и дружной команды, готовой к сотрудниче ству. Важно, чтобы все члены команды имели необходимую ква лификацию, а также умели общаться друг с другом. В основном это все, что касается человеческого фактора в «безнадежном» проекте.
К сожалению, этого явно недостаточно для большинства ме неджеров «безнадежных» проектов, поскольку они работают в организациях, пренебрегающих человеческим фактором даже в нормальных проектах. Может показаться, что в таких условиях «безнадежные» проекты обречены на провал, но иногда получа ется как раз наоборот. Как отмечалось выше, менеджер может быть вынужден согласиться с нереальными сроками или бюдже том, но в качестве компенсации настаивать на принятии предло женных им решений по вопросам персонала (на праве нанимать нужных исполнителей, соответствующим образом вознаграждать их и обеспечивать им нормальные условия работы).
«Безнадежный» проект может восприниматься как угроза те ми, кто желает сохранить бюрократическое статус-кво. Менед жер проекта, обходя бюрократические ограничения с помощью непосредственных распоряжений высшего руководства, должен быть готов к тому, что приобретет себе вечных врагов в лице кад ровых работников и других администраторов. Тем не менее, если «безнадежный» проект будет иметь фомкий успех, он может пос лужить катализатором к изменению кадровой политики в после дующих проектах.
Первая отличительная особенность «безнадежного проекта» - умение правильно сформировать проектную команду. Сущест вуют четыре наиболее распространенных стратегии формирова ния команды «безнадежного проекта»:
•нанять суперпрограммистов и предоставить им свободу действий;
•настаивать на привлечении команды, которая готова к «не выполнимой миссии» и имеет опыт совместной работы;
Особенности современных проектов |
487 |
•набрать команду из «простых смертных», но при условии, что они будут знать, на что идут;
•взять любых сотрудников, которых дают, и сделать из них
команду «невыполнимой миссии».
Первая стратегия выглядит весьма заманчиво. Предполагает ся, что суперпрограммисты будут невероятно изобретательны, чтобы предложить для «безнадежного» проекта новые решения. С другой стороны, это риск, поскольку суперпрограммисты обычно являются эгоистами и могут не ужиться друг с другом. Кроме того, для многих организаций такая стратегия проблема тична, поскольку руководство не желает платить суперпрофаммистам такую высокую зарплату, какую они требуют
Вторая стратегия почти наверняка будет идеальной для боль шинства организаций, поскольку она не требует привлечения су перпрограммистов. Однако, если организация предпринимает свой первый «безнадежный» проект, такой команды просто не су ществует. Если же такие проекты ранее имели место, то их коман ды в дальнейшем, скорее всего, распались и прекратили свое су ществование. Таким образом, стратегия сохранения в целости проектной команды успешного «безнадежного» проекта должна, как правило, планироваться заранее как корпоративная страте гия, исходя из предположения, что такие проекты могут появить ся в будущем.
Третья стратегия по вполне очевидным причинам является наиболее распространенной. В большинстве организаций нет су перпрограммистов и нет тех, кто уцелел в предыдущих «безна дежных» проектах. Следовательно, команда каждого нового про екта комплектуется заново. Участники команды вполне компете нтны и, возможно, выше среднего уровня разработчиков в дан ной организации, однако от них нельзя ожидать сотворения чу дес. Для данной стратегии жизненно важно, чтобы участники ко манды понимали, на что они идут; знали, что им придется совер шать необычайные подвиги в разработке ПО.
Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка бу дет самоубийственным.
Центральный вопрос формирования команды «безнадежно го» проекта: до какой степени менеджеру проекта следует наста ивать на своем праве принимать кадровые решения? Как было
488 |
Глава 7 |
отмечено выше, большинство менеджеров вынуждены прими риться с фактом, что они не получат карт-бланш, чтобы нанимать самых талантливых программистов в мире. Кроме того, сущест вующая в организации политика может не позволить менеджеру по собственной воле, не спрашивая разрешения, привлечь в про ект лучших сотрудников организации, поскольку они либо уже участвуют в других важных проектах, либо их отстаивают другие менеджеры. Но есть один аспект, который менеджер должен от стаивать как свое абсолютное право: это право наложить вето на попытку других руководителей навязать проектной команде неу годного им сотрудника. В противном случае уровень риска в про екте может повыситься до недопустимых пределов.
Одной из ключевых характеристик команды, которой менед жер проекта должен уделять максимальное внимание, является ее отношение к проекту. Существуют уровни или степени мотива ции. Можно рассчитывать на то, что разработчик проявит опре деленную степень мотивации в нормальном проекте, но «безна дежные» проекты требуют более высокой степени, поскольку участникам команды месяцами придется выдерживать изнури тельную работу, политическое давление и технические трудности.
Было бы хорошо решить проблему мотивации, посулив боль шие суммы денег каждому участнику проектной команды. День ги, выгода, комфорт и тому подобное являются факторами «гиги ены» — их отсутствие вызывает неудовлетворенность, однако они не могут заставить людей полюбить свою работу и дать им необ ходимые внутренние стимулы. Что действительно может стать стимулами, так это ощущение значительности достигнутых ре зультатов, гордость за хорошо выполненную работу, более высо кая ответственность, продвижение по службе и профессиональ ный рост, все то, что обогащает труд.
Эта оценка достаточно точно характеризует нормальные про екты. В большинстве «безнадежных» проектов деньги все же иг рают важную роль. Многие начинающие компании предприни мают безумные и бесперспективные проекты в надежде на то, что им удастся разработать какое-нибудь совершенно новое прило жение для нового технического устройства и продать миллион его копий на рынке. Если участники проектной команды явля ются акционерами и собираются участвовать в распределении прибыли, то денежное вознаграждение, очевидно, составляет весьма существенную часть мотивации их участия в проекте.
Особенности современных проектов |
489 |
Действительно, многие компании намеренно придерживают зарплату на 20—30% ниже преобладающего на рынке уровня, за интересовывая своих специалистов возможностью серьезного участия в акционировании и других формах распределения буду щей прибыли. Эта стратегия направлена не только на повышение мотивации, но и на снижение расхода наличности, поскольку зарплаты сотрудников зачастую составляют единственные самые крупные затраты начинающей компании.
Если «безнадежный» проект достаточно важен для предприя тия, оно найдет способы зарезервировать значительный преми альный фонд для поощрения проектной команды при условии удачного завершения проекта в срок. Допуская возможность та кого вознаграждения, не следует забывать, что 20%-ное повыше ние зарплаты имеет гораздо большее значение для молодого программиста, чем для опытного и квалифицированного прог раммиста.
Размер премии напрямую не связан с количеством времени, затрачиваемым проектной командой на выполнение проекта. В некоторых организациях высшее руководство пытается соблаз нить проектную команду двойной премией (при отставании про екта от фафика), поскольку руководство, очевидно, верит, что это заставит людей работать вдвое больше. Однако, если участни ки команды уже работают по 18 часов в день, законы физики не позволят работать вдвое больше даже самым рьяным из них.
Что касается проектов, за выполнение которых невозможно получить большие премии, менеджеру проекта важно не забы вать о том, что существуют разнообразные виды нематериально го вознаграждения (дополнительный отпуск, свобода действий, создание полностью оснащенной домашней компьютерной сис темы и др.), и с их помощью можно стимулировать участников проекта. Это также справедливо и для нормальных проектов, но для «безнадежных» особенно важно.
В то время как премии и дополнительные отпуска являются положительным стимулом, необходимость сверхурочной работы на протяжении проекта считается отрицательным. Тем не менее, в «безнадежных» проектах она почти всегда неизбежна; это един ственный способ, дающий менеджеру проекта хоть какой-то шанс уложиться в жесткий график. Сверхурочным временем не обходимо правильно распоряжаться, чтобы избежать отрицатель ного воздействия на команду и не поставить под угрозу успех
490 |
Глава 7 |
проекта. Один из способов это сделать - убедиться, что высшее руководство знает реальную стоимость сверхурочной работы.
До тех пор, пока участники проектной команды не будут иметь такие же хорошие возможности участия в акционерном ка питале компании, как высшее руководство, любые другие формы компенсации за участие в «безнадежном» проекте нельзя всерьез считать вознаграждением (в положительном смысле). В то время как менеджер проекта редко распоряжается такого рода компен сацией, то, что ре^ьно можно сделать — это немедленно оплачи вать сверхурочную работу. При этом люди, почти полностью отда ющие себя проекту, получат хоть какую-то отдачу, а тех, кому не мешало бы знать точную стоимость проекта (высшее руководство и др.), можно будет заставить ее узнать (посредством бюджета).
Независимо от того, получают участники команды компенса цию за сверхурочную работу или нет, большой ошибкой будет от сутствие учета этого времени. Даже если с точки зрения бухгалте рии именно так оно и есть, менеджер не должен рассматривать сверхурочное время как свободное. Даже если участники коман ды способны всю жизнь без устали работать по 18 часов в день, для менеджера важно фиксировать, сколько таких сверхурочных часов затрачивается в течение работы над проектом. Это един ственный способ точно измерить производительность команды и вероятность своевременного достижения каждой промежуточ ной контрольной точки в графике проекта.
Каждому известно, что люди не в состоянии работать всю жизнь по 18 часов в день; даже если они будут очень стараться, все равно скоро устанут. А когда они устают, то становятся разд ражительными и вспыльчивыми, работают менее продуктивно и делают гораздо больше ошибок. Это может отрицательно повли ять на работу над проектом. Поэтому менеджер должен четко по нимать, когда следует попросить команду поработать сверхуроч но, а когда не следует этого делать.
Одна из опасностей, которые менеджер проекта должен пред видеть — это чрезмерная добровольная сверхурочная работа той части молодых энтузиастов, которые не представляют пределов своих собственных возможностей и не задумываются о побочных эффектах работы до изнеможения. Производительность труда действительно может расти в первые 20 часов сверхурочной рабо ты (благодаря повышенному содержанию адреналина в крови, концентрации внимания и т.д.). Но рано или поздно каждый дос-