Экспертиза фактически выполненного объема работ

Здравствуйте.
Рады приветствовать вас на сайте Союза «Федерация судебных экспертов».
Уважаемый клиент, ваш спор в Арбитражном суде г. Москвы касается взыскания задолженности за разработку программного обеспечения (ПО), разбитого на 4 этапа. Исполнитель выполнил 2 этапа, но у заказчика есть претензии. Исполнитель требует оплатить 2-ю часть за 2-й этап, заказчик подал встречный иск. Цель экспертизы – установить, соответствует ли результат работ требованиям договора и допсоглашения для этапов 1 и 2, является ли ПО работоспособным, если есть недостатки – исправимы ли они, а также проверить соответствие работ техническому заданию (ТЗ), которое не подписывалось сторонами, но является частью договора. Это классическая судебная компьютерно-техническая и строительно-техническая (для ПО) экспертиза. Именно экспертиза фактически выполненного объема работ позволит ответить на вопрос, оплачены ли работы в полном объеме или нет, и кто виноват в недостатках. Разберем стоимость, сроки, документы, процедуру, трудности и места проведения в Москве.
1. Что может установить эксперт по вашему делу?
Эксперт в области разработки ПО (программист с квалификацией судебного эксперта) или IT-эксперт проанализирует: 1) соответствует ли фактически предоставленный код, алгоритмы, документация и демо-версия ПО условиям договора и ТЗ (даже если ТЗ не подписано, но на него есть ссылка в договоре, оно считается согласованным), 2) работоспособно ли ПО на этапах 1 и 2 (т.е. выполняет ли оно заявленные функции без критических ошибок), 3) если есть недостатки – являются ли они устранимыми (требуют доработки) или неустранимыми (полная переделка), 4) какой объем работ фактически выполнен (например, 80% от этапа или только 30%), 5) имели ли место скрытые недостатки, которые заказчик не мог обнаружить при приемке. Экспертиза фактически выполненного объема работ также поможет определить, можно ли принять результат частично (например, 2-й этап оплатить пропорционально качеству).
2. Стоимость
В Москве цена экспертизы фактически выполненного объема работ по разработке ПО (два этапа) зависит от сложности кода, объема документации и необходимости тестирования. Базовый вариант (анализ документации, проверка соответствия договору, оценка работоспособности на тестовых примерах) – от 80 000 до 120 000 рублей. Расширенный (полный анализ исходного кода, функциональное тестирование, написание подробного заключения с перечнем недостатков и оценкой их устранимости) – от 130 000 до 200 000 рублей. Если требуется провести исследование на реальных серверах заказчика (нагрузочное тестирование, проверка безопасности) – до 250 000 рублей. Срочный режим (10-14 дней) добавляет 40-50%. Учитывая, что ТЗ не подписано, но является частью договора, потребуется дополнительная работа по его идентификации – это плюс 20-30 тыс. рублей.
3. Сроки
Стандартный срок – от 15 до 25 рабочих дней (3-5 недель). Расклад: 3-5 дней на изучение договора, ТЗ, переписки сторон, актов сдачи-приемки, 5-7 дней на анализ исходного кода (если он предоставлен), 3-5 дней на функциональное тестирование (установка ПО, выполнение сценариев), 2-3 дня на выявление недостатков и оценку их устранимости, 2-3 дня на составление заключения. Если код не предоставлен (только исполняемые файлы), срок может сократиться до 10-15 дней, но точность снизится. Срочный режим (10-12 дней) возможен при условии предоставления всей документации в электронном виде и удаленного доступа к тестовому стенду. Качественная экспертиза фактически выполненного объема работ требует времени на воспроизведение ошибок – разработчики часто прячут дефекты за сложными сценариями.
4. Какие документы необходимы?
Для того чтобы эксперт дал заключение, которое примет Арбитражный суд г. Москвы, предоставьте:

• Договор между Исполнителем (ГК) и Заказчиком (ХК) – с указанием этапов, сроков, стоимости, порядка приемки, ссылок на ТЗ.
• Техническое задание (даже если не подписано, но есть в переписке или в приложении к договору) – эксперт будет его использовать как обязательный документ, если в договоре есть фраза «работы выполняются в соответствии с ТЗ».
• Дополнительные соглашения к договору (если есть).
• Акты сдачи-приемки этапов 1 и 2 (с вашими возражениями или без).
• Переписку сторон (письма, электронные сообщения, протоколы совещаний), где обсуждались требования, ошибки, доработки.
• Исходный код (если есть) или исполняемые файлы, базы данных, конфигурационные файлы, документацию к ПО (руководство пользователя, администратора).
• Доступ к тестовой или продуктивной среде (сервер, база данных, API) – для проверки работоспособности.
• Описание недостатков, которые заказчик предъявил (список ошибок, скриншоты, логи, видео).
• Исковое заявление и встречное исковое заявление (чтобы эксперт знал, на какие вопросы суда отвечать).
• Для судебной экспертизы – определение суда о назначении экспертизы фактически выполненного объема работ.
  Без ТЗ эксперт будет опираться только на договор и обычаи делового оборота – это менее надежно. Но если ТЗ не подписано, но есть в проекте и стороны его обсуждали, эксперт может его использовать как ориентир.

5. Как провести? (процедура шаг за шагом)
Процедура включает изучение документов, анализ кода и тестирование:

• Шаг 1. Эксперт знакомится с материалами дела, договором, ТЗ. Выясняет, какие требования предъявлялись к этапам 1 и 2 (какой функционал должен быть реализован, какие критерии приемки).
• Шаг 2. Анализ переписки: эксперт ищет, признавал ли заказчик какие-то работы выполненными, направлял ли мотивированный отказ от приемки, были ли попытки доработки.
• Шаг 3. Если предоставлен исходный код – эксперт проводит статический анализ (проверка архитектуры, соответствие соглашениям о кодировании, наличие комментариев, документации). Если кода нет – только функциональное тестирование.
• Шаг 4. Установка ПО в тестовой среде (или удаленный доступ к среде заказчика). Эксперт пытается выполнить все функции, описанные в ТЗ и договоре. Фиксирует, какие работают, какие нет, какие выдают ошибки.
• Шаг 5. Если есть ошибки (баги) – эксперт классифицирует их: критичные (ПО не выполняет основную функцию, вылетает, теряет данные), значительные (функция работает с ограничениями), незначительные (косметические, не влияют на работу). Оценивает, можно ли их исправить: да, с небольшими трудозатратами; да, но потребуется значительная переработка; нет, нужно переписывать с нуля.
• Шаг 6. Проверка работоспособности: эксперт отвечает на вопрос «может ли ПО на этапах 1 и 2 использоваться по назначению?». Если да – то работы выполнены. Если нет – то объем работ не достигнут.
• Шаг 7. Оценка фактического объема: например, «из 15 функций, указанных в ТЗ для этапа 2, реализовано 10, остальные отсутствуют или неработоспособны, что составляет 67% от плана». Эксперт делает вывод: соответствует ли результат условиям договора (если договор требует 100% функционала – то не соответствует), и подлежит ли оплате (если да, то пропорционально).
• Шаг 8. Заключение: таблица с перечнем недостатков, их критичностью, устранимостью, и итоговый вывод о том, выполнены ли этапы 1 и 2 надлежащим образом.

6. Какие трудности могут возникнуть?
Практика IT-экспертиз в арбитраже знает следующие проблемы:

• Отсутствие подписанного ТЗ. Это самая большая сложность. Если в договоре сказано «работы выполняются согласно ТЗ», но ТЗ не подписано, суд может признать, что стороны не согласовали предмет договора (ст. 432 ГК РФ). Однако эксперт может использовать ТЗ, если оно было направлено по электронной почте и заказчик не возражал. Экспертиза фактически выполненного объема работ в таком случае будет опираться на это ТЗ как на обычай делового оборота. Но риск того, что суд откажется его принять, есть. Рекомендуйте сторонам подписать ТЗ задним числом – это снизит риски.
• Исполнитель не предоставляет исходный код (ссылается на коммерческую тайну). Тогда эксперт может проверить только исполняемые файлы (exe, dll). Это ограничивает анализ: нельзя увидеть, есть ли «закладки», недокументированные возможности, плохой стиль кода. Эксперт должен указать на это в заключении.
• Заказчик не предоставляет доступ к своему серверу (например, опасается за безопасность). Эксперт предлагает выделить изолированную тестовую среду – виртуальную машину. Если заказчик отказывается, эксперт делает вывод «невозможно провести полноценное тестирование».
• Спор о том, что считать «недостатком»: заказчик может считать багом то, что не было в ТЗ, а исполнитель – что это «дополнительная функция». Эксперт должен строго придерживаться ТЗ. Если в ТЗ нет требования, то его отсутствие – не недостаток.
• Недостатки могут быть исправимы, но требовать много времени (например, 3 месяца). Эксперт должен оценить трудозатраты в человеко-часах или деньгах (например, пригласить калькулятора). Это уже смежная экономическая экспертиза.
• Если в процессе разбирательства ПО было изменено (заказчик сам доработал или исполнитель исправил ошибки после подачи иска), эксперт должен исследовать версию на момент сдачи работ. Поэтому важно предоставить архивные копии.

7. Где провести в Москве?
В Москве есть несколько центров судебной IT-экспертизы. Союз «Федерация судебных экспертов» рекомендует:

• Лабораторию компьютерно-технической экспертизы при МГТУ им. Баумана (кафедра «Программное обеспечение ЭВМ») – сильные специалисты по анализу кода.
• Независимый центр «ИТ-Эксперт» (м. Текстильщики, Волгоградский проспект) – входит в наш союз, имеет опыт арбитражных споров по разработке ПО.
• Центр судебной экспертизы при РГУП (Российский государственный университет правосудия) – часто назначается арбитражными судами.
  Главное требование – эксперт должен иметь высшее техническое образование по специальности «Программная инженерия» или «Информатика», а также квалификацию судебного эксперта по специальности 27.3 (исследование программных продуктов). Не привлекайте обычных программистов – они могут оценить качество кода, но не оформят заключение для суда.

8. Общие правила и процедура проведения (судебная)
Правила для экспертизы фактически выполненного объема работ в арбитраже:

• Экспертиза назначается определением суда. Эксперт предупреждается об уголовной ответственности по ст. 307 УК РФ.
• Стороны вправе присутствовать при тестировании (но не мешать). Они могут задавать эксперту вопросы через суд.
• Эксперт не может давать правовую оценку (например, «исполнитель нарушил сроки»), только техническую.
• Если для исследования нужен доступ к серверам заказчика, а он его не предоставляет, эксперт делает отметку, и суд может применить ст. 66 АПК РФ (истребование доказательств).
• Срок проведения может быть продлен, если код содержит миллионы строк или требует сложного нагрузочного тестирования.
• Если вы не согласны с выводами, вы заказываете рецензию или ходатайствуете о повторной экспертизе (часто поручают другому эксперту).

Практический совет: Уважаемый клиент, ключевая проблема в вашем деле – отсутствие подписанного ТЗ. Если стороны не подписали ТЗ, но в договоре есть ссылка на него, эксперт будет исследовать этот документ как часть договора. Однако ответчик (исполнитель) может заявить, что ТЗ не согласовано. Поэтому до экспертизы попробуйте решить вопрос миром: подпишите ТЗ задним числом или зафиксируйте в судебном порядке, что стороны руководствовались этим ТЗ (например, через переписку). Также обязательно предоставьте эксперту все письма, где обсуждались требования к этапам – они помогут восстановить действительную волю сторон. И еще один важный момент: если ПО работоспособно, но имеет недостатки (баги), эксперт должен оценить, можно ли их исправить. Если да, то суд может обязать исполнителя их исправить, а не отказывать в оплате. Экспертиза фактически выполненного объема работ в таком случае покажет, что работы выполнены, но с дефектами, которые подлежат устранению. Это позволит заказчику удержать часть оплаты на устранение недостатков, а не проиграть весь этап. Не забудьте попросить эксперта рассчитать примерные трудозатраты на исправление (в часах или деньгах) – для этого эксперт может привлечь калькулятора или использовать среднерыночные ставки.
За подробной и точной консультацией приглашаем вас в наш офис Союз «Федерация судебных экспертов», адрес которого указан на сайте: https://tehexp.ru/contacts