Microsoft Solutions Framework Белая книга

Масштабирование модели проектной группы

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

Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия.

Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т.н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.

Группы направлений

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

В “Rapid Development” Steve McConnel писал:

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

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

2. 
   Группы направлений
   

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

Аналогично, в команде разработчиков возможна группировка сотрудников в соответствии с назначением разрабатываемых ими модулей: интерфейс пользователя, бизнес-логика или объекты данных. Часто программистов разделяют на разработчиков библиотек и разработчиков решения. Программисты библиотек обычно используют низкоуровневый язык C и создают повторно используемые компоненты, которые могут пригодиться всему предприятию. Создатели же решения обычно соединяют эти компоненты и работают с языками более высокого уровня, такими как, например Microsoft® Visual Basic®.

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

Объединение ролей

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

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

3. 
   Объединение ролей в малых проектах
   

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

Эскалация и подотчетность

Модель проектной группы не есть организационная структура

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

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

Внешняя координация – на ком лежит ответственность?

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

Рис. 4 иллюстрирует типичное распределение ответственности за координацию как по вопросам бизнеса, так и по вопросам технологий. “Управление программой”, “Управление продуктом”, “Удовлетворение потребителя” и “Управление выпуском” являются основными внешними координаторами. Эти роли решают как внутренние, так и внешние задачи, в то время как разработчики и тестировщики сфокусированы на внутренних задачах и не участвуют во внешнем обмене информацией.

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

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

4. 
   Коммуникации
   

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

Заключение

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

Поясняя это, Steve McConnell в “Rapid Development” пишет:

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

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

Для получения дальнейшей информации, см.:

Microsoft Solutions Framework: http://www.microsoft.com/msf/

Microsoft Operations Framework: http://www.microsoft.com/mof/

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

Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ, В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ.

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

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

© Корпорация Майкрософт (Microsoft Corp.), 2002. Все права защищены.

Microsoft и Visual Basic являются охраняемыми товарными знаками корпорации Майкрософт в США и других странах.

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

Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (http://www.elinesoftware.com). Другие документы по MSF на русском языке доступны в Internet по адресу: http://www.microsoft.com/rus/msf .

1 Термин “Белая книга” (whitepaper) в современной англоязычной литературе обычно обозначает официальный документ компании, свободно распространяемый в Internet (прим. редактора перевода).

2 Желающим досконально изучить MSF и подготовиться к сдаче экзамена 74-100 Microsoft Solutions Framework Practitioner Exam в дополнение к прочтению всех пяти “Белых книг” MSF рекомендуется прослушать учебный курс 1846 Microsoft Solutions Framework Essentials (прим. редактора перевода).

3 В контексте управления проектами под термином “спонсоры проекта” (project sponsors) обычно понимают лиц (либо организации), которые инициировали проект, выделяют для проекта ресурсы и утверждают его результаты. Иногда “project sponsor” переводится как “куратор проекта” (прим. редактора перевода).

1 См. Jim McCarthy, Dynamics of Software Development (Redmond, WA: Microsoft Press, 1995) для получения дальнейшей информации об оптимизации участия команды в проектировании.

~~

жүктеу/скачать 0.7 Mb.

Достарыңызбен бөлісу: