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

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

Таблица - Классификация рисков

Вид риска	Характеристика
Классификация рисков для оценки:
Экономический риск,в т.ч. внешнеэкономический риск	Риск, связанный с нестабильностью экономического законода­тельства и текущей экономической ситуации, условий инвестиро­вания и использования прибыли, возможность введения ограни­чений на торговлю и поставки, закрытия границ и т.п
Природно-климатический риск	Неопределенность природно-климатических условий, возможность стихийных бедствий
Производственно--технологический риск	Неполнота или неточность информации о динамике технико-экономических показателей, параметрах новой техники и технологии, аварии и отказы оборудования, производственный брак, риск невыполнения планиру­емых объемов работ и/или увеличения затрат, недо­статки производственного планирования и, как следствие, уве­личение текущих расходов предприятия
Инвестиционный риск	Рисквозможного обесценивания инвестиционно-финансового портфеля, состоящего как из собственных ценных бумаг, так и приобретенных
Рыночный риск	Риск колебания рыночной конъюнктуры, цен, валютных курсов и т.п.
Политический риск	Риск понесения убытков или сни­жения прибыли вследствие изменений в государственной по­литике, неопределенности политической ситуации, неблагопри­ятных социально-политических изменений в стране или регионе
Финансовый риск	Риск, связанный с осуществлением операции с финансовыми активами. Включает процентный, кредитный и валютный риски. Процентный риск возникает обычно при заключении дол­госрочных соглашений о займе на основе плавающей процен­тной ставки. Кредитный риск возникает при невозможности выполнения банком кредитного договора вследствие финансового краха. Валютный риск представляет риск потенциальных убытков, которые может понести фирма вследствие изменений в валют­ных курсах.
Классификация рисков для целей планирования проекта:
Внешние непредсказуемые риски	1.Неожиданные государственные меры регулирования в сферах материально-технического снабжения; охраны окружающей среды; проектных и производственных нормативов; землепользования; экспорта-импорта; ценообразования; налогообложения. 2. Природные катастрофы: наводнения; землетрясения; штормы; климатические катаклизмы и др. 3. Преступления: вандализм; саботаж; терроризм. 4. Неожиданные внешние эффекты: экологические; социальные. 5. Срывы в финансировании; в создании необходимой инфраструктуры; из-за банкротства подрядчиков; из-за ошибок в определении целей проекта; из-за неожиданных политических изменений.
Внешние предсказуемые (но неопределенные) риски	1. Рыночный риск в связи с: ухудшением возможности получения сырья; повышением стоимости сырья; изменением требований потребителей; экономическими изменениями; усилением конкуренции; потерей позиций на рынке; нежеланием покупателей соблюдать торговые правила. 2. Операционные: невозможность поддержания рабочего состояния элементов проекта; нарушение безопасности; отступление от целей проекта. 3. Недопустимые экологические воздействия. 4. Отрицательные социальные последствия. 5. Изменение валютных курсов. 6. Инфляция. 7. Налогообложение.
Внутренние нетехнические риски	1. Срывы планов работ из-за: недостатка рабочей силы; нехватки материалов; поздней поставки материалов; плохих условий на строительных площадках; изменения возможностей заказчика проекта, подрядчиков; ошибок проектирования; ошибок планирования; недостатка координации работ; изменения руководства; инцидентов и саботажа; трудностей начального периода; нереального планирования; слабого управления; труднодоступности объекта. 2. Перерасход средств из-за: срывов планов работ; неправильной стратегии снабжения; неквалифицированного персонала; переплат по материалам, услугам и т.д.; параллелизма в работах и нестыковок частей проекта; протестов подрядчиков; неправильных смет; неучтенных внешних факторов.
Технические риски	1. Изменение технологии 2. Ухудшение производительности в проекте 3. Специфические риски технологии, закладываемой в проект 4. Ошибки в проектно-сметной документации
Правовые риски	1. Лицензии, патенты 2. Невыполнение контрактов 3. Судебные процессы с внешними партнерами 4. Внутренние судебные процессы 5.Форс-мажор (чрезвычайные обстоятельства)
Страхуемые риски	1. Прямой ущерб имуществу. 2. Косвенные потери: демонтаж и передислокация поврежденного имущества; перестановка оборудования; потери арендной прибыли; нарушение запланированного ритма деятельности; увеличение необходимого финансирования. 3. Риски, страхуемые в соответствии с нормативными документами посто­ронним лицам: нанесение телесных повреждений; повреждение имущества; ущерб проекту вследствие ошибок проектирования и реализации; нарушение графика работ. 4. Сотрудники: телесные повреждения; затраты на замену сотрудников; потери прибыли.
Специалисты-аналитики классифицируют риски следующим образом:
Динамический	это риск непредвиденных изменений стои­мостных оценок проекта вследствие изменения первоначальных управленческих решений, а также изменения рыночных или полити­ческих обстоятельств. Такие изменения могут привести как к поте­рям, так и дополнительным доходам.
Статический	это риск потерь реальных активов вследствие нанесения ущерба собственности или неудовлетворительной орга­низации. Этот риск может привести только к потерям.
При управлении проектами менеджеры проектов выделяют риски:
«известные»	т. е. иметь ряд известных характерис­тик: определенную категорию, значение вероятности, оценку возможного влияния на проект и способ проявления. Управление такими рисками мож­но планировать и осуществлять, предлагая способы реагирования.
«неизвестные»	если они не могут быть идентифици­рованы по своей природе и спрогнозированы вообще.

Тема 9: Управление человеческими ресурсами IT-проекта.

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

2. Подходы к формированию команды IT-проекта:подход Центра объектно-ориентированной технологии компании IBM. Команда ХР проекта. Проектная группа: подход MSF.

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

=1=

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

1. планирование человеческих ресурсов – определение и документальное оформление ролей, ответственности и подотчетности, а также создание плана обеспечения проекта персоналом.

2. набор команды проекта – привлечение человеческих ресурсов, необходимых для выполнения проекта.

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

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

1 процесс: Планирование человеческих ресурсов

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

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

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

Существуют различные форматы документирования распределения ролей и ответственности членов команды проекта. Большинство форматов относятся к одному из трех типов (рис. 9.2):

1. иерархическому,

2. матричному

3. текстовому.

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

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

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

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

Пример типовой матрицы ответствен­ности приведен на рис.

Название проекта:
Менеджер проекта:
Инструкции:
О – ответственный	Полностью отвечает за успех и провал данной работы
П – принимает участие	Активно участвует в выполнении этой работы
К – контролирует	Проверяет качество полученных результатов
И – Информирует	Передает исполнителю этой работы входную информацию
У - утверждает	Утверждает документы
Пакет работ (работа)	Ф.И.О.	Ф.И.О.	Ф.И.О.	Ф.И.О.	Ф.И.О.	Ф.И.О.	Ф.И.О.	Ф.И.О.
Менеджер проекта	Инвестор/ заказчик	Команда управления проектом	Руководитель совета по управлению изменениями	Финансист	Руководитель подразделения
Лидер группы 1	Лидер группы 2	Лидер группы 3

Рисунок - Матрица ответственности

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

И — исполнение,

СИ — соисполнение,

ОИ — ответственное исполнение,

ТО — текущая ответственность,

У — утверждение,

С — согласова­ние,

О — обсуждение,

Э — экспертиза,

К — консультирование,

УС — участие в совещании и т. д.

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

2 процесс: Набор команды проекта

Набор команды проекта – это процесс привлечения человеческих ресурсов, необходимых для выполнения проекта.

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

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

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

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

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

1. Специфика проекта.

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

3. Особенности личного стиля взаимодействия руководителя с другими членами команды.

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

3 процесс: Развитие команды проекта

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

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

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

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

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

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

3. Проведение действий по сплочению ко­манды – ТИМБИЛДИНГ -(тренинги, неформальные мероприятия), командному решению проблем, осуществление действий по поддержке чувства успеха проекта и команды.

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

5. Со-расположене. Совместное размещение подразумевает размещение всех или большинства активных членов команды проекта в одном месте, чтобы укрепить их способность работать в единой команде.

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

4 процесс: Управление командой проекта

Управление командой проекта включает в себя:

- контроль за деятельностью членов команды проекта,

- обеспечение обратной связи,

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

Для эффективного управления командой проекта рекомендуется:

1. Обеспечить правильное руководство проектом и демонстрировать его ре­альное присутствие.

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

3. Создать положительный имидж проекту в компании во внешней к проекту среде.

4. Осуществлять эффективное планирование проекта, обсуждать рабочие задания.

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

6. Спланировать правильный процесс работы, вызвать трудовой энтузи­азм, рабочий настрой.

7. Способстволвать эффективному обмену информацией, укреплять обя­зательность сотрудников.

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

9. Стремиться к разрешению конфликтов и проблем.

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

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

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

- кадровые перестановки,

- проведение дополнительных тренингов

- меры дисциплинарного воздействия.

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

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

- дополнительное разъяснение отдельных ролей, чтобы убедиться, что выполняются все должностные обязанности,

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

=2=

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

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

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

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

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

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

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

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

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

5. Архитектор — отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом;

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

7. Эксперт предметной области — изучает сферу приложения, поддерживает направленность проекта на решение задач данной области;

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

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

10. Специалист по пользовательскому интерфейсу — отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям;

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

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

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

Желательное или часто встречающееся совмещение ролей:

1. менеджер проекта + архитектор

2. руководитель команды + архитектор

3. руководитель команды + менеджер

4. разработчик + разработчик (с различными функциональными направлениями)

5. библиотекарь + разработчик

6. специалист по пользовательскому интерфейсу + менеджер

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

Нежелательное или невозможное совмещение ролей:

1. заказчик + планировщик

2. руководитель команды + проектировщик

3. менеджер проекта + разработчик

4. разработчик + тестировщик

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

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

Заказчик -человек или группа людей, заинтересованных в создании конкретного программного продукта.

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

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

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

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

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

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