Путь камикадзе

Эдвард Йордон

Путь камикадзе

ПРЕДИСЛОВИЕ

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

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

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

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

Проработав в индустрии ПО более 30 лет, я обнаружил, что наша профессия весьма интересно воспринимает безнадёжные проекты. В некоторых областях индустрии ПО, особенно в Силиконовой Долине, такие проекты окружены ореолом славы, как испытание силы духа и стойкости, нечто наподобие покорения Эвереста босиком. Я сам разделял эти убеждения во время моих первых проектов в середине 60-х годов, и не секрет, что такие же взгляды превалируют у следующего поколения, что наводит меня на мысль о постоянстве этого феномена, поскольку технология продолжает развиваться такими же быстрыми темпами, как это было в моё время. Наша индустрия ещё не достигла зрелости. Каждый год появляется новый Эверест и новая масса отчаянных программистов, которые уверены, что смогут пробежать босиком весь путь до вершины.

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

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

Без сомнения, в этом есть некоторая доля правды. Управляя нашими проектами, мы совершаем множество глупых ошибок, наше высшее руководство увлекается смехотворными политическими играми и наши пользователи предъявляют к нам непомерно высокие требования. Я убеждён, что это в основном объясняется высоким темпом изменений в окружающем мире, а также обычным неуважением каждого нового поколения к советам и опыту предыдущего поколения. Зачем сегодняшнему поколению Java-ориентированных фанатиков уделять хотя бы какое-нибудь внимание советам моего поколения, которое обладает 30-летней давности опытом программирования в автокоде и на ассемблере? И как сегодняшнее поколение пользователей в бизнесе может узнать, какое Web-приложение для них наиболее приемлемо, если они знают только об использовании их предшественниками онлайновых систем на мэйнфреймах с символьными, монохромными и немыми терминальными интерфейсами?

Каким бы ни было объяснение этого феномена, я уже пришёл к следующему трезвому заключению: безнадёжные проекты являются нормой, а не исключением. Я полагаю, что сегодняшние разработчики ПО и менеджеры проектов достаточно изобретательны и полны желания управлять проектами разумным образом; я также полагаю, что сегодняшние пользователи и высшее руководство обладают гораздо большей компьютерной грамотностью, чем предыдущее поколение, и гораздо менее наивны относительно результатов, которые можно ожидать от разработчиков ПО в условиях ограниченных ресурсов. Однако это не останавливает и тех, и других от участия в очередном безнадёжном проекте, поскольку это диктуется необходимостью выживания в конкурентной борьбе, а также заманчивыми возможностями, предлагаемыми новыми технологиями. Бизнес-менеджеры могут вполне осознавать, что при разумном планировании разработка новой системы займёт 12 календарных месяцев, однако в то же время они будут настойчиво утверждать, что отсутствие готовой системы через 6 месяцев позволит конкурентам захватить весь рынок и вытеснить их новый продукт или услугу. Аналогично, технические специалисты могут вполне осознавать высокий риск использования новых технологий, таких, как Internet, однако они также будут утверждать, что новая технология в случае успеха обеспечит им стратегическое преимущество в конкурентной борьбе, и это оправдывает любой риск.

С другой стороны, отчёты таких организаций, как Standish Group, а также статистические данные таких авторитетных экспертов, как Capers Jones, Howard Rubin, Paul Strassman и Larry Putnam, говорят о том, что в среднем продолжительность проекта превышает плановую на 6-12 месяцев, а стоимость превышает бюджет на 50-100%. Конкретная ситуация зависит от размера проекта и ряда других факторов, но в любом случае суровая реальность заставляет вас предполагать, что условия вашего проекта повлекут за собой некоторую степень обречённости на неудачу, и это отразится на поведении менеджера проекта и его технических специалистов. Если проект с самого начала характеризуется высокой степенью риска, это наверняка повлечёт за собой массу сверхурочной работы, потерянных выходных, и, скорее всего, массу эмоциональных и физических стрессов до самого его завершения. Если даже проект начинается в разумной и спокойной обстановке, все равно велика вероятность, что по мере своего продолжения он выродится в безнадёжный – то ли первоначальные план и бюджет окажутся крайне нереалистичными, то ли у пользователей появится много новых требований, которые никак не учитывались при составлении первоначального плана и бюджета.

Итак, спрашивается: если невозможно избежать безнадёжных проектов, как их можно выдержать? Что следует предпринять для повышения своих шансов на успех? Когда следует быть готовым к компромиссу – и когда следует быть готовым уйти в отставку, если дальнейшее продолжение работы невозможно? Именно об этом идёт речь в данной книге. Очевидно, решение перечисленных проблем затрагивает такие вопросы, как кадровое обеспечение, процессы и методологии, а также методы и средства. Если вы собираетесь руководить безнадёжным проектом, следует ли настаивать на свободе выбора при формировании проектной команды? Следует ли занимать твёрдую позицию в отношении процессов и методологий, таких, как модель SEI-CMM, или следует позволить проектной команде отказаться от любых формальных методологий, если они считают, что это поможет им нормально выполнить работу? Следует ли настаивать на использовании определённых языков программирования, рабочих станций и CASE-средств, или более важно активно участвовать в политических баталиях?

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

Если в этот момент вы решили, что у вас нет времени читать всю книгу, скажу только одно слово, которое может окупить время, потраченное на чтение предисловия: приоритетность (triage). Если вы участвуете в безнадёжном проекте, почти наверняка окажется недостаточно ресурсов, чтобы реализовать всю функциональность и возможности ПО, которые требуются конечному пользователю, в рамках утверждённого плана и бюджета. Так или иначе придётся решать, какие возможности следует реализовывать в первую очередь, а какими можно пожертвовать. Действительно, некоторые из незначительных возможностей не будут реализованы никогда, поэтому самое лучшее – это дать им спокойно умереть собственной смертью. Другие возможности являются достаточно важными, но также относительно легко реализуемыми, например, с помощью поставляемой библиотеки классов или используемых вами CASE-средств. Говоря языком медиков, эти возможности выживут сами по себе. Успех или неудача безнадёжного проекта зачастую зависит от способности проектной команды выделить критические функции и возможности, которые нельзя реализовать, не вкладывая значительные ресурсы и энергию.

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

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

Кроме всего прочего, я намереваюсь постоянно собирать на своём Web-сайте (http://www.yourdon.com) информацию и практические рекомендации от различных проектных команд по поводу наилучшей практики, наихудшей практики и разнообразных проблем. Даже если в вашем проектном бюджете недостаточно денег на покупку этой книги (такой крохотный бюджет уже говорит о рискованности проекта!), ровным счётом ничего не стоит обратиться к Web-странице.

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

ГЛАВА 1.

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3 Почему существуют безнадёжные проекты?

Если вы задумываетесь о том, что происходит в вашей организации, нетрудно понять, почему существуют безнадёжные проекты. Как отмечает Scott Adams [2]:

Когда я впервые услышал эти истории [о неразумном корпоративном поведении], я пришёл в недоумение, однако после тщательного анализа я разработал сложную теорию, объясняющую такое странное поведение. Она заключается в следующем: люди – это идиоты.

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

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

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

Таблица 1.1. Причины безнадёжных проектов

1.3.1 Политика, политика, политика

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

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

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

Что если ваш менеджер открыто соглашается с вами? Что если он отвечает: «Да, на самом деле весь этот проект не более, чем ожесточённая схватка между вице-президентом Смитом и вице-президентом Джонсом»? Если это так, почему же тогда сам менеджер участвует в этом проекте? Для этого, как сказано ниже в подразд. 1.4, может быть множество причин; но причины, заставляющие менеджера участвовать в проекте, совсем не обязательно должны заставлять и вас. Неизбежное зло политики не означает, что вы должны немедленно бросить проект или совсем уволиться с работы, однако, что бы там не происходило в проекте, следует отстаивать свои собственные приоритеты, цели и моральные ценности – особенно потому, что скорее всего многие принимаемые решения (начиная с решений по плану/бюджету/ресурсам, превративших проект в безнадёжный с самого начала) не соответствуют интересам пользователей и организации в целом. Если проект все же увенчается успехом, то это скорее всего либо счастливая случайность, либо означает, что намеченный козёл отпущения (например, ваш непосредственный руководитель или менеджер более высокого уровня) оказался более хитрым политиком, чем считали его противники.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3.6 Высокая конкуренция, порождённая глобализацией рынков

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

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

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

1.3.7 Высокая конкуренция, вызванная появлением новых технологий

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

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

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

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

Хотя все это может восприниматься участниками старой проектной команды (теми, кто помнит «старое доброе время» языков FORTRAN II и Ассемблера) как неприятный опыт, важно помнить, что молодые технари и менеджеры предпочитают эти новые технологии именно потому, что они новые. И это те же самые люди, которых я ранее характеризовал как наивных оптимистов по отношению к тем условиям ограниченных планов и бюджетов, в которых они работают. Что же удивительного в том, что все работают до позднего вечера и в выходные, пытаясь придать экспериментальной новой технологии некоторое подобие работоспособной, а проекты при этом вырождаются в безнадёжные?

1.3.8 Сильное воздействие неожиданных правительственных решений