«сначала сделай, потом извиняйся». Может быть, не стоит терять время на переговорах, чтобы добиться для себя временной передышки от всяких бюрократических ограничений, которые могут погубить проект. Определённо, незачем пытаться это сделать, поскольку само ваше назначение со стороны высшего руководства обычно даёт достаточно прав, чтобы обойти или проигнорировать деятельность различных начальников, комитетов и блюстителей стандартов, которые будут виться вокруг проекта. Однако, если вы получите уклончивый ответ вроде: «Мы вовсе не уверены, что это такая уж хорошая идея — дать вашим программистам два ПК и разрешить им работать вне офиса; нам надо посоветоваться с хозяйственной службой и узнать, что они об этом думают», не теряйте больше времени даром. Просто идите и делайте то, что считаете нужным!
Любой умный человек найдёт способ обойти многие из бюрократических рогаток таким образом, что бюрократам потребуется шесть месяцев, чтобы обнаружить это и предпринять ответное наступление; к тому времени ваш проект может уже закончиться (или успеет провалиться). Если же бюрократия пойдёт в наступление, будьте готовы ответить тем же. В конце концов, работа находится в самом разгаре, и руководство, вероятно, не захочет сталкиваться с риском вашего ухода (и ухода всей команды) и необходимостью начинать все сначала. Если вы выбрали такой вариант действий, нужно помнить о двух вещах:
30) Вы должны быть готовы к тому, что вас будут провоцировать. Если блюстители методологии из службы стандартов посетят ваш проект и придут в негодование от того, что вы не используете официально утверждённую методологию компании, то вас наверняка ждёт гневный звонок от босса босса вашего босса. Вы должны быть готовы ответить: «Мистер Большая Шишка, мы решили не использовать эту методологию, потому что она гарантирует провал. Если вы считаете необходимым настаивать на ней, моя команда и я готовы уйти хоть сегодня — с другой стороны, я был бы чрезвычайно признателен, если бы вы оставили нас в покое и велели блюстителям стандартов сделать то же самое. Мы делаем все, что необходимо». Этот приём не сработает до тех пор, пока большой начальник в самом деле не убедится, что вы и ваша команда уйдёте немедленно, как только вас к этому вынудят.
31) Вы должны быть готовы иметь дело с врагами, которые даже в случае успеха проекта будут иметь на вас зуб. Например, в описанном выше случае вы бросили вызов Большой Шишке и она этого не забудет. Вы спутали карты блюстителям методологии и тем самым облегчили жизнь их жертвам; они никогда не простят вам этого. В самом деле, вы могли сжечь так много мостов и нажить столько врагов, что вам (и, возможно, вашей команде тоже) придётся уйти к концу проекта.
Если отставка или жёсткая линия поведения на переговорах для вас неприемлемы, что же тогда остаётся делать, если переговоры приносят неудовлетворительные результаты? Все очень просто: надо переопределить сущность проекта (рис. 2.1, глава 2). В самом начале переговоров вам может казаться, что начинается проект «невыполнимая миссия». Действительно, имея достаточные ресурсы и талантливых исполнителей, вы готовы творить чудеса. Однако, если ресурсов окажется недостаточно, а программисты будут тупыми, то с чудесами ничего не выйдет.
Таким образом, более вероятно, что вас толкают в проект «камикадзе» или «самоубийство»; в лучшем случае, при достаточно жёсткой позиции на переговорах, может получиться «отвратительный» проект. В любом случае необходимо отметить, что менеджер проекта должен верить в возможность достижения поставленных целей (в частности, планов, требуемой функциональности и т.д.) и должен быть способен убедить участников проектной команды в их достижимости. Как отметил John Boddie в [10]:
Лидер проекта, который заботится о своих сотрудниках, не должен обещать им золотые горы и скрывать истинное положение вещей. Он должен честно говорить о том, какие усилия от них потребуется и каковы шансы на успех. Программисты вовсе не так уж глупы. Самые опытные из них прекрасно чувствуют, когда им «вешают лапшу на уши». Большинство из них не желают участвовать в разных играх вокруг проекта, поскольку они знают, что в случае кризиса вся его тяжесть ляжет именно на них.
Если же менеджер проекта убедился, что цели безнадёжного проекта недостижимы, но проект в любом случае должен продолжаться, то для него очень важно донести до остальных участников команды, что они оказались в проекте «камикадзе» или «самоубийство». Некоторые могут согласиться с любым вариантом, и менеджеру важно понимать причины, толкнувшие их на это; а другие могут отказаться от участия в проекте. Например, вполне возможно, что ущемлённые в чем-либо участники проекта рассматривают его как отличный способ отомстить обидевшей их организации, поэтому они могут присоединиться к проектной команде с единственной целью — обеспечить провал проекта.
В этом есть любопытный этический аспект. Как было отмечено выше, я вовсе не советую поступать неэтично или аморально, однако я также считаю, что те переговоры, которые имеют место в безнадёжном проекте, вынуждают менеджера проекта относиться к владельцу, заказчику и/или высшему руководству как к противникам. С другой стороны, участники проектной команды подобны одной семье. Помимо чисто деловых и профессиональных взаимоотношений с участниками команды, менеджер должен ощущать ответственность за них и заботиться о том, чтобы они не стали жертвами политических баталий. Я признателен John Boddie [10] за цитирование одного высказывания Наполеона, которое выражает эту мысль более убедительно, чем я смог бы это сделать:
Каждый командующий армией, обязанный выполнять план, который он считает порочным, должен отстаивать свои доводы и требовать изменения плана, и, в конце концов, должен скорее подать в отставку, чем послужить причиной поражения своей армии.
Литература к главе:
1) Tarek Abdel-Hamid, Stuart Madnick. Software Project Dynamics. Englewood Cliffs, NJ: Prentice-Hall, 1993.
2) Barry Boehm. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, 1981.
3) Barry Boehm, Bradford Clark, Ellis Horowitz, Chris Westland, Ray Madachy, Richard Selby. The COCOMO 2.0 Software Cost Estimation Model. American Programmer, July 1996.
4) Frederick Brooks. The Mythical Man-Month. 20 th anniversary edition, Reading, MA: Addison-Wesley, 1995.
5) Jim McCarthy. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995.
6) Robert E. Park, Wolfhart B. Goethert, J. Todd Webb. Software Cost and Shedule Estimating: A Process Improvement Initiative. Technical Report CMU/SEI-94-SR-03. Pittsburgh, PA: Software Engineering Institute, May 1994.
7) Robert E. Park. Checklist and Criteria for Evaluating the Cost and Shedule Estimating Capabilities of Software Organizations. Technical Report CMU/SEI-95-SR-005. Pittsburgh, PA: Software Engineering Institute, January 1995.
8) Rob Thomsett. Double Dummy Spit and Other Estimating Games. American Programmer, June 1996.
9) Edward Yourdon. Rise and Resurrection of the American Programmer. Upper Saddle River, NJ: Prentice-Hall, 1996.
10) John Boddie. Crunch Mode. Englewood Cliffs: Prentice-Hall/Yourdon Press, 1987.
ГЛАВА 4.
ЧЕЛОВЕЧЕСКИЙ ФАКТОР В БЕЗНАДЁЖНЫХ ПРОЕКТАХ
Когда солдаты получают боевое крещение на поле битвы, они в моих глазах все становятся равными по званию.
Наполеон Бонапарт
Генерал настолько хорош или настолько плох, каким его делают собственные солдаты.
Дуглас МакАртур
Будьте настойчивы в отстаивании права формировать свою собственную команду. Можно ожидать от команды сверхурочной работы, но при этом помните, что они участвуют в марафоне и могут пробежать в спринтерском темпе только последние 100 ярдов. Добейтесь для них щедрого вознаграждения, если проект закончится успешно, но не дразните их обещаниями будущих экстраординарных наград, потому что это только собьёт их с толку. Приложите максимум усилий для создания спаянной и дружной команды, готовой к сотрудничеству; очень важно обладать необходимой квалификацией, однако ещё более важно, чтобы она была дополнена психологической совместимостью. Все сказанное должно способствовать максимальному единению участников проекта.
К сожалению, этого явно недостаточно для большинства менеджеров безнадёжных проектов, поскольку они работают в организациях, пренебрегающих человеческим фактором даже в «нормальных» проектах. Хотя может показаться, что в таких условиях безнадёжные проекты обречены на провал, иногда получается как раз наоборот. Как отмечалось в главе 3, менеджер может быть вынужден согласиться с нереальными сроками или бюджетом, но в качестве компенсации может настаивать на своих решениях по вопросам персонала (на праве нанимать нужных исполнителей, соответствующим образом вознаграждать их и обеспечивать им нормальные условия работы).
Безнадёжный проект может восприниматься как угроза теми, кто желает сохранить бюрократическое статус-кво. Менеджер проекта имеет возможность обойти бюрократические ограничения, связанные с персоналом, с помощью непосредственных распоряжений высшего руководства, однако он должен быть готов к тому, что, поступая таким образом, приобретёт себе вечных врагов в лице кадровой службы и различных других администраторов. Тем не менее, если безнадёжный проект будет иметь громкий успех, он может послужить катализатором к изменению кадровой политики в последующих «нормальных» проектах.
В любом случае, в этой главе я вовсе не ставлю перед собой задачу менять сложившуюся в организации культуру управления людскими ресурсами. На эту тему уже написано достаточно много, включая отдельные главы в моих книгах Rise and Resurrection of the American Programmer и Decline and Fall of the American Programmer (ряд ссылок содержится также в конце этой главы). Главный вопрос данной главы заключается в следующем: если вы уже знакомы с «основами» управления персоналом, что нового привносят безнадёжные проекты?
4.1 Кадровые вопросы
Первая отличительная особенность безнадёжного проекта — явно выраженный акцент на правильном формировании проектной команды. Сотрудничая с софтверными организациями в разных странах, я сталкивался с четырьмя наиболее общими стратегиями формирования команды безнадёжного проекта:
1) нанять суперпрограммистов и предоставить им свободу действий;
2) настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;
3) набрать команду из простых смертных, но при условии, что они будут знать, на что идут;
4) взять любых сотрудников, которых вам дают, и сделать из них команду «невыполнимой миссии».
Первая стратегия выглядит весьма заманчиво, поскольку существует предположение, что суперпрограммисты будут невероятно продуктивны и достаточно изобретательны, чтобы предложить для безнадёжного проекта новые решения. С другой стороны, эта стратегия рискованна, поскольку суперпрограммисты обычно являются суперэгоистами и могут не ужиться друг с другом. Кроме того, такая стратегия для многих организаций проблематична, поскольку руководство не желает платить суперпрограммистам такую высокую зарплату, какую они требуют. И даже если это вам по карману, мало шансов на то, что они согласятся работать над безнадёжным проектом — ведь они все работают в Netscape или Microsoft или ещё где-нибудь, где, по их мнению, имеют место действительно впечатляющие проекты.
Вторая стратегия почти наверняка будет идеальной для большинства организаций, поскольку она не требует привлечения суперпрограммистов; кроме того, такой тип проектной команды воспет телесериалом «Невыполнимая миссия». Однако, если ваша организация предпринимает свой самый первый безнадёжный проект, такой команды просто не существует. Если же такие проекты ранее имели место, и они носили характер «самоубийственных», «камикадзе» или «отвратительных» проектов, то их команды в дальнейшем, скорее всего, распались и прекратили своё существование. Таким образом, стратегия сохранения в целости проектной команды успешного безнадёжного проекта должна, как правило, планироваться заранее как корпоративная стратегия, исходя из предположения, что безнадёжные проекты могут снова иметь место в будущем (более детально это будет обсуждаться в главе 7).
Третья стратегия по вполне очевидным причинам является наиболее распространённой для тех организаций, в которых мне довелось побывать. В большинстве организаций нет суперпрограммистов и нет тех, кто уцелел в предыдущих безнадёжных проектах. Следовательно, команда каждого нового безнадёжного проекта комплектуется заново. Участники команды вполне компетентны и, возможно, выше среднего уровня разработчиков в данной организации, однако от них нельзя ожидать сотворения чудес. Для данной стратегии жизненно важно, чтобы участники команды понимали, на что они идут; даже хотя они являются простыми смертными, им придётся совершать необычайные подвиги в разработке ПО.
Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет «самоубийственным». Такой тип команды также воспет Голливудом, особенно в таких фильмах, как Чёртова Дюжина ; их смысл заключается в том, что отверженных и неудачников может сплотить сильный, харизматический лидер и заставить их совершать чудеса, которые все считали невозможными. Все это хорошо, однако Голливуд ничего не рассказывает нам обо всех таких проектах с собранными из неудачников командами, которые закончились провалом. Мне думается, что если вы согласитесь руководить таким проектом (или участвовать в нем), то вас ждёт судьба самоубийцы.
Все сказанное приводит нас к центральному вопросу формирования команды безнадёжного проекта: до какой степени менеджеру проекта следует настаивать на своём праве принимать кадровые решения? Как было отмечено выше, большинство менеджеров вынуждены примириться с фактом, что они не получат карт-бланш , чтобы нанимать самых талантливых суперпрограммистов в мире; кроме того, существующая в организации политика может не позволить менеджеру по собственной воле, не спрашивая разрешения, привлечь в проект лучших сотрудников организации, поскольку они либо уже участвуют в других важных проектах, либо их с пеной у рта отстаивают другие менеджеры. Тем не менее, существует один аспект, на котором, по моему убеждению, менеджер должен настаивать как на своём абсолютном праве: это право наложить вето на попытку других руководителей навязать проектной команде неугодного им сотрудника. В противном случае и без того уже высокий уровень риска в проекте может повыситься до недопустимых пределов.
Естественно, такая ситуация порождает разнообразные и весьма неприятные политические баталии. Менеджеру проекта придётся, вероятно, выслушивать всякие успокаивающие заверения вроде: «Не надо беспокоиться. У Чарли были некоторые проблемы в предыдущих проектах, но в твоём с ним будет все в порядке» или чрезвычайно льстивые речи наподобие: «Ты такой грандиозный менеджер, что я уверен в твоей способности развернуть Чарли на 180° и получить от него реальную отдачу» или разные призывы проявить лояльность и мужество. Мой совет — держаться до последнего и быть непреклонным в своём праве отвергнуть любого, кто, по вашему мнению, не подходит для проектной команды.
Один из критериев, которые следует принимать во внимание при таких решениях — это вероятность того, что предполагаемый участник команды покинет проект, не дожидаясь его окончания. Разумеется, большинство разработчиков не расскажут вам ничего о своих планах уйти в середине проекта; однако, некоторые из них все же расскажут вам заранее о своих личных намерениях — женитьбе, разводе, планируемой экспедиции в Гималаи и т.д. — которые могут выключить их из работы над проектом. Крайне нежелательно в самом разгаре проекта лишиться некоторых сотрудников и оказаться вынужденным принять в проект новых людей.
В главе 3 я рассматривал варианты действий, которые имеются у менеджера проекта в случае неудачи переговоров: уйти в отставку, обратиться за помощью к более высокому руководству, игнорировать бюрократические правила и принимать свои собственные решения, или определить для себя проект как самоубийственную миссию. Игнорирование правил обычно является наиболее сложным делом, поскольку включение дополнительных участников в проектную команду может быть связано с ограничениями штатного расписания, которое менеджеру проекта неподконтрольно. С другой стороны, иногда имеется возможность «одолжить» людей из другого проекта или даже нанять по контракту временных исполнителей.
Можно также попытаться изолировать нежелательного участника команды, которого включили в проект против воли менеджера; его можно загрузить какой-нибудь безобидной работой или отправить изучать поведение африканских мух цеце до самого конца проекта. Doug Scott описал ещё более хитрый вариант такой стратегии:
Безнадёжные проекты к концу зачастую оказываются в таком отчаянном положении, что высшее руководство готово выбросить любые средства, например, чтобы нанять ещё 20 человек.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Любой умный человек найдёт способ обойти многие из бюрократических рогаток таким образом, что бюрократам потребуется шесть месяцев, чтобы обнаружить это и предпринять ответное наступление; к тому времени ваш проект может уже закончиться (или успеет провалиться). Если же бюрократия пойдёт в наступление, будьте готовы ответить тем же. В конце концов, работа находится в самом разгаре, и руководство, вероятно, не захочет сталкиваться с риском вашего ухода (и ухода всей команды) и необходимостью начинать все сначала. Если вы выбрали такой вариант действий, нужно помнить о двух вещах:
30) Вы должны быть готовы к тому, что вас будут провоцировать. Если блюстители методологии из службы стандартов посетят ваш проект и придут в негодование от того, что вы не используете официально утверждённую методологию компании, то вас наверняка ждёт гневный звонок от босса босса вашего босса. Вы должны быть готовы ответить: «Мистер Большая Шишка, мы решили не использовать эту методологию, потому что она гарантирует провал. Если вы считаете необходимым настаивать на ней, моя команда и я готовы уйти хоть сегодня — с другой стороны, я был бы чрезвычайно признателен, если бы вы оставили нас в покое и велели блюстителям стандартов сделать то же самое. Мы делаем все, что необходимо». Этот приём не сработает до тех пор, пока большой начальник в самом деле не убедится, что вы и ваша команда уйдёте немедленно, как только вас к этому вынудят.
31) Вы должны быть готовы иметь дело с врагами, которые даже в случае успеха проекта будут иметь на вас зуб. Например, в описанном выше случае вы бросили вызов Большой Шишке и она этого не забудет. Вы спутали карты блюстителям методологии и тем самым облегчили жизнь их жертвам; они никогда не простят вам этого. В самом деле, вы могли сжечь так много мостов и нажить столько врагов, что вам (и, возможно, вашей команде тоже) придётся уйти к концу проекта.
Если отставка или жёсткая линия поведения на переговорах для вас неприемлемы, что же тогда остаётся делать, если переговоры приносят неудовлетворительные результаты? Все очень просто: надо переопределить сущность проекта (рис. 2.1, глава 2). В самом начале переговоров вам может казаться, что начинается проект «невыполнимая миссия». Действительно, имея достаточные ресурсы и талантливых исполнителей, вы готовы творить чудеса. Однако, если ресурсов окажется недостаточно, а программисты будут тупыми, то с чудесами ничего не выйдет.
Таким образом, более вероятно, что вас толкают в проект «камикадзе» или «самоубийство»; в лучшем случае, при достаточно жёсткой позиции на переговорах, может получиться «отвратительный» проект. В любом случае необходимо отметить, что менеджер проекта должен верить в возможность достижения поставленных целей (в частности, планов, требуемой функциональности и т.д.) и должен быть способен убедить участников проектной команды в их достижимости. Как отметил John Boddie в [10]:
Лидер проекта, который заботится о своих сотрудниках, не должен обещать им золотые горы и скрывать истинное положение вещей. Он должен честно говорить о том, какие усилия от них потребуется и каковы шансы на успех. Программисты вовсе не так уж глупы. Самые опытные из них прекрасно чувствуют, когда им «вешают лапшу на уши». Большинство из них не желают участвовать в разных играх вокруг проекта, поскольку они знают, что в случае кризиса вся его тяжесть ляжет именно на них.
Если же менеджер проекта убедился, что цели безнадёжного проекта недостижимы, но проект в любом случае должен продолжаться, то для него очень важно донести до остальных участников команды, что они оказались в проекте «камикадзе» или «самоубийство». Некоторые могут согласиться с любым вариантом, и менеджеру важно понимать причины, толкнувшие их на это; а другие могут отказаться от участия в проекте. Например, вполне возможно, что ущемлённые в чем-либо участники проекта рассматривают его как отличный способ отомстить обидевшей их организации, поэтому они могут присоединиться к проектной команде с единственной целью — обеспечить провал проекта.
В этом есть любопытный этический аспект. Как было отмечено выше, я вовсе не советую поступать неэтично или аморально, однако я также считаю, что те переговоры, которые имеют место в безнадёжном проекте, вынуждают менеджера проекта относиться к владельцу, заказчику и/или высшему руководству как к противникам. С другой стороны, участники проектной команды подобны одной семье. Помимо чисто деловых и профессиональных взаимоотношений с участниками команды, менеджер должен ощущать ответственность за них и заботиться о том, чтобы они не стали жертвами политических баталий. Я признателен John Boddie [10] за цитирование одного высказывания Наполеона, которое выражает эту мысль более убедительно, чем я смог бы это сделать:
Каждый командующий армией, обязанный выполнять план, который он считает порочным, должен отстаивать свои доводы и требовать изменения плана, и, в конце концов, должен скорее подать в отставку, чем послужить причиной поражения своей армии.
Литература к главе:
1) Tarek Abdel-Hamid, Stuart Madnick. Software Project Dynamics. Englewood Cliffs, NJ: Prentice-Hall, 1993.
2) Barry Boehm. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, 1981.
3) Barry Boehm, Bradford Clark, Ellis Horowitz, Chris Westland, Ray Madachy, Richard Selby. The COCOMO 2.0 Software Cost Estimation Model. American Programmer, July 1996.
4) Frederick Brooks. The Mythical Man-Month. 20 th anniversary edition, Reading, MA: Addison-Wesley, 1995.
5) Jim McCarthy. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995.
6) Robert E. Park, Wolfhart B. Goethert, J. Todd Webb. Software Cost and Shedule Estimating: A Process Improvement Initiative. Technical Report CMU/SEI-94-SR-03. Pittsburgh, PA: Software Engineering Institute, May 1994.
7) Robert E. Park. Checklist and Criteria for Evaluating the Cost and Shedule Estimating Capabilities of Software Organizations. Technical Report CMU/SEI-95-SR-005. Pittsburgh, PA: Software Engineering Institute, January 1995.
8) Rob Thomsett. Double Dummy Spit and Other Estimating Games. American Programmer, June 1996.
9) Edward Yourdon. Rise and Resurrection of the American Programmer. Upper Saddle River, NJ: Prentice-Hall, 1996.
10) John Boddie. Crunch Mode. Englewood Cliffs: Prentice-Hall/Yourdon Press, 1987.
ГЛАВА 4.
ЧЕЛОВЕЧЕСКИЙ ФАКТОР В БЕЗНАДЁЖНЫХ ПРОЕКТАХ
Когда солдаты получают боевое крещение на поле битвы, они в моих глазах все становятся равными по званию.
Наполеон Бонапарт
Генерал настолько хорош или настолько плох, каким его делают собственные солдаты.
Дуглас МакАртур
Будьте настойчивы в отстаивании права формировать свою собственную команду. Можно ожидать от команды сверхурочной работы, но при этом помните, что они участвуют в марафоне и могут пробежать в спринтерском темпе только последние 100 ярдов. Добейтесь для них щедрого вознаграждения, если проект закончится успешно, но не дразните их обещаниями будущих экстраординарных наград, потому что это только собьёт их с толку. Приложите максимум усилий для создания спаянной и дружной команды, готовой к сотрудничеству; очень важно обладать необходимой квалификацией, однако ещё более важно, чтобы она была дополнена психологической совместимостью. Все сказанное должно способствовать максимальному единению участников проекта.
К сожалению, этого явно недостаточно для большинства менеджеров безнадёжных проектов, поскольку они работают в организациях, пренебрегающих человеческим фактором даже в «нормальных» проектах. Хотя может показаться, что в таких условиях безнадёжные проекты обречены на провал, иногда получается как раз наоборот. Как отмечалось в главе 3, менеджер может быть вынужден согласиться с нереальными сроками или бюджетом, но в качестве компенсации может настаивать на своих решениях по вопросам персонала (на праве нанимать нужных исполнителей, соответствующим образом вознаграждать их и обеспечивать им нормальные условия работы).
Безнадёжный проект может восприниматься как угроза теми, кто желает сохранить бюрократическое статус-кво. Менеджер проекта имеет возможность обойти бюрократические ограничения, связанные с персоналом, с помощью непосредственных распоряжений высшего руководства, однако он должен быть готов к тому, что, поступая таким образом, приобретёт себе вечных врагов в лице кадровой службы и различных других администраторов. Тем не менее, если безнадёжный проект будет иметь громкий успех, он может послужить катализатором к изменению кадровой политики в последующих «нормальных» проектах.
В любом случае, в этой главе я вовсе не ставлю перед собой задачу менять сложившуюся в организации культуру управления людскими ресурсами. На эту тему уже написано достаточно много, включая отдельные главы в моих книгах Rise and Resurrection of the American Programmer и Decline and Fall of the American Programmer (ряд ссылок содержится также в конце этой главы). Главный вопрос данной главы заключается в следующем: если вы уже знакомы с «основами» управления персоналом, что нового привносят безнадёжные проекты?
4.1 Кадровые вопросы
Первая отличительная особенность безнадёжного проекта — явно выраженный акцент на правильном формировании проектной команды. Сотрудничая с софтверными организациями в разных странах, я сталкивался с четырьмя наиболее общими стратегиями формирования команды безнадёжного проекта:
1) нанять суперпрограммистов и предоставить им свободу действий;
2) настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;
3) набрать команду из простых смертных, но при условии, что они будут знать, на что идут;
4) взять любых сотрудников, которых вам дают, и сделать из них команду «невыполнимой миссии».
Первая стратегия выглядит весьма заманчиво, поскольку существует предположение, что суперпрограммисты будут невероятно продуктивны и достаточно изобретательны, чтобы предложить для безнадёжного проекта новые решения. С другой стороны, эта стратегия рискованна, поскольку суперпрограммисты обычно являются суперэгоистами и могут не ужиться друг с другом. Кроме того, такая стратегия для многих организаций проблематична, поскольку руководство не желает платить суперпрограммистам такую высокую зарплату, какую они требуют. И даже если это вам по карману, мало шансов на то, что они согласятся работать над безнадёжным проектом — ведь они все работают в Netscape или Microsoft или ещё где-нибудь, где, по их мнению, имеют место действительно впечатляющие проекты.
Вторая стратегия почти наверняка будет идеальной для большинства организаций, поскольку она не требует привлечения суперпрограммистов; кроме того, такой тип проектной команды воспет телесериалом «Невыполнимая миссия». Однако, если ваша организация предпринимает свой самый первый безнадёжный проект, такой команды просто не существует. Если же такие проекты ранее имели место, и они носили характер «самоубийственных», «камикадзе» или «отвратительных» проектов, то их команды в дальнейшем, скорее всего, распались и прекратили своё существование. Таким образом, стратегия сохранения в целости проектной команды успешного безнадёжного проекта должна, как правило, планироваться заранее как корпоративная стратегия, исходя из предположения, что безнадёжные проекты могут снова иметь место в будущем (более детально это будет обсуждаться в главе 7).
Третья стратегия по вполне очевидным причинам является наиболее распространённой для тех организаций, в которых мне довелось побывать. В большинстве организаций нет суперпрограммистов и нет тех, кто уцелел в предыдущих безнадёжных проектах. Следовательно, команда каждого нового безнадёжного проекта комплектуется заново. Участники команды вполне компетентны и, возможно, выше среднего уровня разработчиков в данной организации, однако от них нельзя ожидать сотворения чудес. Для данной стратегии жизненно важно, чтобы участники команды понимали, на что они идут; даже хотя они являются простыми смертными, им придётся совершать необычайные подвиги в разработке ПО.
Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет «самоубийственным». Такой тип команды также воспет Голливудом, особенно в таких фильмах, как Чёртова Дюжина ; их смысл заключается в том, что отверженных и неудачников может сплотить сильный, харизматический лидер и заставить их совершать чудеса, которые все считали невозможными. Все это хорошо, однако Голливуд ничего не рассказывает нам обо всех таких проектах с собранными из неудачников командами, которые закончились провалом. Мне думается, что если вы согласитесь руководить таким проектом (или участвовать в нем), то вас ждёт судьба самоубийцы.
Все сказанное приводит нас к центральному вопросу формирования команды безнадёжного проекта: до какой степени менеджеру проекта следует настаивать на своём праве принимать кадровые решения? Как было отмечено выше, большинство менеджеров вынуждены примириться с фактом, что они не получат карт-бланш , чтобы нанимать самых талантливых суперпрограммистов в мире; кроме того, существующая в организации политика может не позволить менеджеру по собственной воле, не спрашивая разрешения, привлечь в проект лучших сотрудников организации, поскольку они либо уже участвуют в других важных проектах, либо их с пеной у рта отстаивают другие менеджеры. Тем не менее, существует один аспект, на котором, по моему убеждению, менеджер должен настаивать как на своём абсолютном праве: это право наложить вето на попытку других руководителей навязать проектной команде неугодного им сотрудника. В противном случае и без того уже высокий уровень риска в проекте может повыситься до недопустимых пределов.
Естественно, такая ситуация порождает разнообразные и весьма неприятные политические баталии. Менеджеру проекта придётся, вероятно, выслушивать всякие успокаивающие заверения вроде: «Не надо беспокоиться. У Чарли были некоторые проблемы в предыдущих проектах, но в твоём с ним будет все в порядке» или чрезвычайно льстивые речи наподобие: «Ты такой грандиозный менеджер, что я уверен в твоей способности развернуть Чарли на 180° и получить от него реальную отдачу» или разные призывы проявить лояльность и мужество. Мой совет — держаться до последнего и быть непреклонным в своём праве отвергнуть любого, кто, по вашему мнению, не подходит для проектной команды.
Один из критериев, которые следует принимать во внимание при таких решениях — это вероятность того, что предполагаемый участник команды покинет проект, не дожидаясь его окончания. Разумеется, большинство разработчиков не расскажут вам ничего о своих планах уйти в середине проекта; однако, некоторые из них все же расскажут вам заранее о своих личных намерениях — женитьбе, разводе, планируемой экспедиции в Гималаи и т.д. — которые могут выключить их из работы над проектом. Крайне нежелательно в самом разгаре проекта лишиться некоторых сотрудников и оказаться вынужденным принять в проект новых людей.
В главе 3 я рассматривал варианты действий, которые имеются у менеджера проекта в случае неудачи переговоров: уйти в отставку, обратиться за помощью к более высокому руководству, игнорировать бюрократические правила и принимать свои собственные решения, или определить для себя проект как самоубийственную миссию. Игнорирование правил обычно является наиболее сложным делом, поскольку включение дополнительных участников в проектную команду может быть связано с ограничениями штатного расписания, которое менеджеру проекта неподконтрольно. С другой стороны, иногда имеется возможность «одолжить» людей из другого проекта или даже нанять по контракту временных исполнителей.
Можно также попытаться изолировать нежелательного участника команды, которого включили в проект против воли менеджера; его можно загрузить какой-нибудь безобидной работой или отправить изучать поведение африканских мух цеце до самого конца проекта. Doug Scott описал ещё более хитрый вариант такой стратегии:
Безнадёжные проекты к концу зачастую оказываются в таком отчаянном положении, что высшее руководство готово выбросить любые средства, например, чтобы нанять ещё 20 человек.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24