Думаю, в начале стоит пояснить, зачем проводить промежуточные демо, и почему не стоит проводить разработку по принципу “Сначала все сделаем, а затем проведем полный показ системы”.

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

Однако, во-первых, если проект крупный, то от момента начала формирования требований до старта проекта проходит довольно продолжительное время, бывает, что проект инициируется с не до конца актуальными требованиями.

Во-вторых, не все компании ведут электронные репозитории бизнес-процессов. Из тех, кто ведёт - не все поддерживают их актуальность. Из тех, кто поддерживает актуальность, не все готовят к проекту целевую модель для автоматизации.

Таким образом команде внедрения приходится в сжатые сроки формализовать целевую модель автоматизации, а иногда, предварительно ещё создавать модель AS IS или актуализировать ее. Отсюда возможны незначительные пропуски деталей БП.

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

Можно привести ещё ряд причин, однако суть одна - в процессе показа у заказчика могут появиться дополнительные требования к автоматизации БП. Требования могут оказаться критическими (например, требования регуляторов). И без исполнения таких требований запускать ИС в работу не будет иметь смысла, т.к. ею нельзя будет пользоваться.

И вот перед вами 2 ситуации:

▫️ вы реализовали все доработки без промежуточных показов, а только по окончании разработки сделали общий показ и получили целую “пачку” замечаний, ряд из которых являются критическими;

▫️ вы в течение всего процесса разработки периодически показывали функциональность системы заказчику, периодически получая на вход новые требования, ряд из которых являлись критическими.

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

А во втором случае при появлении новых требований у вас есть “время для маневра”. То есть по сути появляется шанс успеть сделать оценку доп.работ, согласовать увеличение ресурсов проекта, время для согласования доп.соглашения (на коммерческих проектах), либо согласовать запрос на изменение, в котором реализация критически важной функциональности будет происходить за счёт отказа от менее значимой (например, если увеличение финансирования невозможно, а сроки сдвинуть - тоже нельзя) и т.д. То есть успеть отреагировать на изменение так, чтобы и заказчику, и исполнителю подходил вариант изменений.

Полностью цепочка этапов разработки - здесь. Полный перечень результатов по этапам проекта - здесь.