Управление безнадежными проектами

Обсуждение книги Эдварда Йордана Death March. The Complete Software Developers?s Guide to Surviving "Mission Impossible" Projects. Prentice Hall, 1997

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

Рассматриваемая здесь книга Эдварда Йордана является, по существу, руководством по решению следующих проблем:

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

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

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

Под безнадежным проектом понимается такой проект, параметры которого отклоняются от нормальных значений по крайней мере на 50%.

Но это обычно означает наличие одного или нескольких ограничений из перечисленных ниже.

• План проекта сжат более чем наполовину по сравнению с нормальным расчетным планом; таким образом, проект, требующий в нормальных условиях 12 календарных месяцев, приходится выполнять за шесть или менее месяцев. Жесткая конкуренция на мировом рынке делает такую ситуацию наиболее распространенной.
• Количество разработчиков уменьшено более чем наполовину по сравнению с действительно необходимым для проекта данного размера и масштаба. Это может быть результатом наивной веры в магические возможности новых CASE-средств или языков программирования либо сокращения штатов компании вследствие реорганизации, реинжиниринга и т. д.
• Бюджет и связанные с ним ресурсы урезаны наполовину. Зачастую это происходит из-за сокращения компании или конкурентной борьбы за выгодный контракт. В итоге, например, может быть принято решение привлечь относительно недорогих и неопытных молодых разработчиков вместо опытных дорогостоящих специалистов.
• Требования к функциям, возможностям, производительности и другим техническим характеристикам вдвое превышают значения, которые они могли бы иметь в нормальных условиях.

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

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

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

Заметим, что существуют и другие определения безнадежных проектов, отличные от данного. Например, Том Демарко утверждает, что безнадежные проекты всегда характеризуются следующими тремя особенностями:

• атмосфера страха, существующая в компании;
• отсутствие оправдывающих обстоятельств (бессмысленность проекта);
• обреченность на неудачу.

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

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

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

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

• небольшие проекты — проектная команда включает менее 10 человек, работает в исключительно неблагоприятных условиях и должна завершить проект в срок от трех до шести месяцев;
• средние проекты — проектная команда включает от 20 до 30 человек, протяженность проекта составляет один-два года;
• крупномасштабные проекты — проектная команда включает от 100 до 300 человек, протяженность проекта 3-5 лет;
• гигантские проекты — в проекте участвует армия разработчиков от 1000 до 2000 человек и более (включая, как правило, консультантов и соисполнителей), протяженность проекта от 7 до 10 лет.

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

ПРИЧИНЫ, ПОРОЖДАЮЩИЕ БЕЗНАДЕЖНЫЕ ПРОЕКТЫ

В число основных причин, порождающих безнадежные проекты, входят следующие:

• политика;
• наивный оптимизм заказчиков и разработчиков;
• высокая конкуренция;
• неожиданные кризисы.

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

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

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

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

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

Начинающие компании временами оказываются подверженными так называемому синдрому "морского корпуса" ("Настоящие программисты не нуждаются в сне!"), однако гораздо чаще его приходится наблюдать в консалтинговых организациях вроде EDS и аудиторских фирм "Большой шестерки". Этот синдром может быть отражением особенностей характера основателей фирмы или внутрикорпоративной культуры с самого ее основания. Так, например, обстоит дело с корпоративной культурой Microsoft.

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

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

Конкуренция на расширяющемся рынке зачастую вызывает защитные меры, но может также привести к активной и агрессивной политике. Аналогично, появление принципиально новой технологии может вызвать у компании, которую вполне устраивают продукты, созданные с помощью прежней технологии, защитную реакцию; либо может привести к смелому решению использовать новую технологию для получения преимущества в конкурентной борьбе. Очевидный пример такого феномена — технологии, подобные Java или World Wide Web. Самое замечательное в индустрии ПО, что такие технологии появляются каждые несколько лет.

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

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

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

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

С другой стороны, можно также привести много примеров повышения степени регулирования со стороны властей — особенно в области налогообложения, аудита, рынков ценных бумаг, охраны окружающей среды и т. д. В любом демократическом обществе о таких решениях должно быть известно задолго до их принятия, поскольку законодательные органы обсуждают их в деталях в течение нескольких месяцев или даже лет, пока не примут в окончательном виде. Однако зачастую конкретные детали решений могут оставаться неясными до последнего момента, и типичная реакция высшего руководства компаний заключается в игнорировании всех проблем, пока они не станут неизбежной реальностью. (Подобная ситуация может возникнуть в ближайшее время в связи со сменой правительства и руководства ЦБ РФ.)

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

На практике становится все труднее и труднее предвидеть и планировать все возможные кризисы, которые случаются в мире бизнеса (эти слова также можно соотнести с нынешней ситуацией в России). Даже если кризис можно предвидеть, все равно безнадежные проекты начинаются, поскольку руководство склонно отмахиваться от проблем до самого последнего момента. Как еще можно объяснить панику, охватившую многие IS/IT-организации, когда на горизонте замаячила проблема 2000 года? Все давно знали о наступлении 1 января 2000 года и знали, что этот конечный срок никак нельзя отодвинуть. В любом случае, непредвиденный кризис может повлечь за собой самые разнообразные безнадежные проекты. В худшем случае конечный срок таких проектов — "вчера, если не раньше", поскольку кризис уже наступил и ситуация будет ухудшаться до тех пор, пока внедрение новой системы не позволит решить проблемы. В других случаях, например при неожиданном увольнении основных разработчиков, нормальный в обычных условиях проект превращается в безнадежный из-за нехватки рабочей силы и потери ключевых интеллектуальных ресурсов.

ПРИЧИНЫ, ПОБУЖДАЮЩИЕ УЧАСТВОВАТЬ В БЕЗНАДЕЖНЫХ ПРОЕКТАХ

По мнению автора, таких причин несколько:

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

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

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

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

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

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

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

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

ОТНОШЕНИЕ Э. ЙОРДАНА К БЕЗНАДЕЖНЫМ ПРОЕКТАМ

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

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

(Японцы по этому поводу говорят: "Кому не удалось подняться на гору Фудзи — тот дурак. Тот, кто поднялся на гору Фудзи дважды, еще больший дурак".)

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