ПРЕДИСЛОВИЕ

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

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

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

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

Проработав в индустрии ПО более 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.

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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