Ключевые роли коллектива разработчиков и задача определения кадровых ресурсов проекта

Руководство коллективом разработчиков — постоянная задача менеджера. Очень часто она выходит за пределы проекта, поскольку опытный менеджер, когда берется за проект, всегда имеет в виду команду, с которой ему будет комфортно работать, которая справится с заданием вполне гарантированно. Подобные команды не складываются сразу, а формируются в процессе выполнения проектов. В конечном счете за руководство стоит браться только тогда, когда есть шанс в процессе выполнения работ получить такую команду.

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

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

Не надо путать понятия ключевой роли и ключевого работника. Первое носит характер, отстраненный от персоналий коллектива, а второй соотносится именно с коллективом. Часто случается, что некоторые первоначально не зарекомендовавшие себя исполнители, а потому не занимающие высоких позиций в управлении проектом, фактически берут на себя ответственность за проект, подсистему и т.д. и в результате становятся ключевыми работниками. И тогда менеджеру приходится изменять стиль руководства — он уже не может принимать решения, не считаясь с мнением образовавшейся лидирующей группы. Когда такая ситуация становится явной, нужно соответственно пересматривать расстановку сил. Попросту говоря, стоит попытаться изменить управляющую структуру проекта. Но нужно учитывать и то, что такое изменение потенциально конфликтно, а потому повышает уровень риска.

Намного лучше, когда лидерство сотрудников обнаруживается или заранее известно на ранней стадии проекта. Это позволяет сразу правильно выстроить административную структуру. Тем не менее и здесь есть свои подводные камни. Не все лидеры готовы или хотят брать на себя управленческие обязательства. В этом случае лучше с самого начала назначить администратора, который освободит фактического лидера от перманентных административных проблем. Другая проблема — соперничество за лидерство в коллективе, что является потенциально рискованной для проекта ситуацией. Если такое случается, а еще лучше, когда соперничество только зарождается, сразу же разделить сферы ответственности конкурентов.

В принципе правильная неформальная структура в коллективе предполагает лидерство одной персоны. Если лидером является менеджер проекта, то это хорошо сказывается на исполнительности работников и благотворно влияет на коллектив и ход развития проекта. Но и здесь существует риск: возможно формирование так называемой групповой мысли ( термин, предложенный Дженисом в [ 40 ] для обозначения ситуации, когда ценные рабочие качества членов группы не используются из-за преданности их обладателей команде ), которая приводит к подавлению инициативы. Чтобы избежать этого, необходимы специальные меры: заседания, на которых все члены команды вынуждены так или иначе высказывать собственное мнение, приглашение независимых экспертов для анализа решений группы и т.д.

Есть еще одна причина, по которой ситуация с менеджером в качестве лидера может отрицательно сказываться на результативности выполнения проекта: в таком случае ему неизбежно придется вникать в детали производственного процесса, которые не соответствуют менеджерской функции распределения ресурсов, работ и контроля.

Наличие единственного лидера в группе, на которого может положиться менеджер проекта, — одна из главных предпосылок формирования продуктивно работающего коллектива. Но если появляется противодействующий лидер, ситуация в проекте становится крайне неустойчивой. И менеджеру нужно всячески избегать ее: распознавать противодействие как можно раньше, быть терпимым и терпеливым при обсуждении вариантов решений даже тогда, когда кажется, что решение лежит на поверхности. Следует подчеркнуть, что в такой ситуации "хирургическое вмешательство" способно разрушить коллектив со всеми вытекающими отсюда последствиями. Борьба с лидером, особенно со скрытым неформальным лидером, к тому же заметная членам команды, также плохое средство. Она может быть действенной только в тех случаях, когда руководитель уверен в своей победе без административных воздействий. По сути, такая борьба должна рассматриваться в рамках мер по смене лидера команды. И наиболее трудной она оказывается тогда, когда противодействующий лидер выполняет одну из ключевых ролей в проекте.

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

Следующий перечень ключевых ролей характеризует наиболее типичные ситуации для программных проектов:

• архитектор проекта;
• проектировщики подсистем;
• руководители команд разработки подсистем;
• специалист по пользовательскому интерфейсу;
• эксперт предметной области

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

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

В начале проекта роль специалиста по пользовательскому интерфейсу считать ключевой обычно не требуется. Это бывает, когда основная нагрузка проекта связана не с функциональностью системы, а с тем, какое управление потребуется пользователям. И именно тогда целесообразно привлекать специалиста по пользовательскому интерфейсу к решению стратегических вопросов.

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

Кандидаты на ключевые роли — основа коллектива. Заполнение других вакансий определяется, когда такая основа имеется, зачастую даже в ходе развития проекта и по мере необходимости. Поскольку первые участники проекта отвечают только за исследования и анализ осуществимости проекта, для начала минимально необходимыми участниками являются те, кто будет выполнять роли архитектора и эксперта предметной области. Но это не значит, что нужно откладывать решение вопроса об остальных персоналиях. Именно до начала проекта надо определить в общих чертах, с кем в дальнейшем предстоит иметь дело менеджеру.