Управление содержанием ИТ проектов
|Август 12, 2014
Проект по своей сути представляет собой координацию усилий, направленную на создание уникального продукта или сервиса, либо достижение определенного результата. Проект является завершенным в том случае, когда поставленные цели достигнуты, либо если выполнение проекта было приостановлено, поскольку реализация его целей больше не является возможной, либо если больше нет необходимости в выполнении данного проекта.
Компания, выполняющая проект, назначает менеджера проекта, ответственного за достижение целей проекта. В то время, как в обязанности менеджера проекта входит управление содержанием, временем, стоимостью, человеческими ресурсами и т.д., непосредственно для управления содержанием проекта может быть привлечен бизнес-аналитик.
Поскольку требования к создаваемому продукту и выполнению проекта исходят от заинтересованных сторон, данный круг лиц должен быть определен на начальном этапе. Идентификация заинтересованных лиц — это процесс установления всех людей, заинтересованных в результатах выполнения проекта, а также документирования информации, касающейся их интересов, их роли в процессе реализации проекта и степени влияния на ход его выполнения. Ключевым фактором успешности проекта является установление круга заинтересованных лиц непосредственно до того, как будет определено содержание проекта. В случае, если все лица, заинтересованные в проекте, не будут определены вовремя, могут быть упущены важные требования, в результате чего цели проекта реализованы не будут.
Управление содержанием проекта состоит из процессов, осуществление которых призвано обеспечить создание всех условий для успешного выполнения проекта.
Сбор и анализ требований
Первым процессом, который выполняет бизнес-аналитик, является сбор требований. Бизнес-аналитик определяет и документирует потребности заинтересованных сторон в реализации целей проекта, поскольку успех проекта напрямую зависит от того, насколько тщательно был произведен сбор требований, и как осуществляется управление ими. Требования должны быть выявлены, проанализированы и задокументированы достаточно подробно, чтобы их можно было измерить после начала исполнения проекта. Предоставление заказчиком технического задания по проекту значительно ускоряет процесс сбора требований и определения содержания проекта.
Существует несколько техник и инструментов, используемых для сбора требований. Наиболее часто используемой техникой является интервью. Сбор необходимой информации осуществляется в процессе переговоров с заинтересованными сторонами при помощи различных информационных каналов. Самым эффективным способом является личная встреча. Кроме того, широко распространены методы дистанционных совещаний, и бизнес-аналитики используют возможности приложения skype для получения нужной информации. Email-переписка является удобным способом получения коротких ответов или назначения времени совещания.
Мы используем также метод фокус-группы, когда для обсуждения некоторых вопросов по skype привлекаются несколько заинтересованных лиц. Данный метод помогает разрешить разногласия, возникающие между заинтересованными сторонами.
Изредка мы используем методологию Совместной разработки приложений (Joint Application Development ), которая предполагает взаимодействие заинтересованных лиц, заказчиков и команды разработчиков с целью оптимизации процесса разработки.
Результатом использования всех описанных техник и инструментов для сбора требований являются:
- документация требований, описывающая, каким образом определенное требование соответствует тем или иным бизнес-потребностям в проекте. Она включает в себя: потребности бизнеса, цели бизнеса или проекта, функциональные требования, требования к качеству, критерии приемлемости проекта и т.д.
- план управления требованиями, который определяет, каким образом будут проводиться анализ, документирование и регулирование требований в ходе реализации проекта.
- матрица отслеживания требований (Requirements Traceability Matrix), гарантирующая соответствие поставляемых результатов требованиям, представленным в документации.
Определение содержания проекта
Вторым процессом является определение содержания проекта, необходимое для создания подробного описания проекта и продукта, что становится возможным, когда все требования собраны. Детальное описание содержания проекта является крайне важным для успешности проекта и основывается на конечных результатах, допущениях и ограничениях. В результате процесса определения содержания проекта создается описание содержания проекта, определяются критерии приемлемости продукта, конечные результаты, исключения, ограничения и допущения проекта. Собранные данные и созданные документы используются для создания иерархической структуры работ и оценивания проекта.
Подтверждение содержания проекта
Во время реализации проекта выполняются требования, которые должны быть подтверждены в соответствии с критериями качества завершенных результатов проекта. Завершенные результаты проверяются вместе с заказчиком для того, чтобы убедиться, что они удовлетворяют требованиям, и получить формальное одобрение заказчика. Одобренные результаты работы помечаются как выполненные, а результаты, не получившие одобрения, возвращаются в процесс разработки с дополнительными комментариями.
Описанная выше процедура известна как процесс подтверждения содержания проекта. В первую очередь он направлен на приемку результатов и не предполагает участия QA-специалистов. Важно понимать разницу между подтверждением содержания и контролем качества, поскольку последний ориентирован на правильность результатов и соблюдение требований качества, заданных для результатов, и выполняется QA-специалистами до подтверждения содержания проекта.
Контроль содержания проекта
В целях экономии времени процессы подтверждения содержания и его контроля могут осуществляться параллельно. В этом случае заказчики получают уведомление, что результаты проекта проходят контроль качества. Если во время процесса подтверждения содержания появляются новые требования или изменения, которые необходимо внести в проект, все они фиксируются с помощью инструмента контроля изменений.
Система XBtrack обычно используется в качестве инструмента контроля изменений и отслеживания ошибок. Задачи типа feature, являются запросами на изменение, а задачи типа bug представляют собой ошибки, обнаруженные QA-специалистами.
В случае, если запрос на изменение был отклонен, необходимо указать причины такого решения. Если же запрос одобрен, он добавляется в содержание проекта, а затем проходит стадии оценки, разработки и проверки.
Таким образом, осуществляется процесс контроля содержания проекта, направленный на мониторинг и контроль продукта и содержания проекта, а также управление изменениями в содержании. Контроль содержания проекта гарантирует, что все запрашиваемые изменения, а также корректировочные и превентивные действия осуществляются под контролем. Неконтролируемые изменения часто ведут к “раздуванию” содержания проекта, затем требуется все больше дополнительного времени, задачи не выполняются в срок, и в конечном итоге работа над проектом прекращается.
К сожалению, контролем содержания довольно часто пренебрегают, поскольку все кажется понятным на начальной стадии выполнения проекта. На последующих этапах вносятся лишь незначительные поправки. В конце концов это может привести к тому, что содержание проекта будет управлять нами, а проект окажется на грани срыва. Однако, если мы возьмем контроль над проектом в свои руки, то сможем предотвратить подобный исход и выполнить проект качественно и в срок.
The following two tabs change content below.
Виталий Горник
Его путь в ИТ начался с ASP веб-разработчика в 2000-ом году и продолжился увлекательной работой с различными технологиями и направлениями веб-разработки. На данный момент погружен в управление проектами и внедряет лучшие практики, основанные на базе знаний PMBOK и CMM.
Последние статьи: Виталий Горник (все статьи)
- Игры в скрам - Март 24, 2016
- FP или T&M контракт. Какой лучше? - Апрель 9, 2015
- Управление содержанием ИТ проектов - Август 12, 2014
