Вопросы для проверки

Вариант 1

1. Функция, выполняемая разработчиком проекта, —это:

□ задание, поручаемое для выполнения

□ действия, выполняемые для достижения определенного
результата

□ действия, предписанные для выполнения должностной
инструкцией разработчика

П действия, предписанные для выполнения разработчиком в проекте

□ любые целенаправленные действия разработчика

2. Проектная группа модели Microsoft Solution Framework —
это:

□ производственный коллектив со строгим разделением
функций

□ мобильный производственный коллектив, создаваемый для
выполнения проекта

□ мобильный коллектив с общей ответственностью за
выполняемые задания

□ производственный коллектив с установленной иерархией
подчинения

П многопрофильная команда, члены которой распределяют между собой ответственность и дополняют области компетентности друг друга

3. Внешние функции менеджера — это:

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

□ те функции, которые выполняет менеджер вне данного
проекта

□ те функции, выполнение которых обеспечивает требуемые
условия развития проекта

□ взаимодействие менеджера с разработчиками, которое не
затрагивает интересы развития проекта

□ работа менеджера, которая направлена на руководство
коллективом в проекте

Вариант 2

1. Поручения, выполняемые разработчиком проекта, — это:

□ Задания, которые дает менеджер для выполнения

□ Разовые или систематические задания, из которых обычно
складываются действия, необходимые для выполнения той
или иной функции

□ Действия, предписанные функцией разработчика

□ Действия, предписанные ролью разработчика в проекте

□ То же, что и функция разработчика

2. Ролевой кластер модели MSF — это:

□ Разработчики проектной группы, которые работают над
достижением одной из целей проекта

□ Непересекающаяся с другими часть проектной группы,
выделенная для достижения одной из целей проекта

□ Организационная структура проектной группы,
ассоциированная с одной из проектных целей и работающая
над ее достижением

□ Ролевая структура проектной группы, ассоциированная с
одной из проектных целей и работающая над ее достижением

□ Административная единица проектной группы, образуемая
для определения каждой из сфер компетентности группы

3. Внутренние функции менеджера — это:

□ Взаимодействие менеджера с членами команды разработчиков
проекта

□ Взаимодействие менеджера с разработчиками

□ Взаимодействие менеджера с теми, кто отвечает за
информационную поддержку проекта

□ Взаимодействие менеджера с теми, кто отвечает за
декомпозицию проекта

О Любая работа, затрагивающая членов команды разработчиков проекта

Вариант 3

1. Функция называется технологической, если:

□ Для нее определен регламент выполнения поручений, из
которых она складывается

□ Для исполнителя не требуется дополнительных разъяснений
как ее выполнять

□ Необходимые для ее выполнения действия предписаны
принятой в проекте технологией разработки

□ Необходимые для ее выполнения действия предписаны любой
технологией разработки

□ Она поддержана средствами автоматизации

2. Какие ролевые кластеры предусматривает модель
проектной группы MSF?

□ Управление продуктом, управление программой, разработка,
тестирование, удовлетворение потребителя и управление
выпуском

□ Управление программой, управление рисками, разработка,
управление выпуском, поддержка, сопровождение

□ Управление выпуском, удовлетворение потребителя,
разработка, тестирование, сопровождение

О Управление программой, разработка, сопровождение, управление рисками, управление версиями, тестирование

□ Управление программой, разработка, тестирование, сопровож­дение, управление версиями, удовлетворение потребителя

3. Не следует допускать совмещения ролей, которые имеют
конфликтные или противоречивые интересы. Что делать,
если такое совмещение все-таки приходится использовать?

□ Привлечь к работе дополнительных исполнителей и тем
самым избежать совмещения ролей

□ Сократить объем работ, согласовав это с заказчиком

□ Ужесточить контроль выполнения заданий для сотрудника,
совмещающего роли

П Предусмотреть механизмы, которые будут демпфировать противоречия

□ Переделать ролевую структуру проектной команды

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

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

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

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

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

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

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

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

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

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

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

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

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

• архитектор проекта;

• проектировщики подсистем;

• руководители команд разработки подсистем;

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

• эксперт предметной области.

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

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

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

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

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

Первый вопрос распределения ресурсов: где подбирать специали­стов на проект. Вариантов немного (см. рис. 3.1).

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

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

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

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

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

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

• об уровне квалификации сотрудника как претендента на ту или
иную роль;

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

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

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

1. У менеджера есть коллектив потенциальных исполнителей, гото­вый приступить к работе над проектом.

2. Менеджерский коллектив потенциальных исполнителей недостаточен: среди членов команды нет сотрудников, которые обладают
нужной квалификацией.

3. В поле зрения менеджера есть независимые потенциальные ис­полнители, из которых можно сформировать коллектив для рабо­ты над проектом.

4. Менеджеру приходится прибегать к найму рабочей силы со стороны.

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

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

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

Резюмируя решение задачи определения кадровых ресурсов проек­та, следует указать на следующую схему (см. рис. 3.2).

• До официального начала выполнения проекта менеджер должен
уяснить, с одной стороны, кадровые потребности проекта и оцен­ки их распределения по времени, а с другой — возможности подбора кадров, на которые он имеет право рассчитывать.

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

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

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

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

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

Вариант 1

1. Априорное распределение кадровых ресурсов проекта — это:

□ стартовый состав коллектива исполнителей проекта

□ ориентировочный план требуемого кадрового состава,
развернутый по времени

□ предполагаемый состав коллектива исполнителей проекта

□ план распределения ролей между исполнителями проекта

□ желательное распределение ролей по исполнителям без учета
текущей кадровой обеспеченности проекта

2. Противодействующий лидер — это:

Q тот, кто своим авторитетом заставляет команду действовать деструктивно

□ член коллектива, успешно оппонирующий принимаемым
решениям

□ лидер коллектива, который фактически препятствует
действиям менеджера проекта

□ достаточно авторитетный критик решений менеджера проекта

□ противник общепринятых мнений, к которому
прислушиваются в коллективе

3. Где можно подбирать кадры для выполнения проекта?

□ менеджер может привлекать кандидатов, знакомых ему по
другим проектам. Это чревато необъективностью

□ менеджер может принять сотрудника со стороны только по
личному впечатлению о нем

fj менеджер может принять сотрудника со стороны. Надежность варианта определяется качеством работы фирмы, кадрового агентства и др.

□ менеджер может заранее знать возможных кандидатов. Это
самый лучший вариант

□ менеджер может подбирать кандидатов из числа сотрудников
фирмы. Надежность варианта определяется качеством
кадровой экспертизы в фирме

Вариант 2

1. Ключевые роли коллектива разработчиков — это:

□ роли в проекте, от которых в наибольшей степени зависит
успех или неудача разработки

□ роли, определяющие стратегию развития проекта

□ роли, которые назначаются наиболее авторитетным
сотрудникам

□ роли, функции которых наиболее значимы в проекте

□ роли, которые должны быть заняты в проекте в течение всего
времени его развития

2. Наличие единственного лидера в группе, на которого
может положиться менеджер проекта, — это:

□ одна из главных предпосылок формирования продуктивно
работающего коллектива

□ недостаток кадрового обеспечения проекта, поскольку реально
требуется несколько ответственных персон

□ возможность переложить на одного из сотрудников часть
менеджерских обязанностей по руководству коллективом
разработчиков

□ возможность переложить на одного из сотрудников часть
менеджерских обязанностей по управлению проектом

Q возможность конфликтов с менеджером, связанных с утверждением лидерства

3. Чем может помочь в подборе кадров сотрудник, уже
принятый на ключевую роль?

□ ничем, так как это не его работа

□ советом, который исходит из того, что данному сотруднику
предстоит взаимодействовать с остальными

□ указанием в качестве кандидатов конкретных персон,
известных ему, которых целесообразно привлекать к проекту

□ проведением экспертного собеседования с целью определения
пригодности кандидатов для работы

□ любая помощь была бы вредна, так как при этом менеджер
попадает в определенную зависимость от сотрудника

Вариант 3

1. Ключевой работник — это:

□ тот, кто занимает в проекте ключевую роль

□ ответственный работник, от деятельности которого в
наибольшей степени зависит успех или неудача разработки

□ незаменимый разработчик

□ сотрудник, определяющий характер деятельности коллектива
в целом

□ тот, кто занимает в проекте наиболее высокое
административное положение

2. Какие ключевые роли характеризуют наиболее типичные
проектные ситуации?

□ архитектор проекта

□ проектировщики подсистем

□ руководители команд разработки подсистем

□ специалист по пользовательскому интерфейсу

□ эксперт предметной области

3. График привлечения сотрудников к проекту — это:

□ план, в котором представлены перечень работ с указанием их
продолжительности, планируемого начала и завершения и
квалификация сотрудников, требуемых для выполнения этих
работ, а также возможные кандидаты

□ перечень кандидатов для приема на работу с указанием их
условий и проектных возможностей эти условия удовлетворить

□ план кадровой потребности проекта

□ план расходов на мероприятия, связанные с приемом на
работу сотрудников

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

Дата добавления: 2014-01-07