Тем не менее, эти обязательства лишаются всякого смысла, если работодатель аннулирует трудовое соглашение; в этом случае необходимо пересмотреть свое отношение к работе и решить, стоит ли ее продолжать. Я вовсе не советую поступать неэтично или аморально, но я не вижу ничего плохого в том, чтобы ограничить свои обязательства по отношению к работодателю одним или двумя годами, или временем одного проекта. Работодатель, который заявляет проектной команде: «Если вы не сдадите систему к 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. ЧЕЛОВЕЧЕСКИЙ ФАКТОР В БЕЗНАДЕЖНЫХ ПРОЕКТАХ
Когда солдаты получают боевое крещение на поле битвы, они в моих глазах все становятся равными по званию.
Наполеон Бонапарт
Генерал настолько хорош или настолько плох, каким его делают собственные солдаты.