Организационная система управления проектами

Контрольная работа

Тема 9

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

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

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

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

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

Для этого необходимо:

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

Факторы, которые следует учитывать при формировании команды программного проекта

К основным факторам, определяющим принципы формирования команды проекта, относятся:

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1. Возможные схемы организации менеджмента проекта.

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

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

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

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

Распределение ролей и ответственности

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

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

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

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

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

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

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

Средством, при помощи которого руководство проектом устанавливает отношения между уровнями полномочий, является делегирование. Делегирование - это передача задач и полномочий лицу, которое принимает на себя ответственность за их выполнение. Именно умение делегировать часть своих полномочий превращает человека в руководителя. Важно отметить, что делегируются только полномочия, ответственность же не может быть делегирована (как только Г. Трумэн стал президентом США, он повесил над головой плакат "Больше ответственность сваливать не на кого"). Объем ответственности - одна из причин высоких окладов менеджеров. Но нельзя забывать о том, что руководитель любого уровня только тогда будет иметь возможность повлиять на деятельность людей, от которых зависит выполнение задачи, когда он будет располагать требующимися для этого ресурсами.

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

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

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

Процессы управления человеческими ресурсами

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

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

Планирование человеческих ресурсов

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2. Форматы определения ролей и ответственности.

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

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

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

На рис. 3 изображена матрица ответственности, называемая диаграммой RACI. Такое название она носит потому, что аббревиатура RACI составлена из первых букв названий документально зафиксированных ролей: Ответственный, Подотчетный, Проконсультированный и Информированный (Responsible, Accountable, Consult and Inform). На примере диаграммы в левой колонке указана выполняемая работа на уровне операций, но при помощи матрицы ответственности можно отобразить на разных уровнях. Имена могут обозначать как конкретных исполнителей, так и группы.

Операция	СОТРУДНИКИ
Иванов	Петров	Морозова	Костин	Серегина
Определение требований	П	О	И	И	И
Проектирование	И	П	О	К	К
Разработка	И	П	О	К	К
Тестирование	П	И	И	О	И
О - ответственный П - подотчетен К - консультации И - информирование

Рис. 3. Матрица ответственности (МО) в формате RACI.

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

Основными результатами процесса планирования человеческих ресурсов являются:

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

Набор команды проекта

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

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

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

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

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

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

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

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

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

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

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

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

Развитие команды проекта

Развитие команды проекта предусматривает повышение квалификации членов команды проекта и укрепление взаимодействия между ними для повышения эффективности реализации проекта. Целями развития команды проекты являются:

- повышение навыков членов команды для повышения их способности выполнять операции проекта; - укрепление чувства доверия и сплоченности среди членов команды для повышения продуктивности ее работы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управление командой проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выбор руководителя проекта

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

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

Критерии отбора

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

- образование и опыт; - лидерство и стратегическое мышление; - техническая компетентность; - умение работать с людьми; - доказанные способности к управлению.

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

Образование и опыт

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

Лидерство и стратегическое мышление

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

Техническая компетентность

Нет ни одного руководителя проекта, техническая подготовка которого была бы столь совершенна, что позволяла бы ему до тонкостей разбираться во всех технических вопросах, возникающих при выполнении сложного проекта. Но поскольку необходимо найти человека, который в состоянии контролировать, оценивать и принимать правильные решения по техническим проблемам, связанным с проектом, то он должен иметь технический опыт, обладать знаниями и навыками как в области, связанной с тематикой проекта, так и в области управления проектами, включая необходимые для этого средства и методы. Гарольд Керзнер (Harold Kerzner, 1982) установил, что требуемая специальная подготовка потенциального руководителя проекта должна включать в себя:

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

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

Умение работать с людьми

Руководитель проекта должен уметь:

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

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

Доказанные на практике способности к управлению

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

Подбор команды проекта

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

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

Критерии отбора

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

Независимо от характера проектов, из опыта разных рабочих групп сформировался следующий "широкий" список критериев отбора кандидатов:

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

Различные подходы к формированию команд программных проектов

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

Еще со времен выхода первой редакции книги Ф. Брукса "Мифический человеко-месяц..." известно, что как только программирование перестает быть уделом одиночек, а превращается в коллективный труд, требующий обмена данными и скоординированной работы отдельных частей программы, механическое увеличение численности команды не только не приводит к сокращению сроков разработки, а зачастую растягивают проект во времени и приводит к дополнительным затратам на обеспечение коммуникации и на устранение последствий плохой организации этой коммуникации (комплексная отладка).

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

Предложение Миллза

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

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

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

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

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

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

Два секретаря. И администратору, и редактору нужны свои секретари; секретарь администратора будет вести корреспонденцию проекта и архивы.

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

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

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

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

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

Как это работает? В чем различие между предложенным Миллзом подходом и обычной командой из 10 человек? Во-первых, в обычных коллективах вся работа разделена между сотрудниками, и каждый из них отвечает за разработку и реализацию своей части. В хирургической бригаде и хирург, и второй пилот в курсе всего проекта и всей программы. Это снимает проблему коммуникации и снижает затраты на координацию и взаимодействие. И, кроме того, сохраняется концептуальное единство работы. Во-вторых, в обычных коллективах все сотрудники равны, и неизбежные различия в оценках требуют постоянных обсуждений и компромиссов. Поскольку работа и ресурсы разделены, различия в суждениях, конечно, подчинены общей стратегии и правилам взаимодействия, но они усугубляются противоположностью интересов. В хирургической бригаде нет различий в интересах, а противоречия во мнениях разрешаются самим хирургом единолично. Эти два обстоятельства - единство задачи и связь только по принципу подчинения - позволяют хирургической бригаде действовать как одно целое. Таким образом, строгое распределение ролей между сотрудниками бригады является ключом к повышению ее производительности, поскольку оно, обеспечивает гораздо более простую структуру связей между сотрудниками.

Группа из 10 сотрудников может работать эффективно только в том случае, если вся задача находится в сфере ее действия. Но как использовать концепцию хирургической бригады применительно к разработке большой системы, когда в решении задачи принимают участие несколько сот человек? Можно отдать всю работу 200 сотрудникам, но проблемы координации поручить 20 хирургам.

Функциональные роли в коллективе разработчиков. Подход Центра объектно-ориентированной технологии компании IBM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Команда ХР проекта - роли для людей

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

Заказчик

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

Зафиксировать сроки выпуска версий продукта;

Принимать решения относительно запланированных составляющих программы;

Знать ориентировочную стоимость каждой функциональной составляющей;

Принимать важные бизнес-решения;

Знать текущее состояние системы;

Изменять требования к системе, когда это действительно важно.

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

Разработчик

Один или группа от двух до десяти человек, занимающихся непосредственно программированием и сопутствующими инженерными вопросами. Разработчик наделен следующими правами и обязанностями:

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

Иметь возможность выяснения деталей в процессе разработки;

Предоставлять ориентировочные, но откровенные оценки трудозатрат на каждую функциональную часть или историю пользователя;

Корректировать оценки в пользу более точных в процессе разработки;

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

Роли внутри роли

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

Сторона заказчика

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

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

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

Сторона разработчика

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

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

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

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

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

Внешние роли

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

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

Проектная группа: подход MSF

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

Хотя модель группы разработчиков весьма конкретна, при знакомстве с MSF ее нужно рассматривать в качестве отправной точки. Разные коллективы реализуют этот каркас по-разному, в зависимости от масштаба проекта, размеров группы и уровня подготовки ее членов. Чтобы проект считался удачным, следует решить определенные задачи:

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

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

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

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

Табл. 1. Цели и роли

Цель	Роль
Удовлетворение требований заказчика	Менеджер продукта
Соблюдение ограничений проекта	Менеджер программы
Соответствие спецификациям	Разработчик
Выпуск только после выявления и устранения проблем	Тестер
Повышение эффективности труда пользователя	Инструктор
Простота развертывания и постоянное сопровождение	Логистик

В проектную группу должны входить:

- опытные руководители; - инициативные сотрудники, способные принимать решения и нести ответственность за свое направление работы,

Их задача:

- сконцентрироваться на выпуске продукта: - выработать общее представление о проекте.

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

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

Для эффективной работы проектной группы требуется соблюдение следующих правил в отношениях между людьми:

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

Менеджер продукта

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

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

Примечание: При этом важно понимать разницу между заказчиком и пользователями: заказчик платит за создание продукта, а пользователи с ним работают.

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

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

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

Менеджер программы

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

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

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

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

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

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

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

Разработчик

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

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

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

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

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

Тестер

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

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

Нельзя совмещать должности тестера и разработчика. Разделение этих обязанностей:

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

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

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

Часто упускают из виду и другие важные обязанности тестеров. К ним относятся:

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

Инструктор

Цель группы обучения -- повысить эффективность труда пользователей. Поэтому инструкторы "принимают сторону" пользователей подобно тому, как менеджеры продукта представляют интересы заказчика. Однако перед пользователями инструкторы выступают в роли представителей проектной группы.

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

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

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

Логистик

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

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

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

Размеры группы и масштаб проекта

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

Крупные проекты

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

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

Тематические подгруппы

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

Функциональные группы

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

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

Небольшие проекты

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

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

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

Эффективность команды проекта

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

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

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

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

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

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

Для эффективной работы над проектом требуется, чтобы члены команды проекта обладали совокупностью следующих навыков:

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

Признаками эффективной проектной команды являются:

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

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

Команда управление программный

Список литературы по курсу:

1. Иванова Г. С. Технология программирования.- М.: из-во МГТУ им. Н. Э. Баумана, 2002. 2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2000. 3. Липаев В. В. Программная инженерия: методологические основы. - М.: ТЕИС, 2006. 4. Костров А. В. Основы информационного менеджмента. - М.: Финансы и статистика, 2001. 5. Орлов С. А. Технологии разработки программного обеспечения. - СПб.: Питер, 2002. 6. Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы. Пер. с англ. - СПб.: Символ, 2001. 7. Уокер Ройс. Управление проектами по созданию программного обеспечения. Пер. с англ. - М.: Лори, 2002. 8. Роберт Т. Фатрелл, Дональд Ф. Шафер, Линда И. Шафер. Управление программными проектами: достижение оптимального качества при минимуме затрат. Пер. с англ. - М.: Издательский дом "Вильямс", 2003. 9. Эдвард Йордон. Путь камикадзе: как разработчику программного обеспечения выжить в безнадежном проекте. Пер. с англ. - М.: Лори, 2001. 10. Скотт Кендалл. Унифицированный процесс. Основные концепции. Пер. с англ. - М.: Издательский дом "Вильямс", 2002. 11. Кент Бек. Экстремальное программирование. Пер. с англ. - СПб.: Питер, 2002. 12. Тимоти Пайрон. Использование Microsoft Project 2003. Пер. с англ. - М.: Издательский дом "Виьямс", 2005. 13. .Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. Пер. с англ. - СПб.: Питер, 2002. 14. Стив Макконнелл. Остаться в живых! Руководство для менеджера программных проектов. Пер. с англ. - СПб.: Питер, 2006. 15. Фергус О'Коннэл. Как успешно руководить проектами. Серебряная пуля. Пер. с англ. - М.: Кудиц-образ, 2003. 16. Дж. Филипс. Менеджмент IT - проектов: на пути от старта до финиша. Пер. с англ. - М.: Лори, 2008. 17. Стив Макконнелл. Сколько стоит программный проект. Пер. с англ. - СПб.: Питер, 2007. 18. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и систем (ISO/IEC TR 155-4 - CMM). Пер. с англ. - М.: Книга и бизнес, 2001. 19. Орлик С. Введение в программную инженерию и управление жизненным циклом ПО. - Copyright © Сергей Орлик, 2005. 20. Скопин И. Н. Основы менеджмента программных проектов.

Похожие статьи

• Организационный план - Автоматизированная система управления городскими финансами

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

• Программное обеспечение автоматизации управления проектами - Мониторинг показателей эффективности проектов и особенности их применения в ИТ-консалтинге

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

• Даталогическое проектирование - Банки и базы данных. Системы управления базами данных

  Даталогической моделью БД называется модель логического уровня, построенная в рамках конкретной СУБД, в среде которой проектируется БД. Описание...

• Методы внедрения системы. - Примение информационных технологий в управлении

  Компания, собирающаяся внедрить компьютерную систему управления, как правило, дает следующую установку: система должна начать действовать как можно...

• Этапы проектирования и создания БД - Система управления базами данных

  При разработке БД можно выделить следующие этапы работы. I этап. Постановка задачи. На этом этапе формируется задание по созданию БД. В нем подробно...

• Распределенная обработка данных - Банки и базы данных. Системы управления базами данных

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

• Применение управления проектами при изучении курса информатики

  ПРИМЕНЕНИЕ УПРАВЛЕНИЯ ПРОЕКТАМИ ПРИ ИЗУЧЕНИИ КУРСА ИНФОРМАТИКИ Грызлова М. С. Новикова И. Н. Решение научно-технической и социально-экономической задачи...

• Описание системы ETWeb - Информационные технологии в управлении персоналом на примере компании ООО "Аксис ПРО"

  Информационная система Lumesse ETWeb является системой, которая автоматизирует весь комплекс процессов управления персоналом. Важно отметить, что данная...

• Структура SQL - Банки и базы данных. Системы управления базами данных

  Широкое развитие информационных систем и связанная с этим унифицированность информационного пространства привело к необходимости создания стандартного...

• Введение - Проблемы конструирования устойчивой системы автоматического управления

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

• Разработка структурной схемы проекта и структуры программного обеспечения, Проектирование базы данных - Разработка и тестирование автоматизированной системы контроля успеваемости студентов

  При работе над проектом разрабатывались два основных компонента системы: база данных (далее - БД) и интерфейс клиентского приложения. Затем необходимо...

• Описание языка программирования - Учебно-демонстрационный стенд "Система автоматического управления инженерными системами помещения"

  CoDeSys -- универсальный инструмент разработки прикладных программ для программируемых логических контроллеров на языках стандарта IEC 61131-3. Данный...

• Состояние ОТ и ТБ - Автоматизированные системы управления и обработки информации

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

• Результаты внедрения информационной системы ETWeb - Информационные технологии в управлении персоналом на примере компании ООО "Аксис ПРО"

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

• Технологический план - Автоматизированная система управления городскими финансами

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

• Уровни и типы моделей БД - Банки и базы данных. Системы управления базами данных

  Любая БД отражает информацию об определенной предметной области. В зависимости от уровня абстракции, на котором представляется предметная область,...

• Модели транзакций - Банки и базы данных. Системы управления базами данных

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

• Диалоговая информационная система контроля оперативной работы (ДИСКОР) - Информационные системы управления на железнодорожном транспорте

  Основная цель системы ДИСКОР - совершенствование оперативного управления работой железных дорог на основе более эффективного использования пропускной...

• Введение, Проект документирования cистемы Linux - Операционная система Linux

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

• Oracle Applications от Oracle, BAAN IV от BAAN, Система управления БОСС компании АйТи. - Примение информационных технологий в управлении

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

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

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

• Введение, Задание 1. Понятие baseline, Общие принципы baseline - Управление проектами как часть системы менеджмента предприятия

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

• Лоцман:КБ - Разработка программной системы управления контентом портала с архивом конструкторской документации

  Лоцман: КБ относится к классу PDM-систем и предназначен для быстрого формирования и поддержания в актуальном состоянии электронного архива...

• Обеспечение пожарной безопасности при эксплуатации проектируемого объекта, Экологичность проекта - Учебно-демонстрационный стенд "Система автоматического управления инженерными системами помещения"

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

• Повышенный уровень шума, Неудовлетворительные условия зрительной работы - Учебно-демонстрационный стенд "Система автоматического управления инженерными системами помещения"

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

• Выбор информационной системы для деятельности компании "Аксис Про", Информационные системы для управления персоналом - Информационные технологии в управлении персоналом на примере компании ООО "Аксис ПРО"

  Информационные системы для управления персоналом "Информационная система - это автоматизированная система, результатом функционирования которой является...

• Определение и типология банков данных - Банки и базы данных. Системы управления базами данных

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

• Микропроцессорная система управления лифтом - Технологический комплекс управления лифтом

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

• Управление моделью с помощью Дерева Построений (Feature Manager), Визуализация проектируемых изделий - Система твердотельного моделирования SolidWorks

  Для упрощения работы с трехмерной моделью на любом этапе проектирования и повышения ее наглядности в SolidWorks используется Дерево Построений (Feature...

• ВВЕДЕНИЕ, ТЕХНИЧЕСКИЙ ПРОЕКТ, Описание предметной области - Информационная система учета службы горючих и смазочных материалов войсковой части

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

• Введение - Система управления базами данных

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

• Разработка алгоритмов функционирования, Заключение - Разработка проекта автоматизации системы водоснабжения

  3.1 Алгоритм функционирования СУ технологического объекта Рисунок 8 - Общий алгоритм функционирования 3.2 Алгоритм запуска технологического объекта...

• Обеспечение высокопомехоустойчивого обмена информацией в автоматизированных системах управлениях

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

• Теоретические основы исследования, Ключевые термины - Мониторинг показателей эффективности проектов и особенности их применения в ИТ-консалтинге

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

• Требования к интерфейсу, Система управления базами данных - Разработка интерфейса базы данных (на примере потребностей охранного предприятия ООО "Пересвет")

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

• Структура и процесс функционирования системы управления базами данных - Разработка базы данных

  СУБД является прикладным программным обеспечением, предназначенным для решения конкретных прикладных задач и выполнения системных функций, расширяющих...

• Понятие, классификация, производительность систем управления базами данных "СУБД" - Разработка базы данных

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

• Заключение, Список использованных источников - Информационные системы управления на железнодорожном транспорте

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

• Перспективы развития информатизации железнодорожного транспорта - Информационные системы управления на железнодорожном транспорте

  Транспортная стратегия России до 2025 г. определила основные направления развития железнодорожного транспорта. Предусмотрено создание таких условий, при...

• Разработка АИС - Разработка автоматизированной информационной системы для устранения различий в структурах баз данных разработчиков, при работе над общим проектом с использованием системы контроля версий

  Алгоритм работы. В результате работы АИС генерируются три xml документа - два со структурой сравниваемых баз данных и один с результатами сравнения. В...

Организационная система управления проектами

Предыдущая | Следующая