Советы эксперта: как снизить риск споров между заказчиком и разработчиком ПО на этапе составления ТЗ

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

Правильно составленное ТЗ – это непосредственно инструкция для IT-специалистов на стороне Исполнителя. В хорошем ТЗ всегда прописываются пункты:

Эти пункты могут быть расширены в зависимости от специфики проекта. Чем больше конкретики, тем меньше возможности у исполнителя сделать что-то не так. Яркий пример: заказчик хочет внедрить искусственный интеллект или другую автоматизацию в свои бизнес-процессы, но не указывает в ТЗ конкретные функции, которые должен выполнять ИИ, думая, что это должно быть очевидно. В это время исполнитель, не увидев в ТЗ конкретики, делает работу по своему усмотрению. Заказчика это, конечно, не устраивает и далее начинаются разногласия с дальнейшим разбирательством в суде, которые могут длиться годами.

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

Если вести речь о государственных контрактах, то, прежде чем устраивать закупку на разработку/внедрение цифровых продуктов, Заказчику стоит предварительно осуществить закупку на разработку ТЗ.

Но на практике мы видим, что такие закупки проводятся редко. Чаще госорганы публикуют закупку на разработку/внедрение с готовым ТЗ. У многих в этот момент может появиться подозрение, что ТЗ разрабатывал под себя потенциальный победитель данной закупки, который «размазал» в смете реализации цифрового продукта, в том числе, и выполненную разработку ТЗ. Но даже в таких случаях Заказчик в лице госорганов часто остается недоволен выполненными работами, в то время как Исполнитель говорит, что он сделал все по ТЗ, и снова возникает конфликт между сторонами.

Если мы говорим о коммерческом договоре на оказание услуг по разработке или внедрению ПО, то чаще всего именно исполнитель совместно с заказчиком разрабатывает ТЗ. Здесь есть как плюсы, так и минусы.

Из плюсов:

Из минусов:

Итак, правильно составленное ТЗ — это инструкция реализации проекта для IT-специалистов. При описании процессов заказчик может видеть реализацию одним образом, а исполнитель - другим. Суть данного тезиса легче всего выражает картинка:

Исполнителю и заказчику необходимо проводить итерации по каждому из этапов работ и подробно описывать действия и их конечный результат. Чаще всего двойные трактования присутствуют в контрактах, когда ТЗ составляет исполнитель. Например, в ТЗ предусмотрен пункт по интеграции разрабатываемой системы со сторонними сервисами, но каким образом и на каком основании должен происходить обмен данными, не сказано. Может, эти сервисы вообще не хранят или не имеют возможности передавать нужные заказчику данные. Исполнитель выберет для себя менее затратный по времени и ресурсам вариант реализации, а заказчик снова не получит ожидаемый результат. По нашему опыту при проведении судебных, досудебных и внесудебных экспертиз цифровых разработок на соответствие утвержденному ТЗ, очень часто именно исполнитель оказывается прав, так как он выполнил все прописанные (им же) пункты в ТЗ. А заказчик, в виду недостаточной в этом вопросе компетенции, не предусмотрел детали.

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

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

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

Сфера ITдостаточно обширна и здесь важно не только доверие всех сторон к выбранной экспертной организации, но и квалификация эксперта, соответствующая профилю разрабатываемой или внедряемой технологии. Именно поэтому мы в МТПП собрали более 50 IT-экспертов, разных уровней и профилей, которые имеют и опыт составления ТЗ, и реализации аналогичных продуктов, и проведения экспертизы. При этом МТПП гарантирует, что выбранный эксперт не будет аффилирован ни одной из сторон конфликта.