Мы будем с вами говорить о заказной разработке программного обеспечения (далее - ПО).
В каждом проекте по разработке заказного ПО наступает момент, когда Исполнитель уходит в себя и начинает программировать по сформулированной и утвержденной постановке задачи.
Это может длиться месяц, два, три, пол года... И очень часто, а точнее почти всегда, Заказчики никак не контролируют этот процесс. Для них этот этап проекта абсолютно закрыт.
В результате может сложиться ситуация, когда Исполнитель приносит свой программный продукт и он оказывается негодным к использованию. Причин может быть масса: ошибки в бизнес логике, проблемы с совместимостью с инфраструктурой Заказчика, проблемы с быстродействием, банально ошибки ПО и др.
А в это время у Заказчика на этот результат может оказаться много чего завязано. Например, смежные информационные системы могут ждать интеграционного взаимодействия и неких данных. А их нет и не будет. И Заказчики, по большому счету, ничего сделать с этим уже не могут, потому что время-то упущено и его совсем не осталось на какие-либо организационные или технические маневры. Ситуации могут получаться довольно скверные.
Контролировать процесс разработки ПО можно и нужно. И Заказчикам и руководителям проектов со стороны Исполнителей.
Но для этого необходимо понимать что такое функциональная спецификация, что такое план релизов, что такое тест планы. Какая структура должна быть у этих документов и для чего они нужны.
Конечно, Заказчики, скорее всего, никогда не разберутся во всех технических деталях, но по совокупности вполне себе понятных признаков вполне можно оценить насколько все хорошо или плохо. Например, Заказчик должен увидеть и проверить подробное описание автоматизируемых бизнес процессов, описание ролевой модели пользователей. Для этого не нужно иметь техническое образование, для этого достаточно уметь читать. Заказчик вполне может оценить полноту тех или иных пользовательских интерфейсов по их подробному описанию и, например, понять что в неком интерфейсе не хватает определенного справочника и логики работы с ним. Это не сложно, если понимать где и в каком виде все это должно быть описано.
В любом случае, будет гарантированно понятно, когда проект покатится в пропасть.
Естественно, чтобы у Заказчика были все эти возможности необходимо не забыть написать об этом нужные слова в техническое задание и в контракт.
---