Управление содержанием проекта по PMBoK
Рисунок 1. Схема процессов управления содержанием проекта
Схема процессов управления содержанием проекта (рисунок 1) в соответствии с PMI PMBoK 5th Edition включает следующие процессы.
Сбор требований
Процесс «Сбор требований» — это процесс определения и документирования потребностей заинтересованных сторон проекта для достижения целей проекта. На успех проекта напрямую влияет тщательность сбора и управления требованиями к проекту и продукту. Требования включают в себя количественно определенные и формализованные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон проекта.
Данные требования должны быть выявлены, проанализированы и зарегистрированы с достаточной степенью детализации так, чтобы их можно было измерить после начала исполнения проекта. Сбор требований представляет собой определение ожиданий заказчика и управление ими.
Требования становятся базой для ИСР. Планирование стоимости, расписания и качества строится на основе этих требований. Разработка требований начинается с анализа информации, содержащейся в Уставе проекта и в Реестре заинтересованных сторон проекта.
Определение содержания
Это процесс разработки подробного описания проекта и продукта. Подготовка подробного описания содержания проекта чрезвычайно важна для успеха проекта и основывается на основных результатах, допущениях и ограничениях, задокументированных во время инициации проекта.
Содержание проекта определяется во время планирования и описывается более подробно по мере поступления информации о проекте. Существующие риски, допущения и ограничения анализируются на предмет полноты. При этом дополнительные риски, допущения и ограничения добавляются по ходу проекта.
Создание иерархической структуры работ (ИСР)
Разработка ИСР — это процесс разделения результатов проекта и работ по проекту на более мелкие и управляемые элементы. Иерархическая структура работ – это ориентированная на результаты иерархическая декомпозиция работ, которые должна выполнить команда проекта для достижения целей проекта и создания требуемых результатов.
На каждом более низком уровне ИСР представляет все более детальное описание работ по проекту. ИСР организует и определяет общее содержание проекта и представляет работы, указанные в текущем одобренном описании содержания проекта.
Подтверждение содержания
Этот процесс необходим для формализованной приемки завершенных результатов проекта. Подтверждение содержания включает в себя проверку результатов вместе с заказчиком или спонсором, чтобы убедиться, что они выполнены удовлетворительно, и формальную приемку результатов заказчиком или спонсором.
Подтверждение содержания отличается от контроля качества в том, что подтверждение содержания в основном связано с приемкой результатов, а контроль качества в основном ориентирован на правильность результатов и соблюдение требований к качеству, заданных для результатов. Контроль качества, как правило, проводится до подтверждения содержания, однако эти два процесса могут выполняться и параллельно.
Управление содержанием
Это процесс мониторинга статуса проекта и содержания продукта, а также управления изменениями базового плана по содержанию. Управление содержанием проекта обеспечивает обработку всех запрошенных изменений и рекомендованных корректирующих и предупреждающих действий в рамках процесса осуществления общего управления изменениями.
Управление содержанием проекта используется также для управления фактическими изменениями по мере их появления; оно интегрировано в остальные процессы управления. Неуправляемые изменения часто называют «сдвигом содержания проекта». Изменения в любом случае неизбежны, и поэтому необходим процесс управления изменениями.
Методы сбора требований или «Как понять, что хочет заказчик?»
Данная статья будет полезна как аналитикам, так и менеджерам, занимающимся сбором и анализом требований. В ней описаны основные методики сбора требований, а также их плюсы и минусы. Возможно, что-то вы уже применяли на практике, а о чем-то, возможно, не знали. В общем, эта статья для всех тех, кто уже занимается бизнес — анализом или только планирует пополнить ряды аналитиков. 
Сбор требований — это один из самых важных этапов процесса создания любой информационной системы, будь то десктопное, веб или мобильное приложение или же просто доработка уже существующего решения. Прежде, чем начать собирать требования, необходимо выявить всех заинтересованных лиц (стейкхолдеров), которые будут пользоваться системой. Чем точнее будет этот список, тем полнее будут требования. Итак, для начала, рассмотрим кто же такие стейкхолдеры.
Стейкхолдерами могут быть любые физические лица и/или организации, которые активно участвуют в нашем проекте, и чьи интересы могут быть затронуты не только в процессе создания системы, но и непосредственно по завершению самого проекта. Ими могут быть менеджеры, начальники отделов, директора, любые сотрудники организации, которые будут хоть как-то взаимодействовать с готовым решением, и чьи требования (пожелания, идеи, потребности, проблемы) будем собирать.
Существует множество различных техник сбора требований, которые помогут лучше понять, что же хочет заказчик.
Рассмотрим основные из них чуть подробнее:
Анкетирование
Данный способ подразумевает под собой составление листа-опросника (анкеты, брифа), который может содержать открытые (требуют от опрашиваемого сформулировать его ответ) и закрытые (требуют от опрашиваемого выбрать ответ из предложенных вариантов) вопросы.
Анкетирование используется для того, чтобы подтвердить или детализировать ранее известные требования, выбрать параметры для решений.
Самым известным примером анкетирования может быть “Бриф на разработку сайта” — анкета содержащая список основных требований и информацию о будущем сайте.
Интервью
Этот метод известен многим, своего рода беседа “по душам” с заинтересованным лицом, тет-а-тет.
Необходимо задавать открытые вопросы для получения информации и закрытые для того, чтобы подтвердить или опровергнуть конкретные варианты требований.
Данный способ применяется, в основном, для получения информации по какой-либо конкретной теме и/или для уточнения требований.
Многим может показаться этот способ достаточно легким, но это не так. Провести хорошее интервью достаточно сложно. Вы должны гибко реагировать на реакцию интервьюируемого и в случае необходимости изменять порядок заготовленных вопросов или их формулировку. Не забудьте включить диктофон во время интервью или вести заметки.
Автозапись
Данный метод подразумевает под собой работу с записями, письмами (электронными письмами), а также с любым другим документом, автором которого является Заказчик или конечный пользователь (т.е. стейкхолдер).
В действительности это может быть и документ и наговоренная на диктофон последовательность действий или самая обычная салфетка, на которой заказчик набросал свои идеи / проблемы /хотелки, которые необходимо превратить в полноценные требования, согласовать и передать в разработку.
Примером такого метода может быть работа с концепцией или видением проекта (сам Заказчик любит называть это — «ТЗ»), которую он прислал вам на момент начала работ по аналитике.
Изучение существующей документации
Данная методика может быть использована при наличии в организации документации, которая может помочь в определении потребностей Заказчика. Примеры документации включают в себя: регламенты,
описания процессов, структура организации, спецификации продукта, различные процедуры, стандарты и инструкции, шаблоны документов и т.д.
Выявленные требования являются основой для дальнейшего анализа и должны быть детализированы.
Данная методика применима, например, при автоматизации устоявшихся в организации регламентированных бизнес процессов.
Повторное использование спецификации
Повторно использовать спецификации можно в том случае, если есть уже завершенные один или несколько подобных проектов.
Техническое задание, подготовленное на предыдущем проекте может быть использовано для другого проекта с целью сократить продолжительность сбора, анализа и разработки требований, что позволит быстрее начать разработку.
Например, ТЗ для интернет магазинов похожи друг на друга и содержат одинаковые требования.
В большинстве случаев только часть документации актуальна для нового проекта, поэтому потребуется тщательная проверка требований на соответствие текущим целям и задачам Заказчика.
Представитель заказчика в компании разработчика
Один из наиболее эффективных методов сбора требований, поскольку позволяет получать от представителя Заказчика своевременную оценку прогресса, корректности реализации, в короткие сроки получать обратную связь (фидбек) и дополнительную информацию для корректировки и разработки требований.
Метод часто применяется для сбора и управления требованиями при итерационной разработке, позволяет оперативно собирать, согласовывать и дорабатывать требования.
В дополнение можно сказать, что наличие представителя заказчика в компании разработчика является одним из главных правил Agile.
Работа «в поле»
Работа «в поле» состоит из наблюдения за деятельностью и процессами будущих пользователей системы, и в определении требований, основанных на этом наблюдении. Если говорить проще, то это наблюдение за тем, как работают пользователи, и документирование процесса, задач и результатов их деятельности.
Метод позволяет избежать проблем, связанных с трудностями стейкхолдеров в описании и выражении своих потребностей. В некоторых случаях процесс наблюдения может сопровождаться «интервьюированием» пользователей для уточнения особенностей и деталей их работы и задач. В процессе наблюдения можно так же выявить пути оптимизации бизнес процессов Заказчика.
Обучение
Обучение — это процесс, в котором Заказчик или любой другой человек из организации Заказчика, знающий процесс, обучает аналитика по принципу учитель — ученик.
Метод полезен, когда процессы и деятельность сотрудников Заказчика трудно описать с помощью других методов или Заказчик не может предоставить адекватное описание требований.
Обучение позволяет лучше понять сложные бизнес-процессы, а также преодолеть трудности, связанные с нехваткой абстрактного мышления и самовыражения у будущих пользователей системы.
Мозговой штурм
Мозговой штурм — наиболее часто используемый метод получения требований, которые связанны с новыми или плохо изученными направлениями деятельности организации Заказчика или функциями системы.
Он позволяет собрать множество идей от различных заинтересованных лиц (стейкхолдеров) в кратчайшие сроки и практически бесплатно.
Во время мозгового штурма участники «накидывают» любые идеи, касающиеся решения данной проблемы.
С помощью этой методики можно проработать несколько различных вариантов решения заданной проблемы, а также разрешить конфликты требований.
Совещание
Совещание — встреча, ориентированная на обсуждение конкретных вопросов, которые были определены и озвучены участникам заранее.
На такие встречи привлекаются люди, которые придерживаются различных точек зрения по текущей проблеме и могут помочь описать требования, основываясь на взглядах с разных сторон. В процессе совещания уточняется общий список требований, выявляются скрытые требования и решаются конфликты требований.
Совещания являются одной из ключевых практик в Agile, т.к. в них участвуют все стороны, заинтересованные в развитии проекта и решении проблемы.
Use case
Use cases или варианты использования позволяют собрать и сформировать функциональные требования от лица участников Диаграммы вариантов использования определяют границы решения и показывают связи с внешними системами и участниками.
Метод позволяет детализировать требования с точки зрения пользователей, а также помогает уточнить и систематизировать функционал, который требуется реализовать.
Эпилог
Комбинирование методик позволяет повысить эффективность сбора требований, а так же избежать их «потери».
При сборе требований необходимо помнить, что важны не только функциональные требования (ЧТО делает система), но и нефункциональные (КАК система это делает).
Тщательно собранные требования минимизируют риски проекта, т.к. позволяют сформировать четкий и понятный базис для разработки системы.
Информация для статьи взята из учебного пособия по подготовке к сертификации REQB Certified Professional for Requirements Engineering (Базовый уровень).
Требования к оформлению документов по делопроизводству
Независимо от формы собственности организации, вида ее деятельности, наименования документации, места ее составления существуют общие требования по оформлению документов. Ранее делопроизводители ориентировались на стандарт 6.30-2003 при оформлении документов, но относительно недавно в действие был введен новый ГОСТ. Какие требования имеют место при ведении делопроизводства и насколько серьезные изменения внес в эту сферу действующий менее года государственный стандарт, рассказывается в статье.
Правила оформления документов и их значение
Оформление документов в широком смысле — это соблюдение требований законодательных актов, нормативных документов в процессе составления, подготовки, копирования, согласования, заверения, пересылки документации.
В более узком смысле – расположение реквизитов документа на материальных носителях: бумажном, электронном, в соответствии с действующими правилами.
Грамотное, в соответствии с нормативными требованиями оформление реквизитов документов не только свидетельствует о делопроизводственной культуре, но и гарантирует юридическую силу документа, а также имеет вполне практическое значение — сокращает время на обработку документа и его регистрацию, обеспечивает правильное направление на исполнение, позволяет связаться с непосредственным исполнителем для решения технических вопросов в рабочем порядке и т.п.
Как оформить реквизиты документов?
Требования, в соответствии с которыми оформляется документ, устанавливаются на федеральном уровне ГОСТом. Это документ нормативно-технического характера, на основе которого каждая организация, ведомство, учреждение разрабатывает свои нормативные акты, касающиеся оформления документации:
Требования к оформлению документов по ГОСТу включают в себя в том числе порядка 30 реквизитов, предназначенных для различных целей. Каждый вид документа содержит собственный набор необходимых реквизитов.
Соблюдение требований к созданию и оформлению документации необходимо:
Расположение реквизитов по ГОСТу позволяет не только работать с ним быстро и эффективно, без потерь времени, но и экономить полезную площадь на бланке, придать документу качественный внешний вид.
Требования ГОСТа
ГОСТ Р 7.0.97-2016 введен в действие 01/07/18, и именно он устанавливает базовые требования по оформлению документов в делопроизводстве. Рассмотрим обзорно, что собой представляет этот документ.
Он достаточно объемный, с подробным изложением информации, предназначенной для делопроизводителей, секретарей, руководства. Требования подразделяются в нем следующим ниже порядком:
В приложениях А, В даны:
На заметку! В ГОСТе уделено много внимания вопросам электронного документооборота, в связи с его все более широким распространением.
Документы организации: учитываем новый стандарт
На какие реквизиты документов и правила оформления следует обратить внимание особое внимание, используя ГОСТ Р 7.0.97-2016, прежде всего?
Вот эти важные моменты:
Заключение
Требования к оформлению документов в делопроизводстве устанавливаются в настоящее время государственным стандартом, действующим с середины прошлого года за №Р 7.0.97-2016. На основе ГОСТа организации и учреждения разрабатывают собственные нормативы по оформлению документации. Стандартизация документооборота необходима, поскольку дает возможность оперативно обрабатывать, искать и копировать документы. Исполнение требований по оформлению документов позволяет говорить о них как о юридически значимых.
В действующем ГОСТе законодатель предлагает рекомендации по оформлению реквизитов, бланков, излагает требования при создании документов. По сравнению с утратившим силу стандартом, некоторым спорным и неясным вопросам уделено особое внимание. В частности, разъясняется, каким шрифтом должен создаваться документ, как оформляется подпись за директора иного ответственного лица, и говорится о том, что печать организации не должна ставиться поверх подписи ответственных лиц.
Руководство к Своду знаний по управлению проектами (Руководство PMBOK)
Руководство к Своду знаний по управлению проектами (Руководство PMBOK®)
© 2013 Project Management Institute, Inc. Все права защищены.
Публикуемые Институтом управления проектами (Project Management Institute, Inc., сокращенно PMI) стандарты и руководства, к числу которых принадлежит и данный документ, разработаны согласно процессу разработки стандартов на основе добровольного участия и общего консенсуса. В ходе такого процесса объединяются усилия волонтеров и/или сводятся воедино замечания и мнения лиц, заинтересованных в предмете, которому посвящено данное издание. Хотя PMI администрирует этот процесс и устанавливает правила, гарантирующие непредвзятость при достижении консенсуса, PMI не занимается написанием документа, а также независимым тестированием, оценкой и проверкой точности или полноты материала, содержащегося в издаваемых PMI стандартах и руководствах. Подобным же образом, PMI не занимается проверкой обоснованности мнений, высказанных в этих документах.
PMI не несет ответственность за какие-либо травмы, повреждения, нанесенные собственности, или какие-либо другие убытки, будь то реальные, косвенные или компенсаторные, произошедшие непосредственно или косвенно вследствие издания, применения или использования данного документа. PMI не несет ответственность и не предоставляет гарантию, прямую или предполагаемую, относительно точности или полноты любого материала, содержащегося в данном документе, а также не несет ответственность и не предоставляет гарантию того, что содержащаяся в данном документе информация отвечает каким-либо вашим целям или нуждам. PMI не предоставляет гарантию относительно качества каких-либо продуктов или услуг отдельного производителя или продавца, проистекающего из использования данного стандарта или руководства.
Издавая и распространяя данный документ, PMI не оказывает профессиональные или иные услуги какому-либо лицу или организации или от имени какого-либо лица или организации; также PMI не выполняет обязательства какого-либо лица или организации по отношению к какой-либо третьей стороне. При использовании данного документа использующее его лицо должно самостоятельно определять действия, необходимые в конкретных обстоятельствах, полагаясь при этом исключительно на свое суждение или, при необходимости, на совет компетентного профессионала. Информация относительно темы, освещаемой данным документом, или относящиеся этой теме стандарты могут быть получены из других источников, к которым пользователь может при необходимости обратиться, чтобы получить дополнительную информацию, не содержащуюся в данном документе.
PMI не имеет полномочий и не берет на себя обязательства по контролю за соответствием существующих практик содержанию данного документа или приведению этих практик в соответствие с данным документом. PMI не занимается сертификацией, проведением контрольных испытаний или инспекций в отношении продуктов, проектов или конструкций на предмет безопасности их эксплуатации или безопасности для здоровья потребителей. Любой сертификат или иное утверждение соответствия какой-либо информации относительно безопасности эксплуатации или безопасности для здоровья, содержащейся в данном документе, не могут быть приписаны PMI; в таком случае ответственность лежит всецело на лице, выдавшем сертификат или высказавшем такое утверждение.
В Руководстве к Своду знаний по управлению проектами (Руководство PMBOK®) – Пятом издании приведены руководящие указания по управлению отдельными проектами и определены концепции, связанные с управлением проектами. Здесь также описан жизненный цикл управления проектом и связанных с ним процессов, а также жизненный цикл проекта.
Руководство PMBOK® содержит в Приложении A1 признанный на мировом уровне стандарт и руководство для профессиональной области управления проектами. Стандарт – это официальный документ, в котором описываются установленные нормы, методы, процессы и практики. Как и в других профессиональных областях, стандарт опирается на передовой опыт специалистов-практиков в управлении проектами, которые внесли вклад в разработку данного стандарта.
Первые два раздела Руководства PMBOK® знакомят с ключевыми понятиями в области управления проектами. В разделе 3 обобщаются группы процессов, и предоставляется обзор взаимодействий процессов в рамках десяти областей знаний и пяти групп процессов. Разделы с 4 по 13 являются руководством к Своду знаний по управлению проектами. Они расширяют информацию стандарта, описывая входы и выходы, а также инструменты и методы, используемые в управлении проектами. Приложение A1 представляет собой стандарт управления проектом, в нем обобщаются процессы, входы и выходы, которые, как правило, считаются хорошей практикой для большинства проектов в большинстве случаев.
В данном разделе определяются несколько ключевых терминов и взаимосвязь между управлением портфелем, программой, проектом и организационным управлением проектами. В следующих разделах приводится обзор Руководства PMBOK®:
1.2 Что такое проект?
1.3 Что такое управление проектом?
1.4 Связи между управлением портфелем, управлением программой, управлением проектом и организационным управлением проектами
1.5 Связь между управлением проектами, управлением операционной деятельностью и организационной стратегией
1.7 Роль руководителя проекта
1.8 Свод знаний по управлению проектами
1.1. Цель Руководства PMBOK®
Повсеместное признание, которое завоевывает управление проектами, является показателем того, что применение соответствующих знаний, процессов, навыков, инструментов и методов может иметь решающее значение для успеха проекта. Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, что в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация и/или команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
Руководство PMBOK® также предоставляет и содействует применению общего словаря терминов в профессии управления проектами для употребления и применения понятий управления проектами. Общий словарь является существенным элементом любой профессиональной дисциплины. Словарь терминов управления проектами PMI (PMI Lexicon of Project Management Terms) [1][1] представляет собой основной профессиональный словарь, который могут постоянно использовать руководители проектов, программ и портфелей и другие заинтересованные стороны.
Приложение A1 является основным справочным материалом для программ PMI по профессиональному развитию в области управления проектами. Приложение A1 продолжает развиваться вместе с профессией и, таким образом, не является всеобъемлющим; данный стандарт – скорее руководство, а не специфическая методология. Для применения его структуры и рекомендаций могут использоваться различные методологии и инструменты, такие как гибкие (agile) методы, водопадная (waterfall) модель, PRINCE2.
Цифры в скобках относятся к списку литературы в конце этого стандарта.