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

Лекция КС ЭК.

Функциональные роли в коллективе разработчиков......................................... 1

ВОПРОСЫ ДЛЯ ПРОВЕРКИ............................................................................... 12

Ключевые роли коллектива..................................................................................... 14

разработчиков и задача определения.................................................................. 14

кадровых ресурсов проекта.................................................................................... 14

Функциональные роли в коллективе разработчиков

Определяются функции, выполняемые сотрудниками в ходе развития проекта и типичные для программных проектов роли разработчиков; указы­вается, какие роли могут совмещаться при выполнении проекта. Представле­ны решения обсуждаемых вопросов, предлагаемые компанией Microsoft и Центром объектно-ориентированных технологий IBM.

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

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

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

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

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

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

Таким образом, в рамках любого проекта возникает задача повы­шения квалификации сотрудников. Для различных схем ведения проектов эта задача решается по-разному. Крайнюю точку зрения на про­блему соответствия квалификации работников требованиям проекта отражает идея экстремального программирования [3], когда использует­ся неформальная организация группы исполнителей проекта без чет­кого распределения ролей, а значит, и обязательств сотрудников. В этом случае провозглашается принцип, когда каждый в группе делает то, что он умеет делать лучше всего. И хотя все функции, которые должны выполняться, остаются, создается впечатление, что в группе исполнителей проекта исчезают роли. В результате возможны пробе­лы в разработке, в частности при анализе и декомпозиции проектиру­емой системы. Чтобы этого избежать, разработчики должны пони­мать, какую абстрактную роль они исполняют в каждый конкретный момент, выполнение каких проектных функций необходимо сейчас, как связаны между собой работы, как должны распределяться ресур­сы. Словом, они должны обращать внимание на выполнение распре­деленных по группе менеджерских функций. И даже в этом случае схему экстремального программирования можно рекомендовать лишь для слаженных групп исполнителей с высоким уровнем коллективной ответственности.

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

Понятно, что как состав, так и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их спи­сок часто становится непомерно велик (иллюстрацией тому может слу­жить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня [30]). Чрезмер­ное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управле­нием.

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

В модели проектной группы концепции Microsoft Solution Framework (MSF) предлагается образовывать небольшие мобильные коллективы как атомарные производственные единицы с общей ответ­ственностью за выполняемые задания — так называемые проектные группы [44]. Такие группы строятся как многопрофильные команды, члены которых распределяют между собой ответственность и дополня­ют области компетентности друг друга. Группа состоит не более чем из 10 человек. Все они считаются обладающими сходным уровнем профес­сиональной подготовки, хотя и в разных областях индивидуальной спе­циализации. Провозглашается равноправие членов группы и коллек­тивная ответственность за выполняемые задания: проектная группа — команда равных. Все это позволяет сохранять внутри группы нефор­мальные отношения.

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

Определено шесть ролевых кластеров, которые соответствующим образом структурируют проектные функции разработчиков (рис. 2.1).

■ Управление продуктом(product management). Ключевая цель класте­ра — обеспечивать удовлетворение интересов заказчика. Для ее дос­тижения кластер должен содержать следующие области компетенции:

—планирование продукта,

—планирование доходов,

—представление интересов заказчика,

—маркетинг.

> Управление программой(program management). Задача — обеспечить
реализацию решения в рамках ограничений проекта, что может
рассматриваться как удовлетворение требований к бюджету проек­та и к его результату. Области компетенции кластера:

—управление проектом;

—выработка архитектуры решения;

—контроль производственного процесса;

—административные службы.

► Разработка(development). Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Обла­cти компетенции кластера:

—технологическое консультирование;

—проектирование и осуществление реализации;

—разработка приложений;

—разработка инфраструктуры.

• Тестирование(test). Задача кластера — одобрение выпуска продукта только после того, как все дефекты выявлены и устранены. Обла­сти компетенции кластера:

—разработка тестов;

• Удовлетворение потребителя(user experience). Цель кластера — по­вышение эффективности использования продукта. Области компетенции кластера:

—общедоступность (возможности работы для людей с недостатка­
ми зрения, слуха и др.);

—интернационализация (эксплуатация в иноязычных средах);

—обеспечение технической поддержки;

—обучение пользователей;

—удобство эксплуатации (эргономика);

—графический дизайн.

• Управление выпуском (release management). Задача кластера — бес­препятственное внедрение и сопровождение продукта. Области
компетенции кластера:

—инфраструктура (infrastructure);

—сопровождение (support);

—бизнес-процессы (operations);

—управление выпуском готового продукта (commercial release
management).

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

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

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

Мы придерживаемся ролевой структуры проекта, которая предложе­на Центром объектно-ориентированной технологии компании IBM [46]. Эта структура включает достаточно полный перечень типичных ролей, согласованный со многими реальными дисциплинами развития про­граммных проектов. В то же время она представляет роли разработчиков в организационном контексте, т.е. рассматривает не только разработчи­ков, но и тех, кто, не участвуя в проекте в качестве исполнителей, оказы­вает влияние на постановку задач проекта, на выделение ресурсов и обес­печение осуществимости развития работ. В представленном перечне ха­рактеристика каждой роли, по сути, задает круг родственных организаци­онных и производственных функций, которые объединяются с целью определить роль.

• Заказчик (Customer) — реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или
кто-либо иной, уполномоченный принимать результаты (как теку­щие, так и окончательные) разработки.

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

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

• Руководитель команды(Team Leader) — производит техническое ру­ководство командой в процессе выполнения проекта. Для больших
проектов возможно привлечение нескольких руководителей под­команд, отвечающих за решение частных задач.

• Архитектор(Architect) — отвечает за проектирование архитектуры
системы, согласовывает развитие работ, связанных с проектом.

• Проектировщик подсистемы(Designer) — отвечает за проектирование подсистемы или категории классов, определяет реализацию и
интерфейсы с другими подсистемами.

• Эксперт предметной области(Domain Expert) — отвечает за изуче­ниесферы приложения, поддерживает направленность проекта на
решение задач данной области.

• Разработчик(Developer) — реализует проектируемые компоненты,
владеет и создает специфичные классы и методы, осуществляет ко­дирование и автономное тестирование, строит продукт. Это широ­кое понятие, которое может подразделяться на специальные роли
(например, разработчик классов). В зависимости от сложности
проекта команда может включать различное число разработчиков.

• Разработчик информационной поддержки(Information Developer) —
создает документацию, сопровождающую продукт, когда выпуска­ется версия. Включаемые в нее инсталляционные материалы, равно как ссылочные и учебные, а также материалы помощи предос­тавляются на бумажных и машинных носителях. Для сложных про­ектов возможно распределение этих задач между несколькими раз­работчиками информационной поддержки.

• Специалист по пользовательскому интерфейсу(Human Factors
Engineer) — отвечает за удобство применения системы. Работает с
заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям.

• Тестировщик(Tester) — проверяет функциональность, качество и
эффективность продукта. Строит и исполняет тесты для каждой
фазы развития проекта.

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

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

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

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

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

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

В зависимости от проекта и условий его выполнения роли участни­ков проекта могут совмещаться. Предельный случай — программист раз­рабатывает проект для себя (по собственному заказу), сам планирует

* Термин «инициаторы работ» — перевод английского слова «stakeholdes». В литературе можно встретить и другие его переводы: организаторы работ, заинтересованные лица и даже акционеры (последнее уводит далеко в сторону). Некоторые прибегают к транслитерации и говорят о степк-хапдерах проекта. Мы предпочитаем назыать всех тех, чьи интересы в той или иной мере затра­гивают проект и его результаты, инициаторами работ. Наряду с этим мы употребляем термин «заинтересованные лица», обозначая им всех тех, кто проявляет интерес к проекту и от действия которых может зависеть его развитие, пусть даже косвенно. Таким образом, инициаторы работ включают в себя заинтересованных лиц (в частности, разработчиков проекта), но обратное невер­но. К примеру, акционер проекта является инициатором работ, так как его интересы судьба про­екта, безусловно, затрагивает. Но полагаясь на своего брокера, он может позволить себе даже не думать о проекте, т.е. не быть его заинтересованным лицом (в нашей терминологии).

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

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

I.He следует допускать совмещения ролей, которые имеют кон­фликтные или противоречивые интересы. Если такое совмещение все-таки используется, то необходимо предусматривать механиз­мы, которые будут демпфировать противоречия.

2. Представление ролей с конфликтными интересами различным
людям обеспечивает равновесие противоречащих точек зрения.

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

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

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

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

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

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

Нежелательно совмещение ролей руководителя команды и проекти­ровщика какой-либо подсистемы. И это обусловлено противоречивостью их ролевых интересов.

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

• Руководитель команды должен выдавать задания исходя из системы
реализационных понятий, которая принципиально отличается от
системы понятий подсистемы в целом, соответствующей уровню
использования. Этот уровень отслеживается проектировщиком.

• Разделение ролей проектировщика и руководителя способствует
равновесию точек зрения пользователя и разработчика подсистемы
(см. принцип 2).

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

По тем же причинам не допускается совмещение ролей менеджера и разработчика. Здесь запрет более жесткий, поскольку контрольные функ­ции менеджера несовместимы с исполнительскими задачами разработчи­ка. Даже в тех случаях, когда у менеджера остается свободное время пос­ле выполнения своих прямых обязанностей, ему не следует «помогать» разработчикам. Лучше занять себя другим делом, в частности выступить в роли разработчика другого проекта.

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

Допустимы и другие совмещения ролей. Так, довольно часто созда­ние документации распределяется между всеми исполнителями проекта, а на руководителя команды и менеджера возлагается задача интеграции документов. Для обозримых проектов функции библиотекаря можно по­ручить одному из разработчиков, соответственно скорректировав его ин­дивидуальное задание (см. принцип 3). Специалистом по пользователь­скому интерфейсу вполне может быть, например, менеджер, поскольку именно он осуществляет контакты с заказчиком (в данной ситуации заказчик либо сам является пользователем, либо выступает как представи­тель пользователя программного изделия).

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

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

Но как обеспечить «независимое» тестирование? Весьма разумный метод — априорное тестирование, т.е. создание тестов до,а не послекодирования модуля. Это одно из требований экстремального программиро­вания, которое вполне может быть распространено на другие методики ведения проектов. В статье [32] вводится специальный термин для обо­значения программистов, которые привыкли писать тесты до разработки: инфицированные тестами, и показывается, что эта «болезнь» только уско­ряет процесс в целом, В книге [4] Бек показывает, как можно выполнять программные проекты с помощью априорного тестирования, какие пре­имущества это дает для процесса разработки и для его результата.

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

Содержательная задача комплексного тестирования предоставляемых функций связывается прежде всего с заказчиком, который в состоянии дать для этого все необходимые материалы. Действуя вне проектной ко­манды, он способен обеспечить проверку, действительно независимую от критериев и предпочтений разработчиков. Однако заказчик чаще всего не в состоянии сам правильно строить тесты. Обычный максимум для него — спецификации ситуаций использования системы, нуждающихся в провер­ке. Материалы заказчика о пользовательской деятельности, для автомати­зации которой предназначена программа, рассматриваются в качестве ин­формационной базы для комплексного тестирования. Формирование этой базы есть прямая функциональная обязанность эксперта предметной обла­сти, который, действуя на стороне разработчиков, обеспечивает проект ориентирами, направляющими развитие. Одна из его задач в проекте — ре­конструкция работы пользователя с системой, из которой извлекаются ре­альные комплексные тесты для проверки предоставляемых функций. Адаптация тестов к условиям разработки, т.е. представление в виде, в кото­ром запуск и анализ прогонов будут требовать от разработчиков минималь­ных усилий, классификация тестов и т.д. *- это основная задача тестировшика как члена проектной команды. Дополнительные его задачи связаны с обеспечением технической помощи и поддержки комплексного тестирова­ния, с ведением протоколов тестирования и архивов тестов.

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

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

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

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

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

ВОПРОСЫ ДЛЯ ПРОВЕРКИ

Вариант 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).

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

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

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

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