Акционеры

Акционеры являются, по существу, «совладельцами» системы; хотя они могут и не иметь полномочий на то, чтобы начать проект, выполнить приемку его результатов или утвердить бюджет, они, тем не менее, кровно заинтересованы в его результатах. На самом деле, во многих случаях они имеют свою долю в бюджете, а также разделяют все прочие выгоды и риски, связанные с проектом. На акционеров надо смотреть, как на членов «Совета Директоров», при этом на владельца - как на «Председателя Совета». Акционеры могут проводить или не проводить регулярные собрания, они могут и не иметь непосредственного контакта с проектной командой, но при этом они все равно остаются акционерами.

Таким образом, проектная команда и менеджер проекта могут иметь дело с акционерами практически в такой же степени, как и с владельцем проекта - во всяком случае, необходимо отметить, что акционеры ни в коем случае не должны быть забыты или проигнорированы. Их трудно не заметить, поскольку они стремятся оказывать влияние на все происходящее вокруг и добиваться, чтобы их голос услышали; они также присутствуют на многих совещаниях и презентациях, связанных с безнадежным проектом. С другой стороны, среди части проектных менеджеров существует тенденция к тому, чтобы по возможности избегать этих индивидуумов, считая, что владелец проекта вполне может выступать от их имени - и, понятное дело, менеджер проекта считает, что каждая лишняя минута обхаживания очередного акционера могла быть с большим успехом потрачена на работу в самом проекте. Однако, поскольку акционеры могут участвовать в принятии решений относительно распределения полномочий, утверждения и финансирования безнадежного проекта, они также могут быть привлечены к принятию решения относительно прекращения проекта. Если им кажется, что их игнорируют, то они, скорее всего, так и сделают.

Консультант Dave Kleist в недавнем письме ко мне определил любопытную разновидность акционера:

В некоторых из безнадежных проектов, в которых я участвовал, мне удалось обнаружить довольно важный тип акционера: это поставщик, особенно если его сотрудники участвуют в работе над проектом. В зависимости от того, кто занимается приобретением проектных решений и программного обеспечения, могут сразу же возникнуть некоторые проблемы. Принятие решений о приобретении во время игры в гольф одного президента с другим - верный путь к безнадежному проекту, поскольку при этом нормальный процесс обсуждения требований к приобретаемым продуктам сокращен до минимума. Старайтесь не быть первопроходцами при приобретении чего-либо.

Естественно, если поставщик вовлечен в проект, у него самого могут быть различные категории акционеров. Например, торговый представитель поставщика в большей степени связан с продажами и получением комиссионных, чем с реальной работой продуктов поставщика и успехами проекта. Если же со стороны поставщика в работе проектной команды участвуют также консультанты, технические и другие специалисты, то степень влияния поставщика на политику несколько возрастает.

Альтернатива - банкротство или прочие разные бедствия

Как я уже объяснял, причиной некоторых безнадежных проектов являются решения относительно реинжиниринга, даунсайзинга и аутсорсинга, принимаемые высшим руководством, которые, в свою очередь, зачастую продиктованы глобальной конкуренцией, неожиданными решениями правительства и т.п. Независимо от причины, результат всегда один и тот же: сотрудники компании соглашаются участвовать в проекте, поскольку верят, что альтернативой является банкротство или какие-нибудь другие ужасные бедствия. Нередко ситуация дополнительно усугубляется провокационными заявлениями руководства, которое предлагает всем, не желающим участвовать в проекте, немедленно освободить свое место, дабы не мешать тем, кто остается, сосредоточиться на спасении компании.

Мы не обсуждаем здесь, правильно или неправильно действует руководство в подобной ситуации, пытаясь заранее упредить надвигающийся кризис. Суть дела в том, что поскольку кризис наступил и руководство затевает безнадежный проект, вам предстоит принять взвешенное решение - участвовать в нем или нет. Когда писалась эта книга, Apple как раз являла собой хороший пример компании, переполненной безнадежными проектами, поскольку она вела борьбу за выживание (хотя лично мне ничего не известно о каких-либо ультиматумах руководства вроде «соглашайся или уходи»).

Учитывая ранее сказанное, вы можете предвидеть, каким будет мой совет: отступите на шаг и спросите себя, является ли этот безнадежный проект исключением, или все еще только начинается. Даже если вы выиграете свое сражение, компания может проиграть войну; в самом деле, ваш успех в проекте может оказать компании медвежью услугу, оттянув ее крах на срок, достаточный для того, чтобы затеять второй

безнадежный проект.

Еще раз повторюсь, что ваше решение является сугубо личным, и к нему могут примешиваться такие соображения, как преданность компании, сочувствие или желание показать всему миру, что вы и ваша компания не собираетесь сдаваться без борьбы. И кто знает, может быть, значительный успех безнадежного проекта сумеет в корне изменить ситуацию.
Именно так произошло в 1995 году с фирмой Borland, выпустившей на рынок свой продукт Delphi. Ни у кого из нас нет хрустального шара, чтобы предсказать будущее безнадежного проекта; мы не можем также точно предсказать, каковы будут последствия успеха или неудачи проекта. Некоторые компании умирают быстро, другие терпят долгий затяжной крах, а некоторые успевает кто-нибудь купить, пока они окончательно не вступили в полосу неудач.

Поскольку вы консультируетесь со своим собственным хрустальным шаром, поинтересуйтесь мнением как можно большего количества людей - особенно тех, кто не имеет своей доли в доходах компании. Может быть, вам удастся побеседовать с честными и беспристрастными руководителями, которые искренне готовы обсуждать последствия неудачи или успеха безнадежного проекта; но вам следует также помнить, что те же руководители делают свои карьеры и заботятся о своей зарплате; эгоизм и политическое чутье могут не позволить им сообщить вам какую-либо информацию, жизненно важную для принятия правильного решения.

Альтернатива - безработица

Поскольку мы действительно

работаем в индустрии молодых оптимистов, и наша индустрия непрерывно (и временами довольно быстро) развивается по крайней мере последние 30-40 лет, я всегда удивлялся, когда участники безнадежных проектов приводили мне этот довод.

С другой стороны нужно учитывать, что в таких условиях профессиональные знания довольно быстро обесцениваются. В самом деле, за последнее десятилетие произошли такие огромные изменения, что наша профессия, как и многие другие профессии «белых воротничков», накопила значительный опыт даунсайзинга, реинжиниринга и аутсорсинга. В целом уровень занятости в индустрии ПО постоянно растет, но при этом не надо забывать, что спрос на программистов С++ растет быстрее, чем падает спрос на программистов КОБОЛа (правда, мои коллеги напомнили мне, что такой спрос еще существует в связи с проблемой 2000 года и необходимостью преобразования множества программ, написанных на КОБОЛе. Тем не менее, я уверен, что после 1-го января 2000 года перспективы программистов КОБОЛа существенно ухудшатся). Кроме того, большие IS/IT-организации, которые превратились в огромные бюрократические монстры с тысячами сотрудников, оказались частично подверженными реинжинирингу и даунсайзингу; их высшее руководство может быть не готовым к сокращению технических специалистов, но зачастую сокращает менеджеров среднего звена, администраторов и обслуживающий персонал.

Все это приобретает особое значение в безнадежных проектах. Вполне возможно, что нехватка людей в проектной команде является следствием общего сокращения штатов разработчиков ПО, предпринятого руководством. И, аналогично, сокращение вдвое срока разработки может быть следствием реинжиниринга под лозунгом: организация должна работать вдвое продуктивнее, чем прежде (что в переводе на командный язык означает «Работать усерднее! Работать быстрее!»). Кстати, эта ситуация гораздо

более характерна для Северной Америки, чем для стран Западной Европы, где мне удалось побывать. Только в Северной Америке увлекаются таким «радикальным» реинжинирингом, что масса сотрудников увольняется с работы.
По этим же причинам ( с учетом культурных традиций, социальной политики и законов) количество безнадежных проектов в этих странах существенно меньше. Служащие, особенно в Западной Европе, гораздо больше защищены от сверхурочной работы и ревностно отстаивают свои права на отпуск, выходные, личное время и др. Хорошо это или плохо - это тема для отдельного разговора.

Поскольку реинжиниринг не является темой данной книги, мне не хотелось бы давать какие-либо комментарии по поводу стратегий реинжиниринга, предпочитаемых менеджментом. В данном случае важно то, что многие технические специалисты и менеджеры ощущают скрытую угрозу, когда проекты выполняются в такой обстановке. Довольно часто бывает, что несогласие с какими-либо установками проекта означает для них увольнение с работы. Для 22-летнего неженатого программиста в этом нет ничего страшного, а для 35-летнего менеджера проекта, обремененного семьей и долгами, увольнение может стать серьезной проблемой. Что же касается 45-летнего программиста, вся квалификация которого - КОБОЛ и CICS, то проблема еще серьезнее. Несмотря на молодость нашей индустрии, она существует достаточно долго для того, чтобы было найти даже 55- и 60-летних программистов, которые вынуждены изо всех сил держаться за свою работу, пока не получат законное право на пенсию.

Для людей среднего возраста и более старших характерна привязанность к своему месту жительства, поскольку их супруги работают в том же городе, либо дети могут учиться только в местных школах, либо совесть не позволяет покинуть своих старых родителей и других членов семьи. Это не является проблемой, если рынок труда достаточно велик, однако каждый, кто сегодня живет в Пукипси, Нью-Йорк, хорошо знает, о чем я говорю. Люди, живущие в Редмонде, Вашингтон, вероятно, могли сталкиваться с такими же неприятными проблемами 5, 10 или 20 лет назад.

Я очень сочувствую профессионалам-разработчикам среднего и более старшего возраста, которые оказались сегодня в сложном положении, хотя я весьма удивлен, что технические специалисты усиленно игнорировали тот факт, что это может случиться именно с ними, несмотря на то, что разнообразные мероприятия по реинжирингу/даунсайзингу проводятся уже достаточно долго.


Но это также предмет для отдельной книги; я уже обсуждал эти проблемы в своих книгах «Decline and Fall of the American Programmer» и «Rise and Resurrection of the American Programmer», и я ограничиваю свои соображения здесь только тем, что непосредственно касается безнадежных проектов.

Если вам говорят открытым текстом или намекают, что если не согласитесь участвовать в проекте со смехотворным графиком, бюджетом и ресурсами, то останетесь без работы, то что вам остается делать? Очевидно, это зависит от того, как вы оцениваете свое финансовое, физическое, эмоциональное и психологическое состояние; но, кроме этого, вы должны точно оценить положение дел в вашей компании. В некоторых случаях реальная опасность заключается в том, что ваше продвижение по службе, премии или рост зарплаты будут остановлены, если вы откажетесь участвовать в проекте (ниже я отдельно остановлюсь на этой проблеме). Однако, даже если вам угрожает потеря работы, в больших компаниях обычно невозможно претворить эту угрозу в жизнь немедленно; у вас может быть два или три месяца в запасе до увольнения, и этого может оказаться достаточно для поиска новой работы.

Но что если угроза гораздо ближе и ощутимее? Например, ваш босс заявляет: «Немедленно ставь свою подпись под согласием участвовать в проекте, или собирай свои вещи и выметайся отсюда!» Непостижимо, чтобы разумный человек мог предпочесть работать в такой обстановке, однако давайте предположим, что до сих пор обстановка была вполне дружелюбной, пока последняя реинжиниринговая мания не сделала вашего босса неуправляемым лунатиком. Итак, вам предстоит выбор: подписаться, уйти или быть уволенным. Что вы предпочтете?

Если это возможно, я советую уйти сразу, потому что потом будет еще хуже. Возможно, придется несколько месяцев посидеть на мели, пока не приобретете опыт в какой-либо новой технологии, однако впоследствии вы, скорее всего, увидите, что это гораздо лучше, чем, подчинившись обстоятельствам, продолжать работу без какой-либо надежды на улучшение ситуации.


В принципе, можно согласиться добровольно участвовать в проекте и одновременно, обновив свое резюме, начать поиск новой работы, хотя при этом может возникнуть проблема этического характера, если вы понимаете, что уход в середине проекта может поставить остальных участников команды в трудное положение.

Если же вам некуда деваться - близится уход на пенсию, ваша квалификация не пользуется спросом на рынке или во всем городе один-единственный работодатель, а семейные обстоятельства не позволяют никуда уехать, вам следует убедить себя выработать более позитивное отношение к безнадежному проекту. «Черт возьми, я докажу им, что этот старый пес еще способен лаять», - скажет среднего возраста ветеран. «Я покажу начальству, что мы ничуть не хуже этих сопливых мальчишек, и мы сделаем проект в срок!» Конечно, смелость и позитивный взгляд на вещи просто замечательны, но не забывайте при этом одно обстоятельство: если безнадежный проект закончится успешно, за ним последует еще один. Не забывайте о том, что было сказано в начале книги: безнадежные проекты являются нормой, а не исключением.

Что делать в случае провала переговоров

Выше я отметил, что если менеджер проекта оказался не в состоянии добиться от заказчика или высшего руководства понимания той неопределенности, которая связана с планом или бюджетом безнадежного проекта, он должен всерьез задуматься об отставке; то же самое касается и технических специалистов проектной команды. Но это только один аспект неудачных переговоров; как следует поступить менеджеру, например, если он на 100% уверен, что продиктованный политическими соображениями срок в шесть месяцев явно недостаточен? Как следует ему поступить, если он на 100% уверен, что проектная команда должна состоять как минимум из трех человек, а руководство дает только двух?

В этой книге я уже несколько упоминал о возможности отставки, и я понимаю, что это не слишком подходящий вариант для некоторых профессионалов; разумеется, для менеджеров отставка является более серьезной проблемой, чем для технических специалистов, по той простой причине, что они, как правило, на 5-10 лет старше и поэтому обременены долгами, семьями, наполовину заработанной пенсией и т.д. Они в большей степени испытывают сомнения относительно возможности быстро найти другую работу, в то время как молодые и холостые участники проектной команды практически уверены, что смогут устроиться на другую работу за 24 часа.

Важно понимать, что я вовсе не рекомендую использовать отставку в качестве наказания или мести. Она является просто разумным действием, которое следует предпринять, столкнувшись с неразрешимой ситуацией и непримиримыми противоречиями на переговорах. Жизнь на этом не кончается, впереди будут еще другие проекты и другие работы. Как отметила недавно Sue Peterson:

Я научилась кое-чему от своих детей и думаю, что это применимо к работе в такой же степени, как и к обыденной жизни… Я должна

беречь себя, свою энергию, эмоциональное и физическое здоровье, свое свободное и рабочее время. Если я не буду беречь себя, у меня не останется ничего для детей.

Однако, есть еще одно соображение, связанное с уходом, которое необходимо принимать во внимание: оно касается лояльности и трудового соглашения между работодателем и работником.
Вплоть до 80- х годов многие профессиональные программисты работали в крупных организациях, элементом корпоративной культуры которых являлась «пожизненная занятость». Хотя это никогда не было столь явным или серьезным, как в японских компаниях, большинство программистов и проектировщиков в крупных банках, страховых компаниях, правительственных учреждениях и компьютерных компаниях (таких, как IBM и DEC) полагали, что в отсутствие войны, голода или чумы они будут продолжать расти вместе с организацией, пока не уйдут в 65 лет на пенсию с золотыми часами.

Небольшие компании никогда не обладали такого рода культурой, и многие профессионалы-разработчики работали именно в таких компаниях, особенно когда компьютерные технологии стали настолько дешевыми, что даже небольшая семейная лавочка могла приобрести ПК и Web-сервер. Те из нас, кто работали в консалтинговых фирмах, бюро обслуживания и различных начинающих компаниях, всегда знали, что там не было и речи о пожизненной занятости.

Профессионалы в больших компаниях также начали сталкиваться с этой проблемой, поскольку наступление эры даунсайзинга, аутсорсинга и реижиниринга повлекло за собой распад многих софтверных компаний и безработицу в нашей области. Эти явления особенно обострились благодаря слияниям и приобретениям компьютерных компаний, а также в отраслях экономики с высокой степенью конкуренции, где обработка информации играет ключевую роль. Например, когда пару лет назад объединились Chemical Bank и Chase Manhattan Bank, высшее руководство столкнулось с проблемой объединения двух совершенно различных системно-технических платформ и иерархий IT-менеджмента. Как я отмечал в главе 1, именно такая ситуация порождала многочисленные безнадежные проекты, которые имели место в 90-х годах.

Проблема многих из таких крупных организаций заключается в следующем: в то время как работодатель определенно менял свой подход к трудовому соглашению, работник оказывался не готов соответствующим образом на это отреагировать. Многие программисты и проектировщики, честно трудившиеся на благо компании от 10 до 20 лет, искренне полагают, что (а) компания будет и дальше заботиться о них и (б) они должны оставаться с компанией при любых неприятностях.


«Неприятность» – это подходящее понятие для большинства безнадежных проектов. Вряд ли можно получать какое-то удовольствие, жертвуя своим свободным временем, работая до изнеможения и сталкиваясь со стрессами и политическим давлением. Так почему же мы делаем это? Потому что мы дали определенные обязательства и считаем делом чести их выполнять.

Тем не менее, эти обязательства лишаются всякого смысла, если работодатель аннулирует трудовое соглашение; в этом случае необходимо пересмотреть свое отношение к работе и решить, стоит ли ее продолжать. Я вовсе не советую поступать неэтично или аморально, но я не вижу ничего плохого в том, чтобы ограничить свои обязательства по отношению к работодателю одним или двумя годами, или временем одного проекта. Работодатель, который заявляет проектной команде: «Если вы не сдадите систему к 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.

Допустимые компромиссы

Предположим, что проектная команда подготовила «разумную» оценку плана, бюджета и персонала, требуемых для безнадежного проекта, и руководство готово пойти на некоторые переговоры перед тем, как принять окончательное решение. Наиболее вероятно, что руководство объявит первоначальную оценку «неприемлемой» и выдвинет свои требования, которые окажутся гораздо более жесткими. Как в этом случае следует поступить менеджеру проекта?

Как отметил автор и консультант John Boddie, очень важно, чтобы все согласились с наличием более чем одного возможного «сценария» для проекта. Для проведения переговоров нелишними будут такие вопросы, как «обанкротится ли организация, если система будет готова не к 1-му сентября, а к 5-му?» или «все хотят, чтобы работа была сделана хорошо, быстро и дешево. Все знают, что реально можно выполнить только два требования из трех. Какие именно два для вас важнее?».

Если контрпредложение со стороны высшего руководства или заказчика содержит только одну «переменную», менеджер проекта может оценить влияние остальных переменных. Например, если первоначальная оценка менеджера проекта заключается в том, что проект потребует 12 месяцев на реализацию, трех разработчиков и бюджет 200.000$, вполне вероятно, что первой реакцией руководства будет: «Вздор! Нам нужно, чтобы система была готова и работала через шесть

месяцев!» На первый взгляд, очевидный способ сделать это заключается в увеличении штата и/или бюджета (например, увеличить зарплату, чтобы привлечь более продуктивных программистов).

С другой стороны, Фред Брукс уже более 20 лет назад отмечал, что зависимость между количеством разработчиков и временем разработки носит нелинейный характер; поэтому термин «человеко-месяц» был объявлен мифом. Разумеется, практически все зависимости между ключевыми переменными проекта являются нелинейными и зависящими от времени. Вследствие эффекта «обратной связи», возникающего в результате многих решений руководства, изменение одной переменной (например, увеличение штата) повлияет со временем не только на другие переменные (такие, как продуктивность), но и на собственное первоначальное значение - например, увеличение штата может отрицательно повлиять на моральное состояние команды, что, в свою очередь, может увеличить текучесть рабочей силы в проекте и в конечном счете снизить численность персонала.

Упомянутые выше динамические модели систем как раз отражают сущность этих нелинейных и нестационарных зависимостей; их характер является, к тому же, причиной использования различных коммерческих средств оценки, описанных выше. Следует отметить, что математической основой этих динамических моделей являются, как правило, нелинейные дифференциальные уравнения, в которых большинство из нас не слишком хорошо разбирается. Аналогично, коммерческие средства оценки выполняют сложные расчеты с учетом множества параметров; попытка сделать такую работу на интуитивном уровне, основываясь только на своем замечательном чутье, приведет, скорее всего, к грубым ошибкам.

К сожалению, именно в таком положении оказывается большинство менеджеров безнадежных проектов. Отчасти это объясняется самой природой переговорного процесса (напоминающего игру под названием «Испанская инквизиция», которая будет обсуждаться ниже); однако, причиной может быть отсутствие адекватных средств оценки и соответствующего опыта во многих организациях. Если этой проблемой ранее не занимались, то тем более бесполезно пытаться решать ее во время безнадежного проекта. Если в организации привыкли к торопливости и небрежности в количественной оценке проектов, то менеджеру безнадежного проекта вряд ли удастся выбить 10.000$ на приобретение достаточно сложного средства оценки.

Итак, что же делать в такой ситуации менеджеру? В крайнем случае, менеджеру остается осознать тщетность усилий и отреагировать соответственно; такая ситуация будет детально обсуждаться ниже в подразд. 3.5. Однако, в менее сложной ситуации существуют два возможных варианта действий:

·  Если требования пользователей или высшего руководства включают изменение одной из переменных проекта в пределах 10%, его можно компенсировать пропорциональным изменением одной из остальных переменных. Так, например, если руководство хочет сократить срок разработки на 10%, следует увеличить на 10% состав проектной команды. Вряд ли это будет точной компенсацией, но достаточно хорошо в первом приближении, и, как правило, это все, что вам удастся сделать в процессе переговоров.



·  Если изменение одной переменной выходит за пределы 10%, следует исходить из предположения, что обратное воздействие на какую-либо одну из оставшихся переменных будет квадратичным. Так, предположим, что руководство хочет наполовину уменьшить срок разработки, с 12 месяцев до 6. Вместо того, чтобы удваивать состав проектной команды, менеджеру следует увеличить его в 4 раза - или увеличить в 4 раза бюджет, чтобы нанять суперпрограммистов, которые умеют кодировать одновременно обеими руками. В отсутствие формальной модели оценки невозможно определить, насколько эта грубая эвристика будет соответствовать конкретной ситуации, но во всяком случае это лучше, чем оказаться в ловушке или придерживаться линейной зависимости между временем и людьми. К сожалению, «квадратичный» вариант достаточно трудно отстоять, и, скорее всего, «наглые» требования менеджера проекта будут отвергнуты, однако в случае хотя бы минимальной удачи менеджер все равно может оказаться в лучшем положении, чем при «линейном» варианте.

«Достаточно хорошее» программное обеспечение

Определение приоритетов требований, обсуждавшееся выше, может быть одним из способов, помогающих безнадежному проекту двигаться в «разумном» направлении. Для достижения успеха вовсе не обязательно реализовывать все требования; будет «достаточно хорошо», если мы сможем реализовать требования, которые «необходимо выполнить», и приемлемое количество требований, которые «следует выполнить».

Существует, однако, еще один аспект в разработке ПО, порождающий трудности в безнадежных проектах: неявно подразумеваемое требование достижения идеального качества. Обычно оно выражается в терминах количества дефектов (ошибок), но может быть также выражено в терминах переносимости, независимости от платформы, гибкости, сопровождаемости и других «стей». Даже в «нормальных» проектах достаточно трудно удовлетворить всем этим требованиям, а в безнадежных проектах сделать это просто невозможно. Вместо этого проектная команда должна придти к решению - и по возможности согласовать его с акционерами и заинтересованными лицами - относительно того, какое качество является достаточно хорошим.

Важность такого решения объясняется тем, что достижение абсолютного качества съедает все ресурсы проекта - особенно время. Если вы хотите разработать сертифицированную, не содержащую ошибок программу и математически доказать ее корректность, на это потребуется время. Это может также потребовать более высокого уровня таланта и способностей, чем те, которыми располагает проектная команда. Кроме того, одному или более участникам команды придется расходовать дополнительную энергию, следовательно, они не смогут работать над другими задачами. Короче говоря, выполнение таких требований, как надежность, переносимость и сопровождаемость, невозможно без компромиссов, и это необходимо учитывать в процессе определения приоритетов требований.

Командам безнадежных проектов приходится сталкиваться с такой неприятной реальностью лицом к лицу, поскольку альтернатива - «совершенное» ПО, которое не будет готово даже тогда, когда пройдут все мыслимые сроки.
Лучше всего, когда команда с самого начала проекта настроена прагматично на создание достаточно хорошего ПО, однако, мой опыт, к сожалению, говорит о том, что многие обычные разработчики ПО соглашаются с понятием достаточно хорошего ПО только тогда, когда упираются в тупик - например, когда оказываются в кризисном положении за месяц или два до окончания проекта.

Вплоть до этого момента времени они выражают свое недовольство: «Как вам понравится, если мы будем использовать ваш «достаточно хороший» подход применительно к ПО ядерного реактора или системы управления воздушным движением?» Разумеется, я отвечу, что мне это совсем не нравится; и, если кто-нибудь вздумает затеять безнадежный проект для создания такого рода высоконадежных приложений, тогда я просто перестану летать на самолетах и буду держаться как можно дальше от предприятий с ядерными реакторами. С другой стороны, нам обычно и не приходится сталкиваться с безнадежными проектами такого рода; скорее, это может быть кадровая система на ядерном предприятии или система резервирования авиабилетов. Это, конечно, не означает, что кадровые системы и системы резервирования авиабилетов должны работать со сбоями, однако все же непосредственные последствия этих сбоев будут не столь серьезны.

В любом случае, совершенная

надежность, сопровождаемость, переносимость и т.д. не являются необходимыми, практичными или даже желательными в большинстве безнадежных проектов. В самом деле, достичь такого совершенства невозможно даже в «нормальных» проектах, хотя в этом случае мы можем позволить себе установить планку своих стандартов гораздо выше, поскольку не связаны такими жесткими ограничениями на время, бюджет и людские ресурсы. Что же касается безнадежных проектов, то пользователям в действительности

нужна система, которая достаточно дешева, достаточно производительна, обладает достаточными возможностями, достаточно устойчива и будет готова достаточно скоро - вот в чем заключается их определение «достаточно хорошего» ПО.

Почему же нам не удается создать «достаточно хорошее» ПО? Это обычно объясняется совокупностью следующих причин:



·  Мы стремимся определять качество только

в терминах дефектов, не задумываясь о других его аспектах - которые, с точки зрения пользователя, включают, например, готовность к определенной дате.

·  Мы предполагаем, что малое количество дефектов равносильно лучшему качеству, и полагаем, что пользователь всегда

предпочитает такое качество - хотя существуют обстоятельства, когда пользователь готов пойти на компромисс и примириться с некоторыми ошибками в обмен на более скорое завершение работы или возможность продукта работать на различных программных/технических платформах и др.

·  Мы стремимся определить требования к качеству (дефектам) один раз, в самом начале проекта, и зафиксировать их, хотя обстоятельства могут измениться в течение проекта не один раз.

·  Мы так долго твердили, что процессы

являются критически важными, что при этом зачастую забываем об их «нейтральности» - дурак, вооруженный процессами и средствами, все равно останется дураком. Невозможно обеспечить качество, если просто слепо следовать всем деталям методологии структурного анализа или рекомендаций SEI-CMM.

·  Мы рассматриваем обеспечение качества как процесс, укладывающийся в жесткую схему, заданную в начале проекта раз и навсегда (или, что еще хуже, для всех проектов во всей компании).

·  Мы недооцениваем нелинейный характер зависимостей между такими ключевыми параметрами проекта, как численность персонала, плановые сроки, бюджет и количество дефектов - все эти аспекты в безнадежных проектах являются ключевыми.

·  Мы игнорируем динамику процессов: запаздывания, циклы обратной связи и т.д. Например, большое количество сверхурочной работы в течение данной недели может выразиться в повышении продуктивности и прогрессе в работе над проектом в целом; но, с другой стороны, оно может повлечь за собой большее количество ошибок на следующей неделе (о которых конечные пользователи и высшее руководство могут ничего и не узнать), которые снизят продуктивность работы (в терминах конечных результатов) и, может быть, даже отбросят проект назад.



·  Мы игнорируем такие факторы, как моральное состояние команды, адекватные условия для работы и др.

Каким же образом мы сможем создать «достаточно хорошее» ПО? Как отмечает James Bach [3], для этого требуется несколько вещей:

·  Утилитарная стратегия - искусство количественного анализа и максимизации чистого выигрыша в неопределенных ситуациях - обобщает идеи системного анализа, управления рисками, экономики, теории принятия решений, теории игр, теории управления и нечеткой логики.

·  Эволюционная стратегия - рассматриваемая не только по отношению к жизненному циклу проекта, но также к людям, процессам и ресурсам.

·  Героические команды - не Могучие Гениальные Программисты, а обычные умелые специалисты, способные к эффективному сотрудничеству.

·  Динамическая инфраструктура - противоположность бюрократии и засилью политики. Высшее руководство уделяет необходимое внимание проектам, уделяет внимание положению на рынке, предупреждает и разрешает конфликты между проектами, и становится на сторону проекта в случае конфликта между ним и бюрократами.

·  Динамические процессы - процессы, поддерживающие работу в эволюционирующей среде. Динамический процесс, в свою очередь, является часть идентифицируемого мета-процесса и всегда может подвергаться изменениям.

БЕЗНАДЕЖНЫЕ ПРОЕКТЫ КАК ОБРАЗ ЖИЗНИ

На протяжении всей книги я утверждал противоречие, которое нам сейчас необходимо разрешить. С одной стороны, я утверждал, что безнадежные проекты качественно отличаются от всех остальных «нормальных» проектов, выполняемых организациями-разработчиками. С другой стороны, в главе 1 я отметил, что условия, порождающие безнадежные проекты - сжатые сроки и бюджет, чрезмерные требования к функциональности - встречаются в сегодняшних организациях все чаще и чаще.

Многие разработчики и  менеджеры могут задать вопрос: разумно ли вообще планировать безнадежные проекты. John Boddie, автор Crunch Mode, таким образом высказался относительно отрасли, в которой ему довелось работать:

Я провел годы в лотерейном бизнесе, где все делается в экстремальных условиях, поскольку это единственный способ существования и развития отрасли. Если вы не желаете работать в таком режиме, то не сможете играть в этой песочнице. Разработчики в данной отрасли мирятся с таким положением, поскольку им доставляет удовольствие добиваться успеха в краткосрочных и в высшей степени интенсивных проектах и получать взамен значительную свободу действий, включая, в частности, двухмесячные отпуска между проектами. Эти команды считают себя элитой, и компании всячески поддерживают такие убеждения.

И, как отмечает Doug Scott:

Руководством движут различные мотивы. Они знают, что риск лишиться своей власти в наши дни особенно велик, и стремятся этого избежать, затевая различные проекты. Они также понимают, что на их выполнение нам потребуется не так уж мало времени из-за различных бюрократические процедур. Они полагают, что если особо обозначить важность конкретного проекта по сравнению с остальными, то эти процедуры можно будет обойти, не предпринимая для этого никаких специальных действий. Они понимают, что не могут привлечь к этой работе самых лучших специалистов; они также понимают, что самые лучшие технологии могут помочь в том случае, если они не потребуют длительного цикла обучения, что, в свою очередь, лишает возможности использовать такие технологии в данном проекте. Или наоборот, они верят шумной рекламе и считают, что новые технологии чудесным образом окажутся вполне зрелыми, свободными от ошибок, и их тотчас же сможет понять каждый.

Однако, если безнадежные проекты являются нормой, следует ли тогда называть их безнадежными? Не становятся ли они частью корпоративной культуры? Далее мы обсудим, почему такая трансформация может иметь место в нормальных организациях-разработчиках ПО, и затем перейдем к более серьезному вопросу: каким образом можно изменить

культуру обычной сегодняшней организации с тем, чтобы она могла эффективно справляться с безнадежными проектами, не считая их какой-то аномалией?

ЧЕЛОВЕЧЕСКИЙ ФАКТОР В БЕЗНАДЕЖНЫХ ПРОЕКТАХ

Когда солдаты получают боевое крещение на поле битвы, они в моих глазах все становятся равными по званию.

Наполеон Бонапарт

Генерал настолько хорош или настолько плох, каким его делают собственные солдаты.

Дуглас МакАртур

Будьте настойчивы в отстаивании права формировать свою собственную команду. Можно ожидать от команды сверхурочной работы, но при этом помните, что они участвуют в марафоне и могут пробежать в спринтерском темпе только последние 100 ярдов. Добейтесь для них щедрого вознаграждения, если проект закончится успешно, но не дразните их обещаниями будущих экстраординарных наград, потому что это только собьет их с толку. Приложите максимум усилий для создания спаянной и дружной команды, готовой к сотрудничеству; очень важно обладать необходимой квалификацией, однако еще более важно, чтобы она была дополнена психологической совместимостью. Все сказанное должно способствовать максимальному единению участников проекта.

К сожалению, этого явно недостаточно для большинства менеджеров безнадежных проектов, поскольку они работают в организациях, пренебрегающих человеческим фактором даже в «нормальных» проектах. Хотя может показаться, что в таких условиях безнадежные проекты обречены на провал, иногда получается как раз наоборот. Как отмечалось в главе 3, менеджер может быть вынужден согласиться с нереальными сроками или бюджетом, но в качестве компенсации может настаивать на своих решениях по вопросам персонала (на праве нанимать нужных исполнителей, соответствующим образом вознаграждать их и обеспечивать им нормальные условия работы).

Безнадежный проект может восприниматься как угроза теми, кто желает сохранить бюрократическое статус-кво. Менеджер проекта имеет возможность обойти бюрократические ограничения, связанные с персоналом, с помощью непосредственных распоряжений высшего руководства, однако он должен быть готов к тому, что, поступая таким образом, приобретет себе вечных врагов в лице кадровой службы и различных других администраторов. Тем не менее, если безнадежный проект будет иметь громкий успех, он может послужить катализатором к изменению кадровой политики в последующих «нормальных» проектах.

В любом случае, в этой главе я вовсе не ставлю перед собой задачу менять сложившуюся в организации культуру управления людскими ресурсами. На эту тему уже написано достаточно много, включая отдельные главы в моих книгах Rise and Resurrection of the American Programmer и Decline and Fall of the American Programmer (ряд ссылок содержится также в конце этой главы). Главный вопрос данной главы заключается в следующем: если вы уже знакомы с «основами» управления персоналом, что нового привносят безнадежные проекты?

ПЕРЕГОВОРЫ

«Сделка – это сама сущность соглашения между неприятелями… разве все люди не стараются снизить цену того, что они приобретают? Я утверждаю, что даже дружеская сделка – это объявление войны».

Лорд Байрон, Письмо, 14 июля 1821 года.

Если вы являетесь менеджером безнадежного проекта, то очень легко предсказать результат переговоров относительно бюджета, срока и ресурсов: вы проиграете. Это практически неизбежно, поскольку такие переговоры имеют место в самом начале проекта (или даже до его официального начала), когда владелец проекта/заказчик ни интеллектуально, ни эмоционально, ни политически не расположен воспринимать те неприятные для него контрпредложения, с которыми выступает менеджер. Более разумные переговоры могут иметь место за месяц или два до срока завершения проекта, когда новый менеджер проекта может в качестве обязательного условия своего назначения потребовать, чтобы все трезво оценили невозможность выполнения первоначальных планов и бюджета и реализации требуемой функциональности.

Никто из нас, видимо, не хотел бы оказаться в таком малоприятном положении. Поэтому, несмотря на сосредоточенность данной главы на разумных переговорных стратегиях, я, тем не менее, стараюсь не уходить от решения проблемы, с которой сталкивается большинство из нас: каким образом в самом начале проекта добиться нормальных условий его выполнения? Увы, но в этой главе вы не найдете никаких волшебных секретов; мрачная реальность такова, что в результате переговоров вы, скорее всего, окажетесь в проигрыше. Однако все же полезно разбираться в некоторых хитростях политических игр и уметь извлекать из них выгоду, а также в тех возможностях, которые следует изучить, если вы столкнулись с совершенно нереальными сроками, бюджетом и/или ограничениями на формирование проектной команды.

В данной главе я исхожу из предположения, что вы так или иначе участвуете в переговорах по поводу безнадежных проектов, планов и т.д. Если вы технический специалист, то ваше участие может и не быть непосредственным - например, вы можете консультировать менеджера проекта и готовить для него необходимую информацию с тем, чтобы он мог проводить переговорные баталии на более высоком уровне. Однако, как напомнил мне недавно Doug Scott, даже менеджер проекта может оказаться на вторых ролях, поскольку все переговоры проводятся от его имени менеджером более высокого уровня.

Единственной и самой большой помехой для меня в безнадежных проектах было мое собственное руководство. Необходимо знать, какую позицию оно обычно занимает в переговорном процессе, и если руководство чересчур увлекается политическими играми, лучше держать его подальше от проекта.

ПОЛИТИКА

Политика играет вполне определенную роль в любом софтверном проекте, хотим мы этого или нет; отличительной чертой безнадежных проектов является настолько сильное влияние политики, что она может свести на нет все усилия выполнить хотя бы какую-нибудь работу. Поскольку процессы, связанные с политикой, в особенности процесс переговоров, будут обсуждаться в отдельной главе, здесь важно просто обозначить наличие политики и предложить некоторые общие рекомендации.

Многие разработчики ПО считают, что поскольку политики не избежать, они предпочли бы держаться подальше от всей этой грязи. Это вполне понятное желание - многие из нас, кто всерьез поглощен разработкой ПО, социально инертны и политически наивны: мы не только считаем политические игры тошнотворными, но и уверены, что попытки играть в политические «игры» ничем хорошим для нас кончиться не могут. Все это хорошо до тех пор, пока кто-нибудь (обычно менеджер проекта) в состоянии держать политиков в руках. Однако, если все участники безнадежного проекта полагают, что «поскольку данный проект так важен, они оставят нас в покое и избавят от грязных политических игр», такой проект имеет весьма мало шансов на успех.

В данной главе будут обсуждаться три аспекта политики:

·  идентификация политических «игроков», вовлеченных в проект;

·  определение сущности проекта;

·  отношение участников к проекту.

ПРОЦЕССЫ

Если вы запомните хотя бы одно слово из данной главы (или вообще из всей книги), то эти словом должна быть приоритетность (triage). Исходя из названия главы, вы можете подумать, что речь в основном пойдет о таких знакомых методологиях, как структурный анализ, или формальных дисциплинах наподобие SEI Capability Maturity Model (CMM), или различных подходах к разработке ПО под общим названием RAD (Rapid Application Development). Все это важные и нужные вещи, но самое главное заключается в том, что в безнадежном проекте вам не хватит времени на то, чтобы удовлетворить все потребности пользователя. Если вы будете строить все свои процессы и методы, исходя из этого непреложного факта, то у вас появятся шансы на успех; если же вы начнете проект, будучи уверенными, что к кодированию нельзя приступать до тех пор, пока все диаграммы потоков данных, полученные в результате структурного анализа, не будут утверждены пользователем, то вы определенно потерпите неудачу.

Это не означает, что нам следует игнорировать все методологии и стратегии, связанные с процессами (я поговорю о них позже в этой главе); но моя мысль, как вы можете убедиться, заключается в том, что они, безусловно, должны быть частью общей корпоративной стратегии, однако их не следует навязывать команде безнадежного проекта в отчаянных попытках избежать его провала. В данной ситуации применима концепция приоритетности - испытывая нехватку времени и ресурсов, команда безнадежного проекта откажется от тех методов, которые она сочтет бесполезными или несущественными (например, детальные мини-спецификации в структурном анализе), и примет на вооружение только самые полезные для нее методы. Аналогично, менеджер проекта, располагающий весьма малым временем для чтения данной главы, предпочтет прочесть наиболее важную информацию и пропустить остальное; я построил обсуждение в данной главе, исходя именно из этих соображений.

ТЕХНОЛОГИЯ И СРЕДСТВА

Летом 1992 года мне довелось обедать с дружной группой менеджеров среднего уровня Microsoft. Во время завязавшейся беседы я спросил, является ли для проектных команд Microsoft обычным делом использование таких методологий, как структурный анализ или объектно-ориентированное проектирование. Ответы были примерно следующими: «иногда», «хммм, вроде бы да», «от случая к случаю» и «а что это такое?». Когда же я спросил их относительно использования CASE-средств (которые в то время все еще были довольно популярными в индустрии ПО), то из их ответов понял, в чем заключается общее мнение майкрософтовцев: такие средства годятся для «людей с улицы». С таким выражением я еще не встречался, его можно грубо интерпретировать как «невежественные дикари, которые только что вылезли из своего первобытного леса и начали обучаться программированию, в отличие от настоящих программистов, которые не нуждаются во всяких финтифлюшках».

Будучи слегка уязвленным, я поинтересовался, используют ли их проектные команды хоть какие-нибудь

средства, и в ответ услышал, что каждая команда Microsoft может выбрать любые средства, которые сочтет подходящими для своего проекта. Ухватившись за такой ответ, я спросил, какое средство считает наиболее важным типичная проектная команда?

«На днях я задал одной из проектных команд такой же вопрос», - ответил один из менеджеров. «Как вы думаете, что они ответили?»

«Какой-нибудь высокопроизводительный компилятор С++?», - спросил я. «Ассемблер? Или мощное средство отладки для устранения множества ошибок в их коде (хи-хи-хи)?»

«Ничего подобного», - ответил менеджер, игнорируя мое гнусное хихиканье. «Они ответили: электронная почта. Средний разработчик Microsoft получает сотню сообщений в день; он живет в электронной почте. Уберите электронную почту, и проект умрет».

Рассказывая этот анекдотический случай, я неспроста в самом начале упомянул 1992 год: эти события происходили до начала эры Internet и World Wide Web. Сотня почтовых сообщений в день потрясла мое воображение; в 1992 году я был безумно счастлив, если получал два или три сообщения в день.
Однако можно представить себе, что если бы такой же вопрос о «наиболее важном средстве» был задан в 1996 году, ответом могло быть «World Wide Web»; по аналогии, «факс» в 1987, «ПК» в 1983, «онлайновый терминал» в 1976 и «мой собственный телефон на рабочем столе» в 1964 году, когда я только начинал свою карьеру программиста.
Очевидно, не следует ожидать, что команда безнадежного проекта сможет ограничиться только одним средством. Большинство команд - даже в «нормальных» проектах - пользуются в своей повседневной работе самыми разнообразными средствами и технологиями. Правда, иногда количество средств становится чересчур большим, технологии - слишком новыми, а иногда нежелательные средства навязываются им некомпетентными менеджерами.
Если вас встревожили эти обстоятельства, позвольте мне уверить вас, что я вовсе не собираюсь агитировать за использование экзотических, суперсовременных средств, которые, телепатически взаимодействуя с программистом, получают из его беспорядочных мыслей хорошо структурированный код. Напротив, я хочу обсудить понятие «минимально необходимого набора средств» для безнадежных проектов. Я хочу также обратить особое внимание на критически важные взаимосвязи между средствами и процессами, особенно поскольку процессы в безнадежном проекте, скорее всего, отличаются от тех, которые используются в организации. И, наконец, я хочу предостеречь от использования в безнадежном проекте совершенно новых средств.

ВВЕДЕНИЕ

Что такое безнадежные проекты? Почему они существуют? По какой причине здравомыслящие люди соглашаются участвовать в таких проектах?

Для многих закаленных ветеранов эти вопросы - чистая риторика. С точки зрения их опыта, каждый проект - это безнадежный проект. Почему так происходит? Поведение больших корпораций зачастую выглядит неразумным. Как отмечает эксперт Richard Sargent, «неразумное поведение корпораций заключается в том, что они делают одно и тоже снова и снова, каждый раз ожидая различных результатов». Почему мы участвуем в таких проектах? Как отмечает эксперт Dave Kleist:

Вряд ли можно где-нибудь увидеть объявление о найме для участия в безнадежном проекте. Какой смысл спрашивать: «Хотите ли вы работать сверхурочно без какой-либо прибавки к зарплате? Привлекает ли вас бесконечная работа по устаревшей технологии и тщетное ожидание участия в каком-нибудь замечательном проекте GUI/DSS/DWH/HTML? Каково будет узнать, что трехзвенная архитектура «клиент-сервер» позволит остальным участникам проекта обойтись без вашей помощи?»

На самом деле, безнадежные проекты редко объявляются таковыми во всеуслышание, и вам придется достаточно долго проработать в нанявшей вас компании, прежде чем удастся обнаружить, что она обладает склонностью плодить безнадежные проекты.

Если вашему коллеге приходится руководить безнадежным проектом, то ему можно посоветовать включить в контракт пункт, позволяющий цивилизованным способом выйти из проекта. Одна из серьезных причин выхода - неспособность высшего руководства воспринимать правдивую информацию о проекте. Принимающий на себя руководство безнадежным проектом должен быть готов к тому, что у него будет практически отсутствовать пространство для маневра в отношении функциональности, затрат или времени.

Если ответы на эти вопросы кажутся вам очевидными, можете смело переходить к следующей главе. Я и сам начинаю думать, что они очевидны, поскольку меня редко спрашивают, что же я понимаю под «безнадежным проектом».

Идентификация «игроков», вовлеченных в проект

Главное, что я хочу здесь отметить, это что ваши шансы на успех в безнадежном проекте будут равны нулю до тех пор, пока участники проектной команды не узнают ключевых «игроков». Некоторые из них производят больше шума, чем другие, некоторые будут друзьями и сторонниками; в то же время некоторые будут крикливыми оппонентами проекта, а другие будут ждать удобного момента, чтобы нанести менеджеру удар в спину. Обо всем этом легко забыть среди тысячи других административных и технических проблем, но это очень важно.

Я убежден, что каждый

участник проекта обязан знать ключевых «игроков» - даже если постоянное взаимодействие с ними входит в обязанность только менеджера проекта. В редких случаях «особо важных» команде удается отгородиться от всего остального мира на время выполнения проекта, но это не типично. На самом деле в современном мире даже такие проекты не могут быть полностью изолированы, поскольку все взаимодействуют друг с другом посредством электронной почты и Internet. В нормальной рабочей обстановке каждый участник проекта взаимодействует со своими коллегами - техническими специалистами, а также с вышестоящим руководством и различными представителями сообщества пользователей. Это неизбежно - мы сталкиваемся с ними в коридоре, кафетерии или в комнате отдыха.

Поэтому, если участник проекта сталкивается с совершенно невинным, на первый взгляд, телефонным звонком, почтовым сообщением или как бы случайным вопросом типа «Как движется проект?», который задает дружелюбным тоном один из менеджеров среднего звена, для участника проекта важно знать, кто к нему обращается - друг или враг, и не содержит ли в связи с этим вопрос политический подтекст. Что бы вы не ответили на такой вопрос, ответ, скорее всего, станет достоянием всей организации, и ничего удивительного, если содержащаяся в нем информация будет утрирована, искажена или скрыта.

Типичными «игроками» в безнадежном проекте являются следующие:

*                    владелец;

*                    заказчик;

*                    акционер;

*                    заинтересованное лицо;

*                    защитник.

Каждая из этих ролей будет обсуждаться ниже.

Кадровые вопросы

Первая отличительная особенность безнадежного проекта - явно выраженный акцент на правильном формировании проектной команды. Сотрудничая с софтверными организациями в разных странах, я сталкивался с четырьмя наиболее общими стратегиями формирования команды безнадежного проекта:

·  нанять суперпрограммистов и предоставить им свободу действий;

·  настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;

·  набрать команду из простых смертных, но при условии, что они будут знать, на что идут;

·  взять любых сотрудников, которых вам дают, и сделать из них команду «невыполнимой миссии».

Первая стратегия выглядит весьма заманчиво, поскольку существует предположение, что суперпрограммисты будут невероятно продуктивны и достаточно изобретательны, чтобы предложить для безнадежного проекта новые решения. С другой стороны, эта стратегия рискованна, поскольку суперпрограммисты обычно являются суперэгоистами и могут не ужиться друг с другом. Кроме того, такая стратегия для многих организаций проблематична, поскольку руководство не желает платить суперпрограммистам такую высокую зарплату, какую они требуют. И даже если это вам по карману, мало шансов на то, что они согласятся работать над безнадежным проектом - ведь они все работают в Netscape или Microsoft или еще где-нибудь, где, по их мнению, имеют место действительно впечатляющие проекты.

Вторая стратегия почти наверняка будет идеальной для большинства организаций, поскольку она не требует привлечения суперпрограммистов; кроме того, такой тип проектной команды воспет телесериалом «Невыполнимая миссия». Однако, если ваша организация предпринимает свой самый первый безнадежный проект, такой команды просто не существует. Если же такие проекты ранее имели место, и они носили характер «самоубийственных», «камикадзе» или «отвратительных» проектов, то их команды в дальнейшем, скорее всего, распались и прекратили свое существование. Таким образом, стратегия сохранения в целости проектной команды успешного

безнадежного проекта должна, как правило, планироваться заранее как корпоративная стратегия, исходя из предположения, что безнадежные проекты могут снова иметь место в будущем (более детально это будет обсуждаться в главе 7).
Третья стратегия по вполне очевидным причинам является наиболее распространенной для тех организаций, в которых мне довелось побывать. В большинстве организаций нет суперпрограммистов и нет тех, кто уцелел в предыдущих безнадежных проектах. Следовательно, команда каждого нового безнадежного проекта комплектуется заново. Участники команды вполне компетентны и, возможно, выше среднего уровня разработчиков в данной организации, однако от них нельзя ожидать сотворения чудес. Для данной стратегии жизненно важно, чтобы участники команды понимали, на что они идут; даже хотя они являются простыми смертными, им придется совершать необычайные подвиги в разработке ПО.
Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет «самоубийственным». Такой тип команды также воспет Голливудом, особенно в таких фильмах, как Чертова Дюжина; их смысл заключается в том, что отверженных и неудачников может сплотить сильный, харизматический лидер и заставить их совершать чудеса, которые все считали невозможными. Все это хорошо, однако Голливуд ничего не рассказывает нам обо всех таких проектах с собранными из неудачников командами, которые закончились провалом. Мне думается, что если вы согласитесь руководить таким проектом (или участвовать в нем), то вас ждет судьба самоубийцы.
Все сказанное приводит нас к центральному вопросу формирования команды безнадежного проекта: до какой степени менеджеру проекта следует настаивать на своем праве принимать кадровые решения? Как было отмечено выше, большинство менеджеров вынуждены примириться с фактом, что они не получат карт-бланш, чтобы нанимать самых талантливых суперпрограммистов в мире; кроме того, существующая в организации политика может не позволить менеджеру по собственной воле, не спрашивая разрешения, привлечь в проект лучших сотрудников организации, поскольку они либо уже участвуют в других важных проектах, либо их с пеной у рта отстаивают другие менеджеры.


Тем не менее, существует один аспект, на котором, по моему убеждению, менеджер должен настаивать как на своем абсолютном праве: это право наложить вето на попытку других руководителей навязать проектной команде неугодного им сотрудника. В противном случае и без того уже высокий уровень риска в проекте может повыситься до недопустимых пределов.
Естественно, такая ситуация порождает разнообразные и весьма неприятные политические баталии. Менеджеру проекта придется, вероятно, выслушивать всякие успокаивающие заверения вроде: «Не надо беспокоиться. У Чарли были некоторые проблемы в предыдущих проектах, но в твоем с ним будет все в порядке» или чрезвычайно льстивые речи наподобие: «Ты такой грандиозный менеджер, что я уверен в твоей способности развернуть Чарли на 180° и получить от него реальную отдачу» или разные призывы проявить лояльность и мужество. Мой совет - держаться до последнего и быть непреклонным в своем праве отвергнуть любого, кто, по вашему мнению, не подходит для проектной команды.
Один из критериев, которые следует принимать во внимание при таких решениях - это вероятность того, что предполагаемый участник команды покинет проект, не дожидаясь его окончания. Разумеется, большинство разработчиков не расскажут вам ничего о своих планах уйти в середине проекта; однако, некоторые из них все же расскажут вам заранее о своих личных намерениях - женитьбе, разводе, планируемой экспедиции в Гималаи и т.д. - которые могут выключить их из работы над проектом. Крайне нежелательно в самом разгаре проекта лишиться некоторых сотрудников и оказаться вынужденным принять в проект новых людей.
В главе 3 я рассматривал варианты действий, которые имеются у менеджера проекта в случае неудачи переговоров: уйти в отставку, обратиться за помощью к более высокому руководству, игнорировать бюрократические правила и принимать свои собственные решения, или определить для себя проект как самоубийственную миссию. Игнорирование правил обычно является наиболее сложным делом, поскольку включение дополнительных участников в проектную команду может быть связано с ограничениями штатного расписания, которое менеджеру проекта неподконтрольно.


С другой стороны, иногда имеется возможность «одолжить» людей из другого проекта или даже нанять по контракту временных исполнителей.
Можно также попытаться изолировать нежелательного участника команды, которого включили в проект против воли менеджера; его можно загрузить какой-нибудь безобидной работой или отправить изучать поведение африканских мух цеце до самого конца проекта. Doug Scott описал еще более хитрый вариант такой стратегии:
Безнадежные проекты к концу зачастую оказываются в таком отчаянном положении, что высшее руководство готово выбросить любые средства, например, чтобы нанять еще 20 человек. В таких случаях я всегда соглашаюсь. Я поручаю этим субъектам менять перегоревшие предохранители у кофейного автомата и другие важнейшие задания, в то время как я занимаюсь своими лучшими сотрудниками. (Среди этих людей, если вдруг повезет, тоже могут оказаться хорошие исполнители.) Затем вы можете способствовать уходу из проекта лишних людей и продолжать настаивать на их замене все новыми и новыми людьми. Например, в одном случае я сократил первоначальный персонал на 20% и, несмотря на это, получил нужный результат, причем гораздо более высокого качества. В этом нет ничего удивительного.

Категории безнадежных проектов

Далеко не все безнадежные проекты одинаковы; помимо ограничений в планах, штатах, бюджете и функциональности, они могут иметь различные масштабы, формы и другие особенности.

Исходя из моего опыта, наиболее важной отличительной характеристикой безнадежного проекта является его масштаб. В зависимости от масштаба можно выделить четыре категории проектов:

n    небольшие проекты - проектная команда включает менее 10 человек, работает в исключительно неблагоприятных условиях и должна завершить проект в срок от 3 до 6 месяцев;

n    средние проекты - проектная команда включает от 20 до 30 человек, протяженность проекта составляет 1-2 года;

n    крупномасштабные проекты - проектная команда включает от 100 до 300 человек, протяженность проекта составляет 3-5 лет;

n    гигантские проекты - в проекте участвует армия разработчиков от 1000 до 2000 человек и более (включающая, как правило, консультантов и соисполнителей), протяженность проекта составляет от 7 до 10 лет.

По различным причинам, небольшие проекты являются наиболее распространенной категорией проектов в тех организациях, где мне удалось побывать, и, к счастью, их шансы на успешное завершение наиболее высоки. Компактная и сплоченная команда не более, чем из 10 человек, скорее всего не распадется, несмотря на все препятствия, в течение короткого шестимесячного периода; в случае высокой степени заинтересованности ее участники, вероятно, будут готовы пожертвовать своей личной жизнью (но не здоровьем!) в течение 3-6 месяцев, поскольку они знают, что бессонные ночи, потерянные выходные и отсроченные отпуска через считанное время закончатся.

Шансы на успешное завершение средних проектов заметно ниже, а для крупномасштабных проектов почти равны нулю. В больших проектных командах более трудно поддерживать чувство сплоченности и высокий командный дух; резко возрастает вероятность, что кого-нибудь переедет грузовик или он станет жертвой одной из многочисленных опасностей, подстерегающих людей в современном обществе.
Причем решающее значение имеет не только количество участников проекта, но и временная протяженность: 80-часовую рабочую неделю в течение 6 месяцев еще можно вытерпеть, но если работать так в течение двух лет, скорее всего, возникнут проблемы. Даже если менеджер способен убедить небольшую группу технарей принести такую жертву, это практически невозможно сделать для больших проектных команд; по статистике, очень вероятно, что некоторые из них женятся или выйдут замуж или найдут себе еще какое-нибудь занятие на стороне.

Что касается гигантских проектов, может показаться непонятным, как они вообще существуют. Возможно, разработка системы, связанной с проектом NASA высадки человека на Луну в 1969 году, может считаться примером успешного завершения безнадежного проекта; однако, подавляющее большинство таких проектов с самого начала обречено на провал.

Естественно, проект может вовсе не задумываться как гигантский, и перспектива его провала может быть совсем не очевидна. Об этом мне недавно напомнил один из участников неудачного совместного проекта Apple и IBM под названием Taligent. Этот проект ранее фигурировал в Apple под кодовым названием Pink, а еще раньше был известен как SNARC (Sexy New Architecture - Новая Сексуальная Архитектура). Самое замечательное заключалось в том, что в любой момент его семилетнего жизненного цикла и в любой из его ипостасей он всегда воспринимался как двухлетний проект. Такое ощущение было в первый день проекта, и в это свято верило большинство менеджеров после семи лет безумной работы, когда проект был прекращен.

К счастью, большинство руководителей высшего звена это понимают, и большинство крупных организаций (а только они могут себе позволить подобные проекты!) стараются их избегать. К сожалению, государственные учреждения все еще пускаются в такие рискованные мероприятия, мотивируя это соображениями «национальной безопасности» или какими-либо другими эмоциональными призывами, которые эффективно действуют на недальновидное высшее руководство, не отдающее себе отчет, что успеха достичь невозможно.



Для того, чтобы охарактеризовать « степень безнадежности» проекта, может оказаться полезным помимо масштаба проекта использовать такой критерий, как количество организаций-пользователей, вовлеченных в проект. Достаточно трудно бывает удовлетворить и одного-единственного пользователя, или однородную группу пользователей из одного подразделения. Трудности, с которыми приходится сталкиваться в проектах масштаба предприятия, на порядок серьезнее хотя бы из-за политических и коммуникационных проблем, связанных с коллективной деятельностью любого рода. В результате системные проекты, связанные с проектами реинжиниринга бизнес-процессов, часто вырождаются в безнадежные - даже если на разработку затрачиваются достаточно скромные ресурсы (технические средства и ПО), политические баталии способны парализовать всю организацию и причиняют проектной команде бесконечную головную боль.

Наконец, нужно различать очень сложные и принципиально невыполнимые проекты. Как отмечает John Boddie [1]:

Сочетания высококвалифицированных технических специалистов, замечательного руководства, выдающихся проектировщиков и интеллигентных пользователей недостаточно, чтобы гарантировать успех сомнительного проекта. На самом деле реально существуют невыполнимые проекты, и все новые и новые начинаются каждый день. Наиболее нереальные проекты могут быть квалифицированы как таковые на самой ранней стадии. По-видимому, существует два основных типа таких проектов: «системы с нечеткими целями» и «очень сложные системы».

До сих пор остались без ответа вопросы, почему вполне разумные организации предпринимают подобные проекты, и почему разумные менеджеры и технические специалисты соглашаются участвовать в таких проектах. Эти вопросы будут рассмотрены ниже.

Концепция «triage»

Слово «triage» происходит от старого французского «trier», что означает «сортировать, классифицировать». American Heritage Dictionary (3-е издание) определяет его следующим образом:

triage - существительное

1.   Процесс распределения раненых по группам в зависимости от их потребности в оказании немедленной медицинской помощи. Применяется на поле боя, в местах катастроф и госпиталях в условиях ограниченных медицинских ресурсов.

2.   Система, используемая при распределении дефицитных товаров (например, продовольствия) среди тех, кто способен получить от этого наибольшую выгоду.

Большинство из нас знакомы с медицинской трактовкой этого термина, однако для безнадежных проектов более подходящим является второе определение: распределение дефицитных ресурсов (самым дефицитным из которых обычно является время) таким образом, чтобы извлечь из этого наибольшую выгоду.

Или, как отметил Stephen Covey в [1], «главное - это быть уверенным в том, что главное - это главное». (В самом деле, можно будет достичь гораздо лучших результатов в проекте, если каждый участник команды вместо увесистого тома методологии разработки ПО получит экземпляр замечательной книги Covey!)

Большинство подходов, связанных с прототипированием и RAD, вполне сочетаются с данной концепцией, а некоторые даже явно на нее ссылаются. Однако, большинство подходов RAD делают акцент только на быстром получении некоторого - какого угодно! - результата (работающего приложения), который можно показать пользователю с целью (а) продемонстрировать, насколько ощутим достигнутый прогресс, и (б) получить замечания, касающиеся функциональности системы и (преимущественно) пользовательского интерфейса. Все это весьма полезно, однако если проектная команда будет расходовать свои ресурсы на  проектирование начальных прототипов с внешне привлекательными, но несущественными возможностями, то как команда, так и пользователь будут зря терять время.

Большинство методологий разработки ПО, независимо от того, базируются ли они на классической «каскадной» модели жизненного цикла, или на более современной «спиральной» модели и прототипировании, имеют незаметное на первый взгляд, но довольно коварное свойство.
Оно выражается следующей фразой: « неважно как, но ко времени завершения проекта мы сделаем все». Возможно, причина этого заключается в том, что в детстве родители запрещали нам выходить из-за обеденного стола, пока мы не оставим пустые

тарелки; в любом случае, невысказанный девиз многих проектных команд - «мы не оставим невыполненным ни одного требования».

Разумеется, это честный девиз, но в безнадежных проектах он почти всегда невыполним. Как я уже отмечал в главе 1, в большинстве безнадежных проектов «официально утвержденные» требования превышают ресурсы проектной команды - в особенности, человеческие и временные ресурсы - на 50-100 процентов. В этой ситуации неопытная команда надеется, что, работая сверхурочно вдвое больше, она сможет как-нибудь покрыть этот дефицит; а циничная команда «самоубийственного» проекта предполагает, что их проект все равно затянется на 50-100 процентов по сравнению с первоначальным планом, как и любой другой проект. Но даже если циничная команда ошибается в этом, она все равно предполагает, что раньше или позже (обычно гораздо

позже!) она в конце концов реализует все функции, которые требовались пользователю.

Один из ключевых моментов в безнадежных проектах состоит в том, что некоторые требования не просто останутся невыполненными до официального срока завершения проекта, но и не будут выполнены никогда. Если предположить, что известное правило «80-20» справедливо, то проектная команда сможет добиться 80 процентов «эффекта» от разработанной системы, реализовав 20 процентов требований к ней - при условии правильного выбора этих 20 процентов. И, поскольку пользователю, как правило, не терпится получить работающую систему задолго до того срока, который проектная команда считает разумным, то он может взять эти готовые 20 процентов, приступить к их использованию и навсегда позабыть об оставшихся 80 процентах функций системы.

Это, конечно, чересчур упрощенный подход, но, тем не менее, почти во всех безнадежных проектах, в которых я принимал участие, приходилось устанавливать приоритеты, разделяя все требования к системе на три категории: «необходимо выполнить», «следует выполнить» и «можно выполнить».


Смысл этих категорий очевиден, и тот факт, что их всего три, предупреждает любые бесполезные дискуссии на тему о приоритетах, например, какой приоритет присвоить конкретному требованию - шестой или седьмой. При такой расстановке приоритетов в проекте очевидная стратегия будет заключаться в следующем: в первую очередь сосредоточиться на требованиях, которые необходимо выполнить; затем, если останется время, сосредоточиться на требованиях, которые следует выполнить; и наконец, если произойдет чудо, заняться  требованиями, которые можно выполнить.

Если не следовать такой стратегии с самого начала проекта, то к концу он окажется в крайне неприятной кризисной ситуации. Чтобы понять, почему это происходит, рассмотрим типичный график проекта, изображенный на рис. 5.1:

Начало проекта                          Середина проекта                                   Кризис      Окончание

Рис. 5.1 График проекта

Когда проект начинается, никто и слушать не желает, что его сроки нереальны - в особенности все пользователи и высшее руководство. У менеджера проекта и участников команды может возникнуть неприятное ощущение, что им предстоит выполнять «самоубийственную» миссию, однако если они - оптимисты, то могут поверить, что проект будет иметь характер «невыполнимой миссии» и впоследствии какое-нибудь чудо придет им на помощь. В этот момент самым важным является то, что конечный срок еще достаточно далеко (через шесть месяцев или год), и никто не хочет всерьез задумываться о невыполнимости поставленных задач.

В самом деле, политическое давление и неопытность проектной команды могут привести к тому, что даже в середине проекта он не будет подвергнут никакой переоценке. Как не смешно это звучит, но проблема может оказаться еще более сложной, если проектная команда использует какую-либо разновидность RAD-подхода, поскольку они, вероятно, уже продемонстрировали пользователю один или более прототипов системы и тем самым поддержали у него иллюзию, что все будет сделано вовремя.


Однако, к этому моменту проектная команда скорее всего начнет понимать, что они пытаются прыгнуть выше головы, и если для менеджера этот безнадежный проект - первый, он будет наивно верить, что высшее руководство и пользователи тоже в конце концов их поймут.

Увы, но обычно этого не происходит. В конце концов наступает кризис, когда пользователи и/или высшее руководство оказываются вынуждены посмотреть в лицо реальности: несмотря на их требования и искренние заверения менеджера проекта, система не будет готова в срок. Обычно это случается за месяц до окончания проекта, иногда за неделю, а иногда и через день после официального окончания! Последствия могут быть различными: это зависит от степени напряженности политических баталий к этому моменту, а также от степени изнуренности и разочарованности менеджера проекта. Тем не менее, при этом, как правило, происходит следующее: высшее руководство приходит к выводу, что во всем виноват менеджер проекта, и в итоге несчастного увольняют (если только он сам уже не уволился!) и ставят нового с требованием «ликвидировать весь этот бардак и сдать систему вовремя».

Новый менеджер может быть как закаленным ветераном из самой организации, так и сторонним консультантом. Иногда случается так, что он в самом деле обнаруживает ряд грубых ошибок, сделанных его предшественником (например, отсутствие планирования вообще или отсутствие рабочих графиков); иногда новый менеджер приходит к выводу, что его предшественник в основном делал все правильно, но не смог избежать участи козла отпущения, когда высшее руководство наконец убедилось, что их первоначальные требования невыполнимы.

Однако, независимо от его оценки, почти не подлежит сомнению, что новый менеджер должен быть готов к следующему: все проектные требования в полном объеме не удастся реализовать в соответствии с первоначально установленным сроком – если бы это было не так, то предыдущего менеджера вряд ли бы уволили. Итак, что же следует предпринять новому менеджеру? Две наиболее очевидные возможности заключаются в следующем:



·  пересмотреть срок окончания проекта;

·  пересмотреть требования к системе.

( Консультант John Boddie предлагает еще одну возможность: менеджер проекта может стать одним из тех, кто добьется официального прекращения проекта, если его действительно невозможно спасти. Новому менеджеру сделать такое гораздо проще, чем его предшественнику, поскольку тот вложил в проект столько личных усилий и эмоций, что ему трудно представить себе, как вообще можно прекратить проект. Boddie дает несколько хороших советов относительно политически приемлемых способов прекращения проекта в своей статье «Calling Doctor Kevorkian», опубликованной в журнале American Programmer, February 1997.)

Первая возможность в принципе вполне допустима, однако в безнадежном проекте практически нереальна. В самом деле, ведь основной причиной, побудившей пользователей настаивать на таких нереальных планах, является неотложная потребность в системе, которая позволила бы им справиться со своими проблемами в бизнесе. Поскольку новый менеджер приходит в проект в тот момент, когда уже близок первоначально установленный срок завершения, высока вероятность того, что пользователи уже строят планы эксплуатации новой системы. Последнее, что им хотелось бы слышать – это то, что проект продлится еще 6-12 месяцев.

Поэтому наиболее часто – и успешно – применяемый прием заключается в определении приоритетов для первоначальных требований. Отметим, что при этом новый менеджер разговаривает с позиции силы – это не его вина, что проект оказался в таком плачевном состоянии; при этом не высказывается вслух, но подразумевается, что руководство и пользователи в первую очередь были настолько глупы, что позволили загнать себя в такой тупик. Новый менеджер может даже поставить свое согласие на участие в проекте в зависимость от успешного окончания переговоров – например, заявив: «Если вы хотите, чтобы я вытащил вас из этой ямы, то должны принять как факт, что мы сможем реализовать в срок только небольшой процент первоначально заданных функций.


Таково реальное положение вещей, согласны вы с ним или нет».

Такое заявление будет прямым и честным, хотя и обескураживающим. Однако при этом уместно задать вопрос: что же делать со всем тем, что было наработано до наступления кризиса и прихода нового менеджера? Ведь команда, вероятно, уже успела много напрограммировать и оттестировать, и может быть, даже успела разработать некоторую документацию и проектные модели. Что же делать со всей этой частично выполненной работой. Наиболее разумный ответ: большую часть придется выбросить.

Такое утверждение может показаться чересчур пессимистичным. В самом деле, почему бы просто не отложить всю частично выполненную работу в сторону и вернуться к ней позднее? В лучшем из миров так оно и происходит; однако это возможно при наличии хороших средств и процессов контроля версий, конфигурационного управления, контроля исходного кода и т.д. – всего того, что отвергается в пылу сражения, когда все усилия команды сосредоточены на получении как можно больших результатов.

Реальная причина, по которой вся эта частично выполненная работа превращается в напрасный труд, заключается в следующем: ни у кого не найдется времени, чтобы снова к ней вернуться. Предположим, что участники проектной команды (теперь уже под руководством нового менеджера, к которому они могут относиться с уважением или нет) способны реализовать только самый минимум необходимых функций, причем работа над проектом обычно доводит их до такого истощения, что половина из них уходит. Кроме того, проект уже так осточертел пользователям, что они не будут приставать с вопросами относительно функций, оставшихся нереализованными; или же, наоборот, они будут настолько довольны минимальным набором функций, что также никогда не потребуют доделать систему до конца. Даже если они это сделают, и даже если проектная команда все еще будет существовать в первоначальном составе, высока вероятность, что в попытках реализовать «скелет» системы в нее будет внесено так много архитектурных изменений, что наполовину законченные компоненты системы (соответствующие второстепенным функциям) никогда больше не будут использоваться.



Заметьте, что мы в данном обсуждении еще ни разу не коснулись таких тем, как структурный анализ, SEI-CMM или любые другие «книжные» методологии и процессы создания ПО. Все, что говорилось по поводу приоритетности, продиктовано исключительно здравым смыслом, что для безнадежных проектов является критически важным. Чтобы эта концепция работала, все акционеры и заинтересованные лица должны принять согласованное решение, какие требования следует отнести к категории «необходимо выполнить», какие к «следует выполнить» и какие к «можно выполнить». Разумеется, если владелец проекта категорически настаивает на том, чтобы все

требования были обязательно выполнены, все дальнейшее обсуждение будет пустой тратой времени. (На самом деле, я бы порекомендовал менеджеру проекта и его команде использовать такое обсуждение в самом начале проекта как лакмусовую бумажку. Если пользователи, владелец проекта, высшее руководство, акционеры и заинтересованные лица не желают принимать такой подход к расстановке приоритетов требований, то наиболее разумным ответным шагом будет выйти из проекта, пока не поздно. В качестве дополнительной лакмусовой бумажки следует предложить пользователям разделить все требования на три равные группы в соответствии с вышеуказанными категориями. Это может уберечь от того, чтобы 90 процентов требований были объявлены критическими.) Если различные акционеры и заинтересованные лица никак не могут достичь консенсуса по поводу отнесения требований к той или иной категории, то проектная команда, пытаясь удовлетворить всех, в результате окажется парализованной из-за отсутствия необходимых ресурсов.

К сожалению, «суровая реальность» такова, что большинство организаций не обладает необходимой дисциплиной, опытом и политической силой, чтобы определить приоритет требований в самом начале проекта. Все, что я описал в предыдущих абзацах, вовсе не является чем-то заумным, и даже самый технологически необразованный менеджер или пользователь в состоянии это понять; в самом деле, этот подход одинаково хорошо подходит для любых проектов с ограниченными ресурсами и недостатком времени.Однако, даже если все хорошо понимают, о чем идет речь, политические баталии вокруг безнадежного проекта могут сделать почти невозможным достижение консенсуса по приемлемым для всех приоритетам. Только когда в проекте наступит кризис, тогда, наконец, противоборствующие стороны придут к соглашению, которое им надо было бы достичь в самом начале проекта.

Из таких мрачных прогнозов можно сделать одно исключение: оно касается организаций, для которых безнадежные проекты являются образом жизни. Разумеется, пользователи и высшее руководство не дураки, и они обычно извлекают уроки из своего опыта, даже если для их усвоения потребуется три или четыре проваленных проекта. Как было отмечено выше, первого менеджера безнадежного проекта обычно губит неспособность расставить приоритеты в начале проекта, в то время как выжившие постепенно до этого доходят. Я еще вернусь к этим вопросам в главе 7.

Концепция «военных игр»

Хотя такие формы обучения выглядят разумными и рациональными, во многих небольших организациях они игнорируются; обучение проводится непосредственно во время работы, разработчикам приходится вникать в тонкости процессов и средств по ходу дела. Еще хуже дело обстоит для менеджеров - как заметил мой приятель Tim Lister, единственное обучение, которое получает большинство менеджеров проектов, заключается в двух словах: «Желаю удачи!»

Разумеется, руководства и аудиторное обучение методам, процессам и средствам управления проектами являются важными и полезными. Однако многие организации считают, что «реальную работу» ничем не заменишь - в самом деле, они вполне сознательно игнорируют аудиторное обучение, полагая, что если вы пройдете через реальный

безнадежный проект, то приобретете опыт, который никогда не получите, занимаясь в классе.

Вместо того, чтобы спорить о достоинствах и недостатках аудиторного и «боевого» обучения, я думаю, что организациям стоит рассмотреть компромиссный вариант: имитацию безнадежного проекта. Аналогия с «имитатором полетов» является более близкой, чем это может показаться на первый взгляд: пилоты авиалиний используют эти имитаторы не только для отработки нормального взлета и посадки, но и действий в различных аварийных ситуациях, что они не могут позволить себе на реальных самолетах. Имитатор полетов дает отличную возможность врезаться в гору, никого при этом не убив. Почему бы менеджеру проекта вместе со всеми участниками команды не направить полет своего проекта в подобие такой горы, чтобы они могли приобрести опыт решения возникших проблем, никого при этом не убивая? И почему бы не потребовать от разработчиков и менеджеров, чтобы они раз в год посещали имитатор безнадежного проекта, как это делают пилоты авиалиний?

Скептики могут возразить, что такой имитатор не в состоянии воспроизвести тот постоянный цейтнот и напряжение, которые имеют место в реальном проекте; пилоты авиалиний, использующие свои имитаторы для отработки действий в аварийных ситуациях, будут убежденно возражать против такой точки зрения.
Однако, если нам действительно

необходимо смоделировать стрессовую ситуацию в софтверном проекте, мы можем позаимствовать хорошо знакомую тактику из военной области: «военные игры». Как отмечают Tom DeMarco и Tim Lister в своей книге Peopleware [1]:

Военные игры помогают вам оценить свои относительные достоинства и недостатки, и помогают организации в целом оценить свои слабые и сильные места.

Наиболее эффективной для участников формой военной игры, позволяющей стимулировать творческий беспорядок, является командная игра.

Таким образом, военная игра по отношению к безнадежным проектам может заключаться в следующем: несколько разных проектных команд получают один и тот же «проектный сценарий» - одинаковые требования, одинаково сжатый временной интервал, одинаковые ресурсы для работы. Или, если культура безнадежных проектов в организации еще не получила надлежащую формализацию и стандартизацию, предоставьте каждой команде возможность использовать любые средства и процессы, которые она захочет - все, что они смогут выпросить, одолжить или украсть в честной игре. Australian Computer Society проводит такие военные игры на своих ежегодных конференциях, начиная с 1994 года, и некоторые местные консалтинговые фирмы используют эти игры как часть своего собственного процесса обучения.

Чтобы организовать в безнадежном проекте военную игру или любой другой «имитатор полетов», необходимо иметь имитационную модель, на которой можно было бы проиграть последствия технических и управленческих решений. Эта концепция обсуждается в моей книге Rise and Resurrection of the American Programmer, и в конце данной главы также приведен ряд ссылок; особенно следует отметить работу Tarek Abdel-Hamid, Stuart Madnick Software Project Dynamics [2], которая описывает полную и детальную имитационную модель для проекта среднего размера.

Имитационная модель может быть в принципе реализована на любом языке программирования, однако для этих целей существуют специализированные языки и средства.


Возможно, наиболее известными из них являются SIMSCRIPT, DYNAMO и GPSS; модель, описанная Abdel-Hamid и Madnick, реализована на DYNAMO (в приложении к книге приведен полный текст программы). Несколько позже появился ряд средств «визуального» моделирования, большинство из которых достаточно дешевы. Из коммерческих продуктов я отдаю предпочтение перечисленным ниже средствам:

·  iThink (Macintosh, Windows). High Performance Systems Inc., Hanover, NH. Тел. 603-643-9636, факс 603-643-9502.

·  VenSim (Windows). Ventana Systems Inc., Belmont, MA. Тел. 617-489-5234, факс 617-489-5316.

·  Professional DYNAMO (Windows). Pugh-Robert Associates, Cambridge, MA. Тел. 617-864-8880, факс 617-864-8884.

·  Extend (Macintosh, Windows). Imagine That, Inc., San Jose, CA. Тел. 408-365-0305, факс 408-629-1251.

Даже при наличии хороших средств и множества опубликованных материалов невозможно отрицать тот факт, что для создания модели, отражающей среду конкретной компании и предоставляющей руководству возможность проигрывать разнообразные сценарии безнадежных проектов, необходимо серьезное отношение к делу и немалые инвестиции. Исходя из своего личного опыта участия с начала 90-х годов в ряде подобных проектов по созданию имитаторов и сценариев военных игр, могу сказать, что на построение адекватной и хорошо настаиваемой модели требуется по крайней мере несколько человеко-месяцев; в качестве дополнительной иллюстрации интересно отметить, что модель, опубликованная в [2], была предметом диссертации Abdel-Hamid.

Это означает, что такая работа лежит за пределами возможностей одного-единственного менеджера проекта, если он хочет использовать такой подход в процессе обучения. Ясно, что эти инвестиции носят стратегический характер, и ими должна заниматься корпорация в целом, причем вряд ли они под силу небольшой компании из десяти человек. Однако для организации-разработчика, в штате которой работают сотни и даже тысячи человек, такие инвестиции будут весьма скромными.


Напомним, о чем идет речь: руководство пытается найти способы утвердить процессы и технологии, которые могли бы обеспечить уверенность в выполнимости планов, бюджетов и функциональности, являющихся вдвое или втрое более претенциозными по сравнению с «нормальными» проектами. Планируя такие радикальные изменения, руководство зачастую готово затратить огромные суммы денег - в некоторых случаях буквально миллионы долларов - на оснащение разработчиков новыми рабочими станциями, средствами визуального программирования и объектно-ориентированными методологиями. Ворчать по поводу затрат шести человеко-месяцев на разработку имитатора просто смешно, а лишать свои проектные команды возможности получить опыт на модели безнадежного проекта перед тем, как рисковать миллионами долларов, просто глупо.

Увы, высшее руководство обычно так не думает. Оно и так негативно относится к затратам времени, усилий и средств на любое обучение, а на затраты, связанные с имитацией безнадежных проектов, посмотрит еще более косо. Это одна из главных причин, по которым культура безнадежных проектов в большинстве крупных организаций никогда не будет успешно внедрена.

Лояльность, отношение, мотивация и вознаграждения

Вопросы отношения к безнадежному проекту обсуждались мной в главе 2; оно является важным элементом политики в проектах такого рода, а также одной из ключевых характеристик команды, которой менеджер проекта должен уделять максимальное внимание. В идеальном случае (с точки зрения менеджера проекта) участники команды должны дать клятву верности и преданности безнадежному проекту; для молодых и неженатых технарей это звучит не так уж дико, как может показаться. С другой стороны, отношение существенно зависит от таких факторов, как длительность проекта. Можно полностью посвятить себя 3-х или 6-ти месячному проекту, но вряд ли это возможно для трехлетнего проекта.

Отношение к проекту также существенно зависит от способности менеджера проекта обеспечить необходимую мотивацию участников команды. До некоторой степени это определяется его харизмой. Некоторые менеджеры способны вызвать у участников команды такую преданность, что они последуют за ним хоть на край земли, не обращая внимания на рискованность проекта; другие же настолько бездарны в этом отношении, что их команды и палец о палец бы не ударили, даже если целью проекта было бы спасение человечества от вторжения пришельцев.

Конечно, можно возразить, что менеджер должен брать в свою команду только тех, кто проявляет высокую

заинтересованность. Можно также утверждать, что данное обсуждение вообще бессмысленно, поскольку большинство разработчиков ПО и так обладает достаточной мотивацией, как отмечают в [1] Tom DeMarco и Tim Lister:

Для любого работника нет ничего более обескураживающего, чем чувствовать, что его собственной мотивации явно недостаточно, и она должна «подкрепляться» его боссом. Достаточно редко приходится прибегать к драконовским мерам, чтобы заставить ваших людей работать; большинство из них любит свою работу.

Существуют, однако, уровни или степени мотивации. Мы можем рассчитывать на то, что разработчик ПО проявит определенную степень мотивации в «нормальном» проекте, но безнадежные проекты требуют более высокой степени, поскольку участникам команды месяцами придется выдерживать изнурительную работу, политическое давление и технические трудности. Кроме того, в начале проекта менеджер сталкивается с такой проблемой, как отсутствие точного знания мотивации каждого из участников команды. Как отмечает Doug Scott:

Вы предполагаете, что менеджер знает, что за людей он получает в свою команду. У меня обычно получалось так, что их включали в команду до того, как я успевал узнать о них что-либо хорошее или плохое.

Во многих случаях основные факторы, влияющие на мотивацию (или демотивацию), сосредоточены вокруг тех процессов, которые происходят в команде (ниже я буду обсуждать эти вопросы более детально). Существует, однако, два конкретных фактора, которые также оказывают значительное воздействие на мотивацию и которые находятся под непосредственным контролем менеджера: вознаграждения за работу и сверхурочное время.

Менталитет «Морского Корпуса» (Marine Corps): Настоящие программисты не нуждаются в сне!

Начинающие компании временами оказываются подверженными синдрому «Морского Корпуса», однако мне гораздо чаще приходилось наблюдать его в консалтинговых организациях вроде EDS и аудиторских фирм Большой Шестерки. Этот синдром может быть отражением особенностей характера основателей фирмы или внутрикорпоративной культуры с самого ее основания. Так, например, обстоит дело с корпоративной культурой Microsoft. По существу, ваш ближайший менеджер просто скажет: «Этот проект ничем не отличается от других, потому что мы всегда так работаем. Это приносит нам успех и мы этим гордимся, черт возьми. Если вас это не устраивает, то вам здесь нечего делать».

Является ли такая позиция цивилизованной, гуманной или вообще верной - это тема для отдельного разговора. Другой вопрос, разумеется, насколько она приносит успех. Важно понять, что она не случайная, а обдуманная. Если вы - революционер или мученик, то можете решить повоевать с корпоративной культурой, но вряд ли у вас при этом хоть что-нибудь получится. Вполне вероятно, что в целом культура, порождаемая безнадежными проектами, будет иметь долговременные негативные последствия, в частности, будут потихоньку увольняться лучшие специалисты, и сама компания может в конце концов развалиться. Однако, когда имеешь дело с конкретным безнадежным проектом, бессмысленно спрашивать, почему у него такие нереальные сроки и бюджет. Как отвечает типичный менеджер такой компании: «Если вас это не устраивает, то вам здесь нечего делать».

Иногда такая позиция компании имеет официальное обоснование - например, «Мы работаем в условиях жесткой конкуренции, и все наши конкуренты не глупее нас. Единственный путь к успеху - работать вдвое интенсивнее». Бывает также, что целью безнадежного проекта является естественный отбор среди самых молодых (слабых) сотрудников, чтобы только выжившие в проекте достигли высокого статуса «Партнера»  или «Вице-президента». Независимо от обоснования, такая позиция обычно выдерживается весьма последовательно, и нет смысла затевать бучу из-за одного-единственного проекта.

Это вовсе не означает, что вам следует согласиться участвовать в таком проекте; из того, что все проекты данной организации - безнадежные, вовсе не следует, что вы сумеете преуспеть или вообще выжить в нем. Ясно только то, что причины, порождающие безнадежные проекты, вполне понятны.

Менталитет первопроходцев у неопытных предпринимателей

Я не просто наблюдал такие проекты со стороны, а сам участвовал в них, причем иногда отвечал за развертывание работ. Когда я писал эту книгу, случилось так, что любая начинающая компания со словом «Java» в своем названии или названии ее продукта, могла получить такой начальный капитал, что не знала, что с ним делать. Но в общем случае начинающие компании недоукомплектованы специалистами и менеджерами, не имеют достаточного финансирования и слепо верят в свои шансы на успех. Так и должно быть, поскольку предусмотрительный и консервативный менеджер никогда не подумает о создании новой компании без тщательного планирования и крупной суммы на банковском счете на случай непредвиденных расходов.

Итак, по определению, высокий процент проектов, связанных с начинающими компаниями - это безнадежные проекты. Большая их часть заканчивается крахом как самих проектов, так и компаний вместе с ними. Се ля ви - такова судьба почти всех начинаний в области высоких технологий (особенно в США). Будучи воспитан в таких условиях, я думаю, что это вполне нормально (моя позиция подкрепляется также тем, что я достаточно удачно завершил несколько таких начинаний). Несомненно, такой сценарий развития событий часто является одним из положительных мотивов для начинания безнадежного проекта, что в дальнейшем будет детально обсуждаться в подразд. 1.4.

Далеко не каждый знаком с культурой и средой начинающих компаний. Если последние 20 лет вы работали в каком-нибудь дряхлеющем государственном учреждении, окруженные пишущими на КОБОЛе зомби (то же самое можно сказать и про большинство банков, страховых и телефонных компаний), и буквально только что вследствие даунсайзинга, аутсорсинга или реинжиниринга оказались на работе в начинающей фирме, вряд ли у вас имеются какие-либо идеи относительно вашей перспективы. Безнадежные проекты имеют место и в больших корпорациях, но там в штат проекта, как правило, включаются разные лишние люди из «Ночи Живых Мертвецов». В безнадежных проектах начинающих компаний обстановка совершенно другая, она подобна напору адреналина.

В то же время начинающие компании часто страдают разновидностью наивного оптимизма, о котором я уже говорил. Многие начинающие компании основываются технарями-сверхэнтузиастами, убежденными, что их новая технология сделает их богаче Билла Гейтса; другие основываются гениями маркетинга, убежденными, что смогут продавать доверчивым эскимосам холодильники с возможностями Internet. Оптимизм важен для любого начинающего предприятия, его успех может зависеть от деятельности, которой ранее никто не занимался. Но даже самая агрессивная и оптимистичная компания вынуждена подчиняться основным законам физики и математики. Если вы оказались вовлеченными в безнадежный проект начинающей компании, проверьте, существует ли какой-нибудь план достижения успеха, или все это предприятие - воздушный замок.

Месть

Месть может показаться не слишком разумным объяснением участия в безнадежном проекте, но, тем не менее, это обстоит именно так. Успех безнадежного проекта может оказаться достаточным для того, чтобы выбить власть из рук некомпетентного вице-президента компании, или утереть нос критиканам, которые все время уверяли вас, что в рамках ограниченных сроков и бюджета такой проект выполнить немыслимо. Месть - это весьма сильное чувство, и оно играет особенную роль на уровне высшего руководства в крупных организациях, где обиды запоминаются на всю жизнь, и хитрые политики могут месяцами и годами дожидаться возможности отомстить своим противникам.

Месть может быть очень мощным личным мотиватором, но обычно не так просто внушить это чувство всей проектной команде. Если это случается, то возникает ситуация, когда проектная команда перестает видеть «официальную» цель разработки, которая была запланирована в проекте - их первым и высшим приоритетом становится месть.

Если вашим личным мотивом является месть, то я могу сказать только одно - это ваши личные проблемы. Но если вы собираетесь участвовать в проекте, в котором менеджер или вся команда из чувства мести готовы согласиться с совершенно неразумными для «нормального» проекта планом и бюджетом, то следует быть особенно осмотрительным. «Вице-президент - кретин», - может сказать вам менеджер проекта, - «и если мы завершим этот проект за шесть месяцев, то он будет выглядеть таким дураком перед Советом Директоров, что ему придется подать в отставку!» Хорошо, все это замечательно - может быть, вице-президент и в самом деле кретин. Однако, стоит ли ради его отставки жертвовать своей личной жизнью в течение двух ближайших лет? В конце концов, следующий вице-президент может оказаться еще большим кретином, чем прежний.

С другой стороны, если в глазах всех вице-президент выглядит воплощением темных сил, а менеджер проекта предстает этаким героем-освободителем, то это придает безнадежному проекту дополнительные силы. В этом случае весь проект предстает в виде битвы Господа с Дьяволом, и этого достаточно, чтобы люди добровольно принесли огромные жертвы на алтарь проекта.

Минимально необходимый набор средств

В предыдущей главе я настоятельно рекомендовал устанавливать приоритеты для пользовательских требований. Такой же подход можно использовать по отношению к средствам и технологии: существуют средства, которые «необходимо использовать», «следует использовать», и огромное разнообразие средств, которые «можно использовать». Этот подход разумно применить в самом начале проекта, и тому есть ряд причин.

Наиболее очевидная причина лежит в плоскости экономики. Даже если средства хорошо работают и все знакомы с ними, их приобретение может стоить слишком дорого. Кроме того, на их получение может уйти слишком много времени - процесс приобретения в условиях обычной корпоративной бюрократии может завершиться уже после окончания проекта. Для большинства безнадежных проектов следует сосредоточиться на небольшом количестве критически важных средств, и затем убедить высшее руководство (или соответствующую службу) в необходимости их приобретения.

С другой стороны, предположим, что команда работает в крупной корпорации, имеющей в своем распоряжении сотни различных средств, приобретавшихся в течение целого ряда лет. Следует ли их все использовать? Конечно, нет! Даже если все они работают, те умственные усилия, которые необходимо приложить, чтобы запомнить, как

ими пользоваться, а также дополнительные усилия для обеспечения их совместной работы обычно сводят на нет всю выгоду. Можно провести аналогию с командой альпинистов, которые собираются штурмовать вершину и пытаются решить, какое снаряжение им использовать. Существуют вещи, которые необходимы (палатки, питьевая вода и т.д.); и, если маршрут не слишком сложный, можно взять с собой некоторые новомодные приспособления, о которых они прочли в своем любимом альпинистском журнале. Однако, если они собираются штурмовать Эверест, им не обойтись без помощи ослов-носильщиков или местных жителей, иначе они будут не в состоянии тащить на спине по 300 фунтов снаряжения на человека.

Команда безнадежного проекта должна самостоятельно, независимо от принятых в организации стандартов, решить, какие средства являются необходимыми, а без каких можно обойтись.
Меня очень удивил подход ряда организаций, в которых я побывал, к безнадежным проектам, когда менеджер проекта с грустью говорил, что все проекты заставляют разрабатывать на КОБОЛе (или, в других организациях, в таком качестве может фигурировать Visual Basic или Oracle или что-нибудь еще ...), даже если эта технология совершенно не подходит для его проекта. Чепуха! Пошлите их подальше! Используйте те средства и технологии, в которых есть смысл! В противном случае это можно сравнить с ситуацией, когда кто-либо говорит руководителю команды альпинистов, собирающейся штурмовать Эверест: «Наш комитет решил, что ваша проектная команда должна взять подробную схему Нью-Йоркского метро, поскольку в большинстве проектов ее сочли очень полезной». (Иногда в это дело вмешивается своими грязными руками политика. В прошлом году мне приходилось видеть несчастных сотрудников IBM, вынужденных использовать Lotus Freelance вместо PowerPoint и Lotus 1-2-3 вместо Excel, поскольку у них не было никакого желания ввязываться в противном случае в политические баталии. Аналогично, я не уверен, что хотел бы оказаться в проектной команде Microsoft, которая решила бы примерно в августе 1996 года использовать Netscape Navigator вместо Internet Explorer.)

Я думаю, очень важно, чтобы участники команды пришли к единому мнению относительно используемых в проекте средств, иначе наступит хаос. Разумеется, это утверждение не следует понимать слишком буквально; оно не означает, что все участники команды должны обязательно использовать один и тот же текстовый процессор для подготовки своих документов, однако, скорее всего, важно использовать один и тот же компилятор С++. Одна из проблем, связанных с безнадежными проектами, заключается в том, что разработчики ПО считают допустимой полную анархию на индивидуальном уровне (например, если им хочется использовать никому не известный компилятор С++, который они переписали с университетского Web-сайта, то они считают, что это их неотъемлемое право). Это совсем не так: неотъемлемым правом обладает команда, и менеджер проекта должен неуклонно проводить его в жизнь во всех ситуациях, когда несовместимые средства могут привести к значительным разногласиям.



Это означает, что, пока участники команды не поработают вместе на нескольких безнадежных проектах, они не придут к единому мнению относительно «минимального» набора средств. После того, как достигнут консенсус по поводу набора средств, команда может обсудить средства, которыми «следует» пользоваться, при этом проблемы заключаются в том, чтобы добиться согласия в команде и получить разрешение руководства на приобретение новых средств. Если после этого еще останется время и желание, то можно обсудить качества неопределенного количества средств, которые «можно использовать» и в которых заинтересованы различные участники команды.

Выше я высказал мысль, что менеджер проекта должен быть готов к тому, чтобы настаивать на достижении консенсуса; в самом деле, это может быть одним из критериев, используемых менеджером для выбора потенциальных участников команды. Отметим, что то же самое можно сказать относительно процессов, которые мы обсуждали в главе 5. И, как мы увидим далее, это имеет еще большее значение, поскольку средства и процессы тесно связаны друг с другом.

Помня обо всех высказанных предостережениях, практически невозможно для такого «дилетанта», как я, с ходу перечислить все средства, рекомендуемые для безнадежного проекта. Когда задают такой вопрос, мой ответ - «это зависит от ... » - обычен для присущего консультантам и приводящего к замешательству стремления уходить от прямого ответа на любой вопрос. Итак, поскольку вы крепко запомнили мои предыдущие советы, далее приводится перечень средств, которые мне хотелось бы видеть в безнадежных проектах:

·  Электронная почта, ПО для групповой работы, средства Internet/Web - так же, как и в эпизоде с Microsoft, эти средства находятся в начале моего списка. Причина заключается в следующем: электронные средства общения и взаимодействия являются не только гораздо более эффективным средством коммуникации, чем записки и факсы, но они также способствуют координации и сотрудничеству. Лично мне безразлично, какие именно средства использовать: Microsoft Mail, cc:Mail, Netscape Collabra или Lotus Notes; важно только, чтобы вся команда работала в сети хранила общие проектные данные также в сети.


Помимо этого, существуют и другие хорошие новые средства, но они скорее относятся к категории «следует использовать», а не «необходимо использовать».

·  Средства прототипирования/быстрой разработки приложений (RAD) - как отмечалось ранее, почти все безнадежные проекты используют в той или иной степени прототипирование и пошаговую разработку; следовательно, им необходимы соответствующие инструментальные средства. Сегодня не так просто отыскать популярную среду разработки приложений, которая заявляла бы о себе иначе, чем среда RAD, и большинство таких средств обладают визуальным пользовательским интерфейсом, выполненным в стиле «drag and drop», облегчающим и ускоряющим процесс разработки. Я не берусь давать общие рекомендации, какие средства лучше использовать - Delphi, C++, Visual Basic или Smalltalk (или множество других). Существенно важно только одно: чтобы вся команда использовала один и тот же набор средств от одного и того же поставщика. Если одна часть команды использует VisualWorks (ParkPlace Digitalk), а другая - VisualAge for Smalltalk (IBM), то это явно глупо, хотя и допустимо с точки зрения технологии.

·  Средства управления конфигурацией (CM)/контроля версий - некоторые из моих коллег полагают, что они должны быть на первом месте в списке. John Boddie, автор Crunch Mode, высказал такое мнение:

Я хотел бы отметить, что средства управления конфигурацией действительно «необходимо использовать». По мере разработки будет возникать множество нестыковок между отдельными частями проекта, поэтому менеджер и команда нуждаются в средствах, позволяющих фиксировать и отслеживать версии системы по мере продвижения к завершению проекта.

·  Очевидно, использование средств CM может принести гораздо больше пользы, если они будут интегрированы со средствами разработки приложений.  Например, SourceSafe (Microsoft) может быть, а может и не быть самым лучшим средством контроля версий ПО, однако тот факт, что оно тесно интегрировано с Visual Basic, является весомым аргументом в его пользу.


Аналогично, многие другие средства разработки приложений интегрированы с PVCS (InterSolv), ENY/Developer (IBM) или другими подобными средствами CM.

·  Средства тестирования и отладки - многие из нас автоматически включают эти средства в «базовый» набор средств разработки приложений, позволяющих создавать, компилировать и выполнять код. Однако, когда мы перешли от онлайновых приложений на мэйнфреймах к клиент-серверным системам с графическим пользовательским интерфейсом, то постепенно поняли, что необходим совершенно новый набор средств тестирования; в то же время средства таких поставщиков, как SQA и Mercury Interactive, еще не получили достаточного распространения в тех организациях, где мне удалось побывать. Аналогично, проектные команды, разрабатывающие приложения в среде Internet, скорее всего нуждаются в полностью новых средствах тестирования и отладки.

·  Средства управления проектом (оценка, планирование, PERT/GANTT и т.д.) - обычно их считают средствами менеджера проекта и, наверное, так оно и есть; возможно, только менеджеру проекта приходится каждый день пересчитывать «критический путь». Однако, к той же категории следует отнести такие средства оценки, как ESTIMACS (Computer Associates, автор - Howard Rubin), CHECKPOINT (Software Productivity Research)

и SLIM (Quantitative Software Management). Эти средства, по моему мнению, являются достаточно важными, поскольку они позволяют в ходе выполнения проекта динамически пересматривать планы и сроки.

·  Наборы повторно используемых компонент -  если проектная команда знакома с концепцией повторного использования ПО, и если она рассматривает ее как стратегическое оружие, позволяющее достичь высокого уровня продуктивности разработки, то набор повторно используемых компонент должен быть в списке тех средств, которые «необходимо использовать». Это может быть набор компонент VBX для Visual Basic, библиотека классов ParkPlace Digitalk Smalltalk или библиотека классов MFC для C++ (Microsoft); разумеется, можно также использовать компоненты, разработанные другими проектными командами в организации.


Выбор компонент обычно зависит от используемого языка программирования, и это еще одна проблема, нуждающаяся в выработке единого подхода со стороны проектной команды.

·  CASE-средства для анализа/проектирования - некоторые проектные команды рассматривают CASE-средства как «костыли» для новичков, а другие считают их не менее важными, чем текстовые процессоры. Я сам отдаю предпочтение простым, недорогим и гибким CASE-средствам; кроме того, я избегаю рекомендовать какой-либо конкретный продукт или поставщика, поскольку самым разумным ответом на вопрос, какие CASE-средства использовать, будет «это зависит от ...». В самом деле, как заметил Doug Scott, может вообще не понадобиться никакой технологии:

Самое лучшее средство - это большая диаграмма, приколотая к стене. Она может содержать (частично полные) E/R-диаграамы, или потоки данных, или что-нибудь другое. Важно то, что она служит отправной точкой для обсуждения проектных решений и почти не требует затрат.

Как я говорил ранее, самая большая проблема, связанная с CASE-средствами, заключается в том, что они поддерживают (а иногда навязывают) определенную методологию, которую проектная команда не понимает и не желает использовать.

Наилучшая практика и наихудшая практика

Не один раз уже в этой книге я предупреждал об опасностях, связанных с вмешательством блюстителей методологии и попытками насильно внедрить в практику проектной команды лишенные гибкости методологии или процессы создания ПО. То же самое касается внешних консультантов, гуру, знахарей, целителей, заклинателей змей и книг. Даже этой книги: если то, что я рекомендую, не находит должного понимания, и проектная команда не испытывает по этому поводу особого энтузиазма, то такую рекомендацию лучше проигнорировать!

Однако это особенно справедливо по отношению к методологиям и процессам создания ПО. Вместо того, чтобы следовать рекомендуемой кем-либо практике – или, что еще хуже, практике, навязываемой сверху руководством и комитетами по методологии, которые обычно сами не знают то, о чем они говорят – гораздо лучше следовать практике, которую сама команда считает «наилучшей» в данных обстоятельствах. В этом заключается существо подхода «наилучшей практики», который стал популярным в последние пару лет: основного подхода, принятого на вооружение организациями-разработчиками ПО, признанного удачным настоящими разработчиками.

К сожалению, у команд безнадежных проектов практика такого рода зачастую отсутствует, поскольку их проект, как правило, рассматривается как первый проект такого рода в организации. Если он даже не первый, то все равно рассматривается как исключение – поэтому никто не побеспокоился заранее составить перечень хорошо и плохо зарекомендовавших себя методов. Что еще хуже, большой процент безнадежных проектов заканчивается провалом (иначе они не назывались бы «смертельными маршами»!). Таким образом, люди, которые могли бы помочь полезными советами в последующих безнадежных проектах, уже ушли, были уволены, покончили жизнь самоубийством, заработали нервное расстройство или превратились в закоренелых циников.

Если вы в самом деле начинаете первый в организации безнадежный проект, то, вероятно, самое лучшее, что вы можете сделать – это документально фиксировать все реально работающие процессы, которые могли бы пригодиться в последующих безнадежных проектах.
·  Формальное управление рисками – я буду обсуждать его позже в данной главе.

·  Согласованные интерфейсы – аппаратные интерфейсы, программные интерфейсы и интерфейсы между вашей системой и другими внешними системами.

·  Экспертные оценки – экспертизы, проверки, сквозной контроль. Это весьма распространенная и понятная практика, однако в безнадежных проектах от нее зачастую отказываются, поскольку считают, что это затормозит работу. В принципе, большинство из нас понимает полезность таких экспертиз, но в экстремальных условиях безнадежных проектов каждый успевает только делать свое дело, и ему не до того, чтобы показывать свою работу остальным участникам команды.

·  Планирование и управление, основанное на метриках – речь идет о том, что в основу наших планов и оценок должны быть положены данные, накопленные в предыдущих проектах. Однако, как было сказано выше, предыдущих безнадежных проектов может просто не быть, а если даже они и были, маловероятно, чтобы кто-нибудь позаботился записать какие-либо полезные данные (кроме подсчета потерь, понесенных командой). Все же, если имеются в распоряжении какие-либо данные, полученные в «нормальных» проектах, их можно было бы использовать для выверки оценок, сделанных в безнадежном проекте – хотя бы для того, чтобы убедиться в их безумной оптимистичности!

·  Бинарная оценка качества по результатам этапов – другими словами, вместо того, чтобы заниматься подведением итогов каждые три месяца, во время которых команда рапортует, что она написала 97 процентов кода, следует подводить промежуточные итоги еженедельно, или даже ежедневно, фиксируя достигнутые результаты с помощью «бинарных» признаков. Одним из способов выполнения этого является стратегия «ежедневного завершения проекта», которая обсуждается в следующем разделе.

·  Свободный доступ к информации о проектных планах и фактических результатах – это согласуется с моими рекомендациями в предыдущих главах. Безнадежный проект будет испытывать достаточно большие трудности, если менеджер будет скрывать от остальной команды информацию о состоянии проекта.



·  Фиксация дефектов в соответствии с заданными показателями качества – одна из идей данного проекта заключается в том, что дефекты идентифицируются, фиксируются и устраняются на ранних

стадиях процесса разработки. Это позволяет не только точно установить уровень дефектности в разработанной системе, но и устранять дефекты в тот момент, когда стоимость их устранения относительно невелика, а не дожидаться стадии тестирования системы.

·  Конфигурационное управление – как бы оно не называлось (контроль версий, контроль исходных кодов, или как-нибудь еще), конфигурационное управление обычно рассматривается как важная практическая составляющая проектов, протекающих в экстремальных условиях.

·  Ответственность и подотчетность руководства перед сотрудниками – увы, но в большинстве безнадежных проектов этому моменту не уделяется достаточно внимания; как было отмечено выше, многие безнадежные проекты относятся к типу «самоубийственных» или «камикадзе».

Одно из наиболее значительных достижений данного проекта министерства обороны – это понятие наихудшей практики; особенно хорошо оно применимо к безнадежным проектам, где зачастую бывает более важно предотвращать катастрофы, а не заниматься поисками наилучшего решения проблем. Список таких практик приведен ниже:

·  Не следует ожидать более чем 10-процентного сокращения сроков по сравнению со среднестатистической нормой для аналогичных проектов – разумеется, если вы действительно в это верите, то не следует даже и начинать безнадежный проект!

·  Не пытайтесь использовать новую технологию как средство для сокращения сроков

– у вас будет и без того достаточно проблем кроме отлавливания ошибок в бета-версиях новых средств и технологий, добытых у знакомого поставщика. Более детально этот вопрос будет обсуждаться в главе 6.

·  Не навязывайте заказчику решения, специфичные только для него – полезный совет для любого проекта.

·  Не следует заниматься поиском панацей – об этом стоит вспомнить, когда ваше руководство (сразу же после визита очередного настойчивого поставщика!) предлагает использовать для «спасения» проекта какое-нибудь «поражающее воображение» средство или методологию разработки.



·  Не упускайте возможность удалить из критического пути те элементы, которые находятся вне сферы вашего контроля – если ваша проектная команда не в состоянии их контролировать, то иметь такие элементы на критическом пути означает повышенную степень риска. Это относится к таким вещам, как инструментальные средства поставщика, оборудование, программные продукты и другие компоненты, поступающие от внешних поставщиков. Это касается также вещественных результатов деятельности и политических решений акционеров и заинтересованных лиц, имеющих отношение к проекту.

·  Не следует ожидать точной оценки состояния проекта от чисто формальных оценок, выполненных множеством чересчур активных и некомпетентных критиков – проектная команда не должна об этом беспокоиться, поскольку она уже знает, что такие сеансы оценки представляют собой политические ритуалы. Этот совет предназначен скорее для руководителей высокого уровня, которые наблюдают за безнадежным проектом с безопасного расстояния, пытаясь при этом определить, в каком состоянии он находится.

·  Не следует ожидать, что в результате более чем 10-процентного отставания от плана удастся избежать более чем 10-процентного снижения функциональности разработанного ПО – эта рекомендация является критически важной для команды безнадежного проекта, поскольку вероятность отставания от плана более чем на 10 процентов во время выполнения проекта достаточно высока. В самом деле, для безнадежного проекта опасно даже 10-процентное запаздывание, поскольку команда, вероятно, уже так много работает сверхурочно, что у них просто не хватит сил, чтобы тратить каждый день на работу еще на 10 процентов больше времени. Однако, самым главным в этой рекомендации министерства обороны является следующее: менеджер проекта должен помнить, что зависимость между временем работы команды и функциональностью ПО не является линейной.

В течение прошлого года на своих семинарах в разных концах света я задал нескольким сотням менеджеров проектов два вопроса: «Если ваш коллега предпринимает свой первый безнадежный проект, какой единственный совет для достижения успеха вы могли бы ему дать? И что единственное вы бы посоветовали ему не делать?» Я был весьма заинтригован, обнаружив, что никто даже не упомянул средства или технологии в качестве «одной самой важной вещи»; не были также упомянуты и формальные методологии и методы, такие, как структурный анализ или объектно-ориентированное проектирование.


Некоторые рекомендовали стратегии управления человеческими ресурсами (например, «наймите хороших исполнителей» и «добейтесь, чтобы команда была действительно нацелена на успех»), однако почти все рекомендации были направлены на проведение переговоров, контроль за выполненным объемом работ (которому хорошо способствует обсуждавшееся ранее определение приоритетов требований) и управление рисками (о котором речь пойдет ниже).

Еще один последний подход, заимствованный из упоминавшегося проекта министерства обороны, может оказаться полезным для безнадежных проектов, хотя он в большей степени предназначен для менеджеров за пределами проекта, чем для менеджера самого проекта и участников его команды. Он называется «тест на алкоголь»: какие вопросы следует задать команде безнадежного проекта, чтобы быстро определить, не утратили ли они чувство реальности до такой степени, что проект пора прекращать? Вопросы такого рода часто задаются консультантами, которых высшее руководство уполномочило проанализировать состояние проекта. Я сам был в таком положении, и я обычно могу заключить, что проект находится в плачевном положении, когда вижу остекленевший взгляд менеджера проекта, который напоминает взгляд лани, застигнутой светом фар приближающегося автомобиля.

Иногда безобидный вопрос типа «знаете ли вы, кто является вашим заказчиком?» приводит всех в полное замешательство, и в гробовом молчании каждый озадаченно смотрит на своего соседа, а потом все внимательно вглядываются в пол. Если вас интересуют некоторые другие вопросы «теста на алкоголь», ниже приведен их список:

·  Используете ли вы (и поддерживаете в актуальном состоянии) сетевой график работ?

·  Располагаете ли вы утвержденным планом и бюджетом?

·  Знаете ли вы, за разработку какого ПО несете ответственность?

·  Можете ли вы перечислить первые десять проектных рисков?

·  Известен ли вам процент сжатия вашего плана по сравнению с нормальным?

·  Каков оценочный объем вашего ПО? Каким образом он вычисляется?



·  Известна ли вам та часть внешних интерфейсов, которая находится вне вашего контроля?

·  Достаточными ли знаниями о предметной области располагают ваши специалисты?

Как было отмечено выше, «тест на алкоголь» проводится в том случае, когда кто-либо в организации – как правило, не

менеджер проекта, а кто-либо, стоящий на существенно более высоком уровне иерархии – почувствует, что проект идет не так, как надо. Для того, чтобы выжить в политических схватках, менеджеру проекта и всей команде периодически следует задавать друг другу подобные вопросы. Менеджеру проекта вообще все время следует быть бдительным по отношению к другим признакам, говорящим о тревожном состоянии проекта, даже если в соответствии с официальным графиком PERT все выглядит как положено. Такими признаками могут быть:

·  Уход ключевых участников команды – это может произойти по ряду причин, однако важно вовремя почувствовать, не утратили ли участники проекта веру в свою способность завершить проект. Если начнут уходить ключевые разработчики, другие могут последовать за ними.

·  «Фактор обратной корреляции Дильберта» – чем больше карикатур Дильберта появляется на дверях в офисе и на досках объявлений, тем хуже идут дела в проекте.

·  Чрезмерный юмор висельников – если проектная команда начнет носить в офисе черные рубашки и проигрывать на аудиосистеме погребальные мелодии, значит, что-то идет не так.

·  Проекту даются новые имена, например, «Проект Титаник» – другая разновидность юмора висельников, которая, однако, является более серьезным признаком того, что проектная команда утратила веру в успех, чувство причастности к проекту и вообще какой-либо интерес к работе.

·  Зловещее молчание конечных пользователей и высшего руководства, которые обычно каждый день интересовались ходом проекта – к тому моменту, когда вы это осознаете, может оказаться слишком поздно, чтобы наверстать упущенное, однако у вас может быть по крайней мере несколько дней, чтобы обновить свое резюме.

·  Бестолковая суета – бурная деятельность при отсутствии видимых результатов. Выходом из такой ситуации может быть использование идеи «мини-этапов» и стратегии «ежедневной сборки проекта».

Наивность и оптимизм молодости

Наша индустрия достаточно молода, и многие из наиболее претенциозных и вызывающих проектов выполняются и возглавляются людьми, которым нет еще и 30 лет. Для безнадежного проекта не ничего необычного, если все технические специалисты в проектной команде моложе 25 лет. Они напоминают мне пилотов-истребителей, призванных в Военно-Воздушные Силы во время Второй Мировой и вьетнамской войн: такие же молодые идеалисты, абсолютно убежденные, что они могут все. Как отметил David Maxwell:

Проекты подобны вступлению в брак. Поначалу мы наивны и полны надежд, однако со временем реальность вынуждает нас умерить свои надежды. Существует много причин, не имеющих отношения к логике, которые побуждают людей вступать в брак, и то же самое можно сказать о проектах. Поскольку молодые менеджеры и разработчики изо всех сил стремятся проявить себя и проверить свои силы, безнадежные проекты будут начинаться снова и снова. Мой личный опыт говорит о том, что одни и те же ошибки могут повторяться много раз.

Разумеется, огромная самоуверенность выручает такие команды в ситуациях, когда обычные проектные команды терпят поражение. Тот факт, что наиболее успешные продукты - от Lotus 1-2-3 до Netscape Navigator - были разработаны небольшими командами в условиях, неприемлемых для нормальных людей, уже стал фольклором в нашей индустрии. Когда такие проекты заканчиваются успешно, они приносят проектной команде известность и славу; даже когда они проваливаются, то зачастую позволяют всем участникам извлечь для себя важные уроки (хотя для организации в целом последствия могут быть катастрофическими!).

Важно отметить, что наивность и оптимизм молодости обычно сочетаются с огромной энергией, целеустремленностью и отсутствием таких помех, как семейные отношения. Безусловно, все это не является прерогативой одной лишь только молодости, однако гораздо чаще можно встретить 22-летнего программиста, который готов и жаждет участвовать в безнадежном проекте со 100-часовой рабочей неделей в течение года или двух, чем 35-летнего женатого программиста с двумя детьми и весьма умеренной склонностью к покорению горных вершин. Молодой программист, готовый участвовать в безнадежном проекте, а также относительно молодой менеджер проекта, дающий оптимистические обещания начальству, как бы утверждают: «Разумеется, мы обеспечим успех этого проекта и сокрушим все препятствия на своем пути!»

Мне не хотелось бы высказывать какое-либо серьезное суждение по этому поводу, потому что это бессмысленно. Как уже было отмечено выше, наша индустрия привлекает молодых, и я не думаю, что ситуация изменится в ближайшие несколько лет. Я также не думаю, что молодежь может лишиться своего оптимизма, энергии и способности сосредотачиваться на решении проблем. Что касается их наивности ..., ничего не поделаешь, эта болезнь проходит только с возрастом.

Наивные представления маркетинговых служб, высшего руководства, менеджеров проекта и др.

Наивность часто связана с неопытностью, поэтому не удивительно, когда люди, не имеющие представления о трудоемкости и длительности создания нужной им системы, принимают нереалистичные решения. В самом худшем варианте это может привести к тому, что мой коллега Том ДеМарко называет «истерическим оптимизмом», когда все поголовно в организации бездумно верят, что сложный проект, ничего подобного которому они никогда не делали, можно как-нибудь сделать за девять месяцев, хотя реалистичная оценка его продолжительности - три года.

 Наивность и оптимизм, как мы видим, присущи также и техническим специалистам. Однако, вообразим на минуту, что именно ваши менеджер, отдел маркетинга или конечный пользователь несут ответственность за чересчур оптимистичный план или бюджет. Как они отреагируют, когда в конечном счете поймут чрезмерную оптимистичность первоначальных оценок? Захотят ли они продлить срок разработки, увеличить бюджет и спокойно согласиться с тем, что все не так просто, как они себе представляли? Скажут ли они вам и вашим коллегам спасибо за героические усилия? Если это так, то самым важным для вас может оказаться заменить классическую каскадную модель жизненного цикла ПО на подход RAD, чтобы сразу после реализации первой версии прототипа системы можно было получить реалистичную оценку плана, бюджета и ресурсов.

Тем не менее, в большинстве безнадежных проектов такого рода рациональная коррекция курса в середине проекта невозможна. Так может случиться, например, если главный менеджер наивно пообещал что-либо заказчику и считает, что дело чести - выполнять свое обязательство, несмотря ни на что. Самое худшее - когда человек, принимающий на себя обязательства, вполне осознает происходящее (в особенности такие дела всплывают наружу, когда после празднования по поводу заключения нового контракта с очередным доверчивым пользователем менеджер по маркетингу признается менеджеру проекта за кружкой пива: «Послушай, мы никогда бы не заключили этот контракт, если бы сказали клиенту, сколько времени потребует проект на самом деле; в конце концов, мы знали, что наши конкуренты тоже придут с заманчивыми предложениями.
И, кроме всего прочего, твои ребята всегда раздувают планы и бюджеты, не так ли?»).

На последнее замечание особенно трудно возразить, если оно исходит от вашего босса или менеджера, который выше вас на два или три уровня. Предполагается, что вся оценка планов и бюджета является предметом переговоров (которые будут детально обсуждаться в главе 3). В то же время ваш менеджер ведет себя в некоторой степени наивно, если он, будучи недовольным «раздуванием» плана и бюджета, полагает, что вы сможете завершить проект в смехотворно короткий срок, принятый без вашего ведома. Такой срок может быть установлен и под влиянием менталитета «Морского Корпуса», который обсуждается в подразд. 1.3.5. Наконец, принятие отделом маркетинга смехотворного плана и бюджета может быть результатом политических игр, о которых говорилось ранее; менеджера по маркетингу вряд ли особенно волнует реалистичность предлагаемого им плана и бюджета, поскольку его основная цель - получить комиссионное вознаграждение или доставить удовольствие своему боссу.

Представим себе, что наш безнадежный проект - это результат «наивности в чистом виде», свободной от политики или каких-либо других злонамеренных воздействий. Главный вопрос заключается в следующем: что делать? Как было отмечено выше, определяющим фактором является вероятность того, что лица, принимающие решения, пересмотрят свои бюджеты и планы, когда станет очевидной невыполнимость взятых на себя первоначально обязательств. Трудно предсказать заранее, произойдет это или нет, однако небесполезно было бы оглядеться вокруг себя и посмотреть, что же происходит в подобной ситуации с другими безнадежными проектами. (Если это первый такой проект, который когда-либо осуществлялся в вашей компании, значит, вы в самом деле - белое пятно на карте!)

Если у вас есть твердая уверенность, основанная на вашем политическом чутье или опыте предыдущих проектов вашей организации, что руководство, отрицая очевидные факты, будет настаивать на первоначальном бюджете и плане, значит, придется принимать гораздо более серьезное решение относительно дальнейшего продолжения работы.При этом имеет существенное значение степень вашего влияния на другие аспекты проекта - например, на состав привлекаемых технических специалистов - что будет обсуждаться в главе 2.

Наивный оптимизм юности: «Мы сможем сделать это за выходные!»

Несмотря на то, что руководство компании, как правило, является удобной мишенью для критики за множество нелепых решений, связанных с безнадежными проектами, технические специалисты тоже не такие уж невинные агнцы. Несомненно, во многих случаях высшее руководство, к счастью, осознает свою неопытность в вопросах оценки и планирования сложных проектов. Оно обязательно будет консультироваться относительно продолжительности проекта с каким-нибудь технократом-сорвиголовой, которого, может быть, только неделю как назначили на высокую руководящую должность.

И, если этот технократ честолюбив и полон юношеского оптимизма (что напоминает юношеские фантазии относительно бессмертия, всемогущества и всеведения), он, скорее всего, ответит: «Нет проблем! Мы можем покончить с этой ерундой за выходные!» Высококвалифицированный программист (правда, здесь больше подходит определение «хакер») твердо уверен, что может разработать любую систему за выходные. Такие незначительные мелочи, как документирование, отладка, тестирование и проработка пользовательского интерфейса, настолько скучны, что нечего о них и говорить.

Если вы как раз именно такой чересчур оптимистичный программист и при этом ответственны за оценку параметров проекта, то, скорее всего, не представляете себе, что вы делаете. Вероятно, вы прочли последний абзац, немедленно оскорбились и проворчали: «Черт возьми! Я в самом деле могу разработать любую систему за выходные!» Господи, благослови вас; может статься, вы и преуспеете. В любом случае, что бы вы не услышали от старого пердуна вроде меня, вряд ли это изменит ваше мнение.

Однако, если вы - закаленный в битвах ветеран и замечаете, что вас почти втянули в безнадежный проект, поскольку какой-то молодой и наивный технический менеджер взял на себя смехотворно оптимистичные обязательства относительно плана, бюджета и ресурсов, то что же вам остается делать? По-моему, самое лучшее - спасаться бегством. Когда до таких менеджеров дойдет, что они пытаются прыгнуть выше головы, они впадают в состояние коллапса, что выражается в непредсказуемом поведении или полной беспомощности. В большинстве случаев им никогда не приходилось прежде иметь дело с такими большими и сложными проблемами, которые невозможно решить ни гениальным умом, ни грубой силой (например, кодируя без перекуров 48 часов в выходные). В любом случае, когда проект не уложится в срок, для них, наверняка, будет весьма неприятно услышать от вас: «А я ведь тебя предупреждал!».

Неожиданный и/или незапланированный кризис

Вообразите, что два самых лучших программиста только что пришли к вам в офис, чтобы сказать, (а) что они вступают в брак, (б) что они вступают в Корпус Мира и (в) сегодня последний день их работы. Или, например, ваш сетевой администратор звонит и сообщает, что ваш поставщик только что обанкротился, а чтобы использовать сетевой протокол другого поставщика, необходимо за следующие 30 дней все перепрограммировать. Или, ваш юридический отдел звонит и сообщает, что компании предъявлен судебный иск на невообразимое количество долларов, потому что она нарушила подпункт 13(б) Указа Q о каком-то скрытом налоге, о котором даже никто и не знал. Или, ...

Конечно, можно возразить, что в компании с хорошим руководством такие вещи, как возможный уход двух лучших программистов, стараются предвидеть заранее и быть к ним готовыми. И вы не так глупы, чтобы полностью зависеть от единственного поставщика телекоммуникационного оборудования. И руководство должно быть достаточно предусмотрительным, чтобы детально изучить Указ Q. В представлении идеалиста такие кризисы - это результат плохого планирования и плохого руководства; «незапланированный кризис» - это нонсенс.

Может быть, так оно и есть, но на практике становится все труднее и труднее предвидеть и планировать все возможные казусы, которые случаются в мире бизнеса. Хорошо это или плохо, но мы живем в мире хаоса, и безнадежные проекты - это естественное следствие такого хаоса. В самом деле, даже если мы хорошо представляем себе, что может произойти в будущем в этом хаотическом мире, мы в состоянии отреагировать на это только безнадежными проектами. Например, каждый, кто живет поблизости от разлома Сан Андреас в Калифорнии, знает, что там рано или поздно произойдет крупное землетрясение, но это не остановило начало массы всяких прожектов буквально на следующий день после того, как западная половина штата оказалась немножко поближе к Тихому Океану.

В самом деле, даже если нам точно

известно, когда произойдет кризис, все равно начинаются безнадежные проекты, поскольку руководство склонно отмахиваться от проблем до самого последнего момента.
Как еще можно объяснить панику, охватившую многие IS/IT-организации, когда на горизонте замаячила проблема 2000 года? Мы давно

знали о наступлении 1 января 2000 года, и знали, что этот конечный срок никак нельзя отодвинуть подальше. Мы точно знали, в чем заключается существо проблемы и что для ее решения не требуются никакие новомодные технологии вроде Java. Я работаю над этой книгой летом 1996 года и знаю наверняка, что сейчас формируется очередная команда для безнадежного проекта, связанного с решением проблемы 2000 года, и еще более безумные проекты будут начаты в 1997, 1998 и 1999 году.

В любом случае, непредвиденный кризис может повлечь за собой самые разнообразные безнадежные проекты. В худшем случае конечный срок таких проектов - «вчера, если не раньше», поскольку кризис уже наступил, и ситуация будет продолжать ухудшаться до тех пор, пока внедрение новой системы не позволит решить проблемы. В других случаях, например, при неожиданном увольнении ключевых разработчиков, «нормальный» в обычных условиях проект превращается в безнадежный из-за нехватки рабочей силы и потери ключевых интеллектуальных ресурсов.

По различным причинам, такая ситуация приводит к наихудшим разновидностям безнадежных проектов, поскольку заранее предвосхитить ее невозможно. Если к тому же еще имеет место синдром «Морского Корпуса», о котором говорилось выше, такое положение вообще не должно никого удивлять. С самого первого дня проекта все знают, что он, также как и все предыдущие проекты, потребует экстраординарных усилий. Что касается начинающих компаний, так они даже испытывают особенное волнение и возбуждение, начиная безнадежный проект; ведь его успех сделает всех сказочно богатыми.

Нормальные переговоры

Заявление о том, что мы в самом деле

знаем, как точно оценить сроки, бюджет и ресурсы какого-либо нетривиального проекта, наверняка вызовет бурные дебаты между различными группами софтверных профессионалов и менеджеров. Наши результаты, полученные в течение ряда лет, вряд ли будут слишком убедительными; с другой стороны, многие могут заметить, что проблемы, возникающие при оценке, являются результатом политических игр, связанных именно с безнадежными проектами, которые мы обсуждаем в данной книге. Однако, в большинстве крупных организаций могут припомнить дюжину-другую проектов, в которых команда разработчиков сама планировала, составляла бюджет и твердо обещала создать в этих условиях функционально полную систему; потом все эти обещания лопались как мыльный пузырь, и в результате не получалось вообще ничего. Поэтому нет ничего удивительного, что во многих таких организациях пользователи и высшее руководство, не отвлекаясь на переговорные процессы, просто навязывают жесткие сроки и бюджеты типа «сделай-или-умри». Таково происхождение многих безнадежных проектов.

Сказанное вовсе не означает, что мы не должны прилагать никаких усилий к получению «разумных» оценок, которые можно было бы использовать во время предварительных переговоров по проекту. Крайне важно, чтобы менеджер проекта избежал соблазна пойти по пути наименьшего сопротивления и принять любые начальные условия безнадежного проекта как указ свыше. Одним из общих признаков того, что проектная команда приняла стиль поведения «самоубийственного» проекта (который обсуждался в предыдущей главе) является позиция, выражаемая менеджером проекта (и разделяемая участниками команды), которая заключается в следующем: «Мы не имеем представления, сколько времени реально потребует этот проект, да это и не имеет значения,  поскольку нам уже сообщили конечный срок. Таким образом, нам придется работать семь дней в неделю и 24 часа в день, пока мы не свалимся от изнеможения. Пускай нас ругают и колотят, но мы не в состоянии прыгнуть выше головы...»

Я не собираюсь долго обсуждать различные методы оценки; если у менеджера проекта нет никакой квалификации или опыта в оценке, то безнадежный проект - совсем неподходящее место, чтобы начинать обучение таким методам. Позволю себе все же отметить некоторые полезные и доступные ресурсы, которые имеются в данной области:

·  Средства оценки, являющиеся коммерческими продуктами - такие, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates) и CHECKPOINT (Software Productivity Research (SPR)). Глава SPR Capers Jones, «гуру» в области метрик ПО, оценивает  рынок средств оценки проектов примерно в 50 продуктов. Эти продукты нельзя назвать совершенными, и все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип «мякину заложишь - мякину получишь»). В лучшем случае с помощью таких продуктов можно получить оценку с точностью с точностью ±10%. Даже если точность будет ±50%, чем иметь дело только с продиктованными политикой требованиями, с которыми приходится справляться менеджеру проекта и которые на 1000% выходят за пределы возможностей проектной команды.

·  Динамические модели систем - разработано множество имитационных моделей, которые позволяют исследовать нелинейные зависимости между различными факторами, влияющими на динамику проектных процессов. Например, если частью стратегии безнадежного проекта является требование сверхурочной работы участников проекта со стороны менеджера, каков будет эффект через несколько недель или месяцев? Естественно предположить, что по сравнению с нормальным восьмичасовым рабочим днем «отдача» увеличится, однако наиболее опытный менеджер проекта также отметит, что производительность (измеряемая в количестве функциональных точек в день, строках кода в час и т.д.) по мере накопления усталости будет постепенно снижаться. Кроме того, возрастет количество ошибок, что, очевидно, повлияет на трудоемкость тестирования и отладки. И, если сверхурочная работа будет продолжаться достаточно долго, то проектная команда просто окажется на грани истощения.


Из всех имитационных моделей, которые я видел, наилучшей представляется модель, описанная в [1], которая реализована на языках DYNAMO и iThink.

·  На тему об оценке проектов написано множество книг. Лучше всего начать с книги Барри Боэма [2]; отметим также, что его модель COCOMO, разработанная в начале 80-х годов, была позднее модифицирована в модель COCOMO-2 [3]. Другой классической работой является книга Фреда Брукса [4], также недавно переизданная с учетом современной технологии и практики разработки ПО. Еще одна новая книга, которую можно рекомендовать - это работа Джима Маккарти [5].

·  Сам процесс оценки достаточно изучен и документирован, и организации, подобные Software Engineering Institute (SEI), уже опубликовали различные руководства и отчеты [6,7], которые могут помочь при выполнении оценки проектов.

·  Такие распространенные методы, как прототипирование, также могут использоваться для оценки критичности тех или иных проектных ограничений для всей разрабатываемой системы в целом. Этот подход ни в коем случае не может служить «защитой от дурака», но, тем не менее, он позволяет привнести немного здравого смысла в проектную команду и окружающих ее менеджеров и заказчиков. Если руководство хочет, чтобы команда из трех разработчиков написала миллион строк кода за 12 месяцев, то следовало бы в течение первого месяца разработать небольшой прототип будущей системы, который, по крайней мере, позволит грубо оценить производительность проектной команды, а также реализуемость проекта в целом.

Обучение участников безнадежных проектов

В главах 6 и 7 я затрагивал вопросы обучения проектной команды новым процесса и средствам. Однако, потребность в таком обучении изменяется, если безнадежные проекты становятся частью корпоративной культуры. В этих случаях соответствующие процессы и средства должны быть частью корпоративных стандартов, что исключает необходимость внедрения их в начале каждого проекта как чего-то радикально нового.

В реальности, разумеется, существует некоторый переходный период, когда организация меняет свой режим работы, переходя от прежней формы выполнения проектов к новому стилю. Однако даже во время переходного периода идеальным вариантом было бы проводить обучение не в самом безнадежном проекте, а в нормальной обстановке; разумеется, такое обучение следует рассматривать как часть переходного процесса. При удачном стечении обстоятельств это позволит сделать процесс обучения более упорядоченным и не загонять его в цейтнот, как это обычно бывает, если обучение проводится в середине безнадежного проекта.

Соответствующее обучение также должно проводиться для новых сотрудников, принимаемых на работу. Новичкам - например, выпускникам колледжей, которые никогда не занимались полноценной разработкой ПО - нет необходимости объяснять, что новый подход отличается от старого подхода; в самом деле. ведь они даже не слышали такое понятие - «безнадежный проект». В чем они действительно нуждаются, так это в обучении методам, процессам и средствам, которые организация считает эффективными для применения в безнадежных проектах. Они, скорее всего, будут сильно отличаться от тех процессов и средств, с которыми новобранцам приходилось иметь дело прежде. (Ирония заключается в том, что как только прежние новобранцы примут участие в своем первом безнадежном проекте, менеджер велит им «игнорировать все, чему их научили в классе» и усвоить более прагматичный подход к разработке ПО.)

Определение безнадежного проекта

Под безнадежным проектом (death march) я понимаю такой проект, параметры которого отклоняются от нормальных значений по крайней мере на 50%. По отношению к софтверным проектам это обычно означает одно или более из следующих ограничений:

n    План проекта сжат более чем наполовину по сравнению с нормальным расчетным планом; таким образом, проект, требующий в нормальных условиях 12 календарных месяцев, приходится выполнять за 6 или менее месяцев. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной.

n    Количество разработчиков уменьшено более чем наполовину по сравнению с действительно необходимым для проекта данного размера и масштаба; таким образом, вместо формирования проектной команды из десяти человек, менеджера проекта убеждают, что достаточно и пяти. Такое представление может быть результатом наивной веры в магические возможности новых CASE-средств или языков программирования удваивать производительность труда разработчиков - несмотря на то, что разработчики не обучались или не имеют практического опыта работы с новой технологией и, скорее всего, с ними никто не советовался по поводу решения использовать новую технологию. На сегодняшний день более общей причиной уменьшения количества разработчиков является сокращение штатов компании в результате реорганизации, реинжиниринга и т.д.

n    Бюджет и связанные с ним ресурсы урезаны наполовину. Зачастую это результат сокращения компании и других противозатратных мер, хотя это может быть и результатом конкурентной борьбы за выгодный контракт. В этой ситуации менеджер проекта в консалтинговой фирме получает из отдела маркетинга следующую информацию: «У нас хорошая новость - мы выиграли тендер, но есть и плохая новость - мы были вынуждены наполовину урезать бюджет, чтобы победить конкурентов». Такое ограничение часто непосредственно влияет на количество нанимаемых разработчиков, однако последствия могут быть и менее явными - например, может быть принято решение привлечь относительно недорогих и неопытных молодых разработчиков вместо опытных дорогостоящих специалистов.
Наконец, это может породить атмосферу мелочной экономии, когда менеджер проекта не в состоянии заказать пиццу для своей команды, проработавшей все выходные в офисе.

n    Требования к функциям, возможностям, производительности и другим техническим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях. Например, проектной команде могут заявить, что они должны по сравнению с конкурентом выжать в два раза больше возможностей из фиксированного объема RAM или дискового пространства. Или, например, от них могут потребовать, чтобы система поддерживала вдвое большее количество транзакций по сравнению с любой сопоставимой системой. Требования, связанные с производительностью, могут и не повлечь за собой неудачу проекта; в конце концов, всегда можно использовать преимущества более дешевого и производительного оборудования, а также разработать более совершенный алгоритм или подход к проектированию, чтобы достичь повышения производительности (хотя, при сжатых сроках, могут не помочь и безграничные возможности человеческого мозга). С другой стороны, удвоение функциональных возможностей обычно означает удвоение необходимого объема работы, что обязательно приведет к неудаче проекта.

Во многих организациях непосредственный результат перечисленных ограничений заключается в том, что от проектной команды требуют работать вдвое интенсивней и/или тратить в два  раза больше часов в неделю, чем в «нормальном» проекте. При том, что нормальная рабочая неделя составляет 40 часов, команде безнадежного проекта зачастую приходится работать по 13-14 часов в день и 6 дней в неделю. В такой обстановке, естественно, возрастает напряженность и количество стрессов.

Другой способ охарактеризовать безнадежный проект заключается в следующем: беспристрастная, объективная оценка риска такого проекта (включая риск, связанный с техническими проблемами, человеческим фактором, законами, политикой и т.д.) определяет вероятность провала свыше 50%.

Безусловно, даже если перечисленные ограничения отсутствуют, риск неудачи проекта все равно может быть высоким, например, из-за конфликтов между IT-подразделением и пользователями.Однако, в общем случае, причиной высокого риска является сочетание указанных мной факторов.

Определение сущности проекта

В предыдущей главе я определил некоторые характеристики безнадежных проектов: они могут быть большими или нет; они могут иметь однородную группу заказчиков или группы с противоположными интересами; наконец, могут присутствовать различные ограничения на сроки, бюджет и ресурсы.

Существует, однако, другой способ охарактеризовать безнадежные проекты, имеющий наибольшее значение с точки зрения политики. Он представляется, как показано на рис. 2.1, в двухмерной системе координат, где горизонтальная ось представляет вероятность успешного завершения проекта, а вертикальная - степень удовлетворенности участников проектной команды в ходе выполнения проекта. Один из способов определить, как ощущают себя участники проектной команды - это спросить: «Когда этот проект закончится, как вы посмотрите на участие еще в одном безнадежном проекте?» Или, еще проще: «Вы чувствуете себя нормально или нет?»

 

   высокая

                                Камикадзе                         Невыполнимая

Степень                                                                    миссия

удовлет-

ворен-

ности                    Самоубийство                        Отвращение

     низкая

                  низкая                                                                     высокая

                                 Вероятность успешного завершения

Рис. 2.1 Квадрант безнадежных проектов

На данной диаграмме нет какого-либо точного масштаба, и границы между четырьмя квадрантами весьма условны; для некоторых известных мне проектов я даже не могу точно определить, к какому квадранту они принадлежат. Весьма сомнительно, чтобы кто-либо начинал безнадежный проект с явным намерением отнести его к той или иной конкретной категории, да и по ходу дела совокупность всех возможных ограничений (на сроки, бюджет и т.д.) может переместить проект в любом направлении.

Определение данных четырех квадрантов также весьма условно, и вы можете изменять его как угодно, чтобы приспособить к условиям своей организации.
В данном случае я определяю основные характеристики четырех квадрантов следующим образом:

·  Проекты «Невыполнимая миссия» - этот вид проектов воспет старыми телесериалами и новым (1996 года) фильмом с участием Тома Круза. Кажется, что все темные силы на свете объединились против проекта, все злодеи и изменники жаждут его провала. Но менеджер проекта - великолепный голливудский супермен, его хакеры - интеллектуальные гении, и на стороне команды сам Бог. Участники команды фанатически преданы друг другу (несмотря на все препятствия и капризы судьбы, как в фильме), крепнут с каждым ударом, их возбуждает «ходьба по лезвию ножа». В реальных проектах такого рода их команды обычно мечтают о славе, почестях и богатстве в случае успеха проекта. В конце концов, их миссия должна

закончиться успешно; они убеждены, что сочетание интенсивной работы с профессиональной виртуозностью сделает это возможным.

·  «Отвратительные» проекты - это такие проекты, в которых участники команды - это жертвенные агнцы, которые будут зарезаны хладнокровным менеджером ради успеха проекта. Проекты такого рода обычно обладают менталитетом «Морского Корпуса», который обсуждался в главе 1 - то есть менеджер проекта будет постоянно произносить перед своей командой речи на тему «настоящие программисты не нуждаются в сне!». При этом также подразумевается, что «настоящим» программистам нет необходимости бывать дома со своими семьями, навещать своих престарелых родителей в больнице, и вообще заниматься чем-либо, что хотя бы на минуту может отвлечь от проекта. Для таких проектов неудивительны случаи, когда один или двое участников команды падают от изнеможения, страдают от язвы или нервных припадков или разводятся. Когда такое происходит, менеджер проекта только посмеивается и заявляет остальным участникам команды, что такие люди - неудачники и слабаки, которые заслуживают своей судьбы.

Ключевыми характеристиками таких проектов являются следующие: (а) менеджер проекта нацелен на успех, (б) менеджер проекта нацелен на выживание и, вследствие этого, извлечение выгоды из успеха проекта, и (в) менеджер проекта ради достижения успеха готов, и даже настроен



на то, чтобы пожертвовать здоровьем и благополучием участников проектной команды.

·  «Самоубийственные» проекты - в таких проектах все выглядят несчастными и обреченными. Участники команды и

менеджер проекта обычно бывают вынуждены согласиться работать над таким проектом только потому, что альтернатива - увольнение; они с самого начала знают, что нет никаких шансов на успех. Они не могут позволить себе выйти из проекта, у проекта нет владельца, все карты складываются против них...

·  Проекты «камикадзе» - такие проекты также обречены на неудачу, но все согласны с тем, что это будет почетный провал, и они впоследствии будут гордиться своей причастностью к проекту. Технические специалисты проектной команды могут быть счастливы от возможности поработать с передовой технологией, которую они никогда ранее не использовали и которую, как они полагают, им больше никогда не придется увидеть после того, как проект будет свернут. Менеджер проекта надеется, что проект послужит хорошим уроком будущим менеджерам. Иногда такие проекты затеваются обреченными компаниями, чье славное прошлое объясняет такую неистовую преданность некоторых участников команды, что они почитают за честь и привилегию право пожертвовать собой в обреченном проекте, провал которого станет последним «ура» компании. Разумеется, существует небольшая вероятность того, что проект закончится успешно, и компания сможет выжить; даже если при этом участники проектной команды истощат себя до крайности, пытаясь совершить чудо, они все равно будут счастливы.

Исходя из этих определений, вы, наверное, могли бы сказать, что я с одобрением отношусь к проектам «Невыполнимая миссия», восхищаюсь проектами «камикадзе», сочувствую тем, кто добрался до конца «самоубийственных» проектов, и испытываю неприязнь к «отвратительным» проектам. Хочу, однако, заметить, что это моя собственная система ценностей, она может и не совпадать с вашей. Что еще более важно, она может не совпадать с системой ценностей вашего менеджера проекта; или, если вы являетесь менеджером проекта, то можете обнаружить, что системы ценностей у вас и участников вашей команды не совпадают.


По вполне очевидным причинам, самое лучшее, когда все вписываются в один квадрант. Трудно рассчитывать на успех проекта «Невыполнимая миссия», если один или два ключевых участника команды полагают, что они участвуют в «самоубийственном» проекте.

Следует также помнить, что публичные заверения различных акционеров, заинтересованных лиц и разнообразных менеджеров вокруг безнадежного проекта могут и не быть объективным отражением реальной ситуации. Хотелось бы надеяться, что у владельца проекта хватит ума не затевать «самоубийственный» безнадежный проект, однако в больших компаниях порой происходят странные вещи - например, такой проект может быть частью большой политической баталии, в которой участвует владелец проекта. Но все же гораздо чаще высшее руководство располагает достаточной информацией, чтобы оценить реальные шансы проекта на успех. Например, ваш вице-президент может совершенно точно знать о предстоящем слиянии или приобретении компаний, о котором будет публично объявлено за неделю до планируемого завершения вашего безнадежного проекта, и проект при этом будет прекращен независимо от того, насколько успешно он выполняется. Се ля ви.

Наиболее опасно оказаться вовлеченным в «отвратительный» безнадежный проект, когда менеджер проекта отказывается признать, что он собирается принести участников команды в жертву, если сочтет это целесообразным. К счастью, такую ситуацию обычно легко распознать, даже если менеджер отказывается признать это. Чересчур «мужественное» поведение и уничтожающие характеристики, даваемые самым слабым участникам команды, которые неспособны демонстрировать такую же производительность, как «настоящие программисты», абсолютно точно характеризуют позицию такого менеджера. Разумеется, если вы обладаете менталитетом «Морского Корпуса», а также готовы решать любые физические, эмоциональные, политические и психологические проблемы, то такой проект не представляет для вас ничего страшного.

Менеджеры «отвратительных» проектов обычно приглашаются со стороны, либо в самом начале проекта, либо после того, как первый менеджер проекта уйдет или будет уволен.


Новый менеджер, как правило, никак не связан с предысторией компании и не имеет личных взаимоотношений с кем-либо из ее сотрудников, и поэтому испытывает меньше колебаний, чем можно было бы ожидать, когда приходится заставлять участников проектной команды работать интенсивнее и дольше. Я наблюдал несколько ситуаций, когда менеджер проекта представляет собой «наемного стрелка», который кочует из одной компании в другую, каждый раз принимая вызов в виде подобных проектов. Такой менеджер обычно добивается успешных результатов в проекте - ведь благодаря этому он получает репутацию, позволяющую ему получать довольно высокое вознаграждение - но при этом участники проектной команды испытывают такое истощение и отвращение к своей работе, что по завершении проекта (если не раньше) дружно уходят всей командой, а менеджер проекта наживает так много врагов, что у него также не остается другого выбора, как упаковать свои чемоданы и перебраться в другой безнадежный проект. Такая роль идеально подходит для Клинта Иствуда, и лучше поостеречься, если кто-либо похожий на его героев въезжает в ваш городок, чтобы захватить власть в проекте, в котором вы только что согласились участвовать.

Один такой менеджер, которого я имел счастье наблюдать, работая в сфере финансовых услуг на Уолл-Стрит, имел любопытную стратегию для испытания физической выносливости и силы духа своей команды: в самом начале проекта он создавал «искусственный» кризис и немедленно

бросал всю команду на его ликвидацию, заставляя при этом работать с удвоенной энергией. При этом он наблюдал происходящее из-за кулис; один или двое из участников команды могли уволиться, один или двое могли заработать нервный срыв, и один или двое «скромных героев» могли проявить себя и ликвидировать кризис за счет сверхинтенсивной работы или удачного технического решения. Испытав таким образом свою команду, этот хладнокровный менеджер мог затем ослабить давление и приступить к реальной работе над проектом, будучи уверен, что в случае возникновения настоящего



кризиса ( который рано или поздно наступит в безнадежном проекте) он будет хорошо знать, на что способна его команда.

О такой перспективе лучше всего иметь представление до начала проекта; в процессе формирования проектной команды менеджеру следует оценить, с какого рода проектом он ожидает иметь дело, и затем спросить у предполагаемых участников команды, (а) как они оценивают проект, и (б) что они думают относительно принадлежности проекта к одному из четырех квадрантов на рис. 2.1. Как будет далее сказано в главе 4, я твердо уверен, что менеджер безнадежного проекта должен иметь свободу выбора участников своей команды; и помимо учета их профессиональной квалификации, не менее важно подбирать людей, имеющих сходное представление относительно «категории» проекта.

Разумеется, совсем другое дело, если вы сами являетесь предполагаемым участником команды безнадежного проекта, и вас интервьюирует менеджер проекта. Как уже было сказано ранее в главе 1, у вас может просто не быть никакого выбора, и, в противоположность тому, что было сказано в предыдущем абзаце, менеджер может также не иметь выбора решения относительно вашего участия в проекте; в такой ситуации по крайней мере полезно выяснить, как оценивает проект ваш менеджер. Но если вы можете

позволить себе отказаться от участия в проекте, тогда гораздо важнее убедиться, что ваша оценка проекта сходна с оценкой вашего менеджера. Как было сказано выше, это вдвойне важно, если намечается «отвратительный» проект; вы должны спросить себя, не может ли так случиться, что вы станете одной из жертв этого проекта.

Не забывайте также, что ситуация может резко измениться в ходе самого проекта в зависимости от прогресса (или его отсутствия), достигнутого командой, в зависимости от политического климата вокруг самой команды, в зависимости от физического или эмоционального истощения некоторых участников проекта и т.д.

Отношение участников к проекту

Последняя тема, которую следует обсудить: то отношение к работе, на которое готовы и способны различные участники проектной команды.

Характер отношения участников команды сильно зависит от того, к какой категории из ранее обсуждавшихся принадлежит проект; например, если всем становится ясно, что они участвуют в «самоубийственном» проекте, вряд ли они будут физически и эмоционально напрягаться больше, чем это необходимо. Даже если руководство настаивает на необходимости длительной сверхурочной работы, можно будет обнаружить, что участники команды проводят вечерние часы и выходные (то самое время, когда высшее руководство, навязавшее сверхурочную работу, само отсутствует), звоня приятелям по телефону, строча письма своим семьям или сидя вокруг кофейного автомата и обмениваясь последними сплетнями.

Аналогично, в «отвратительном» проекте отношение его участников диктуется менеджером проекта, или, по крайней мере, сильно зависит от его требований. Мой опыт говорит, что менеджер такого проекта сам должен проявлять такое же отношение к работе, какое он требует от остальных; если проектная команда все субботы и воскресенья проводит в офисе, он должен быть вместе с ними и пощелкивать кнутом при необходимости.

Что же касается проектов «камикадзе» и «невыполнимая миссия», а также безнадежных проектов, которые вообще невозможно отнести к какой-либо одной определенной категории, то для них очень важно, чтобы у менеджера проекта было реалистичное представление о тех пределах, в которые укладывается отношение участников команды к проекту; и, кроме того, важно, чтобы любой участник проекта, которому в перспективе придется  пожертвовать своей личной жизнью на ближайшие несколько месяцев, знал, может ли он рассчитывать на такое же отношение к работе со стороны своих коллег.

Самое лучшее, если каждый участник проекта честно и объективно оценит свои возможности. Может случиться так, что кто-то скажет: «Я готов работать на все 100%, но моя сестра собирается выйти замуж в июне, как раз перед завершением проекта, и мне придется взять отпуск на три недели.
Я очень сожалею, но ее свадьба - самое важное событие в моей жизни.» Поскольку остальные участники проекта даже не знакомы с его сестрой, они могут счесть такое исчезновение в критический заключительный период разработки чересчур легкомысленным, но по крайней мере этот участник команды честно сказал о своих намерениях. Однако, менеджер «отвратительного» проекта может крайне негативно отнестись к такому заявлению, и сказать, что такой вариант неприемлем. Что ж, это тоже в порядке вещей - если происходит в самом начале проекта. Участнику проектной команды при этом необходимо выбрать одно из двух: если свадьба сестры для него важнее, то лучше сразу и без особого ущерба выйти из проекта, чем позже оказаться в критическом положении.

К сожалению, далеко не каждый способен запланировать все, что может повлиять на его участие в проекте. Обычный участник команды может пообещать 100-процентное участие в проекте, однако если его ребенок заболеет и попадет в больницу, все обещания будут нарушены. Кроме того, разумеется, у каждого участника есть шанс выиграть главный приз какой-нибудь лотереи и получить раз в жизни уникальный шанс отправиться всей семьей на Таити, ... и кто знает, какие еще непредвиденные события могут заставить нарушить данные обещания? Кстати, это хорошая причина для формирования небольших проектных команд и краткосрочных планов. Команда из 5 человек, работающая над 6-месячным проектом, гораздо меньше подвержена воздействию всяких непредвиденных событий, чем команда из 30 человек, работающая 3 года. Многие люди вступают в брак, у них есть дети и другие многочисленные заботы; если связанные с этим проблемы и можно иногда отодвинуть на несколько недель или даже месяцев, то уж никак не на три года. Бессмысленно требовать от кого-либо предвосхищения всех возможных ситуаций, но для менеджера проекта вполне по силам составить себе реалистичное представление относительно ожидаемой степени участия в проекте для каждого его участника. Если двухнедельное отсутствие на работе из-за свадьбы вашей сестры будет рассматриваться как государственная измена, то лучше всего знать об этом заранее.

Для каждого участника проекта также очень важно знать, как относятся к своей работе все остальные участники. Как сделать информацию об участии и личном вкладе каждого в проект общедоступной - это забота менеджера проекта.

Переговорные игры

Переговоры - это игра, она имеет место во всех софтверных проектах. Переговоры в безнадежных проектах характерны тем, что ставки гораздо выше, эмоции перехлестывают через край, а запросы противоположной стороны (в терминах плана, бюджета и т.д.) обычно доходят до такой крайности, что могут превысить любой «запас прочности». В обычном проекте, например, самый очевидный запас прочности - это сверхурочное время. Даже если менеджер проекта оказался вынужден принять под давлением жесткий график и урезанный бюджет, успеха все равно можно будет добиться, уговорив проектную команду работать сверхурочно от 10 до 20 часов в неделю в течение нескольких заключительных месяцев проекта. Эти дополнительные усилия никак не отражаются в официальной статистике, поскольку программисты ничего не получают за сверхурочную работу, поэтому менеджер в конце проекта выглядит героем.

Однако, в безнадежном проекте небольшого количества сверхурочного времени обычно явно недостаточно, чтобы достичь тех впечатляющих результатов, которые требует руководство. Кроме того, пользователи и высшее руководство не столь наивны - они знают, что может потребоваться сверхурочная работа, и учитывают ее в своих собственных оценках графика выполнения проекта - лишая таким образом менеджера возможности использовать этот свободный ресурс. Правда, менеджеры-ветераны подобных переговоров должны иметь запасные карты в рукаве, которые могут пойти в ход в начале переговоров.

В самом плохом положении находится неопытный менеджер; в худшем случае он даже не представляет, что его последний успех мог быть достигнут только благодаря тому, что проектная команда добровольно согласилась на большую сверхурочную работу, чтобы уложиться в сжатые до безобразия сроки. В свою очередь, такой смехотворный план мог быть навязан проектной команде именно из-за неопытности менеджера в области проектных оценок и переговоров.

Консультант в области менеджмента Rob Thomsett в своей замечательной статье [8] определил наиболее общие варианты переговорных игр; наиболее распространенные из них приведены ниже:

·  Удвой и добавь еще - эта уловка используется в проектах, начиная с египетских пирамид, если не раньше. Используйте любые методы оценки, оказавшиеся под рукой, затем полученную «разумную» оценку удвойте и для большей надежности добавьте еще три месяца (или три недели, или три года, в зависимости от масштаба проекта). Главная проблема такой стратегии заключается в том, что она прямиком ведет к самому жесткому ограничению, связанному с безнадежными проектами: сжатым срокам.

·  Обратное удвоение - как было отмечено ранее, руководство может быть вполне осведомлено о попытках менеджеров проектов «раздуть» свои оценки, используя предыдущую стратегию. Одна из причин такой проницательности заключается в том, что высшее руководство во многих организациях - это бывшие менеджеры проектов в области информационных технологий, поэтому они хорошо разбираются в таких играх. В результате они берут те начальные оценки, которые им дают менеджеры проектов, и автоматически урезают их наполовину. Беда несчастному неопытному менеджеру, который даже не знает, что его подозревают в удвоении своих начальных оценок!

·  «Угадай число, которое я задумал» - такую игру я освоил в одном из моих первых проектов, когда был еще молодым программистом. У пользователя или руководителя высокого уровня есть своя «приемлемая» оценка для сроков, бюджета и/или других аспектов переговоров, но они отказываются четко ее сформулировать. Когда менеджер проекта предлагает свою оценку сроков и бюджета, пользователь или руководитель попросту качает головой и говорит: «Нет». Такой ответ подразумевает: «Это слишком много - попробуй угадать еще раз». Незадачливый менеджер в конце концов (иногда после полудюжины попыток!) приходит с нужной оценкой, но поскольку теперь это его оценка, ему впоследствии и придется отвечать за нее.

·  Двойной плевок пустышкой - «пустышкой» (dummy) на австралийском сленге называется детская соска, и «выплюнуть пустышку» означает, что ребенок настолько расстроен и рассержен, что выплевывает свою соску.


Thomsett использует это как метафору, чтобы описать такую ситуацию в процессе переговоров, когда руководитель высокого уровня впадает в буйное неистовство, когда менеджер проекта в первый раз докладывает свои предложения по плану и бюджету. Дисциплинированный менеджер поспешно удаляется, затем снова возвращается с пересмотренной оценкой, а руководитель снова закатывает истерику - получается в точности «двойной плевок пустышкой». Идея заключается в том, чтобы запугать и затерроризировать менеджера до такой степени, чтобы он согласился с чем угодно, лишь бы избежать еще одной вспышки раздражительности.

·  Испанская инквизиция - такое случается, когда менеджер проекта приходит на совещание руководителей высшего уровня, совершенно не представляя, что от него потребуют дать «немедленную оценку» безнадежному проекту. Представьте себе комнату, полную ворчливых вице-президентов, которые пристально смотрят на вас, в то время как директор грозным тоном спрашивает: «Итак, Смит, когда же, по вашему мнению, мы получим эту систему? Я уже доложил всему руководству, что она будет готова к середине марта - вы же не собираетесь подвести меня, не так ли?» Если у вас хватит смелости возразить, что более реальный срок - середина ноября, тогда дюжина инквизиторов обрушится на вас с вопросами относительно вашего интеллекта, полномочий, лояльности и, возможно, даже религиозных убеждений.

·  Игра на понижение - по мере роста тенденции к использованию аутсорсинга во многих организациях такая игра становится все более распространенной; она также часто имеет место в ситуации, когда организация-разработчик ПО проигрывает своим конкурентам борьбу за право разработки системы для организации-клиента. Эта игра достаточно очевидна: заказчик (или, в некоторых случаях, представитель службы маркетинга организации-разработчика) говорит менеджеру проекта, что один из других претендентов на проект предложил более короткий срок разработки и/или более скромный бюджет. Это вынуждает менеджера проекта не только ответить на вызов конкурента (который может быть вполне реальным, а может и нет), но и превзойти его, чтобы повысить свои шансы на заключение контракта.


Одним из вариантов такой игры является случай, когда клиент дает понять, что он не исключает возможность, что проект вообще не состоится; при этом организация-разработчик, которая во что бы то ни стало стремится заполучить этот проект (возможно, потому, что он служит карьерным целям вице-президента по информационным технологиям), постарается выдвинуть такие заманчивые для клиента предложения, чтобы наверняка гарантировать их принятие. Разумеется, это означает, что, как правило, один или более членов IT-иерархии знают, что эти предложения чрезмерно оптимистичны или просто явно лживы. Такие действия, в свою очередь, ведут к описанным ниже играм «Месть» и «Китайская пытка водой».

·  Месть - эту игру иногда затевает против своего руководства менеджер проекта: хотя он с самого начала знает, что предложения по срокам и бюджету нереалистичны, он нарочно соглашается с ними, полагая, что к тому моменту времени, когда их нереалистичность станет, наконец, очевидной для всех (например, за неделю до окончания проекта), клиент уже не сможет ничего изменить. Однако эта игра достаточно опасна, поскольку клиент может задуматься, стоит ли ему так рисковать своими деньгами. Если организация-разработчик уже заработала не слишком хорошую репутацию предыдущими аналогичными проектами, клиент может вообще отказаться от проекта и списать свои расходы в убыток. Но все же имеется вероятность, что отказаться от безнадежного проекта сразу же не удастся, поскольку он обычно связан с целями бизнеса и политическими реалиями, которые невозможно обойти. Тем не менее, это не помешает заказчику найти способ отомстить за ту игру, которую с ним сыграли, и наиболее очевидной формой такой мести будет увольнение менеджера проекта. Точно так же его может подставить собственное руководство (которое в первую очередь виновато в нереальных условиях безнадежного проекта), чтобы списать на него свою вину. Все могут подумать, что виной всему является некомпетентность менеджера проекта; наймут другого менеджера, примут (или нет) более реалистичные сроки и бюджет, и проект продолжится.


Тем временем, разумеется, никто и не подумает ослабить пресс сверхурочной работы, который давит на участников проектной команды.

·  Китайская пытка водой - в отличие от предыдущей игры ва-банк, связанной с высоким риском, данная игра заключается в том, что плохие новости преподносятся заказчику и/или высшему руководству маленькими порциями. Вообразите, например, такую ситуацию, когда разумная оценка срока выполнения проекта, сделанная менеджером, составляет 12 месяцев; по его мнению, при помощи сверхурочной работы и разного рода чудес проект можно попытаться закончить за 6 месяцев, однако руководство настаивает на 4-х месяцах. Менеджер нехотя уступает и устанавливает для проекта последовательность «контрольных точек» - например, новая версия прототипа системы должна предъявляться заказчику каждую неделю. Первое предъявление окажется опоздавшим на один день, однако менеджер докажет, что для данной работы задержка может составлять от 14 до 20% (в зависимости от того, сколько дней в неделю работает команда - 5 или 7); отсюда, по его мнению, следует, что срок разработки заключительной версии системы также может быть отодвинут на 14-20%. На такой ранней стадии проекта руководство отказывается пойти на уступки, но когда вторая контрольная точка также окажется сдвинута на день (что означает общую задержку в два дня в течение двух недель), менеджер вновь повторит свои аргументы. Кап, кап, кап; это похоже на китайскую пытку водой - одной единственной плохой новости недостаточно, чтобы сразить вас, но все вместе могут оказаться роковыми.

·  Туманы и миражи - горе тому несчастному менеджеру проекта, вице-президент которого нанял консультанта по метрикам с моделью оценки, в которой никто ничего не понимает. Метрики ПО в конечном счете представляют собой статистику, а модели оценки основываются, как правило, на сложных математических зависимостях. Когда они попадают в руки человека неопытного, наивного или преследующего определенные политические цели, эти средства могут быть использованы для «доказательства» корректности любой произвольной оценки.


Все это вдвойне опасно, если источником этих метрик является поставщик, пытающийся доказать, что безнадежный проект преуспеет благодаря фантастической производительности его CASE-средств, средств визуального программирования или новейшей методологии разработки ПО.

·  Спрятанное качество - это одна из наиболее хитрых игр, в ней могут участвовать (в конструктивной или деструктивной манере) хорошо информированные менеджеры проектов, менеджеры высокого уровня по информационным технологиям и/или заказчики. На самом деле все очень просто: как менеджер проекта, я могу предоставить пользователю бесконечно большое количество программ за нулевое время, пока их не нужно реально эксплуатировать. Разумеется, было бы глупо предлагать такой экстремальный сценарий, однако, суть заключается в том, что качество ПО (выражаемое в количестве ошибок, переносимости, сопровождаемости и т.д.) - это одно из «измерений» проекта, которое нужно учитывать во время переговоров по срокам, затратам, персоналу и другим ресурсам. Некоторые заказчики слишком неопытны, чтобы понимать это, а другие не собираются принимать в расчет длительную перспективу: «Мне все равно, будет ли система работоспособна через два года, поскольку за это время возможности для бизнеса могут кардинально измениться, да и я сам, в любом случае, буду другим. Что меня действительно беспокоит - это чтобы система была готова через три месяца и работала после этого 12 месяцев». Если политика оказывает достаточно сильное давление на принимаемые решения, то нетрудно обнаружить IT-менеджеров и менеджера проекта, готовых согласиться с такой позицией; гораздо менее вероятно, чтобы с ней могли соглашаться технические специалисты. В самом лучшем варианте такая «игра» отражает стратегию «достаточно хорошего» (good-enough) ПО, которую я описал в [9]; в худшем виде она носит такой же жульнический характер, как и некоторые другие упомянутые выше политические игры.

Почему безнадежные проекты становятся нормой

Начнем с анализа вероятности того, что безнадежные проекты будут становиться нормой. На протяжении всей книги я приводил по крайней мере три причины, по которым это могло бы стать реальностью:

·  Организация находится в разгаре продолжающегося кризиса – это может быть результатом неудачного совпадения нескольких неожиданных кризисов, случившихся за небольшой промежуток времени; однако чаще это относится к организациям, оказавшимся в трудном положении, отчаянно пытаясь справиться с «потоком изменений» на рынке или с используемой технологией. В большинстве случаев такие организации оказываются в слишком отчаянном положении, чтобы суметь отступить на шаг назад и реорганизовать свою работу таким образом, чтобы спокойно планировать и выполнять все свои проекты. Редким исключением является ситуация, когда в компанию приходит новый руководитель, призванный вывести ее из кризиса; при этом он может внедрить в компании совершенно иной стиль работы.

·  Руководство и пользователи принимают такой подход в качестве своей стандартной позиции во время переговоров – как отмечалось в главах 1 и 2, в таком духе зачастую начинается первый безнадежный проект; однако, если такой подход сработает один раз, почему бы не повторить его снова? Если департамент маркетинга или департамент финансов, или некоторое другое подразделение в организации столкнется с необходимостью «перманентного» реинжиниринга для достижения конкурентоспособного уровня, они могут также принять соответствующее решение и настаивать, чтобы все разработчики и поставщики, с которыми они взаимодействуют, аналогичным образом подвергли себя реинжинирингу. С точки зрения таких подразделений департамент информационных технологий рассматривается как еще один «поставщик» продуктов и услуг. Вариацией на эту тему является указание высшего руководства департаменту информационных технологий: «Если ваши люди не улучшат радикально свою продуктивность во всех проектах, мы отдадим все на аутсорсинг в Индию!»

·  Это часть «стратегического преимущества» компании – такой подход может иметь место в организациях, подобных EDS, и он является вполне определенным в таких организациях, как Cambridge Technology Partners.
Он имеет смысл для консалтинговых организаций, где производительность проектных команд является их бизнесом. Однако, мы можем легко вообразить такую же ситуацию в других областях деятельности, связанных с информационной индустрией, таких, как банковское дело, страхование и телекоммуникации – там, где способность продвинуть новый программный продукт на рынок в значительной степени зависит от скорости его разработки. В той мере, в какой сказанное справедливо, я ожидаю появления все большего и большего количества организаций, прививших у себя культуру безнадежных проектов.

Однако то, что имеет некоторый смысл для организации в целом, совсем не обязательно должно иметь такой же смысл для отдельных разработчиков и менеджеров проектов. Точка зрения организации имеет, безусловно, важное значение, однако я хочу уделить основное внимание точке зрения разработчика и менеджера; в конце концов, я не слишком надеюсь на то, что многие директора и вице-президенты по маркетингу прочтут эту книгу.

Главный вопрос для разработчика и менеджера проекта заключается в следующем: если удалось пройти через один безнадежный проект, следует ли повторять этот опыт снова? Как можно себе представить, ответ на этот вопрос существенно зависит от того, насколько успешным был первый проект. В конце концов, если вы только что завершили «самоубийственный» или «отвратительный» проект, то, скорее всего, находитесь в состоянии физического и эмоционального истощения. Вашему самолюбию нанесен серьезный урон, личная жизнь, возможно, оказалась разрушена. Кто на целом свете захочет еще раз повторить такое? Даже так называемые проекты «камикадзе», где вы жертвуете своими личными потребностями в угоду столь возвышенным (но проигрышным) целям корпорации, могут в конце концов оказаться несостоятельными. Вы можете считать свою жертву благородной, однако если вы не выступаете в амплуа страдальца, то вряд ли вам захочется добровольно повторить этот эксперимент.

Отметим, что «отвратительный» проект, как говорилось в главе 1, может закончиться успешно; таким образом, у высшего руководства и пользователей будет повод для хорошего настроения.


У менеджера проекта тоже может быть такой повод, особенно если он к концу проекта собрал хороший урожай в виде разнообразных вознаграждений. Если вы – один из участников команды, успешно прошедший через проект, вы можете быть довольны результатами, а можете и нет; в конце концов тот факт, что пролито море крови и причинен вред многим жизням и карьерам, может вас и не беспокоить. В самом деле, это становится частью корпоративной культуры – не обращать внимания на чужую кровь, которая проливается во имя проекта.

Очевидно, наибольшими шансами найти добровольцев для повторения опыта обладает проект «невыполнимая миссия»: проект, который не только успешно завершился, но и внушил каждому чувство истинной гордости за то чудо, которое они сотворили. Если по окончании проекта есть время покопаться в его результатах, то в этот момент крайне важно ответить на  вопрос: «За счет чего мы сумели добиться успеха?» Было ли это всего лишь везением? Может быть, это полностью зависело от харизмы менеджера проекта, или от гениальности проектировщика базы данных, или от того, что конечный пользователь и системный аналитик безумно влюбились друг в друга и поженились к концу проекта? Основной вопрос заключается в следующем: существует ли какая-нибудь разумная причина ожидать, что мы сумеем повторить этот фокус?

На эти вопросы важно ответить как можно раньше, поскольку организация, скорее всего, захочет повторить опыт независимо от желания отдельных личностей. Как было отмечено выше, в экстремальной ситуации организация поступает так, поскольку она вынуждена это делать; некоторые организации достаточно долго движутся к своему концу, и последние пять-десять лет были не чем иным, как бесконечной вереницей безнадежных проектов. Даже в менее экстремальных ситуациях  неудачи одного безнадежного проекта может быть недостаточно, чтобы заставить организацию отказаться от подобного подхода; как отмечалось в предыдущих главах, в провале зачастую обвиняют менеджера проекта или новую технологию. «В следующий раз», - клянется директор, - «мы не повторим те же самые ошибки; у нас будет новый менеджер проекта и новая супертехнология».

Разумеется, если первый же безнадежный проект закончится успешно, вероятность того, что конечные пользователи и высшее руководство попытаются его повторить, будет гораздо выше; однако, может наступить момент, когда участники проектной команды решать сделать ручкой и станцуют конгу по направлению к двери. Пугать такой акцией бессмысленно; руководство обычно полагает, что легко найдет новых добровольцев. Самое лучшее, что могут сделать доведенные до изнеможения участники проекта – это пожелать всем доброго здоровья и отправиться искать более спокойных и нормальных условий существования где-нибудь в другом месте.

---

---