Управление проектами по Технологии быстрого результата

Управление требованиями

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

Основные мысли

В результате изучения лекции слушатель будет способен:
1. Объяснить статистическую взаимосвязь между качеством требований и провалами IT-проектов.
2. Обосновать необходимость быстрого сбора требований с приемлемым уровнем качества.
3. Классифицировать различные форматы и методы выявления требований (интервью, опросники, прототипирование и др.).
4. Сравнить роли заказчика и исполнителя в процессе валидации требований.
5. Сформулировать ключевые критерии качественных требований (полнота, уникальность, приоритизация, документированность).
Показывать лекцию целиком
Краткое изложение
Записаться
Управление требованиями в IT-проектах

Статистика провалов и ключевая роль требований

Статистика показывает, что 90% причин провалов проектов в области информационных технологий заключается в плохом управлении требованиями. Это данные анализа около 6000 неудачных проектов, проведенного инициативной группой.

Ключевой вывод таков: для IT-проекта хорошие требования являются залогом успеха, а плохие требования практически гарантируют неудачное завершение.

Рекомендуемая методология и литература

Для выстраивания процесса рекомендуется книга Карла Вигерса «Управление требованиями к программному обеспечению». В ней описываются подходы, позволяющие формально обеспечить полноту и достаточность требований. Эти методы необходимо внедрять в организациях и обучать им персонал.

Примечание: В отраслевом решении «1С:Профкейс» шаблоны концепции и спецификации требований к системе выполнены по лекалам Вигерса.

Принципы сбора требований: скорость и качество

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

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

Требования могут фиксироваться в различных формах: протоколы интервью, классические спецификации требований, перечни работ, варианты использования (use cases) или записи в системе автоматизации управления проектами. Главное — форма не должна быть самоцелью.

Критерии качественных требований

Для эффективного управления критически важны следующие условия:
1. Понимание и согласие сторон. Необходимо двустороннее согласование:
o Заказчик (владелец документа) должен понимать требования и быть с ними согласен.
o Исполнитель (пользователь документа, команда разработки) также должен понимать и принимать эти требования.
2. Приоритизация. Требования должны быть приоритизированы самим заказчиком.
3. Документирование. Требования должны быть задокументированы в любом виде: на бумаге с подписью, в системе управления проектами или в иной форме.

Итоговые условия успеха

Чтобы обеспечить успешное управление требованиями, нужен подготовленный персонал, владеющий формальными методами сбора и анализа. Требования должны быть:
• Собраны;
• Достаточны;
• Уникальны;
• Полны (описывать всю систему целиком);
• Задокументированы и утверждены.

Выполнение этих условий обеспечивает корректную работу механизмов управления проектом и, в частности, управления изменениями.

Краткие итоги

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

Центральной идеей выступает перенос фокуса внимания с формы на содержание. Формат фиксации требований вторичен — это может быть как классический документ, так и набор цифровых записей. Принципиально иным является требование многоканального сбора информации и перманентного уточнения деталей на каждой фазе проекта. Отказ от единого шаблона в пользу гибридных методов (от ролевых тренингов до экспресс-обследований) позволяет адаптироваться к когнитивным особенностям разных групп заинтересованных лиц и снизить риск искажения смыслов.

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

Внедрение формальных методов, описанных в профессиональных стандартах (например, у Карла Вигерса), не является бюрократическим актом. Это создание системы, в которой полнота и уникальность требований становятся измеряемыми величинами, а не субъективными ощущениями. Только утвержденные и зафиксированные требования становятся фундаментом для эффективного управления изменениями: без замороженного базового состояния невозможно оценить стоимость и влияние будущих модификаций, что превращает управление изменениями в хаотичное реагирование на запросы.
90% причин провалов ИТ-проектов заключаются в плохом управлении требованиями (статистика анализа 6000 неудачных проектов). Хорошие требования — ключ к успеху, плохие — гарантия провала.

Методологическая база
Для системной работы рекомендуется книга Карла Вигерса «Управление требованиями к программному обеспечению». Ее ценность — в формальных методах обеспечения полноты и достаточности требований, которые нужно внедрять и обучать им персонал. Шаблоны «1С:Профкейс» основаны именно на методике Вигерса.

Баланс скорости и качества
Требования нужно собирать быстро и с приемлемым уровнем качества. Бесконечно шлифовать документы нельзя: времени мало, а цель — готовый продукт, а не стопка бумаг. Формат представления требований не имеет значения с точки зрения результата.

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

Формы фиксации также разнообразны: спецификации, протоколы, варианты использования (use cases) или записи в системах управления проектами. Важно, чтобы требования уточнялись на каждой фазе.

Критерии состоятельности требований
Для качества требования критичны четыре аспекта:
1. Двустороннее понимание и согласие.
o Заказчик (владелец) должен понимать требования и соглашаться с ними.
o Исполнитель (разработчик) должен их понимать и принимать их реализуемость.
2. Приоритизация. Выполняется исключительно заказчиком.
3. Свойства содержания. Полнота (описание всей системы), уникальность (отсутствие дублей) и достаточность.
4. Документирование. Требования должны быть зафиксированы в любой форме (бумажной или цифровой).

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

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

Выводы

1. 90% провалов ИТ-проектов статистически обусловлены именно некачественной работой с требованиями.
2. Хорошие требования — обязательное условие успеха, а плохие — гарантия провала.
3. Скорость сбора требований имеет критическое значение, так как результат проекта приоритетнее бесконечной проработки документации.
4. Необходим подготовленный персонал, владеющий формальными методами сбора и анализа требований.
5. Книга Карла Вигерса является практическим руководством для обеспечения полноты требований на формальной основе.
6. Формат фиксации требований вторичен: это могут быть протоколы, use cases, записи в системах или вопросники.
7. Требования можно выявлять через интервью, тренинги, совещания, экспресс-обследования и анализ нормативных документов.
8. Уточнение требований должно происходить непрерывно на каждой фазе проекта.
9. Требования обязательно должны быть понятны, согласованы и подписаны с двух сторон: заказчиком и исполнителем.
10. Приоритизация требований — исключительная прерогатива заказчика.
11. Документирование требований обязательно, независимо от носителя (бумага или цифровая запись).
12. Утвержденные требования являются базой для корректной работы механизмов управления изменениями.

Вопросы для самопроверки

1. Каков процент провалов ИТ-проектов, связанных с плохими требованиями, согласно приведенной статистике?
2. Почему затягивание процесса сбора требований несет риски для проекта, даже если это делается ради повышения качества?
3. Назовите автора и название книги, которую рекомендуется знать наизусть специалистам по управлению требованиями.
4. Какие пять методов и инструментов для выявления требований упомянуты в материале?
5. Почему формат представления требований не имеет решающего значения с точки зрения описанного подхода?
6. В чем разница между ролями «заказчика документа» и «пользователя документа» при согласовании требований?
7. Перечислите три обязательных свойства, которыми должны обладать собранные требования (помимо документирования).
8. Какие шаблоны в продукте «1С:Профкейс» основаны на рекомендациях Вигерса?
9. Какую роль играет приоритизация требований и кто ее должен выполнять?
10. Какие формы фиксации требований упоминаются в качестве допустимых альтернатив классической спецификации?
11. Как связаны утвержденные требования и процесс управления изменениями в проекте?
12. На каких фазах проекта необходимо уточнять требования?
Предыдущее занятие Следующее занятие
Вернуться к учебному плану
^