Отношение к этому вопросу и ответ на него сейчас и 10-20 лет назад несколько отличаются. Конечно, можно посмотреть в контракт и выяснить, что там написано по поводу ТЗ и приемки готового продукта. Но факт в том, что, большинство внешних проектов в России как тогда, так и сейчас реализуются по контрактам типа fix price, что существенно усложняет применение в них Agile подходов к разработке ПО.
В одном из моих (где я был РП) проектов (разработка и развертывание внутренней ИТ системы для крупной компании) для внешнего заказчика был интересный кейс. Контрактная документация заказчика включала ТТ (технические требования) разработанные заказчиком (около 10 стр.). Далее на этапе проектирования/дизайна системы аналитики нашей команды разработали очень детальное ТЗ (около 300 стр.). И даже с такой детализацией на этапе разработки заказчик заявил, что реализованный функционал одного конкретного интерфейса не соответствует его представлениям. В качестве аргументации заказчик сказал, что формулировки, написанные нашим аналитиком в ТЗ, допускают различное толкование функциональности, в том числе и то, которое он видит как целевое. И это несмотря на то, что ТЗ до этого момента уже прошло несколько корректировок и согласований, включая и корректировки по спорному разделу.
Я не буду вдаваться в юридические и понятийные аспекты отношений с заказчиком, как не стал этого делать и тогда в проекте. Вместо этого, тогда наша команда пошла на изменение нашей устоявшейся практики разработки и сдачи готового продукта. Мы тогда посадили разработчика спорного интерфейса у заказчика (с моим присмотром, конечно) и прошли для этого интерфейса полноценный путь разработки (как это принято сейчас, совместно с заказчиком) начиная с визуального проектирования, прототипирования, затем дизайна, разработки, тестирования и приемки. Трудозатраты выросли относительно плановых, но, в итоге - весьма незначительно. Плюс, разработчику пришлось самостоятельно провести более полное тестирование, но качество его было выше - поскольку оно проходило "в четыре руки" с заказчиком. Переделок по этому интерфейсу больше не потребовалось, заказчик его принял с удовольствием.
На этом проекте было еще несколько интересных управленческих кейсов, но это уже другая история.
Успешных вам проектов!
Олег Тумасов
PMP, PRINCE2, MSP