Логистик

Инструктор

Тестер

Разработчик

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

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

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

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

- повышает качество продукта за счет конкуренции между группами.

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

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

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

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

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

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

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

=3=

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

К жестким механистическим структурам относится линейно-функциональная структура.

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

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

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

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

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

Разновидности матричных оргструктур:

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

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

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

Преимущества и недостатки ОСУ:

Преимущества	Недостатки
Функциональная ОСУ
1. возможность гибкого формирования команды 2. отсутствует дублирование функций	1.слабая мотивация 2.трудности координации; 3.медленные коммуникации и реакция на требования клиента; 4.проект не управляется как единое целое; 5.нет ответственности за конечные продукты
Матричная ОСУ
1. гибкость 2. снижается дублирование; 3. существует баланс ресурсов при осуществлении нескольких проектов;	1. сложность 2. дорога в использовании; 3. невозможна без качественной корпоративной информационной системы 4. нарушается принцип единоначалия и формируется двойной фокус при­нятия решений; 5. присутствует конфликт приоритетов.
Проектная ОСУ
1. концентрирует все усилия на достижении целей одного конкретного проекта. 2. прямая ответственность за результат; 3. короткие линии коммуникации, высокая скорость коммуникаций; 4. высокая заинтере­сованность в проекте; 5. мотивация членов команды высока и способствует нацеленности на вы­полнение задачи; 6. четко осуществляются контроль и коммуникации	1. дублирование функций; 2. нерациональный объем запасов (в сторону увеличения); 3. противоречивость в ис­полнении процедур и правил; 4. внутренняя конкуренция между проектами

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

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

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

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

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

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

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

=4=

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

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

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

- неформальная атмосфера;

- задача хорошо понята и принимается;

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

- задачи обсуждаются коллективно с участием всех членов команды;

- все члены команды свободно выражают как свои идеи, так и чувства;

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

- группа осознает, что делает, решение основывается на согласии, а не на голосовании большинства.

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

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

[2] Например, необходимая степень точности вычисленных значений.

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

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

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

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

[7] Ресурсы могут включать другие программные продукты, технические средства, расходные материалы (например, бумагу для печати, гибкие диски) и услуги эксплуатирующего, сопровождающего или обслуживающего персонала.

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

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

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

Дата добавления: 2013-12-13