Управление интеграцией и содержанием работ проекта - Роль РМ - Жизненный цикл проекта. Области знаний/группы процессов - Модели жизненных циклов - Жизненный цикл проекта VS жизненный цикл продукта - Сбор и формализация требований - WBS - SOW - Change request

1. Управление интеграцией и содержанием работ проекта.
Игорь Устинов
ustinov.igor.v@gmail.co
m

2. Системный подход к управлению
проектами
• Проекты выполняются в окружении
• Проект вовлекает множество дисциплин и профессий
• Менеджеру проекта необходимо иметь целостное
видение проекта, этим его роль уникальна в команде
проекта

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

4. Жизненный цикл проекта
Проекты делятся на меньшие более управляемые компоненты (фазы)
• Завершение каждой фазы проекта отмечается одним или более результатами поставки и
их рассмотрением. Результат поставки - осязаемый, проверяемый результат работ
• Как правило, результаты фазы (выходы) используются как входы для следующей фазы

5. Области знаний / группы процессов
Initiating Planning Executing Monitoring and Controlling Closing
4. Управление интеграцией проекта 4.1 Разработка
Устава проекта
4.2 Разработка плана управления
проектом
4.3 Руководство и управление
работами проекта
4.4 Мониторинг и контроль работ
проекта
4.5 Интегрированный контроль
изменений
4.6 Закрытие проекта
или фазы
5. Управление содержанием проекта 5.1 Планирование управления
содержанием
5.2 Сбор требований
5.3 Определение содержания
5.4 Создание ИСР
5.5 Подтверждение содержания
5.6 Контроль содержания
6.Управление сроками проекта 6.1 Планирование управления сроками
6.2 Определение операций
6.3 Определение последовательности
операций
6.4 Оценка ресурсов операций
6.5 Оценка длительности операций
6.6 Разработка расписания
6.7 Контроль расписания
7.Управление стоимостью проекта 7.1 Планирование управления
стоимостью
7.2 Оценка стоимости
7.3 Определение бюджета
7.4 Контроль стоимости
8.Управление качеством проекта 8.1 Планирование управления
качеством
8.2 Обеспечение качества 8.3 Контроль качества
9.Управление человеческими ресурсами
проекта
9.1 Планирование управления
человеческими
ресурсами
9.2 Набор команды проекта
9.3 Развитие команды проекта
9.4 Управление командой проекта
10.Управление коммуникациями проекта 10.1 Планирование управления
коммуникациями
10.2 Управление коммуникациями 10.3 Контроль коммуникаций
11.Управление рисками проекта 11.1 Планирование управления рисками
11.2 Идентификация рисков
11.3 Качественный анализ рисков
11.4 Количественный анализ рисков
11.5 Планирование реагирования на
риски
11.6 Контроль рисков
12.Управление закупками проекта 12.1 Планирование управления 12.2 Проведение закупок 12.3 Контроль закупок 12.4 Закрытие

6. Жизненный цикл проекта

7. Жизненный цикл проекта

8. Модели жизненных циклов проекта
• Содержание (сроки, стоимость)
определяются
максимально рано
• Продукты и способ их получения
понятны
• Частичная поставка результата не
имеет смысла
«Водопадная» модель ЖЦ

9. Модели жизненных циклов проекта
Итеративные /инкрементальные ЖЦ
• Содержание (требования) заранее определить невозможно – итеративный «спиральный» ЖЦ
• Продукт в окончательном виде изготовить затруднительно / рискованно – «инкрементальный» ЖЦ
• Частичная поставка результата имеет смысл
• Требуется снизить сложность и/или риски проекта
• Отдельные стороны заинтересованы в небольшой части жидаемой функциональности продукта
• Каждая фаза (итерация), как правило, может включать все группы процессов управления проектом

10. Модели жизненных циклов проекта
(спиральные)

11. Модели жизненных циклов проекта
(спиральные)

12. Модели жизненных циклов проекта
(инкрементные)

13. Модели жизненных циклов проекта
(Agile)
Адаптивные / «гибкие» ЖЦ
• Предпочтительны при высокой изменчивости содержания
• Итеративны + инкрементальны
• Короткие итерации (2-4 недели) фиксированной
продолжительности и стоимости
• Предполагают:
– Высокую вовлеченность заинтересованных сторон
– Приоритезацию требований
– Поставку завершенного результата в каждой итерации
• Могут сочетаться с другими моделями ЖЦ
• Каждая фаза (итерация), как правило, может включать
все группы процессов управления проектом с акцентом

14. ЖЦ продукта и ЖЦ проекта
• ЖЦ продукта: обычно последовательные
неперекрывающиеся фазы (например,
проектирование – постановка на производство –
серийный выпуск - …)
• Последняя фаза ЖЦ продукта – изъятие из обращения
или вывод из эксплуатации
• ЖЦ продукта и ЖЦ проекта в общем случае не
совпадают по длительности
• ЖЦ одного или ряда проектов, как правило,
происходят в период ЖЦ продукта

15. Содержание проекта и содержание
продукта
• Два контекста:
• Содержание продукта
– Свойства и функции, характеризующие результаты поставки проекта
– Фокус процесса на cборе требований
• Содержание проекта
– Работа, которую необходимо выполнить, чтобы поставить результаты проекта заданного
содержания.
– Данный раздел фокусируется на процессе управления содержанием проекта

16. Содержание проекта
• Устанавливает логические границы проекта
• Позволяет определить, что относится к проекту, а что нет
• Позволяет гарантировать, что в проект включены только работы, необходимые для
достижения утвержденных целей
• Предотвращает лишнюю работу и выход проекта за пределы базовых ограничений
• Менеджер проекта обязан управлять содержанием в любом проекте
• Управление изменениями содержания проекта – ключ к сохранению тройного
ограничения (время-деньги-содержание)
• Изменения содержания должны производиться структурированным и контролируемым
образом, только через контроль изменений (change request)

17. Сбор требований
• Описывают, каким образом отдельные требования удовлетворяют потребности бизнеса и
ожидания заинтересованных сторон
• Требования последовательно детализируются, насколько это возможно
• Требования должны быть:
◦ S.M.A.R.T.
Specific (Конкретный) ; Measurable (Измеримый) ; Attainable, Achievable (Достижимый);
Relevant (Актуальный); Time-bound (Ограниченный во времени)
◦ I.N.V.E.S.T. (user-story)
Independent. Reduced dependencies = easier to plan
Negotiable. Details added via collaboration;
Valuable. Provides value to the customer;
Estimable. Too big or too vague = not estimable;
Small. Can be done in less than a week by the team;
Testable . Good acceptance criteria;

18. Категоризация требований
Предоставляет удобство сбора, анализа и контроля
• Бизнес – требования:
– высокоуровневые описания решаемых проблем, реализуемых возможностей и т.п.
• Требования заинтересованных сторон:
– ограничения, предпочтения и т.п.
• Требования к решению:
– функциональные и не функциональные
• Требования к внедрению:
– перенос данных, обучение, поддержка и т.п.
• Требования к проекту:
– Процессы, технологии, ограничения и т.п.
• Требования к качеству, критерии приемки, и т.п.

19. Матрица отслеживания требований
(Requirements Traceability Matrix)
Связывает требования с их происхождением и позволяет проследить их выполнение на
протяжении жизненного цикла проекта
• В конце проекта позволяет документально удостовериться, что утвержденные
требования реализованы в результатах поставки
• Помогает управлять изменениями содержания
• Соотносит требования с
– Бизнес – потребностями и целями проекта
– Элементами жизненного цикла и операциями проекта (проектирование, изготовление,
тесты и испытания)

20. Матрица отслеживания требований
(Requirements Traceability Matrix)

21. Сбор требований

22. Описание бизнес процессов
Наиболее известные нотации описания
бизнес процессов:
- BPMN (англ. Business Process Model and
Notation, нотация и модель бизнес-
процессов)
- Событийная цепочка процессов (EPC-
диаграмма, англ. event-driven process chain)
- UML (англ. Unified Modeling Language —
унифицированный язык моделирования)

23. Use-story, Use-case
Пользовательские истории (англ. User Story) — способ описания
требований, сформулированных как одно или более предложений на
повседневном или деловом языке пользователя.
Как, <роль/персона юзера>, я <что-то хочу получить>, <с такой-то целью>, как
это проверить
Вариант использования (англ. Use case) - описание поведения системы,
когда она взаимодействует с кем-то (или чем-то) из внешней среды.
Другими словами, сценарий использования описывает, «кто» и «что»
может сделать с рассматриваемой системой, или что система может
сделать с «кем» или «чем». Методика сценариев использования
применяется для выявления требований к поведению системы, известных
также как пользовательские и функциональные требования.

24. Иерархическая структура работ проекта
(WBS, work breakdown structure)
WBS – ориентированная на результаты иерархическая декомпозиция
работ, которые должна выполнить команда проекта
• Образует и организует содержание проекта
• Чего нет в WBS – не подлежит выполнению
• Степень детализации зависит от величины и
сложности проекта
• Все планирование и контроль проекта базируются на WBS
• Предотвращает неконтролируемые изменения содержания проекта
• Планирование методом «набегающей волны»
– Декомпозиция приостанавливается до прояснения результата, пакета
работ или подпроекта, затем продолжается на очередной «горизонт
планирования»
• Различные результаты могут отличаться по уровню детализации

25. Техническое задание
(Statement of Work (SOW))
Может составлять как Исполнителем так и Заказчиком. Существует ГОСТы по его подготовке.
Как инструмент коммуникации в связке общения заказчик-исполнитель, ТЗ позволяет (из Википедии):
Обеим сторонам:
◦ представить (вообразить) готовый продукт,
◦ выполнить попунктную проверку готового продукта (приёмочное тестирование — проведение испытаний),
◦ уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением
испытаний).
Заказчику:
◦ осознать, что именно ему нужно,
◦ требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ.
Исполнителю:
◦ понять суть задачи, показать заказчику «технический облик» будущего изделия, продукта,
◦ спланировать выполнение проекта и работать по намеченному плану,
◦ отказаться от выполнения работ, не указанных в ТЗ.
ТЗ в большинстве случае это набор минимально приемлемых требований, т.е. описывает наихудший допустимый вариант реализации!
!!! При грамотно проведенной разработке ТЗ становится мощнейшим инструментом манипуляций как заказчиком, так и исполнителем.

26. Контроль содержания проектапродукта
(change request (CR))
• Предупреждает «расползание содержания»
• Фокусируется на:
– Мониторинге статуса содержания проекта и продукта
– Контроле воздействия изменений на содержание проекта
– Выявлении возникших изменений содержания
– Управлении фактическими изменениями содержания в случае их возникновения
– Предупреждении неконтролируемых изменений содержания (в обход Интегрированного контроля
изменений)
• Базируется на процессе и процедурах контроля изменений. Часто в проекте создается группа которая
принимает решение по возникшим CR (принятьотклонить). Все CR нужно учитывать!
• Интегрируется со всеми остальными процессами управления: стоимостью, сроками, качеством и т.п.

27. Что дальше?
Управление требованиями
 Модели жизненных циклов
 Выявление бизнес требований
 Виды требований. Хорошо описанное требование
 Отслеживание требований
 Запрос на изменения
 Виды представления требований
 Иерархическая структура работ проекта
 Нотации описания процессов
 MVP, прототипирование
Igor Ustinov, PMP , ustinov.igor.v@gmail.com