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

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

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

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

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

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

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

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

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

Лекция КС ЭК.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В модели проектной группы концепции Microsoft Solution Framework (MSF) предлагается образовывать небольшие мобильные коллективы как атомарные производственные единицы с общей ответ­ственностью за выполняемые задания - так называемые проектные группы . Такие группы строятся как многопрофильные команды, члены которых распределяют между собой ответственность и дополня­ют области компетентности друг друга. Группа состоит не более чем из 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 . Эта структура включает достаточно полный перечень типичных ролей, согласованный со многими реальными дисциплинами развития про­граммных проектов. В то же время она представляет роли разработчиков в организационном контексте, т.е. рассматривает не только разработчи­ков, но и тех, кто, не участвуя в проекте в качестве исполнителей, оказы­вает влияние на постановку задач проекта, на выделение ресурсов и обес­печение осуществимости развития работ. В представленном перечне ха­рактеристика каждой роли, по сути, задает круг родственных организаци­онных и производственных функций, которые объединяются с целью определить роль.

Заказчик (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. Если работнику поручается несколько ролей, то он всегда должен
знать, какую из них он выполняет в данный момент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вариант 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вариант 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

информационную поддержку проекта

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

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

Вариант 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Познавательная функция

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

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

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

Прогностическая функция

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

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

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

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

Организационно-технологическая функция

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

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

Управленческая функция

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

Инструментальная функция

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

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

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

Управленческое решение - это продуманное действие, следствием которого является осуществление какого-либо действия для достижения цели организации или воздержание от него .

Процесс принятия решений требует от руководителя высокого профессионализма и чутья.

Требования, предъявляемые к управленческим решениям :

1. всесторонняя обоснованность;
2. правомерность;
3. непротиворечивость;
4. своевременность;
5. обеспеченность ресурсами;
6. ясность и лаконичность.

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

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

Значительное влияние на реализацию технологических функций менеджмента имеет также система коммуникаций .

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

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

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

Помимо этого, коммуникации могут быть вербальными и невербальными , и менеджер должен владеть ими обеими в совершенстве.

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

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

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

Бизнес идеи