Небольшие компании никогда не обладали такого рода культурой, и многие профессионалы-разработчики работали именно в таких компаниях, особенно когда компьютерные технологии стали настолько дешёвыми, что даже небольшая семейная лавочка могла приобрести ПК и Web-сервер. Те из нас, кто работали в консалтинговых фирмах, бюро обслуживания и различных начинающих компаниях, всегда знали, что там не было и речи о пожизненной занятости.
Профессионалы в больших компаниях также начали сталкиваться с этой проблемой, поскольку наступление эры даунсайзинга, аутсорсинга и реижиниринга повлекло за собой распад многих софтверных компаний и безработицу в нашей области. Эти явления особенно обострились благодаря слияниям и приобретениям компьютерных компаний, а также в отраслях экономики с высокой степенью конкуренции, где обработка информации играет ключевую роль. Например, когда пару лет назад объединились Chemical Bank и Chase Manhattan Bank, высшее руководство столкнулось с проблемой объединения двух совершенно различных системно-технических платформ и иерархий IT-менеджмента. Как я отмечал в главе 1, именно такая ситуация порождала многочисленные безнадёжные проекты, которые имели место в 90-х годах.
Проблема многих из таких крупных организаций заключается в следующем: в то время как работодатель определённо менял свой подход к трудовому соглашению, работник оказывался не готов соответствующим образом на это отреагировать. Многие программисты и проектировщики, честно трудившиеся на благо компании от 10 до 20 лет, искренне полагают, что (а) компания будет и дальше заботиться о них и (б) они должны оставаться с компанией при любых неприятностях. «Неприятность» – это подходящее понятие для большинства безнадёжных проектов. Вряд ли можно получать какое-то удовольствие, жертвуя своим свободным временем, работая до изнеможения и сталкиваясь со стрессами и политическим давлением. Так почему же мы делаем это? Потому что мы дали определённые обязательства и считаем делом чести их выполнять.
Тем не менее, эти обязательства лишаются всякого смысла, если работодатель аннулирует трудовое соглашение; в этом случае необходимо пересмотреть своё отношение к работе и решить, стоит ли её продолжать. Я вовсе не советую поступать неэтично или аморально, но я не вижу ничего плохого в том, чтобы ограничить свои обязательства по отношению к работодателю одним или двумя годами, или временем одного проекта. Работодатель, который заявляет проектной команде: «Если вы не сдадите систему к 31 декабря, я вас уволю», тем самым высказывает своё отношение к трудовому соглашению.
Помимо угрозы быть уволенным, которая определённо присутствует на переговорах безнадёжного проекта, существует также опасность, что вас обойдут с повышением должности или продвижением по службе. Однако, если трудовое соглашение нарушается и с вами поступают достаточно жёстко, вы имеете полное право ответить тем же. Один из самых сильных козырей в переговорной игре – это имеющееся у вашего противника понимание того, что вы готовы все бросить и уйти, если результаты переговоров не будут взаимно приемлемыми. (Некоторые читатели, вероятно, будут возражать против использования понятия «противник» по отношению к заказчику или одному из руководителей. Однако, сама сущность безнадёжного проекта такова, что владелец проекта, заказчик, различные акционеры и заинтересованные лица вполне сознательно и умышленно подталкивают менеджера к принятию решений, которые по своей воле он никогда бы не сделал. Если вы не считаете, что «противник» – это подходящая характеристика для того, с кем вас в течение ряда лет связывали тёплые, дружеские, профессиональные отношения, тогда вернитесь к началу главы и снова прочтите слова лорда Байрона.)
Если высшее руководство угрожает уволить вас в случае провала безнадёжного проекта, или вы (что практически одно и то же) категорически не согласны с нереальными планами, которые вас заставляют принять, вам следует в ответ проявить такое же хладнокровие и настойчивость в своих требованиях. Может быть, и не стоит сильно настаивать на изменении плана, однако следует проявить гораздо большую требовательность, когда речь пойдёт о формировании проектной команды (этот вопрос будет более детально обсуждаться в следующей главе). И, определённо, нужно быть настойчивым в том, что касается игнорирования или отмены административных и бюрократических правил и процедур, которые могут гарантировать провал безнадёжного проекта.
По этому поводу есть старая поговорка: «сначала сделай, потом извиняйся». Может быть, не стоит терять время на переговорах, чтобы добиться для себя временной передышки от всяких бюрократических ограничений, которые могут погубить проект. Определённо, незачем пытаться это сделать, поскольку само ваше назначение со стороны высшего руководства обычно даёт достаточно прав, чтобы обойти или проигнорировать деятельность различных начальников, комитетов и блюстителей стандартов, которые будут виться вокруг проекта. Однако, если вы получите уклончивый ответ вроде: «Мы вовсе не уверены, что это такая уж хорошая идея – дать вашим программистам два ПК и разрешить им работать вне офиса; нам надо посоветоваться с хозяйственной службой и узнать, что они об этом думают», не теряйте больше времени даром. Просто идите и делайте то, что считаете нужным!
Любой умный человек найдёт способ обойти многие из бюрократических рогаток таким образом, что бюрократам потребуется шесть месяцев, чтобы обнаружить это и предпринять ответное наступление; к тому времени ваш проект может уже закончиться (или успеет провалиться). Если же бюрократия пойдёт в наступление, будьте готовы ответить тем же. В конце концов, работа находится в самом разгаре, и руководство, вероятно, не захочет сталкиваться с риском вашего ухода (и ухода всей команды) и необходимостью начинать все сначала. Если вы выбрали такой вариант действий, нужно помнить о двух вещах:
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. 20th 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 Кадровые вопросы
4.2 Лояльность, отношение, мотивация и вознаграждения
Профессионалы в больших компаниях также начали сталкиваться с этой проблемой, поскольку наступление эры даунсайзинга, аутсорсинга и реижиниринга повлекло за собой распад многих софтверных компаний и безработицу в нашей области. Эти явления особенно обострились благодаря слияниям и приобретениям компьютерных компаний, а также в отраслях экономики с высокой степенью конкуренции, где обработка информации играет ключевую роль. Например, когда пару лет назад объединились Chemical Bank и Chase Manhattan Bank, высшее руководство столкнулось с проблемой объединения двух совершенно различных системно-технических платформ и иерархий IT-менеджмента. Как я отмечал в главе 1, именно такая ситуация порождала многочисленные безнадёжные проекты, которые имели место в 90-х годах.
Проблема многих из таких крупных организаций заключается в следующем: в то время как работодатель определённо менял свой подход к трудовому соглашению, работник оказывался не готов соответствующим образом на это отреагировать. Многие программисты и проектировщики, честно трудившиеся на благо компании от 10 до 20 лет, искренне полагают, что (а) компания будет и дальше заботиться о них и (б) они должны оставаться с компанией при любых неприятностях. «Неприятность» – это подходящее понятие для большинства безнадёжных проектов. Вряд ли можно получать какое-то удовольствие, жертвуя своим свободным временем, работая до изнеможения и сталкиваясь со стрессами и политическим давлением. Так почему же мы делаем это? Потому что мы дали определённые обязательства и считаем делом чести их выполнять.
Тем не менее, эти обязательства лишаются всякого смысла, если работодатель аннулирует трудовое соглашение; в этом случае необходимо пересмотреть своё отношение к работе и решить, стоит ли её продолжать. Я вовсе не советую поступать неэтично или аморально, но я не вижу ничего плохого в том, чтобы ограничить свои обязательства по отношению к работодателю одним или двумя годами, или временем одного проекта. Работодатель, который заявляет проектной команде: «Если вы не сдадите систему к 31 декабря, я вас уволю», тем самым высказывает своё отношение к трудовому соглашению.
Помимо угрозы быть уволенным, которая определённо присутствует на переговорах безнадёжного проекта, существует также опасность, что вас обойдут с повышением должности или продвижением по службе. Однако, если трудовое соглашение нарушается и с вами поступают достаточно жёстко, вы имеете полное право ответить тем же. Один из самых сильных козырей в переговорной игре – это имеющееся у вашего противника понимание того, что вы готовы все бросить и уйти, если результаты переговоров не будут взаимно приемлемыми. (Некоторые читатели, вероятно, будут возражать против использования понятия «противник» по отношению к заказчику или одному из руководителей. Однако, сама сущность безнадёжного проекта такова, что владелец проекта, заказчик, различные акционеры и заинтересованные лица вполне сознательно и умышленно подталкивают менеджера к принятию решений, которые по своей воле он никогда бы не сделал. Если вы не считаете, что «противник» – это подходящая характеристика для того, с кем вас в течение ряда лет связывали тёплые, дружеские, профессиональные отношения, тогда вернитесь к началу главы и снова прочтите слова лорда Байрона.)
Если высшее руководство угрожает уволить вас в случае провала безнадёжного проекта, или вы (что практически одно и то же) категорически не согласны с нереальными планами, которые вас заставляют принять, вам следует в ответ проявить такое же хладнокровие и настойчивость в своих требованиях. Может быть, и не стоит сильно настаивать на изменении плана, однако следует проявить гораздо большую требовательность, когда речь пойдёт о формировании проектной команды (этот вопрос будет более детально обсуждаться в следующей главе). И, определённо, нужно быть настойчивым в том, что касается игнорирования или отмены административных и бюрократических правил и процедур, которые могут гарантировать провал безнадёжного проекта.
По этому поводу есть старая поговорка: «сначала сделай, потом извиняйся». Может быть, не стоит терять время на переговорах, чтобы добиться для себя временной передышки от всяких бюрократических ограничений, которые могут погубить проект. Определённо, незачем пытаться это сделать, поскольку само ваше назначение со стороны высшего руководства обычно даёт достаточно прав, чтобы обойти или проигнорировать деятельность различных начальников, комитетов и блюстителей стандартов, которые будут виться вокруг проекта. Однако, если вы получите уклончивый ответ вроде: «Мы вовсе не уверены, что это такая уж хорошая идея – дать вашим программистам два ПК и разрешить им работать вне офиса; нам надо посоветоваться с хозяйственной службой и узнать, что они об этом думают», не теряйте больше времени даром. Просто идите и делайте то, что считаете нужным!
Любой умный человек найдёт способ обойти многие из бюрократических рогаток таким образом, что бюрократам потребуется шесть месяцев, чтобы обнаружить это и предпринять ответное наступление; к тому времени ваш проект может уже закончиться (или успеет провалиться). Если же бюрократия пойдёт в наступление, будьте готовы ответить тем же. В конце концов, работа находится в самом разгаре, и руководство, вероятно, не захочет сталкиваться с риском вашего ухода (и ухода всей команды) и необходимостью начинать все сначала. Если вы выбрали такой вариант действий, нужно помнить о двух вещах:
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. 20th 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 человек. В таких случаях я всегда соглашаюсь. Я поручаю этим субъектам менять перегоревшие предохранители у кофейного автомата и другие важнейшие задания, в то время как я занимаюсь своими лучшими сотрудниками. (Среди этих людей, если вдруг повезёт, тоже могут оказаться хорошие исполнители.) Затем вы можете способствовать уходу из проекта лишних людей и продолжать настаивать на их замене все новыми и новыми людьми. Например, в одном случае я сократил первоначальный персонал на 20% и, несмотря на это, получил нужный результат, причём гораздо более высокого качества. В этом нет ничего удивительного.
1) нанять суперпрограммистов и предоставить им свободу действий;
2) настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;
3) набрать команду из простых смертных, но при условии, что они будут знать, на что идут;
4) взять любых сотрудников, которых вам дают, и сделать из них команду «невыполнимой миссии».
Первая стратегия выглядит весьма заманчиво, поскольку существует предположение, что суперпрограммисты будут невероятно продуктивны и достаточно изобретательны, чтобы предложить для безнадёжного проекта новые решения. С другой стороны, эта стратегия рискованна, поскольку суперпрограммисты обычно являются суперэгоистами и могут не ужиться друг с другом. Кроме того, такая стратегия для многих организаций проблематична, поскольку руководство не желает платить суперпрограммистам такую высокую зарплату, какую они требуют. И даже если это вам по карману, мало шансов на то, что они согласятся работать над безнадёжным проектом – ведь они все работают в Netscape или Microsoft или ещё где-нибудь, где, по их мнению, имеют место действительно впечатляющие проекты.
Вторая стратегия почти наверняка будет идеальной для большинства организаций, поскольку она не требует привлечения суперпрограммистов; кроме того, такой тип проектной команды воспет телесериалом «Невыполнимая миссия». Однако, если ваша организация предпринимает свой самый первый безнадёжный проект, такой команды просто не существует. Если же такие проекты ранее имели место, и они носили характер «самоубийственных», «камикадзе» или «отвратительных» проектов, то их команды в дальнейшем, скорее всего, распались и прекратили своё существование. Таким образом, стратегия сохранения в целости проектной команды успешного безнадёжного проекта должна, как правило, планироваться заранее как корпоративная стратегия, исходя из предположения, что безнадёжные проекты могут снова иметь место в будущем (более детально это будет обсуждаться в главе 7).
Третья стратегия по вполне очевидным причинам является наиболее распространённой для тех организаций, в которых мне довелось побывать. В большинстве организаций нет суперпрограммистов и нет тех, кто уцелел в предыдущих безнадёжных проектах. Следовательно, команда каждого нового безнадёжного проекта комплектуется заново. Участники команды вполне компетентны и, возможно, выше среднего уровня разработчиков в данной организации, однако от них нельзя ожидать сотворения чудес. Для данной стратегии жизненно важно, чтобы участники команды понимали, на что они идут; даже хотя они являются простыми смертными, им придётся совершать необычайные подвиги в разработке ПО.
Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет «самоубийственным». Такой тип команды также воспет Голливудом, особенно в таких фильмах, как Чёртова Дюжина ; их смысл заключается в том, что отверженных и неудачников может сплотить сильный, харизматический лидер и заставить их совершать чудеса, которые все считали невозможными. Все это хорошо, однако Голливуд ничего не рассказывает нам обо всех таких проектах с собранными из неудачников командами, которые закончились провалом. Мне думается, что если вы согласитесь руководить таким проектом (или участвовать в нем), то вас ждёт судьба самоубийцы.
Все сказанное приводит нас к центральному вопросу формирования команды безнадёжного проекта: до какой степени менеджеру проекта следует настаивать на своём праве принимать кадровые решения? Как было отмечено выше, большинство менеджеров вынуждены примириться с фактом, что они не получат карт-бланш, чтобы нанимать самых талантливых суперпрограммистов в мире; кроме того, существующая в организации политика может не позволить менеджеру по собственной воле, не спрашивая разрешения, привлечь в проект лучших сотрудников организации, поскольку они либо уже участвуют в других важных проектах, либо их с пеной у рта отстаивают другие менеджеры. Тем не менее, существует один аспект, на котором, по моему убеждению, менеджер должен настаивать как на своём абсолютном праве: это право наложить вето на попытку других руководителей навязать проектной команде неугодного им сотрудника. В противном случае и без того уже высокий уровень риска в проекте может повыситься до недопустимых пределов.
Естественно, такая ситуация порождает разнообразные и весьма неприятные политические баталии. Менеджеру проекта придётся, вероятно, выслушивать всякие успокаивающие заверения вроде: «Не надо беспокоиться. У Чарли были некоторые проблемы в предыдущих проектах, но в твоём с ним будет все в порядке» или чрезвычайно льстивые речи наподобие: «Ты такой грандиозный менеджер, что я уверен в твоей способности развернуть Чарли на 180° и получить от него реальную отдачу» или разные призывы проявить лояльность и мужество. Мой совет – держаться до последнего и быть непреклонным в своём праве отвергнуть любого, кто, по вашему мнению, не подходит для проектной команды.
Один из критериев, которые следует принимать во внимание при таких решениях – это вероятность того, что предполагаемый участник команды покинет проект, не дожидаясь его окончания. Разумеется, большинство разработчиков не расскажут вам ничего о своих планах уйти в середине проекта; однако, некоторые из них все же расскажут вам заранее о своих личных намерениях – женитьбе, разводе, планируемой экспедиции в Гималаи и т.д. – которые могут выключить их из работы над проектом. Крайне нежелательно в самом разгаре проекта лишиться некоторых сотрудников и оказаться вынужденным принять в проект новых людей.
В главе 3 я рассматривал варианты действий, которые имеются у менеджера проекта в случае неудачи переговоров: уйти в отставку, обратиться за помощью к более высокому руководству, игнорировать бюрократические правила и принимать свои собственные решения, или определить для себя проект как самоубийственную миссию. Игнорирование правил обычно является наиболее сложным делом, поскольку включение дополнительных участников в проектную команду может быть связано с ограничениями штатного расписания, которое менеджеру проекта неподконтрольно. С другой стороны, иногда имеется возможность «одолжить» людей из другого проекта или даже нанять по контракту временных исполнителей.
Можно также попытаться изолировать нежелательного участника команды, которого включили в проект против воли менеджера; его можно загрузить какой-нибудь безобидной работой или отправить изучать поведение африканских мух цеце до самого конца проекта. Doug Scott описал ещё более хитрый вариант такой стратегии:
Безнадёжные проекты к концу зачастую оказываются в таком отчаянном положении, что высшее руководство готово выбросить любые средства, например, чтобы нанять ещё 20 человек. В таких случаях я всегда соглашаюсь. Я поручаю этим субъектам менять перегоревшие предохранители у кофейного автомата и другие важнейшие задания, в то время как я занимаюсь своими лучшими сотрудниками. (Среди этих людей, если вдруг повезёт, тоже могут оказаться хорошие исполнители.) Затем вы можете способствовать уходу из проекта лишних людей и продолжать настаивать на их замене все новыми и новыми людьми. Например, в одном случае я сократил первоначальный персонал на 20% и, несмотря на это, получил нужный результат, причём гораздо более высокого качества. В этом нет ничего удивительного.
4.2 Лояльность, отношение, мотивация и вознаграждения
Вопросы отношения к безнадёжному проекту обсуждались мной в главе 2; оно является важным элементом политики в проектах такого рода, а также одной из ключевых характеристик команды, которой менеджер проекта должен уделять максимальное внимание. В идеальном случае (с точки зрения менеджера проекта) участники команды должны дать клятву верности и преданности безнадёжному проекту; для молодых и неженатых технарей это звучит не так уж дико, как может показаться. С другой стороны, отношение существенно зависит от таких факторов, как длительность проекта. Можно полностью посвятить себя 3-х или 6-ти месячному проекту, но вряд ли это возможно для трехлетнего проекта.
Отношение к проекту также существенно зависит от способности менеджера проекта обеспечить необходимую мотивацию участников команды. До некоторой степени это определяется его харизмой. Некоторые менеджеры способны вызвать у участников команды такую преданность, что они последуют за ним хоть на край земли, не обращая внимания на рискованность проекта; другие же настолько бездарны в этом отношении, что их команды и палец о палец бы не ударили, даже если целью проекта было бы спасение человечества от вторжения пришельцев.
Конечно, можно возразить, что менеджер должен брать в свою команду только тех, кто проявляет высокую заинтересованность. Можно также утверждать, что данное обсуждение вообще бессмысленно, поскольку большинство разработчиков ПО и так обладает достаточной мотивацией, как отмечают в [1] Tom DeMarco и Tim Lister:
Вы предполагаете, что менеджер знает, что за людей он получает в свою команду. У меня обычно получалось так, что их включали в команду до того, как я успевал узнать о них что-либо хорошее или плохое.
Отношение к проекту также существенно зависит от способности менеджера проекта обеспечить необходимую мотивацию участников команды. До некоторой степени это определяется его харизмой. Некоторые менеджеры способны вызвать у участников команды такую преданность, что они последуют за ним хоть на край земли, не обращая внимания на рискованность проекта; другие же настолько бездарны в этом отношении, что их команды и палец о палец бы не ударили, даже если целью проекта было бы спасение человечества от вторжения пришельцев.
Конечно, можно возразить, что менеджер должен брать в свою команду только тех, кто проявляет высокую заинтересованность. Можно также утверждать, что данное обсуждение вообще бессмысленно, поскольку большинство разработчиков ПО и так обладает достаточной мотивацией, как отмечают в [1] Tom DeMarco и Tim Lister:
Для любого работника нет ничего более обескураживающего, чем чувствовать, что его собственной мотивации явно недостаточно, и она должна «подкрепляться» его боссом. Достаточно редко приходится прибегать к драконовским мерам, чтобы заставить ваших людей работать; большинство из них любит свою работу.Существуют, однако, уровни или степени мотивации. Мы можем рассчитывать на то, что разработчик ПО проявит определённую степень мотивации в «нормальном» проекте, но безнадёжные проекты требуют более высокой степени, поскольку участникам команды месяцами придётся выдерживать изнурительную работу, политическое давление и технические трудности. Кроме того, в начале проекта менеджер сталкивается с такой проблемой, как отсутствие точного знания мотивации каждого из участников команды. Как отмечает Doug Scott:
Вы предполагаете, что менеджер знает, что за людей он получает в свою команду. У меня обычно получалось так, что их включали в команду до того, как я успевал узнать о них что-либо хорошее или плохое.