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