Об этом важно помнить, поскольку изначальные требования владельца проекта могут быть легко искажены, пока достигнут менеджера проекта. Наиболее часто тем аспектом безнадёжного проекта, по которому не удаётся достичь соглашения, является конечный срок: новая Супер-Система однозначно и безусловно должна быть закончена к 1 января, иначе наступит конец света! Однако, пока это указание доберётся вниз по иерархической лестнице до менеджера, оно с помощью бюрократии обрастёт целым слоем дополнительных требований, например: в качестве языков программирования использовать только Ada и RPG; в проектную команду нужно обязательно включить Джорджа, Харриет и Мелвина (потому что они настолько некомпетентны, что их не берут ни в один проект; в проекте должна использоваться вновь созданная (но никогда не использовавшаяся ранее) объектно-ориентированная методология; проектная команда должна еженедельно проверяться на предмет того, правильную ли методологию она использует; каждый участник проектной команды должен в конце каждого рабочего дня заполнять 17-страничную форму XJ13 в трех экземплярах; … и так можно продолжать до бесконечности.

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

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

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

2.1.2 Заказчики

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

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