Управление требованиями: это нужно 80% аналитиков, но реально работает лишь у 4%

По данным обзора 2024 года «Какую систему управления требованиями выбрать», среди сотни опрошенных аналитиков 67% знают, что такое СУТ (система управления требованиями, она же RMS, Requirements Management System), 80% считают внедрение целесообразным, но лишь 4% реально работают с такой системой. Автор проекта «Прорелиз.рф» Роман разобрал причины этого разрыва и предложил подход для небольших команд. Ниже собрана выжимка: что мешает, сколько стоит, как начать и где помогает ИИ.

Почему 96% команд обходятся без СУТ?

Обзор «Российских СУТ для IT и инженерных команд» выделяет три фактора, которые подталкивают к внедрению:

• Цена ошибки в требовании. Классическое правило: чем позже нашли проблему, тем дороже исправлять.
• Текучка кадров. СУТ снимает зависимость от конкретного эксперта, который может уйти.
• Доказательства. Нужно подтвердить, что сделано именно то, что обещали, и проверены все критичные сценарии.

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

Что говорят исследования о провалах из-за требований?

Исследование NaPiRE (Naming the Pain in Requirements Engineering, 2016) показало: 48% организаций назвали неполные или скрытые требования критической проблемой.

Публикация Mitigating Risk of Failure in Information Technology Projects (2023) включила требования в число 11 устойчивых групп факторов провала проекта. Отдельные источники (Rock Star Developer University, Beta Breakers) приводят цифру: в 37%–39% случаев проблемы с требованиями ведут к провалу.

При этом классическая формула Боэма (Barry Boehm) об экспоненциальном росте стоимости исправлений теряет актуальность. В статье Are Delayed Issues Harder to Resolve? авторы на медианной команде из 7 человек и медианной длительности проекта 61 день не подтвердили экспоненциальный рост трудоёмкости. Автоматизация CI/CD (непрерывная интеграция и доставка кода), модульная архитектура и автотесты сгладили кривую.

Современной методики оценки стоимости переделок, применимой к небольшой команде, в открытых источниках найти не удалось.

Сколько стоит СУТ в России?

Стоимость подписки у российских вендоров начинается от 2 590 рублей в месяц за стартовый набор функций. Для небольшой команды это 150 000–250 000 рублей в год.

Комплексный продукт с архитектурными инструментами обойдётся от 32 700 рублей в месяц. Обслуживание серверных (on-premise) вариантов, по открытым данным, составляет от 1,449 до 7,524 млн рублей в год.

Итог очевиден: посчитать эффект от внедрения трудно, а обосновать бюджет перед бизнесом ещё труднее. Именно это объясняет цифру «4% применяющих».

Что понадобится

• Понимание, какие требования в вашем проекте есть прямо сейчас (даже если они живут в Jira, Google Docs или Excel)
• Доступ к любому инструменту для структурированного хранения: от таблицы до специализированной СУТ
• Если хотите попробовать лёгкий вариант, регистрация на «Прорелиз.рф» (бесплатный старт)
• 2–3 часа на первичный перенос требований из разрозненных источников в единый каталог

Как выстроить управление требованиями без корпоративного бюджета?

1. Соберите все требования в одно место. Выгрузите задачи из Jira, пункты из договоров, заметки из переписок. Даже если это таблица, главное, чтобы каждое требование получило уникальный идентификатор.

2. Присвойте каждому требованию устойчивый ID. Без него невозможно отслеживать, какое требование покрыто тестом, а какое «висит». Формат может быть любым: REQ-001, REQ-002.

3. Свяжите требования с задачами и тестами. Это называется трассировка (traceability): связь «требование, задача, тест, результат». Без неё вы не докажете, что сделали то, что обещали.

4. Определите, кто отвечает за каждое требование. Один человек, одно требование. Иначе «распределённая ответственность» превращается в «ничью».

5. Настройте версионирование. Требования меняются. Если нет истории изменений, через месяц никто не вспомнит, почему решили иначе.

6. Проверяйте полноту перед каждым спринтом. Простой чек: есть ли у каждой задачи в спринте привязанное требование? Если нет, откуда взялась задача?

Что делать с этим прямо сейчас, по ролям?

Автору на Дзене или копирайтеру. Управление требованиями, это не только про код. Если вы пишете контент-план для заказчика, каждый пункт ТЗ с уникальным номером, привязкой к задаче и статусом «согласовано / в работе / сдано» решает ту же проблему: доказать, что сделано именно то, что просили.

Маркетологу. Запуск рекламной кампании с пятью подрядчиками без единого реестра требований ведёт к тем же 37%–39% провалов. Таблица с ID и трассировкой до результата экономит бюджет на переделки.

Предпринимателю в РФ. Если ваша команда до 10 человек и проект длится до полугода, тяжёлая СУТ за миллионы рублей вам не нужна. Посмотрите на «Прорелиз.рф» (позиционируется как лёгкая СУТ для небольших команд) или начните с обычной таблицы по структуре из шага 1 выше.

Цифра «4% используют» звучит как приговор, но на деле это точка роста. Начните с таблицы, присвойте каждому требованию номер, свяжите с задачей и тестом. Через неделю вы увидите дыры, которые раньше находили только на демо перед заказчиком.