Системы управления требованиями где вы?

Всем привет! Меня зовут Роман,  я автор системы управления требованиями прорелиз.рф. И как раз про СУТ давайте поговорим (они же Requirements Management System или RMS). Как вам такая статистика:

• 80% считают целесообразным внедрение СУТ

• 67% знают что такое СУТ

• 4% используют СУТ в работе.

Такие данные опроса сотни аналитиков приведены обзоре 2024 года “Какую систему управления требованиями выбрать: обзор инструментов”. Разрыв 80% и 4%, мягко говоря,  неприятно впечатляет. Казалось бы,  требования есть в любом проекте, специализированный инструмент как раз нужен. Как так выходит? А у вас СУТ применяется? Думаю, большинство ответит  "Нет" или  "Excel" (опрос внизу).

Давайте посмотрим более свежий “Обзор российских СУТ для IT и инженерных команд”. В этом обзоре отмечены три важных фактора, обуславливающих внедрение СУТ:

1. Цена ошибки: в проекте слишком высокая цена за ошибку в требовании

2. Текучка кадров: СУТ позволяет не зависеть от текучки кадров и отдельных экспертов

3. Доказательства: нужны доказательства, что вы сделали именно то, что обещали, и проверили все «опасные» сценарии ”

Кажется, сложилась практика применения СУТ не там где просто есть требования, а там, где без СУТ уже никак не обойтись. Как с задачками тут не работает: есть задачки , значит есть Jira. И СУТ это больше не про само IT, а про проекты авиации, автомобилестроения, медицины, финансов.   

Предлагаю  от  авиации и автомобилестроения перейти все же к более привычным IT- проектам в составе небольших команд и  разобрать факторы по отдельности.

Цена ошибки.  Смотрите, если я  не условный “Боинг”, то мне можно ошибаться и зависеть от конкретных сотрудников? Конечно, это не так. Неважно какого размера команда или бюджет, качество результата должно обеспечиваться на высоком уровне. Предполагается, что тут должно срабатывать правило: исправление ошибки на этапе сбора требований кратно дешевле исправления проблемы на других этапах, и чем ближе этот этап к заказчику - тем больше потери.

Текучесть кадров, конечно, проблема. Но если проект относительно небольшой и длится, скажем, полгода , то это становится не критично.

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

Мне кажется, из перечисленных факторов только "цена ошибки" может повлиять на ситуацию с СУТ в IT-проектах. А какова цена ошибки в IT-проектах? Это стоимость переделок и устранения недоработок. Плюс репутационные потери.

Факторы  обсудили, теперь давайте поговорим о другой стороне: а зачем вообще управлять требованиями? Какие проблемы можно решить при помощи СУТ? Проведу краткий обзор публикаций в сети Интернет:

• NaPiRE — Naming the Pain in Requirements Engineering, 2016  Дает такие цифры: Неполные/скрытые требования назвали критической проблемой 48% организаций; 

• Mitigating risk of failure in information technology projects: Causes and mechanisms, 2023: Требования выделены как одна из 11 устойчивых групп факторов провала. 

• Отдельные сайты  приводят статистику:  в 37%-39% случаев проблемы с требованиями приводят к  провалу проекта:

Видим, что проблемы с требованиям есть и ,возможно СУТ поможет их решить. Но как оценить пользу от СУТ? Есть разные устаревшие методики  оценки экономики ошибок в требованиях. Методики из NASA примерять на типовой “гражданский” проект, думаю, не стоит. Закон Боэма в чистом виде, наверное, потерял актуальность в связи с автоматизацией CI/CD  и тестов, модульной архитектурой и другими нововведениями последних десятилетий.
В статье Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle авторы на медианной команде в 7 человек и медианной длительности 61 день не смогли  подтвердить экспоненциальный рост трудоёмкости исправления, заложенный в основу  методики Боэма. 

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

А какова стоимость СУТ?

Ряд российских вендоров публикуют стоимость своих решений. Стоимость подписки на месяц начинается от 2 590р. за стартовый комплект функций. Для небольшой команды это 150 - 250 тыс. руб. в год.  Следующий ценовой диапазон - подписка 32 700 руб. в месяц за комплексный продукт включающий в себя помимо функций СУТ еще и  архитектурные инструменты.

Стоимость обслуживания on-premise вариантов, судя по открытым источникам составляет от 1,449 до 7,524 млн. руб. в год. 

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

Вывод из предыдущей обзорной части у меня складывается следующий: Управлять требованиям полезно, и небольшим командам в том числе. Но сложность и стоимость традиционных СУТ не устраивает большинство команд. В итоге происходит замена СУТ набором подручных инструментов: Jira, документы, таблицы, договоренности, менеджеры и т.д. Проблема распределяется между инструментами и людьми.

Проект Прорелиз.рф

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

Какой минимальный СУТ нужен? Вот набор по которому я сейчас двигаюсь:

1. каталог требований с устойчивыми идентификаторами требований

2. источники требований

3. история изменений согласованных версий требований

4. связь с релизом, задачей, критериями приемки

5. импорт из существующих документов и экспорт в привычные форматы

Целевой сценарий:

Заказчик прислал ТЗ в виде текстового документа -> Аналитик наполняет каталог требований -> Распределение требований по релизам -> Определение критериев приемки -> Назначение задач -> Контроль подготовки релиза

Свой проект я запустил по адресу прорелиз.рф. Пока он совсем молодой.  Сейчас функциональность сосредоточена вокруг формирования каталога требований. Доступны аутентификация через Яндекс, один бесплатный проект для команды из 6 человек, загрузка документов источников, работа с каталогом требований, назначение релизов, выгрузка каталога требований в виде текстового документа или электронной таблицы. Жду ваших откликов и предложений.

Если дочитали до конца , предлагаю поучаствовать в опросе и ответить на два вопроса:

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

0%Да0

0%Нет0

0%Excel0

0%Первый раз слышу0

Никто еще не голосовал. Воздержавшихся нет.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.