Требования мертвы! Да здравствуют требования!

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

Потом практика показала, что это не так — подробное описание не гарантирует, что: — Описанное решение действительно решает проблему — Не забыто ничего важного — Нет ничего лишнего

Пошла попытка откатиться от требований и остаться на уровне User Story + Map. Это облегчило обзор и управляемость, но всё-таки не дало чёткой трассировки на бизнес-ценность и техническое качество-полноту (попробуйте найти NFR в USM).

На самом деле разные техники работы с требованиями закрывают разные категории рисков с разным ущербом. И когда вы берёте классический фреймворк создания требований, вы получаете конвейер из 15 техник, которые сложно адаптировать под ограничения конкретного проекта. Спирта в огонь добавляет ИИ, который смещает ожидания заказчика, что теперь требования можно сделать не за месяц, а за неделю. Да, можно, но — «такая ерунда получается».

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

В ближайшие недели буду писать про требования именно в этой логике: «управление рисками и решениями», а не «как понятно описать детали».

Если тема у вас отзывается, напишите в комментариях одним предложением:

> 👉 какой самый болезненный провал проекта вы видели лично?