Как оформить акт приемки софта по сценариям ТЗ для защиты исключительных прав заказчика

Почему формальный акт приемки без привязки к ТЗ не защищает заказчика

Стандартный акт выполненных работ часто содержит лишь общую фразу «работы выполнены в срок и надлежащего качества». Такой документ не связывает результат с конкретными требованиями, что позволяет разработчику заявлять: «Мы передали код, а что вы с ним делаете — ваша проблема».

Без привязки к сценариям ТЗ невозможно доказать, что какая-то функция не реализована. Суд или арбитраж будет исходить из буквального содержания акта. Если там написано «софт передан», а в ТЗ — 40 пунктов требований, заказчик рискует потерять рычаги давления. Акт, составленный по формальному шаблону, не защитит вас от претензий разработчика на оплату, даже если половина функционала не работает.

Чтобы акт стал инструментом защиты, он должен содержать:

• Прямую ссылку на уникальный номер технического задания и дату его утверждения.

• Перечень всех сценариев тестирования с отметкой «Пройден/Не пройден».

• Ссылку на протокол тестирования, подпись которого подтверждает, что обе стороны согласны с результатами.

Критерии проверки соответствия функционала сценариям технического задания

Проверку соответствия проводите не «на глаз», а по формализованному чек-листу. Каждый критерий должен быть однозначно измерим.

1. Покрытие сценариев ТЗ. Сравните список требований из ТЗ с перечнем тест-кейсов в протоколе. Допустимый порог — 100% покрытие. Если из 50 требований протокол содержит тесты только на 45, акт подписывать нельзя.

2. Прохождение тестов. Проверьте, что каждый тест-кейс имеет результат: «Пройден» с подписью тестировщика заказчика и разработчика. Фиксируйте статус «Не пройден» с описанием дефекта.

3. Воспроизводимость. Для каждого «Пройденного» теста должен быть скринкаст или лог, подтверждающий корректную работу функции. Просто отметка без доказательства — не аргумент.

4. Соответствие нефункциональным требованиям. Проверьте метрики из ТЗ: время отклика API (например, не более 300 мс), нагрузка (до 1000 одновременных пользователей), доступность (99,9%). Используйте инструменты вроде JMeter или LoadRunner.

5. Отсутствие критических дефектов. В протоколе не должно быть незакрытых багов с приоритетом «Критический» или «Блокирующий». Даже один такой дефект — основание для отказа в подписании.

6. Верификация документации. Сопоставьте переданную документацию (руководство пользователя, API-документацию) с требованиями ТЗ к её наличию и формату.

Структура акта приемки: обязательные юридические формулировки и ссылки на документацию

Акт — это не просто подпись «Работы приняты». Это юридический документ, фиксирующий момент перехода исключительных прав (если это предусмотрено договором) и снимающий риски будущих претензий.

Обязательные разделы акта:

1. Реквизиты сторон и ссылка на договор. Укажите полные наименования, ОГРН/ИНН, номер и дату основного договора.

2. Предмет приемки. Чётко сформулируйте: «Программное обеспечение, разработанное в соответствии с Техническим заданием №[номер] от [дата], именуемое далее «Продукт».

3. Ссылка на комплект документов-приложений. Это ключевой пункт. Перечислите:

* Техническое задание №[номер] от [дата] — на [кол-во] листах.

* Протокол приемочного тестирования №[номер] от [дата] — на [кол-во] листах.

* Перечень скринкастов/демонстраций на [кол-во] носителях.

* Акт интеллектуальной собственности (если применимо).

4. Фиксация результатов тестирования. Прямо укажите: «По результатам тестирования, отраженным в Протоколе №[номер], все [число] требований из Технического задания №[номер] выполнены. Выявленные в ходе тестирования дефекты (перечень в Протоколе) устранены Исполнителем и приняты Заказчиком».

5. Переход исключительных прав. Если в договоре есть условие об отчуждении прав, используйте формулировку: «С момента подписания настоящего Акта Заказчику передаются исключительные права на Продукт в полном объёме, предусмотренном ст. 1234 ГК РФ».

6. Подписи и печати. Места для подписей уполномоченных лиц с расшифровкой и указанием должностей.

Таблица проверки: сопоставление результатов тестирования и требований ТЗ

Используйте таблицу как приложение к акту. Она наглядно демонстрирует покрытие.

Как использовать таблицу:

* Каждая строка — одно конкретное требование из ТЗ.

* Столбец «Результат» может принимать значения: «Пройден», «Не пройден», «Не тестировалось» (крайне нежелательно).

* Акт можно подписывать, только если в столбце «Результат» у всех строк стоит «Пройден». Любое «Не пройден» требует устранения и перепроверки.

Типичные ошибки при подписании акта, ведущие к потере контроля над кодом

1. Подписание акта «на будущее». Фраза «Акт подписан, недочёты будут исправлены по гарантии» — ловушка. Юридически вы приняли работу. Требовать исправлений вы будете уже в рамках гарантийных обязательств, что сложнее и дольше. Не подписывайте до устранения критических дефектов.

2. Отсутствие перечня передаваемых материалов. Акт, где указан только «софт», не обязывает разработчика передать исходные коды, сборочные скрипты, конфигурационные файлы и доступы к репозиториям. В результате вы получите «чёрный ящик».

3. Использование общих формулировок в предмете. «Разработка мобильного приложения» вместо «Мобильное приложение «Название», версия 1.0, разработанное по ТЗ №...». Общая формулировка размывает предмет и позволяет манипулировать объёмом.

4. Нефиксированный статус прав. Если в договоре нет пункта о передаче исключительных прав, то по умолчанию вы получаете только право использования. Убедитесь, что в акте или отдельном акте об интеллектуальной собственности есть прямое указание на отчуждение.

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

Когда подписание акта стоит отложить: критические риски и способы их фиксации

Подписание акта — это не формальность, а юридический факт. Приостановите процесс в следующих случаях:

* Есть незакрытые критические дефекты. Составьте совместный протокол разногласий, где перечислите дефекты, сроки их устранения (например, 5 рабочих дней) и обязательство Исполнителя уведомить об исправлении. Только после исправления подписывайте акт.

* Не переданы исходные коды и доступы. Не подписывайте акт, пока не получите полный архив исходников, инструкции по сборке и доступы к репозиторию (например, GitLab). Фиксируйте этот факт письменно: «Акт не подписан до момента передачи материалов, указанных в п. 4.2 Договора».

* Разработчик отказывается подписать протокол тестирования. Если протокол подписан только вами, он не имеет силы. Настаивайте на совместной подписи. При отказе — фиксируйте его актом в присутствии свидетелей (сотрудников вашей компании) и направляйте разработчику претензию.

* Обнаружено несоответствие архитектуры. Если при тестировании выяснилось, что вместо указанной в ТЗ базы данных PostgreSQL используется MongoDB, это существенное нарушение. Приостанавливайте приемку, требуйте объяснений и пересмотра сроков.

Способ фиксации рисков: Направляйте разработчику официальные письма (заказным с уведомлением или по электронной почте с запросом о прочтении) с перечнем замечаний и требованием их устранить. Сохраняйте все переписки.