Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте - Йордон Эдвард Страница 13

В данной главе будут обсуждаться три аспекта политики:

1) идентификация политических «игроков», вовлечённых в проект;

2) определение сущности проекта;

3) отношение участников к проекту.

2.1 Идентификация «игроков», вовлечённых в проект

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

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

Поэтому, если участник проекта сталкивается с совершенно невинным, на первый взгляд, телефонным звонком, почтовым сообщением или как бы случайным вопросом типа «Как движется проект?», который задаёт дружелюбным тоном один из менеджеров среднего звена, для участника проекта важно знать, кто к нему обращается – друг или враг, и не содержит ли в связи с этим вопрос политический подтекст. Что бы вы не ответили на такой вопрос, ответ, скорее всего, станет достоянием всей организации, и ничего удивительного, если содержащаяся в нем информация будет утрирована, искажена или скрыта.

Типичными «игроками» в безнадёжном проекте являются следующие:

4) владелец;

5) заказчик;

6) акционер;

7) заинтересованное лицо;

8) защитник.

Каждая из этих ролей будет обсуждаться ниже.

2.1.1 Владелец

Традиционно владелец – это человек, который принимает, санкционирует или финансирует систему и/или результаты проекта. Чрезвычайно важно идентифицировать этого человека и сделать все возможное, чтобы он был удовлетворён ходом проекта.

Удивительно, как много проектов выполняются без малейшего представления их участников о том, кто является владельцем; это особенно типично для организаций, где проекты порождаются честолюбием и сверхэнергией IT-профессионалов, которые стремятся перещеголять друг друга утверждениями вроде «держу пари, что отдел маркетинга придёт в экстаз, когда увидит эту новую систему, которую мы разрабатываем для них». Очевидно, в организациях с грамотным руководством такие проекты никогда не смогут начаться – но главное, что я хотел здесь сказать – можно с трудом найти такие безнадёжные проекты, которые начались бы без чёткого распоряжения со стороны владельца. Причина очевидна: такие проекты чрезвычайно дороги и/или рискованны и/или ограничены по срокам. Невероятно, чтобы IS/IT-подразделение выдумало такой проект по собственной инициативе, и нормальные бюрократы в организации не позволят включить его в план и финансировать до тех пор, пока не получат чёткое и недвусмысленное указание от того, кто имеет на это право.

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

С другой стороны, это не означает, что вся руководящая иерархия куда-то исчезла; наоборот, одна из проблем во многих безнадёжных проектах заключается в том, что менеджер проекта совсем мало или вообще не контактирует непосредственно с владельцем проекта. Различные распоряжения и требования об отчётах о состоянии проекта могут спускаться вниз по цепочке от владельца к менеджеру среднего уровня, который является как раз непосредственным начальником менеджера проекта. И все эти посредники между реальным владельцем и менеджером проекта могут быть, говоря вышеуказанными терминами, пользователями, акционерами, заинтересованными лицами или чемпионами – или политическими противниками проекта.

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

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

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

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

2.1.2 Заказчики

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