Читаем Путь камикадзе полностью

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

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

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

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

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

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

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

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