Тема 3. Управление содержанием

1.

Тема 3.
Управление
содержанием
проекта

2.

Что такое «Содержание»?
Приведите примеры

3.

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

4.

Процессы управления содержанием
проекта
Основные процессы управления содержанием включают в себя:
Планирование управления содержанием
Сбор требований и создание Плана управления требованиями
Определение содержания - разработка подробного описания
содержания проекта
Создание иерархической структуры работ проекта - разбиение
проекта на более мелкие и легко управляемые компоненты
Подтверждение содержания - формальное утверждение
результатов проекта
Контроль содержания - управление изменениями в содержании
проекта

5.

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

6.

Управление содержанием проекта и
продукта
Управление содержанием проекта должно быть тесно связано с
управлением содержанием продукта проекта и осуществляться на
протяжении всего жизненного цикла проекта.
Содержание проекта (Project Scope) – работы, которые необходимо выполнить,
чтобы получить продукт, услугу или результат с указанными свойствами.
Содержание продукта (Product Scope) – свойства и функции, которые
характеризуют продукт, услугу или результат.
Реализацию содержания проекта руководитель проекта отслеживает по плану
управления проектом, описанию содержания проекта и ИСР
(иерархической структуре работ).
Реализация содержания продукта должна производиться в соответствии с
требованиями к продукту.

7.

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

8.

Сбор требований
Реестр заинтересованных сторон должен включать:
Идентификационную информацию: имя, должность, роль в
проекте, контакты
Содержательную информацию: основные требования, основные
ожидания, их потенциальное влияние на проект
Классификацию заинтересованных сторон:
внешний/внутренний,
поддерживающий/нейтральный/препятствующий...
ВНИМАНИЕ! Руководитель проекта обязан избегать включения в Реестр
информации, которая может, по мнению заинтересованной стороны,
нарушать ее интересы!
Пример. Это очень токсичная
женщина, которая не любит
работать, а любит только есть
пончики.

9.

Сбор требований
Документированные требования заинтересованных сторон:
Бизнес-цели и цели проекта для отслеживания (трассировки)
Функциональные и нефункциональные требования
Требования к качеству
Влияние на окружение внутри и снаружи исполняющей
организации
Допущения и ограничения требований и т.д.
Документ составляется в виде списка требований, ранжированных
по заинтересованным сторонам и приоритетности, либо в более подробной форме.

10.

Обследование
Что может являться источником
требований?

11.

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

12.

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

13.

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

14.

Уточняющие вопросы
Можете ли Вы привести пример?
Когда это произошло?
Есть ли у этого правила исключения?
Можете ли вы привести какие-нибудь цифры в
подтверждение своих слов?
Можно ли получить копию этого документа?
С какими еще документами вы работаете?
Есть ли что-то еще, о чем бы вы хотели рассказать
мне или я забыл у вас спросить? («метод Коломбо»)
Пример. Со стороны заказчика
возникает необходимость
осуществить повторное
согласование договоров в
юридическом отделе (в начале
этапа согласования и в конце).
Задаем уточняющий вопрос
«Можете привести пример?». Нам
говорят, что бывают случаи, когда
что-то нарушается, договор
искажается в процессе переговоров.
Мы спрашиваем: «Когда это было в
последний раз». Получаем ответ,
что был один такой случай 2 года
назад. Таким образом, эта
потребность является ложной и не
может стать требованием для
вашего программного обеспечения.
Метод Коломбо. Это действительно работает! Как бы хорошо вы ни
готовились к собеседованию, вы все равно можете что-то упустить. В
этом случае метод Коломбо показывает себя превосходно.

15.

Обследование. Хитрости
Работа парами
Вежливость и этикет (обязательно)
Наиболее удобный способ восприятия человеком реальности
Аудиал (больше проговаривайте)
Визуал (взаимодействуйте через зрительные образы – диаграммы,
графики, прототипы интерфейсов)
Кинестетик (используйте объекты реального мира, дайте в руки
документ, постройте прототип и дайте с ним поработать)
Пример. Однажды я долго не мог разработать и согласовать с заказчиком алгоритм
автоматического распределения документов между сотрудниками в отделе. Я купил
игральные карты (для покера) в магазине и мы использовали карты для имитации работы
алгоритма автоматической рассылки документов

16.

Сбор требований в Agile (HADIциклы)
Гипотеза – это то, в чем мы не уверены,
но хотели бы проверить
Гипотеза – это вопрос к бизнесу и
рынку
Пример. У вас есть мобильное приложение? У вас есть гипотеза, что если кнопку
подтверждения разместить в правом нижнем углу, то пользователи будут нажимать на нее
чаще. Вы размещаете кнопку в правом нижнем углу и ставите на нее показатели отслеживания
кликов. Если кнопка нажималась чаще, то гипотеза подтвердилась и размещение этой кнопки
является требованием к вашему продукту. Если стали щелкать реже, значит гипотеза не
подтвердилась и это не требование

17.

Сбор требований в Agile (Customer
Development)
Развитие проекта вокруг клиента и
его проблемы, а не вокруг идеи.
Мы общаемся с клиентами и
проверяем, что они действительно
готовы платить за то, что мы можем
для них сделать.
Пока команда не общается с
клиентом — она коллективно
галлюцинирует о потребностях,
функциях и наличии клиентов.

18.

Типы интервью в Agile
Проблемное интервью
Выявляете, есть ли проблема
Определяете цену её решения для клиента
Решенческое интервью
Определяете, готов ли клиент купить продукт с предлагаемой функциональностью
Вопросы проблемного интервью:
● Есть ли проблема?
● Как клиент оценивает проблему?
● Как он решает эту проблему сейчас?
Спрашивайте о прошлом, а НЕ о будущем. Важны не мнения, а факты и
договорённости о следующем шаге.
Не рассказывайте про продукт или решение на проблемном интервью.

19.

Качество требований
Документированность
Необходимость
Актуальность
Правильность (Корректность)
Однозначность (Недвусмысленность)
Полнота
Согласованность (Консистентность, Непротиворечивость)
Верифицируемость (Проверяемость, Тестируемость)
Модифицируемость
Трассируемость
Структурированность
Четкость (Конкретность, Ясность описания)
Атомарность (Неделимость)
Реализуемость (Осуществимость, Выполнимость)
Независимость от контекста (Самостоятельность)
Независимость от реализации
Подробное описание дано в главе книги (следующий слайд)

20.

Литература по управлению
требованиями к ПО
Вигерс – «Разработка требований к ПО»

21.

Документация требований
Приведите примеры документации требований
ГОСТ, РД?

22.

ГОСТы и РД
ГОСТ 34.601-90 Информационная Технология. КСАС.
Автоматизированные системы. Стадии создания
ГОСТ 34.201-2020 Информационная Технология. КСАС. Виды,
комплектность и обозначение документов при создании
автоматизированных ситем
ГОСТ 34.603-92 Информационная Технология. КСАС. Виды
испытаний автоматизированных систем
ГОСТ 34.602-2020 Комплекс стандартов на автоматизированные
системы. Техническое задание на создание автоматизированной
системы;
ГОСТ Р 59795-2021 «Информационная технология. Комплекс
стандартов на автоматизированные системы. Требования к
содержанию документов»

23.

Лестница
требований

24.

Сбор требований
План управления требованиями определяет порядок анализа,
документирования и управления требованиями в течение жизненного
цикла проекта

25.

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

26.

Описание содержания проекта
Подробное описание содержания проекта фиксируется в документе
"Описание содержания проекта" (Scope Statement).
Возможны различные названия документа "Описание содержания
проекта": "Цепи и задачи проекта", ''Определение проекта" и т.д.
Документ служит ориентиром для команды проекта при выполнении
работ проекта и позволяет проводить более детальное планирование
работ в дальнейшем.

27.

Описание содержания проекта
«Описание содержания проекта» (Scope Statement) - документ,
подробно описывающий продукт проекта и работы, необходимые для
создания этого продукта.
Принцип планирования – от общего к частному.
В Уставе проекта (Project charter) цели, задачи и ограничения проекта даны укрупненно.
В документе «Описание содержания» больше информации, и на основании
этого документа можно сделать гораздо больше выводов о природе проекта.

28.

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

29.

Важный аспект документа
"Описание содержания проекта"
Если цель нельзя однозначно сформулировать как "smart-цель”, то в
документы включают дополнительные разделы, позволяющие сделать
цели более чёткими, измеримыми и т.д.
Примерами таких разделов могут служить:
Критерии достижения целей
Требования к проекту и продукту
Ограничения и допущения проекта
Границы проекта

30.

Создание иерархической
структуры работ
Создание Иерархической структуры работ (Work Breakdown Structure), или
сокращенно ИСР (WSS) - очень важный процесс для любого проекта.
Иерархическая структура работ - это согласованная с результатами проекта
иерархическая декомпозиция работ, которые команда проекта должна выполнить
для достижения целей проекта и создания оговоренных результатов проекта.
С помощью ИСР структурируется и определяется всё содержание проекта.
ИСР подразделяет работы проекта на более мелкие и более управляемые
части, где на каждом более низком уровне ИСР детальнее определяются
проектные работы.
Рекомендуется также создавать словарь ИСР, включающий в себя перечень всех
элементов ИСР с их подробным описанием и уникальным кодом.
Документ «Описание содержания проекта» вместе с ИСР составляют базовый
план проекта по содержанию.

31.

Создание иерархической
структуры работ
ИСР создается путем декомпозиции - разбиения основных
результатов проекта на более мелкие и управляемые части.
Нижний уровень ИСР состоит из Пакетов работ (Work Packages) элементов, для которых можно определить их сроки выполнения и
стоимость.
У каждого пакета работ обязательно должен быть результат.

32.

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

33.

Цель создания ИСР
Цель декомпозиции:
Повышение точности оценок по стоимости и срокам проекта
Определение базиса для измерения и контроля хода выполнения
проекта
Создание четкого распределения ответственности
С помощью ИСР заинтересованные лица проекта могут лучше увидеть
конечный продукт проекта.
На более поздних этапах проекта декомпозиция будет продолжена и
пакеты работ будут детализированы до элементарных работ. Этот процесс
необходим для составления расписания и поэтому рассматривается в
разделе «Управление сроками».

34.

Цель создания ИСР
ИСР - следующий этап разработки и детализации содержания
проекта после создания документа «Описание содержания проекта».
Иерархическая структура работ наиболее полно описывает
содержание работ проекта, и на основании этого документа можно
лучше всего понять, какие работы входят в проект.

35.

Создание ИСР - подходы
При составлении ИСР можно применять разные подходы к
структуризации проекта.
В качестве основы для декомпозиции можно использовать:
Жизненный цикл проекта (этапы водопадной модели –
проектирование, реализация, внедрение….)
Компоненты продукта (подсистема 1, подсистема 2,…)
Функциональный подход (общие функции, функция 1, функция
2,…)
Географический подход (Россия, Китай, Сингапур,…)
Часто применяется комбинированный подход, в котором
используются разные основы декомпозиции для разных уровней ИСР.

36.

Пример ИСР
Данная иерархическая структура работ создана по жизненному циклу проекта.
На верхнем уровне ИСР указывается цель проекта (внедрение информационной
системы), следующий уровень – задачи (или подцели), которые требуют дальнейшей
детализации (в примере декомпозиция проведена не окончательно).

37.

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

38.

Подтверждение содержания
Процесс подтверждения содержания - процесс формального принятия
результатов проекта.
Результаты проекта проверяются на предмет их полной готовности.
При досрочном прекращении проекта процесс подтверждения
содержания должен установить и документировать степень
завершенности проекта.
Основная цель процесса - приёмка результатов и работ проекта
участниками проекта в соответствии с утвержденным содержанием
проекта (Project Scope).

39.

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

40.

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

41.

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

42.

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