Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации

Селиховкин Иван
Санкт-Петербург – 2010

Назад Содержание

Глоссарий

• Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта.
• Бюджет проекта – это сумма предельной цены проекта (cost baseline) и управленческих резервов (management reserves). Определяется спонсором.
• Веха – это работа с нулевой длительностью (используется при создании расписания проекта, чтобы обозначить значимый этап).
• Грубые оценки (ROM-estimate) – предполагают отклонение до 50%. Применимы в фазе инициации проекта.
• Заинтересованные лица проекта – все персоны, на интересы которых влияет реализация проекта (положительным или отрицательным образом).
• Золотая сервировка (gold platting) – добавление в продукт возможностей и функциональности, которая хоть и приятна заказчику, но не была им запрошена и не является необходимой для закрытия работ.
• Иерархическая структура работ (ИСР) (WBS) – поставко-ориентированная, иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов поставки.
• Качество – это уровень выполнения работ, при котором создаваемый продукт удовлетворяет предъявленным требованиям.
• Качественный анализ рисков – это субъективная оценка выявленных рисков. Мы должны определить – как сильно тот или иной угрожает проекту.
• Количественный анализ рисков – это форма объективной оценки риска. Ему подвергаются только «значимые» риски, отобранные в ходе предыдущего шага.
• Критический путь – отражает самый длинный путь в сетевой диаграмме и самое короткое время, за которое можно выполнить проект. У одного проекта может быть более одного критического пути.
• Ожидание – «умозрительная картинка будущего». Как правило – достаточно широкая. Ожидание нельзя включить в состав проекта, не преобразовав в требование. Пример ожидания: «чтобы производительность отдела возросла после внедрения ИТ-системы»; или «чтобы внедрение проекта не сильно сказалось на работе соседнего департамента».
• План управления проектом – это совокупность всех проектных планов.
• ПМ – проектный менеджер (аббревиатура)
• Предельная цена проекта (cost baseline) – это сумма себестоимости всех работ по проекту и стоимости всех резервов на непредвиденные случаи (contingency reserves). Определяется менеджером проекта.
• Продукт – результат (или набор результатов) поставки по контракту. Продукт, это то, что хочет получить заказчик.
• Проект – это процесс создания продукта. Это то, что делает команда, чтобы выдать заказчику продукт. Заказчику, обычно, проект не интересен.
• Риск – это вероятностное событие, которое может оказать положительное или отрицательное влияние на проект.
• Содержание проекта – описание работ, которые необходимо выполнить, чтобы получить продукт.
• Список ресурсов – совокупность договоренностей о выделении ресурсов на проект.
• Спонсор проекта – это фигура, обеспечивающая проект финансовыми ресурсами. .
• Требование – конкретный, измеримый, проверяемый запрос заинтересованного лица. Пример требования: «система должна позволять проходить все пользовательские сценарии без использования манипулятора «мышь»».
• Триггеры риска – признаки, по которым «хозяин риска» поймет, что превентивные действия не сработали и пора «отступать» (использовать План Б).
• Устав проекта – документ, формализующий договоренности со спонсором в ходе инициации проекта.
• Хозяин риска – персона, которой поручено обрабатывать риск (контролировать, что превентивные меры предприняты, а в случае наступления риска – реагировать на него).

Приложения

Перечень:

• Приложение 1 – Устав проекта
• Приложение 2 – Реестр заинтересованных лиц
• Приложение 3 – Матрица требований
• Приложение 4 – Концепция проекта
• Приложение 5 – Реестр рисков
• Приложение 6 – Перечень ресурсов (команда)

Эффективное использование приведенных шаблонов предполагает их модификацию и доработку под нужды вашей организации и/или проекта по необходимости. Приложения данной книги 0 лишь одним из способов адаптировать «лучшие практики» методологии PMBoK к управлению ИТ-проектами

Приложение 1 – Устав проекта

Приложение 2 – Реестр заинтересованных лиц

Иллюстрация: реестр заинтересованных лиц

Инструкции по заполнению реестра заинтересованных лиц:

NB: строки "проект" и "PM" обязательны для заполнения (соответственно – вносится название проекта и фамилия и имя менеджера проекта)

Поле	Алгоритм заполнения
ID	Уникальный идентификатор требования (st + инкремент)
Имя	Фамилия и имя заинтересованного лица
Роль в проекте	Проектная роль (пользователь, эксперт, спонсор, член команды и т.п.)
Должность	Занимаемая заинтересованным лицом должность
Отдел / департамент	Подразделение, где работает заинтересованное лицо
Непосредственный начальник	Прямой начальник заинтересованного лица
Контактная информация	Телефон, e-mail и прочее – ВСЯ известная контактная информация
Предпочитаемый вид коммуникаций	Электронная почта / телефон / совещания и т.п.
Главные ожидания	Главные ожидания заинтересованного лица по проекту
Главные требования	Главные требования заинтересованного лица по проекту (или ID в матрице требований, если были внесены туда)
Влияние на проект	Влияние на проект по в баллах по шкале 1 – 10 (где 1 – минимальное влияние; 10 – максимальное влияние)
Отношение к проекту	Противник / Сторонник / Нейтрал
Интерес к проекту	Возможно, заинтересованное лицо ХОЧЕТ принять участие в проекте как эксперт или в иной форме.
Комментарий	Любые комментарии

Приложение 3 – Матрица требований

Иллюстрация: матрица требований

Инструкции по заполнению матрицы требований

NB: строки "проект" и "PM" обязательны для заполнения (соответственно – вносится название проекта и фамилия и имя менеджера проекта)

Поле	Алгоритм заполнения
ID	Уникальный идентификатор требования (s + инкремент)
Описание требования	Подробное описание требования (функциональные и не функциональные характеристики)
Автор	Автор требования (т.е. тот, кто НАЗВАЛ требование команде, а не тот, кто записал названное в настоящий файл)
Дата	Когда требование впервые стало известно команде
Документ выявления	Документ, формализовавший названное требование (отчет об интервью, протокол совещания и т.д.)
Статус требования	Открыто / закрыто / отменено
Заменено на (ID)	Если настоящее требование изменилось – оно "закрывается" (отметка в столбце "статус требования"), заводится новое , с новым ID (он указывается и в данном столбце)
Последователь чего? (ID)	Если настоящее требование это результат изменения предыдущего, то в данном столбце указывается ID предшественника
Спецификация (ID)	Если формировался технический документ по реализации данного требования – то указать его ID
Модуль	Название модуля ПО, в который войдет реализуемое требования (назвать или перечислить через запятую)
Дата реализации	Дата внутренней приемки (внутри команды проекта)
Дата приемки	Дата приемки заказчиком
Документ приемки (ID)	Документ, подтверждающий приемку заказчиком
Дополнительные комментарии	Любые комментарии

Приложение 4 – Концепция проекта

Приложение 5 – Реестр рисков

Иллюстрация: реестр рисков

Инструкции по заполнению реестра рисков

ID	Уникальный идентификатор риска (rs + инкремент)
Статус риска	"Открыт" для рисков, которые актуальны; "закрыт" для рисков, более не актуальных на проекте (реализовавшихся, ставших невозможными и т.п.)
Влияние риска	Элемент качественной оценки риска ("высокое / среднее / низкое") (выделение цветом автоматическое, соответственно: красный / желтый / зеленый)
Вероятность риска	Элемент качественной оценки риска ("высокая / средняя / низкая") (выделение цветом автоматическое, соответственно: красный / желтый / зеленый)
Уровень риска	Интегральная качественная оценка риска ("красный" – для самых опасных и приоритетных рисков, "желтый" – для умеренных", "зеленый" – для наименее существенных). Оценка формируется автоматически, на основании данных столбцов «влияние риска» и «вероятность риска. Соответственно: (зеленый + зеленый) = зеленый уровень риска (зеленый + желтый) = зеленый уровень риска (желтый + желтый) = желтый уровень риска (желтый + красный) = красный уровень риска (красный + красный) = красный уровень риска
Описание риска	Тезисно – в чем суть (причина, содержание) риска
Влияние на проект	Тезисно – в чем суть влияния риска на проект
Область риска	Общее название группы, к которой можно отнести данный риск
План А (contingency plan)	Что будем делать для того, чтобы реализовать стратегию обработки риска
Триггеры	Условия для запуска действий по плану Б (одновременно – признак того, что риск реализовался)
Тип стратегии обработки риска	Для позитивных рисков: "использование / усиление / разделение"; для негативных рисков: "предотвращение / смягчение / перенос"; для обоих видов риска: "принятие"
Хозяин риска	Лицо ответственное за мониторинг триггера и запуск contingency плана
План Б (fallback plan)	Что будем делать, если риск реализовался (не заполняется, если тип стратегии обработки риска – "принятие")

Приложение 6 – Перечень ресурсов (команда)

Иллюстрация: перечень ресурсов (команда)

Инструкции по заполнению перечня ресурсов

ID	Уникальный идентификатор требования (hr + инкремент)
ФИО сотрудника	ФИО сотрудника, привлекаемого в команду проекта
Отдел	Название отдела, к которому относится привлекаемый сотрудник
Прямой руководитель	Хозяин ресурса (прямой руководитель сотрудника)
Период привлечения и объем загрузки	Период привлечения на проект и объем загрузки – указывается один или несколько интервалов (даты с… – по…) в течении которого сотрудник будет выделен на проект, а также объем его загрузки в % (100% если сотрудник работает только на данном проекте)
Роль на проекте	Роль сотрудника как члена команды проекта
Договоренности	Дата и форма договоренностей
Комментарии	Любые комментарии, в том числе пояснения к столбцу «период привлечения и объем загрузки», если его содержимое не полностью уточнено.

Назад Содержание