Empower vs. Restrict

[EVGL]

Вот эта тема настроила меня на философский лад и рефлексию. На текущих проектах, которые ведутся в основном Microsoft Consulting Services, я сражаюсь с подходом многих коллег дать пользователям инструменты во всей полноте, а там пусть сами разбираются; в конце проверяем все и сразу, и показываем большой красный крест если что не так. Как раз в понедельник руководитель IT одного подразделения Glencore жаловался на издержки этого подхода, когда разгребание заказов на хранение, введенных задним числом до вступления в действие цены и контракта заняло 3 месяца, а разработка жесткого корсета с эвристикой и проверками на каждом шаге процесса - еще 3 месяца.

Апофеоз такого подхода к дизайну в стандартном приложении - это счет на покупку pending invoice: мы даем пользователю форму, он заполняет все данные, отправляет в workflow, проходит через все инстанции, чтобы в конце автоматическая разноска сказала: "нет счета ГК". Характерно, что Reset в distribution на этот момент уже не работает, и единственный вариант - это пересоздать строку счета, по сути ввести его заново.

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

Ваше мнение:
1) Давать задел на будущее и предвосхищать новые требования
2) Строить жесткий корсет вокруг заданного набора требований
?