2010 г.
Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации
Селиховкин Иван
Санкт-Петербург – 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% если сотрудник работает только на данном проекте) |
| Роль на проекте | Роль сотрудника как члена команды проекта |
| Договоренности | Дата и форма договоренностей |
| Комментарии | Любые комментарии, в том числе пояснения к столбцу «период привлечения и объем загрузки», если его содержимое не полностью уточнено. |