№ 8: Используйте руководителей проекта

05.12.2011 г.

Руководители проекта — это члены команды, которые выполняют следующие функции:

       — Возглавляют определение успешного продукта.
       — Возглавляют распространение видения продукта.
       — Возглавляют движение команды к гарантированной поставке продукта.
       Возможно, легче определить, кем не является руководитель проекта, чем описать его роль более конкретно. Эффективный руководитель проекта — это совсем не то, что подчас думает о себе номинальный руководитель проекта.
       Руководитель проекта имеет мало официальной власти (или вообще ее не имеет). Сначала это открытие вызывает у руководителя проекта значительное беспокойство. Начинающий руководитель проекта часто думает, что он будет писать спецификацию продукта, а все остальные будут реализовывать, тестировать и документировать его грандиозное видение во всех деталях. Такое представление — взгляд, в лучшем случае, наивный, а в худшем, — глупый и разрушительный. Чтобы руководитель проекта был полезен команде, предварительно нужно вывести его из заблуждения, что он обладает какой-либо прямой властью. К счастью, в здоровой команде, никому не придется предпринимать для этого специальные шаги: коллеги быстро избавят его от иллюзий, если он их еще питает.
       Конечно, такой ход событий, поначалу, будет расстраивать начинающего руководителя проекта. Он попытается выпросить у своего шефа дополнительные полномочия. Если недальновидный шеф пойдет ему навстречу, — это послужить началом для дальнейших глупостей. (См. эмпирическое правило №9: Будь властью, но не фигурой власти).
       Мне приходилось наблюдать различные реакции при подобном первом разочаровании. Наиболее типичная реакция руководителя проекта, заключается в том, что он отрицательно отзывается об истинной роли руководителя проекта — о лидерстве. Это отношение обычно формулируется, как отказ от “политической ерунды”. В дополнение к пониманию динамики технологии ПО, лидерство в разработке ПО требует глубокого понимания человеческой природы и осознания глубинных мотивов и чувств, определяющих поведение команды. При возникновении трудностей, в ходе их преодоления, некоторые руководители проектов ищут объяснение их появления в отрыве от собственной персоны, представляя себя в самом выгодном свете. В обществе, где технические возможности имеют высшую ценность, принято считать слово “политик” главным ругательством. Это конечно удобно, потому что мастерство технологии гораздо проще, чем мастерство лидерства.
       В действительности, когда люди жалуются на “политику”, они выражают недовольство неразберихой, возникающей в результате некомпетентного лидерства. К несчастью, эта неразбериха в организационных вопросах встречается много чаще, чем порядок, который мы представляем в своем воображении. (Обвинение в излишней “политике” может привести к серьезным неудачам. Но к нашему случаю это отношения не имеет.) Есть единственный момент, когда диагноз “политика” является точным. Это момент, когда руководитель проекта понимает, что его окружение некомпетентно и убийственно для проекта. После этого единственного момента озарения, руководитель проекта несет ответственность за свое неизменное пребывание в нездоровом окружении. Почему же руководитель проекта (или другой член команды) выбирает иногда нездоровое окружение? Потому, что в этом случае он поддерживает своих товарищей по несчастью.
       Хотя вначале многие руководители проекта не имеют ясного представления о своей роли, неуверенны в своем вкладе в проект, и презирают “политику”, постепенно они получают значительную власть вследствие исполнения своих функций, перечисленных в начале раздела — функций лидера. Группа руководителей проекта должна быть университетом лидерства в разработке ПО.
       Управление проектом является технической задачей. Есть два аспекта технического мастерства: (1) технология, используемая при создании продукта и (2) технические аспекты лидерства при создании ПО, которые в большинстве своем и являются предметом нашей книги. Руководитель проекта должен владеть многими искусствами. Он должен уметь уговаривать, содействовать, внушать вдохновление, требовать совершенства и эффективной работы от остальных членов команды. Руководитель проекта должен знать все ходы и выходы для выпуска ПО в срок. Он должен применять лучшие практические методы, которые обеспечивают спецификацию качественного продукта и работоспособные технологии. И наконец, он должен быть представителем команды для прессы, клиентов и руководства корпорации.
       Руководитель команды находится в тесном контакте с духом группы. Ондолжен быть эффективным переговорщиком и отличным слушателем,иметь дар эмоционального общения. Руководитель проекта является сердцем разработки ПО.

Дух группы

       Здесь я хочу изложить очень важную идею, к которой часто буду возвращаться позже. Формулируется идея просто: Программное обеспечение выражает команду, его создавшую. Все, что вам нужно знать о команде может быть открыто при анализе ПО, и наоборот. Я выдвигаю эту идею на первый план, потому что, с моей точки зрения, она является базисом управления разработкой ПО. Слова и поведение команды в любой момент времени могут сбивать с толку, но ПО обманывать не может. Оно неизбежно выразит все слабые и сильные стороны, которыми обладает команда. Если есть сомнения, обратитесь к ПО. Может быть, ваша интерпретация будет поверхностной, если речь зайдет о конкретной последовательности битов. Но если вы внимательно изучите продукт, то вам даже не надо будет знать команду, чтобы понять что в ней неправильно. Самовыражение нельзя подавить в процессе создания ПО. В коробке с ПО лжи быть не может.
       Эта идея является базисом теории управления созданием ПО. Без ПО, как такового, нет второй части уравнения Команда = ПО.
       Основной принцип следующий: если вы не можете понять, что у вас происходит в команде, посмотрите на ПО. Если команда и ПО говорят одно и то же, то вы можете действовать с определенной степенью уверенности. Наоборот, если ПО не достигло желаемого состояния, то способ привести его в порядок лежит в анализе проблем в команде.
       Я написал уравнение Команда = ПО, но что такое, в самом деле, команда? Что это за среда, с которой вы работаете, как лидер команды? Я убежден, что ключ к созданию качественного ПО — поддержание постоянного контакта с тем, что я называю “дух команды”. Это понятие в духе Юнга является достаточно абстрактным. Я вижу результаты анализа духа группы следующим образом:
       Существует коллектив единомышленников, пытающихся создать предмет интеллектуальной собственности.
       Индивидуальное творчество — это таинственная, безграничная человеческая энергия, идущая от подсознания, обогащенная эмоциями и ограниченная возможностями человеческого мозга и техническим мастерством.
       То, что группа людей искренне посвящает себя коллективному творчеству, значительно усложняет индивидуальные творческие порывы. Они перемешиваются в сложной, наполненной энергией структуре коллективных отношений.
       Лидерство в этой ситуации становится важным аспектом в межличностном общении.
       То, что усиливает творческие порывы членов команды, может объединиться в дух группы при условии, если сложные чувства и идеи могут свободно передаваться внутри команды.
       Дух группы можно рассматривать как совокупность индивидуальных духов членов группы. Индивидуальный дух — это, можно сказать, та часть индивидуума, которая позволяет ему чувствовать, думать и рассуждать.
       Любые негативные явления в команде являются результатом игнорирования духа группы.
       Конечно, возникает вопрос: “Как заботиться о правильном формировании духа группы? Как его создать?” Ответом, по моему мнению, является данная книга.

My Fairy Tales

№ 8: Используйте руководителей проекта