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

⇐ ПредыдущаяСтр 15 из 15

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

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

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

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

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

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

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

Рисунок 6. Коммуникации

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2019-01-14; просмотров: 162; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 6 7 8 9 10 11 12 13 1415

Мы поможем в написании ваших работ!