учебники, программирование, основы, введение в,

 

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

Руководство коллективом разработчиков — постоянная задача менеджера. Очень часто она выходит за пределы проекта, поскольку опытный менеджер, когда берется за проект, всегда имеет в виду команду, с которой ему будет комфортно работать, которая справится с заданием вполне гарантированно. Подобные команды не складываются сразу, а формируются в процессе выполнения проектов. В конечном счете за руководство стоит браться только тогда, когда есть шанс в процессе выполнения работ получить такую команду.
В то же время кадровая потребность любого проекта не является постоянной. В самом начале, когда решение о проекте еще не принято, круг лиц, которые имеют дело с будущей разработкой, ограничен предполагаемым менеджером и теми, кто выполняет роли заказчика и планировщика. За этот период, к моменту, когда решение о начале проекта будет принято и предоставление нужных ресурсов будет запланировано, необходимо позаботиться о стартовом кадровом обеспечении проекта, а также выяснить априорное распределение кадровых ресурсов проекта, которое включает ориентировочный план требуемого кадрового состава, развернутый по времени. Это, разумеется, не более чем менеджерская гипотеза, но чем точнее она соответствует ожиданиям заказчика и планировщика, чем более реалистичной она покажется им, тем больше шансов на успешную организацию работ.
В ходе априорного распределения ресурсов менеджер определяет кандидатуры на ключевые роли коллектива разработчиков. Само понятие ключевой роли указывает на то, что от сотрудников, которым такие роли назначены, в наибольшей степени зависит успех проекта. Какие роли в проекте являются ключевыми, во многом зависит от специфики разработки.
Не надо путать понятия ключевой роли и ключевого работника. Первое носит характер, отстраненный от персоналий коллектива, а второй соотносится именно с коллективом. Часто случается, что некоторые первоначально не зарекомендовавшие себя исполнители, а потому не занимающие высоких позиций в управлении проектом, фактически берут на себя ответственность за проект, подсистему и т.д. и в результате становятся ключевыми работниками. И тогда менеджеру приходится изменять стиль руководства — он уже не может принимать решения, не считаясь с мнением образовавшейся лидирующей группы. Когда такая ситуация становится явной, нужно соответственно пересматривать расстановку сил. Попросту говоря, стоит попытаться изменить управляющую структуру проекта. Но нужно учитывать и то, что такое изменение потенциально конфликтно, а потому повышает уровень риска.
Намного лучше, когда лидерство сотрудников обнаруживается или заранее известно на ранней стадии проекта. Это позволяет сразу правильно выстроить административную структуру. Тем не менее и здесь есть свои подводные камни. Не все лидеры готовы или хотят брать на себя управленческие обязательства. В этом случае лучше с самого начала назначить администратора, который освободит фактического лидера от перманентных административных проблем. Другая проблема — соперничество за лидерство в коллективе, что является потенциально рискованной для проекта ситуацией. Если такое случается, а еще лучше, когда соперничество только зарождается, сразу же разделить сферы ответственности конкурентов.
В принципе правильная неформальная структура в коллективе предполагает лидерство одной персоны. Если лидером является менеджер проекта, то это хорошо сказывается на исполнительности работников и благотворно влияет на коллектив и ход развития проекта. Но и здесь существует риск: возможно формирование так называемой групповой мысли (термин, предложенный Дженисом вдля обозначения ситуации, когда ценные рабочие качества членов группы не используются из-за преданности их обладателей команде), которая приводит к подавлению инициативы. Чтобы избежать этого, необходимы специальные меры: заседания, на которых все члены команды вынуждены так или иначе высказывать собственное мнение, приглашение независимых экспертов для анализа решений группы и т.д.
Есть еще одна причина, по которой ситуация с менеджером в качестве лидера может отрицательно сказываться на результативности выполнения проекта: в таком случае ему неизбежно придется вникать в детали производственного процесса, которые не соответствуют менеджерской функции распределения ресурсов, работ и контроля.
Наличие единственного лидера в группе, на которого может положиться менеджер проекта, — одна из главных предпосылок формирования продуктивно работающего коллектива. Но если появляется противодействующий лидер, ситуация в проекте становится крайне неустойчивой. И менеджеру нужно всячески избегать ее: распознавать противодействие как можно раньше, быть терпимым и терпеливым при обсуждении вариантов решений даже тогда, когда кажется, что решение лежит на поверхности. Следует подчеркнуть, что в такой ситуации «хирургическое вмешательство» способно разрушить коллектив со всеми вытекающими отсюда последствиями. Борьба с лидером, особенно со скрытым неформальным лидером, к тому же заметная членам команды, также плохое средство. Она может быть действенной только в тех случаях, когда руководитель уверен в своей победе без административных воздействий. По сути, такая борьба должна рассматриваться в рамках мер по смене лидера команды. И наиболее трудной она оказывается тогда, когда противодействующий лидер выполняет одну из ключевых ролей в проекте.
Из сказанного выше ясно, что лидера команды нельзя назначить, что его не так просто заменить, что вернее всего с самого начала распознавать лидерство и выстраивать отношения сотрудничества с ним и далее через него со всей командой. Вот почему, приступая к проекту, менеджер должен самым тщательным образом отнестись к задаче определения ключевых ролей в проекте и к назначению их исполнителей.
Следующий перечень ключевых ролей характеризует наиболее типичные ситуации для программных проектов:

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

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

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

  • Во-вторых, менеджер может подбирать кандидатов из числа сотрудников фирмы, с которыми он еще не имел дело. В этом случае ему не обойтись без изучения послужного списка сотрудника, собеседований и прочих способов получения сведений о человеке.
  • Третий вариант, на который стоит рассчитывать, если возможности предыдущих вариантов исчерпываются, — это принять на работу нового сотрудника. Ситуация почти такая же, как в предыдущем случае, но несколько хуже: про сотрудника фирмы довольно просто получить объективную информацию, тогда как, нанимая нового человека, приходится довольствоваться сведениями из документов и результатами собеседований.

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

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

Если эту информацию получить не удается, то перед тем, как сделать конкретное предложение, менеджер должен провести собеседование, в процессе которого он корректирует свои предварительные оценки. Выставление априорных оценок может быть сделано на основании послужного списка сотрудника, опроса тех, с кем он работал и т.д. Важно подчеркнуть, что сведения из резюме, а также собираемые при опросах и путем собеседований чаще всего не носят абсолютный характер, а потому при определении кадровых ресурсов проекта менеджер должен провести нормирование имеющихся данных. Удобно выражать оценки в балльной системе.
Используя все возможные способы подбора кандидатов для участия в проекте (не путать с процедурой найма на работу, которая может для разных организаций быть различной), менеджер собирает резюме всех тех, кого он решил привлечь к сотрудничеству. Эта коллекция резюме структурирована: для каждого кандидата должно быть известно, какие роли в проекте он в принципе способен и согласен исполнять. Соответственно, менеджер в состоянии сделать первое распределение ролей между выделенными кандидатами и обозначить роли, не занятые никем. График привлечения сотрудников к проекту сделает это распределение привязанным ко времени, а информация о возможной занятости кандидата и уровне его соответствия каждой роли (квалификация сотрудника) позволит судить о потенциальной обеспеченности проекта кадровыми ресурсами.
Решение задачи подбора кадров для проекта зависит от условий, в которых действует менеджер. Ситуации могут быть следующие:

  1. У менеджера есть коллектив потенциальных исполнителей, готовый приступить к работе над проектом.
  2. Менеджерский коллектив потенциальных исполнителей недостаточен: среди членов команды нет сотрудников, которые обладают нужной квалификацией.
  3. В поле зрения менеджера есть независимые потенциальные исполнители, из которых можно сформировать коллектив для работы над проектом.
  4. Менеджеру приходится прибегать к найму рабочей силы со стороны.

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

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

Задача определения кадровых ресурсов проекта никогда не может быть решена окончательно. Каждый новый участник проекта, каждое увольнение, каждое перераспределение ролей нуждается в корректировке кадровой политики, что проявляется в исправлении графика привлечения сотрудников.
Полезно сопоставить представленную схему с тем, что обычно предлагается в качестве методов для работы с кадрами. В этом плане сегодня чаще всего говорят об организации стихийно складывающихся неформальных групп специалистов разного профиля. По-видимому, это связано с анализом формирования успешных коллективов, с одной стороны, а с другой — с разочарованием в рекомендациях, которые предлагались ранее (см., например, обсуждение этого вопроса у Брукса). В соответствии с такой точкой зрения строятся предложения модели проектной группы MSF, в которых делается попытка определить внешние требования, предъявляемые к группам. Постулат о неформальном образовании групп не позволяет говорить о внутренних требованиях, как-то регламентирующих этот процесс. И если следовать логике этих предложений, то кадровая политика менеджмента проекта сводится к выбору подходящих проектных групп. Когда это удается, есть довольно высокие шансы на успех. Однако, к сожалению, менеджеру чаще всего нужно действовать в иных условиях, в которых приходится формировать команду разработчиков. И тогда задача определения кадровых ресурсов проекта, подбора исполнителей становится одной из наиболее важных для проекта. Хочется надеяться, что представленные выше материалы помогут в ее решении.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика