Многие разработчики и менеджеры могут задать вопрос: разумно ли вообще планировать безнадежные проекты. John Boddie, автор Crunch Mode, таким образом высказался относительно отрасли, в которой ему довелось работать:
Я провел годы в лотерейном бизнесе, где все делается в экстремальных условиях, поскольку это единственный способ существования и развития отрасли. Если вы не желаете работать в таком режиме, то не сможете играть в этой песочнице. Разработчики в данной отрасли мирятся с таким положением, поскольку им доставляет удовольствие добиваться успеха в краткосрочных и в высшей степени интенсивных проектах и получать взамен значительную свободу действий, включая, в частности, двухмесячные отпуска между проектами. Эти команды считают себя элитой, и компании всячески поддерживают такие убеждения.
И, как отмечает Doug Scott:
Руководством движут различные мотивы. Они знают, что риск лишиться своей власти в наши дни особенно велик, и стремятся этого избежать, затевая различные проекты. Они также понимают, что на их выполнение нам потребуется не так уж мало времени из-за различных бюрократические процедур. Они полагают, что если особо обозначить важность конкретного проекта по сравнению с остальными, то эти процедуры можно будет обойти, не предпринимая для этого никаких специальных действий. Они понимают, что не могут привлечь к этой работе самых лучших специалистов; они также понимают, что самые лучшие технологии могут помочь в том случае, если они не потребуют длительного цикла обучения, что, в свою очередь, лишает возможности использовать такие технологии в данном проекте. Или наоборот, они верят шумной рекламе и считают, что новые технологии чудесным образом окажутся вполне зрелыми, свободными от ошибок, и их тотчас же сможет понять каждый.
Однако, если безнадежные проекты являются нормой, следует ли тогда называть их безнадежными? Не становятся ли они частью корпоративной культуры? Далее мы обсудим, почему такая трансформация может иметь место в нормальных организациях-разработчиках ПО, и затем перейдем к более серьезному вопросу: каким образом можно изменить культуру обычной сегодняшней организации с тем, чтобы она могла эффективно справляться с безнадежными проектами, не считая их какой-то аномалией?
7.1 Почему безнадежные проекты становятся нормой
Начнем с анализа вероятности того, что безнадежные проекты будут становиться нормой. На протяжении всей книги я приводил по крайней мере три причины, по которым это могло бы стать реальностью:
· Организация находится в разгаре продолжающегося кризиса – это может быть результатом неудачного совпадения нескольких неожиданных кризисов, случившихся за небольшой промежуток времени; однако чаще это относится к организациям, оказавшимся в трудном положении, отчаянно пытаясь справиться с «потоком изменений» на рынке или с используемой технологией. В большинстве случаев такие организации оказываются в слишком отчаянном положении, чтобы суметь отступить на шаг назад и реорганизовать свою работу таким образом, чтобы спокойно планировать и выполнять все свои проекты. Редким исключением является ситуация, когда в компанию приходит новый руководитель, призванный вывести ее из кризиса; при этом он может внедрить в компании совершенно иной стиль работы.
· Руководство и пользователи принимают такой подход в качестве своей стандартной позиции во время переговоров – как отмечалось в главах 1 и 2, в таком духе зачастую начинается первый безнадежный проект; однако, если такой подход сработает один раз, почему бы не повторить его снова? Если департамент маркетинга или департамент финансов, или некоторое другое подразделение в организации столкнется с необходимостью «перманентного» реинжиниринга для достижения конкурентоспособного уровня, они могут также принять соответствующее решение и настаивать, чтобы все разработчики и поставщики, с которыми они взаимодействуют, аналогичным образом подвергли себя реинжинирингу. С точки зрения таких подразделений департамент информационных технологий рассматривается как еще один «поставщик» продуктов и услуг. Вариацией на эту тему является указание высшего руководства департаменту информационных технологий: «Если ваши люди не улучшат радикально свою продуктивность во всех проектах, мы отдадим все на аутсорсинг в Индию!»
· Это часть «стратегического преимущества» компании – такой подход может иметь место в организациях, подобных EDS, и он является вполне определенным в таких организациях, как Cambridge Technology Partners. Он имеет смысл для консалтинговых организаций, где производительность проектных команд является их бизнесом. Однако, мы можем легко вообразить такую же ситуацию в других областях деятельности, связанных с информационной индустрией, таких, как банковское дело, страхование и телекоммуникации – там, где способность продвинуть новый программный продукт на рынок в значительной степени зависит от скорости его разработки. В той мере, в какой сказанное справедливо, я ожидаю появления все большего и большего количества организаций, прививших у себя культуру безнадежных проектов.
Однако то, что имеет некоторый смысл для организации в целом, совсем не обязательно должно иметь такой же смысл для отдельных разработчиков и менеджеров проектов. Точка зрения организации имеет, безусловно, важное значение, однако я хочу уделить основное внимание точке зрения разработчика и менеджера; в конце концов, я не слишком надеюсь на то, что многие директора и вице-президенты по маркетингу прочтут эту книгу.
Главный вопрос для разработчика и менеджера проекта заключается в следующем: если удалось пройти через один безнадежный проект, следует ли повторять этот опыт снова? Как можно себе представить, ответ на этот вопрос существенно зависит от того, насколько успешным был первый проект. В конце концов, если вы только что завершили «самоубийственный» или «отвратительный» проект, то, скорее всего, находитесь в состоянии физического и эмоционального истощения. Вашему самолюбию нанесен серьезный урон, личная жизнь, возможно, оказалась разрушена. Кто на целом свете захочет еще раз повторить такое? Даже так называемые проекты «камикадзе», где вы жертвуете своими личными потребностями в угоду столь возвышенным (но проигрышным) целям корпорации, могут в конце концов оказаться несостоятельными. Вы можете считать свою жертву благородной, однако если вы не выступаете в амплуа страдальца, то вряд ли вам захочется добровольно повторить этот эксперимент.
Отметим, что «отвратительный» проект, как говорилось в главе 1, может закончиться успешно; таким образом, у высшего руководства и пользователей будет повод для хорошего настроения. У менеджера проекта тоже может быть такой повод, особенно если он к концу проекта собрал хороший урожай в виде разнообразных вознаграждений. Если вы – один из участников команды, успешно прошедший через проект, вы можете быть довольны результатами, а можете и нет; в конце концов тот факт, что пролито море крови и причинен вред многим жизням и карьерам, может вас и не беспокоить. В самом деле, это становится частью корпоративной культуры – не обращать внимания на чужую кровь, которая проливается во имя проекта.
Очевидно, наибольшими шансами найти добровольцев для повторения опыта обладает проект «невыполнимая миссия»: проект, который не только успешно завершился, но и внушил каждому чувство истинной гордости за то чудо, которое они сотворили. Если по окончании проекта есть время покопаться в его результатах, то в этот момент крайне важно ответить на вопрос: «За счет чего мы сумели добиться успеха?» Было ли это всего лишь везением? Может быть, это полностью зависело от харизмы менеджера проекта, или от гениальности проектировщика базы данных, или от того, что конечный пользователь и системный аналитик безумно влюбились друг в друга и поженились к концу проекта? Основной вопрос заключается в следующем: существует ли какая-нибудь разумная причина ожидать, что мы сумеем повторить этот фокус?
На эти вопросы важно ответить как можно раньше, поскольку организация, скорее всего, захочет повторить опыт независимо от желания отдельных личностей. Как было отмечено выше, в экстремальной ситуации организация поступает так, поскольку она вынуждена это делать; некоторые организации достаточно долго движутся к своему концу, и последние пять-десять лет были не чем иным, как бесконечной вереницей безнадежных проектов. Даже в менее экстремальных ситуациях неудачи одного безнадежного проекта может быть недостаточно, чтобы заставить организацию отказаться от подобного подхода; как отмечалось в предыдущих главах, в провале зачастую обвиняют менеджера проекта или новую технологию. «В следующий раз», - клянется директор, - «мы не повторим те же самые ошибки; у нас будет новый менеджер проекта и новая супертехнология».
Разумеется, если первый же безнадежный проект закончится успешно, вероятность того, что конечные пользователи и высшее руководство попытаются его повторить, будет гораздо выше; однако, может наступить момент, когда участники проектной команды решать сделать ручкой и станцуют конгу по направлению к двери. Пугать такой акцией бессмысленно; руководство обычно полагает, что легко найдет новых добровольцев. Самое лучшее, что могут сделать доведенные до изнеможения участники проекта – это пожелать всем доброго здоровья и отправиться искать более спокойных и нормальных условий существования где-нибудь в другом месте.
7.2 Учреждение «культуры» безнадежных проектов
Давайте предположим, что некоторая организация решила изменить свою культуру и начала выполнять все свои проекты в стиле безнадежных. Как было отмечено выше, это может произойти без какого-либо осознанного решения и независимого от того, желают ли отдельные личности примириться более чем с одним безнадежным проектом. Предположим, тем не менее, что это сознательная стратегия руководителей, отвечающих за информационные технологии, или еще более высокого руководства, которому они подчиняются. Какими будут последствия и как типичная организация может осуществить такие изменения?