Управление требованиями: Ключ к успешным ИТ-проектам

Бюджет установлен, цель сформулирована, сроки определены: На этом этапе компании часто торопятся с реализацией, вместо того чтобы уделить достаточно времени систематическому получению требований всех заинтересованных сторон к предполагаемому продукту и управлению спецификациями. В результате, согласно исследованию, первоначально определенные требования становятся частью продукта только в 56 процентах ИТ-проектов. Это означает, что время и бюджетные ресурсы тратятся впустую. Но этого можно избежать с помощью структурированного процесса управления требованиями.

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

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

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

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

Даже если заказчик понесет более высокие затраты из-за более тщательного документирования требований в начале проекта, удовлетворенность заказчика выигрывает от структурированного процесса управления требованиями.

Тем не менее, важность определения и управления требованиями для успеха проекта часто недооценивается компаниями — даже в случае технологических проектов, где управление требованиями к ИТ является обычным делом. Иначе было бы трудно объяснить, почему 52 процента всех ИТ-проектов, согласно исследованию CHAOS, проведенному Standish Group, не укладываются в установленный бюджет и график. Только 55 процентов респондентов считают управление требованиями важным или очень важным. Остальные придают управлению требованиями лишь умеренное или низкое значение для успеха проектов. Это ошибка с серьезными последствиями — как показывает количество проектов, завершенных в соответствии с планом.

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

Наиболее важные задачи управления требованиями включают определение, документирование и анализ требований, а также управление изменениями в ходе проекта.

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

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

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

Во многих случаях имеет смысл не только изложить требования в письменном, но и в графическом виде — особенно при описании систем, процессов и вариантов использования. Для этого обычно используются диаграммы UML.

После того как требования определены и задокументированы, задача управления требованиями заключается в их анализе. Противоречивые требования должны быть выявлены и уточнены с заинтересованными сторонами. Более того, менеджер должен определить и оценить риски (используя оценку, основанную на потенциальном масштабе ущерба и вероятности его возникновения). Также следует провести первоначальную приоритизацию требований.

Затем документация по требованиям должна быть представлена на рассмотрение заинтересованным сторонам. Только после достижения согласия по определению объема работ следует начинать работу по реализации проекта.

В (почти) любом проекте со временем появляются запросы на изменения. Чтобы свести к минимуму обсуждение понесенных дополнительных затрат и обеспечить возможность возврата к старому состоянию проекта в случае недовольства заказчика, хорошо зарекомендовало себя использование версионности. Этот метод изначально пришел из разработки программного обеспечения, но также применяется в управлении проектами. В этом случае ход проекта документируется, а текущие версии отмечаются как новая базовая линия. Это позволяет партнерам по проекту легко сравнивать текущий объем требований с предыдущими.

Многие компании полагают, что управление требованиями не нужно в гибких проектах, поскольку объем все равно меняется в ходе проекта. Это ошибка.

Многие задачи, которые являются частью управления требованиями, в agile-проектах выполняются владельцем продукта. Они контролируют и управляют проектом, а также реализацией требований. Более того, они расставляют приоритеты требований и координируют изменения. Это типичные задачи менеджера по требованиям.

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

Хотя управление требованиями в agile-проектах менее масштабно, оно все равно не менее важно, чем в обычных проектах, управляемых по принципу водопада.