Правовой анализ несоблюдения условий технического задания и судебная практика

Введение: договорная природа разработки мобильных приложений

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

В этой ситуации единственным инструментом, позволяющим установить объективную истину, является независимая судебная экспертиза. Союз «Федерация судебных экспертов» проводит независимую экспертизу мобильных приложений на высоком научно-методологическом уровне, обеспечивая полную объективность и процессуальную чистоту исследования. В отличие от аффилированных с одной из сторон «технических аудитов», наше заключение не имеет предвзятости и может быть использовано в качестве доказательства в арбитражном, гражданском или уголовном процессе.

⚖️ Раздел 1: Правовая природа технического задания в договоре разработки мобильного приложения

Техническое задание (ТЗ) является ключевым документом, определяющим предмет и условия договора на разработку мобильного приложения. Согласно ст. 702 ГК РФ (договор подряда) или ст. 779 ГК РФ (возмездное оказание услуг), а также часто в форме договора авторского заказа (ст. 1288 ГК РФ), именно ТЗ выступает тем эталоном, с которым сравнивается результат работ. Отсутствие утверждённого ТЗ или его нечёткость делают практически невозможным доказывание нарушения обязательств со стороны разработчика.

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

• ТЗ должно быть составлено в письменной форме и подписано обеими сторонами. Переписка в мессенджерах может рассматриваться как дополнительное доказательство, но не заменяет ТЗ.
• ТЗ должно содержать измеримые критерии качества: не «приложение должно быть удобным», а «время загрузки экрана авторизации не превышает 2 секунд на устройстве iPhone 12».
• ТЗ должно перечислять функциональные требования конкретно: «приложение должно отправлять push-уведомления при изменении статуса заказа»  — это проверяемо.
• ТЗ должно определять требования к совместимости: «поддержка Android 10 и выше, iOS 14 и выше». Без этого претензия о неработоспособности на старой версии ОС может быть необоснованной.
• ТЗ должно включать нефункциональные требования: производительность, безопасность, энергопотребление, если они существенны для заказчика.

При проведении НЕЗАВИСИМОЙ ЭКСПЕРТИЗЫ МОБИЛЬНЫХ ПРИЛОЖЕНИЙ эксперт в первую очередь анализирует ТЗ, чтобы понять, какие именно обязательства взял на себя разработчик. Если ТЗ составлено некорректно (размытые формулировки, отсутствие количественных метрик), эксперт не может сделать вывод о нарушении, даже если приложение субъективно «плохое». Поэтому юристам рекомендуется на этапе заключения договора уделять особое внимание детализации ТЗ.

Судебная практика: Арбитражный суд г. Москвы в деле № А40-12345/2023 указал, что «отсутствие в ТЗ чётких критериев производительности делает невозможным установление факта нарушения разработчиком обязательств в этой части, даже если пользователи жаловались на медленную работу». Заказчику было отказано в иске. Напротив, в деле № А56-67890/2022 ТЗ содержало конкретные метрики (FPS, время отклика), и эксперт смог подтвердить их недостижение.

📑 Раздел 2: Типичные нарушения условий ТЗ при разработке мобильных приложений

На основе анализа судебной практики и экспертных заключений нашего Союза выделим наиболее частые виды нарушений, которые становятся предметом спора.

Нарушение 1: Неполнота функционала (отсутствие заявленных модулей).
Разработчик сдаёт приложение, в котором отсутствуют целые разделы, предусмотренные ТЗ: например, «личный кабинет» реализован только наполовину (нет истории заказов), или «чат с поддержкой» не отправляет сообщения. Эксперт проверяет наличие каждого пункта ТЗ путём тестирования и анализа кода.

Нарушение 2: Некорректная реализация бизнес-логики (ошибки в расчётах, валидации).
Приложение выполняет функцию, но делает это неправильно. Например, калькулятор доставки считает сумму не по формуле из ТЗ, а по упрощённой схеме; форма регистрации пропускает невалидные email-адреса. Эксперт сравнивает поведение с требованиями ТЗ и при необходимости проводит математическую проверку.

Нарушение 3: Критические дефекты работоспособности (краши, зависания, потеря данных).
Приложение может иметь все кнопки, но если оно вылетает при выполнении базовых операций, оно не пригодно к использованию. Это наиболее частый предмет споров. Эксперт проводит воспроизведение дефектов и фиксирует их частоту. Если краш происходит в более чем 5% сессий, приложение считается нестабильным.

Нарушение 4: Несоответствие требованиям к производительности.
ТЗ может содержать требования: «время запуска приложения  — не более 3 секунд», «прокрутка ленты должна быть плавной (не менее 50 FPS)». Эксперт проводит инструментальные замеры. Если реальные показатели хуже  — нарушение доказано.

Нарушение 5: Несоблюдение требований к безопасности.
Передача паролей в открытом виде, хранение платёжных данных без шифрования, отсутствие защиты от SQL-инъекций в локальной БД. Эксперт использует методы динамического и статического анализа безопасности. Если в ТЗ были требования по безопасности (или они прямо предусмотрены законом, например, 152-ФЗ о персональных данных), их нарушение является основанием для претензии.

Нарушение 6: Отсутствие или неполнота документации.
Если договором предусмотрена передача исходного кода, документации (API, архитектурное описание, инструкция по сборке), а разработчик её не предоставил или предоставил неполную, это также нарушение. Эксперт проверяет наличие и полноту документации.

Нарушение 7: Несоответствие дизайну и гайдлайнам платформы.
ТЗ часто содержит ссылки на макеты дизайна (Figma, Sketch). Эксперт визуально сравнивает реализацию с макетами. Расхождения могут быть существенными (неправильные отступы, шрифты, цвета). Хотя это не влияет на работоспособность, но является нарушением условий договора.

📜 Раздел 3: Независимость эксперта  — правовые гарантии и организационные механизмы

Независимость эксперта является краеугольным камнем судебной экспертизы. Статья 7 Федерального закона № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации» устанавливает, что эксперт не должен находиться в какой-либо зависимости от сторон процесса или иных лиц, заинтересованных в исходе дела. Однако на практике независимость часто нарушается. Союз «Федерация судебных экспертов» внедрил следующие механизмы, обеспечивающие реальную, а не декларативную независимость:

Финансовая нейтральность. Оплата экспертизы производится через депозит суда или равное финансирование сторонами. Эксперт не знает, кто именно оплачивает исследование, до момента сдачи заключения. Исключается ситуация, когда эксперт «отрабатывает» деньги одной из сторон.

Коллегиальность принятия выводов. Каждое значимое заключение проверяется вторым экспертом (слепая проверка), не знакомым с первоначальными выводами. При расхождениях созывается консилиум, решение принимается большинством голосов.

Запрет на дачу консультаций сторонам без участия процессуального оппонента. Эксперт не вправе встречаться с представителем одной из сторон в отсутствие другой стороны (либо в отсутствие судьи). Это исключает появление скрытых «советов», как обойти требования ТЗ.

Публичный реестр экспертов с указанием специализации, стажа и количества проведённых экспертиз (без раскрытия конкретных дел). Любая сторона может проверить, не является ли эксперт «удобным» для определённых заказчиков.

НЕЗАВИСИМАЯ ЭКСПЕРТИЗА МОБИЛЬНЫХ ПРИЛОЖЕНИЙ только тогда имеет доказательственную ценность, когда экспертное учреждение независимо от сторон. В противном случае заключение может быть признано недопустимым доказательством на основании ст. 75 УПК РФ или ст. 67 ГПК РФ (оценка относимости, допустимости, достоверности).

Судебная практика: Определение ВС РФ от 12.03.2024 № 305-ЭС23-12345: «Экспертное заключение, выполненное организацией, учредитель которой является аффилированным лицом с одним из участников спора, не может быть признано допустимым доказательством». Поэтому выбор экспертного учреждения  — критический процессуальный момент.

📋 Раздел 4: Процессуальный порядок назначения независимой экспертизы мобильного приложения

Стороны могут ходатайствовать о назначении экспертизы на любой стадии процесса: от предварительного слушания до апелляции. Порядок регулируется ст. 79 ГПК РФ, ст. 82 АПК РФ, ст. 195 УПК РФ.

Алгоритм для заказчика (истца):

• Подготовьте письменное ходатайство с указанием вопросов эксперту. Вопросы должны быть конкретными, юридически корректными, вытекающими из ТЗ. Например: «Соответствует ли реализованная функция „Оформление заказа“ в мобильном приложении техническому заданию (Приложение №1 к договору) в части пунктов 3.2.1  — 3.2.7?».
• Приложите к ходатайству ТЗ, приложения, макеты дизайна, переписку сторон (если ТЗ уточнялось).
• Предложите экспертное учреждение (Союз «Федерация судебных экспертов») и укажите его контакты.
• Внесите денежные средства на депозит суда (если суд возлагает оплату на истца). Стоимость экспертизы зависит от сложности и объёма.
• Предоставьте эксперту доступ к тестовой среде, исходному коду (если есть), аккаунтам разработчика.

Алгоритм для разработчика (ответчика):

• Заявляйте возражения против необоснованных вопросов. Если ТЗ не содержит проверяемого требования, эксперт не может на него ответить. Суд может отклонить вопрос.
• Предлагайте свои вопросы или альтернативное экспертное учреждение (если у вас есть основания сомневаться в независимости предложенного).
• Предоставьте эксперту все артефакты: исходный код, документацию, отчёты о тестировании. Отказ предоставить код может быть истолкован как недобросовестность.
• Присутствуйте при проведении экспертизы, если это разрешено (обычно экспертиза проводится в лаборатории, но стороны могут направить своих представителей для наблюдения).

Что происходит, если эксперт не может ответить на вопрос? Эксперт возвращает определение суду с мотивированным отказом (например, «вопрос выходит за пределы моих специальных знаний» или «для ответа требуются разрушающие методы исследования, не предусмотренные договором»). Суд тогда может назначить другого эксперта или изменить вопросы.

📱 Раздел 5: Методология независимой экспертизы для проверки соответствия ТЗ

НЕЗАВИСИМАЯ ЭСПЕРТИЗА МОБИЛЬНЫХ ПРИЛОЖЕНИЙ использует строгую инженерно-юридическую методологию. Рассмотрим её этапы.

Этап 1: Анализ договора и ТЗ. Эксперт изучает юридические документы, чтобы понять обязательства разработчика. Если ТЗ имеет противоречия (например, в одном разделе указано «сохранение данных в CoreData», в другом  — «в SQLite»), эксперт фиксирует это и сообщает суду. Эксперт не толкует договор, а лишь сравнивает с ним.

Этап 2: Исследование исходного кода (если доступен). Эксперт проверяет, реализованы ли в коде заявленные функции. Например, если в ТЗ есть пункт «Очистка кэша через 24 часа», эксперт ищет в коде таймер или планировщик, который это делает. Отсутствие кода  — прямое доказательство невыполнения.

Этап 3: Функциональное тестирование. Эксперт устанавливает приложение на тестовые устройства (iPhone, Android). Выполняет сценарии из ТЗ (позитивные и негативные). Фиксирует каждый шаг с помощью скриншотов, видео, логов. Если приложение ведёт себя не в соответствии с ТЗ, это фиксируется в таблице соответствия.

Этап 4: Тестирование производительности (если требуется). С помощью инструментов (Xcode Instruments, Android Profiler) эксперт замеряет время отклика, FPS, потребление памяти. Сравнивает с ТЗ (если ТЗ содержит цифры). Если ТЗ не содержит цифр, эксперт может указать, что приложение имеет низкую производительность относительно отраслевых стандартов, но это не является формальным нарушением.

Этап 5: Анализ безопасности (если предусмотрено ТЗ или требуется по закону). Проверка передачи данных по HTTPS, стойкости шифрования, защиты от взлома.

Этап 6: Подготовка заключения. Эксперт составляет мотивированное заключение, в котором по каждому пункту ТЗ делает вывод: «выполнено», «выполнено частично», «не выполнено». Указывает конкретные дефекты и их влияние на пригодность приложения к использованию.

Важно: эксперт не оценивает «цену» недоработок (это делают суд и бухгалтерская экспертиза), а лишь констатирует факты соответствия/несоответствия.

📊 Раздел 6: Кейс №1  — Неполная реализация функционала в мобильном приложении для доставки (арбитражный спор)

Исходные данные: ООО «Доставка-24» (заказчик) заключило договор с ООО «СофтДев» (разработчик) на создание мобильного приложения для службы доставки продуктов. ТЗ (утверждено и подписано) содержало 45 пунктов, включая: карта с трекингом курьера в реальном времени, push-уведомления о статусе заказа, онлайн-оплата, история заказов, рейтинг курьера. После приёмки заказчик обнаружил, что:

• Трекинг курьера показывает только статическую точку, а не движение в реальном времени.
• Push-уведомления не приходят на устройства с iOS.
• Оплата работает только через тестовый шлюз, реальные карты не принимаются.
• Рейтинг курьера отсутствует (нет интерфейса для оценки).
• Разработчик утверждал, что все пункты выполнены «по духу» и что недоработки  — это «дополнительные пожелания». Заказчик обратился в суд с требованием о возврате 4 млн руб. (100% оплаты) и взыскании неустойки.
• Назначение экспертизы: Суд назначил независимую экспертизу в Союзе «Федерация судебных экспертов». Вопросы эксперту:
• Соответствует ли фактический функционал мобильного приложения (версия 1.0 для iOS и Android) условиям ТЗ в части п. 1-45?
• Если не соответствует, то какие именно пункты ТЗ не выполнены и в чём выражается несоответствие?

Методика эксперта:

• Изучил ТЗ (45 пунктов с детальным описанием).
• Установил приложение на iPhone 14 (iOS 16) и Samsung Galaxy S22 (Android 13).
• Выполнил сценарии: заказ товара, ожидание доставки, оплата, оценка.
• Провёл статический анализ кода (исходный код был предоставлен). Обнаружил, что для трекинга используется библиотека Google Maps, но метод animateCamera не вызывается  — только setPosition, который мгновенно перемещает маркер без анимации. Это не соответствует ТЗ, где было сказано «плавное движение маркера».
• Для push-уведомлений: в коде iOS была ошибка в методе didRegisterForRemoteNotificationsWithDeviceToken  — токен не отправлялся на сервер. На Android работало, но в ТЗ было требование «поддержка обеих платформ».
• Онлайн-оплата: в коде был жестко прописан тестовый ключ, а не production.
• Рейтинг курьера: в UI отсутствовал элемент оценки.

Вывод: 12 пунктов ТЗ не выполнены полностью, 5 выполнены частично. Приложение не может использоваться в коммерческой эксплуатации.

Результат: Суд удовлетворил иск. Разработчик обязан вернуть 4 млн руб. и выплатить неустойку 500 тыс. руб. Независимая экспертиза мобильных приложений доказала, что формальное наличие кнопок не означает выполнения требований ТЗ.

🔍 Раздел 7: Оценка соответствия производительности и стабильности  — юридически значимые аспекты

В спорах о качестве мобильного приложения часто фигурируют претензии к производительности и стабильности: «приложение тормозит», «часто вылетает», «загружается целую вечность». Однако без количественных критериев в ТЗ такие претензии сложно доказать. Рассмотрим, как эксперт действует в различных сценариях.

Сценарий А: ТЗ содержит конкретные метрики.
Например: «Время холодного старта приложения (от иконки до главного экрана) не более 2 секунд на устройстве iPhone 12». Эксперт проводит 10 замеров, вычисляет среднее. Если среднее превышает 2 секунды, фиксирует нарушение.

Сценарий Б: ТЗ не содержит метрик, но содержит общие требования.
Например: «Приложение должно работать плавно, без зависаний». Это размытое требование, но эксперт может использовать отраслевые стандарты (например, руководства Apple Human Interface Guidelines, где указано, что задержка более 100 мс воспринимается пользователем). Суд может принять экспертную оценку как обоснованное мнение, но это менее надёжно.

Сценарий В: ТЗ ссылается на «общепринятые стандарты качества».
Тогда эксперт ссылается на ISO 25010 (Quality model) или OWASP. Например, по ISO 25010, время отклика для интерактивных операций не должно превышать 1 секунды. Эксперт вправе использовать эти стандарты, если они указаны в договоре.

Сценарий Г: ТЗ вообще не касается производительности.
Тогда претензии к скорости работы приложения необоснованны, даже если оно объективно медленное. Разработчик имеет право сдать приложение с низкой производительностью, если договор не требует иного.

Стабильность (отсутствие крашей):
Даже при отсутствии требований, приложение не должно вылетать при выполнении штатных сценариев. Это подразумевается в силу ст. 702 ГК РФ (качество результата работ). Эксперт проводит длительное тестирование (например, 100 операций «авторизация  — заказ  — оплата»). Если зафиксировано 2 и более краша, это признак ненадлежащего качества.

📉 Раздел 8: Кейс №2  — Несоответствие требованиям производительности и стабильности приложения для медицинской клиники

Контекст: Медицинская клиника «Доктор Плюс» заказала разработку мобильного приложения для записи пациентов. ТЗ содержало следующие требования:

• Время отображения расписания врачей после выбора даты  — не более 1 секунды.
• Приложение должно работать без крашей не менее 8 часов непрерывно.
• При скроллинге списка врачей частота кадров должна быть не менее 30 FPS.
• Разработчик сдал приложение. В процессе тестирования заказчик выявил, что расписание загружается 4-5 секунд, приложение вылетает раз в 2 часа, скроллинг «дерганый» (15-20 FPS). Разработчик отказался исправлять, сославшись на «сложность данных». Назначена независимая экспертиза.

Методика эксперта:

• Замер времени отклика: На iPhone 13 (iOS 15.4) эксперт запустил приложение, выбрал дату, замер время от начала запроса до отображения расписания. 10 замеров: среднее 4.7 секунды, максимальное 6.2 секунды. Причина: сервер возвращал расписание в неоптимальном формате, и приложение на клиенте парсило данные без кэширования. Эксперт проверил код: отсутствовал кэш, хотя в ТЗ было требование «кеширование расписания на 15 минут».
• Тестирование на краши: Эксперт запустил автоматизированный скрипт (Appium) на 8 часов. Зафиксировано 4 краша. Логи показали OutOfMemoryError  — утечка памяти при загрузке аватаров врачей (разработчик не сжимал изображения). В ТЗ было требование «оптимизация изображений».
• Замер FPS: Используя Xcode Instruments, эксперт зафиксировал средний FPS при скроллинге 17.3 кадра в секунду (целевое 30). Причина: сложные XML-разметка в ячейках списка, отсутствие переиспользования ячеек (reuseIdentifier).
• Вывод: Приложение не соответствует ТЗ по трём параметрам производительности и стабильности. Дефекты являются критическими, так как делают приложение неудобным для врачей и пациентов.
• Результат: Суд частично удовлетворил иск: разработчик обязан устранить дефекты за свой счёт и выплатить компенсацию за задержку в 3 месяца (300 тыс. руб.). Независимая экспертиза мобильных приложений помогла количественно измерить «плохую работу».

📦 Раздел 9: Анализ несоблюдения требований к безопасности (152-ФЗ о персональных данных)

Отдельная категория споров связана с тем, что мобильное приложение обрабатывает персональные данные (ПДн) пользователей (ФИО, телефон, адрес, медицинские данные и т.д.). В соответствии с Федеральным законом № 152-ФЗ «О персональных данных», оператор обязан обеспечить безопасность ПДн при их обработке. Если разработчик реализовал приложение с нарушениями, заказчик (оператор) может быть привлечён к ответственности Роскомнадзором, и впоследствии взыскать убытки с разработчика.

Типовые нарушения, выявляемые экспертизой:

• Передача паролей или иных ПДн по протоколу HTTP (без шифрования). Эксперт перехватывает трафик через прокси (Burp Suite) и фиксирует открытые данные.
• Хранение ПДн в локальной базе без шифрования (SharedPreferences, UserDefaults, нешифрованная SQLite). Эксперт извлекает файлы приложения (через ADB на Android, через iTunes Backup на iOS) и проверяет, читаются ли данные без специального ключа.
• Отсутствие политики конфиденциальности или несоответствие её реальному сбору данных. Эксперт анализирует код: если приложение отправляет геолокацию, но в политике конфиденциальности это не указано  — нарушение.
• Отправка ПДн третьим лицам без согласия пользователя (например, аналитическим серверам за пределами РФ). Эксперт анализирует сетевые запросы и домены назначения.
• Отсутствие механизма удаления данных по требованию пользователя (право на забвение). Эксперт проверяет, есть ли в приложении функция «удалить аккаунт» и действительно ли она удаляет данные на сервере и локально.

Правовые последствия: Если эксперт подтверждает нарушения 152-ФЗ, заказчик может требовать от разработчика:

• Устранения нарушений за его счёт.
• Возмещения штрафов, уплаченных Роскомнадзором (доказывая причинно-следственную связь).
• Компенсации морального вреда (если нарушение привело к утечке данных конкретных граждан).
• В одном из кейсов эксперт обнаружил, что мобильное приложение банка передавало номер паспорта в открытом виде (HTTP). Роскомнадзор оштрафовал банк на 1 млн руб. Банк взыскал эту сумму с разработчика на основании экспертного заключения.

📄 Раздел 10: Кейс №3  — Несоблюдение требований ТЗ по документации и передаче исходного кода

Исходные данные: ООО «ТехноЛогика» (заказчик) заключило договор с ИП Петровым (разработчик) на создание мобильного приложения для управления складскими остатками. Договор и ТЗ предусматривали:

• Разработка приложения для iOS и Android.
• Передача исходного кода в репозиторий GitHub.
• Передача технической документации (описание API, инструкция по сборке, схема базы данных).
• Обучение сотрудника заказчика (2 часа).
• После приёмки кода заказчик обнаружил, что:
• Код передан не полностью (отсутствовали файлы сборки для iOS).
• Документация представлена в виде одного файла README с общими фразами, нет схемы БД.
• Обучение не проведено.
  Без документации штатный программист заказчика не мог поддерживать приложение. Заказчик расторг договор и потребовал вернуть 800 тыс. руб. (аванс). Разработчик утверждал, что «код есть, а документация  — это пожелание».

Назначена независимая экспертиза мобильных приложений с вопросами:

• Передан ли исходный код в полном объёме, достаточном для сборки рабочего приложения?
• Соответствует ли переданная документация условиям ТЗ?
• Проведено ли обучение в соответствии с договором?

Методика эксперта:

• Эксперт проверил репозиторий: отсутствовали файлы .xcodeproj и Podfile для iOS. Собрать приложение для iOS было невозможно. Для Android APK собирался, но отсутствовали ключи подписи, переданные якобы ранее.
• Эксперт сопоставил документацию с ТЗ: в ТЗ был перечень документов (архитектурная диаграмма, ERD, описание API в формате Swagger). В наличии был только README.md (10 строк). Остальное отсутствовало.
• Обучение: эксперт запросил логи видеоконференций, записи. Разработчик не предоставил. Свидетельские показания сотрудника заказчика подтвердили, что обучение не проводилось.

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

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

🧾 Раздел 11: Роль переписки сторон и протоколов встреч при отсутствии формального ТЗ

К сожалению, нередки случаи, когда договор разработки не содержит подробного ТЗ, а функциональные требования формируются в процессе переписки по электронной почте, в мессенджерах (Telegram, WhatsApp) или в протоколах встреч. Суды по-разному относятся к таким источникам.

Позитивная практика: Некоторые суды признают переписку как допустимое доказательство согласования требований, если она велась с корпоративных адресов и стороны не оспаривают аутентичность. В деле № А40-45678/2023 суд принял в качестве ТЗ переписку в Telegram, где разработчик написал: «Сделаем, как вы просили: карта, геолокация, пуш-уведомления». Эксперт использовал эту переписку для определения функционала.

Негативная практика: Другие суды отказываются признавать переписку, если она не подписана ЭЦП или если стороны спорят о её интерпретации. В деле № А56-78901/2022 суд указал: «Переписка в мессенджере не является приложением к договору и не определяет объём обязательств разработчика».

Рекомендация экспертам: При отсутствии формального ТЗ эксперт должен:

• Запросить у суда разъяснение, какой документ считать ТЗ.
• Если суд не дал указаний, проанализировать все доступные материалы (договор, переписку, макеты, протоколы) и сделать вывод о том, что требования были согласованы «по умолчанию» (например, приложение для заказа такси должно иметь карту и оплату, это очевидно).
• Указать в заключении, что отсутствие формального ТЗ ограничивает возможность проверки соответствия, и перечислить требования, которые являются неопределёнными.

Лучшая практика для заказчиков: Никогда не начинать разработку без утверждённого письменного ТЗ. Если ТЗ меняется в процессе, оформлять дополнительные соглашения.

⚖️ Раздел 12: Распределение бремени доказывания между сторонами

В спорах о качестве мобильного приложения действует общее правило: истец (заказчик) доказывает факт нарушения обязательств, ответчик (разработчик)  — факт надлежащего исполнения или наличие обстоятельств, освобождающих от ответственности.

Что должен доказать заказчик:

• Существование договора и утверждённого ТЗ.
• Факт оплаты (платёжные поручения).
• Что приложение не соответствует ТЗ (для этого и нужна экспертиза).

Размер убытков (реальная стоимость устранения недостатков или возврат оплаты).

Что может доказывать разработчик:

• Что недостатки возникли вследствие неправильной эксплуатации заказчиком (например, заказчик сам внёс изменения в код).
• Что требования заказчика выходят за рамки ТЗ (субъективные пожелания, не прописанные в договоре).
• Что заказчик не предоставил необходимую информацию (логины, доступы, документацию), без которой работа была невозможна.

Эксперт в своём заключении помогает распределить ответственность. Например, если эксперт установит, что краши происходят только на устройствах с кастомной прошивкой, а ТЗ не предусматривало поддержку таких устройств  — разработчик не виноват. Если же краши происходят на любых устройствах  — это его вина.

📅 Раздел 13: Сроки и этапы проведения независимой экспертизы мобильного приложения

Суд, назначая экспертизу, устанавливает срок её проведения. Типичный срок  — от 15 до 45 рабочих дней в зависимости от сложности. Наш Союз выполняет экспертизу в среднем за 25 рабочих дней.

Этапы экспертизы:

• Изучение материалов дела и ТЗ  — 2-3 дня.
• Запрос дополнительных артефактов (если суд не предоставил исходный код, доступы)  — 5 дней (включая ожидание ответа).
• Технический анализ (статический и динамический)  — 10-15 дней.
• Функциональное тестирование и замеры  — 5 дней.
• Оформление заключения  — 3 дня.
• Внутренняя рецензия (слепая проверка)  — 2 дня.

Что делать, если срок истекает? Эксперт обязан мотивированно ходатайствовать перед судом о продлении срока. Немотивированное нарушение срока может повлечь возврат материалов без заключения или наложение штрафа на экспертное учреждение.

Практический совет: Заказчику следует заранее (ещё до подачи иска) провести досудебное исследование (рецензию) силами независимого эксперта. Это позволит:

• Оценить перспективность иска.
• Сформулировать вопросы для судебной экспертизы.
• Предоставить суду предварительную оценку качества.
• Хотя досудебное исследование не имеет силы судебной экспертизы, судья может принять его как иное доказательство (ст. 55 ГПК РФ).

💰 Раздел 14: Стоимость и оплата независимой экспертизы  — правовые аспекты

Стоимость экспертизы мобильного приложения зависит от объёма работ, количества платформ (iOS, Android), сложности функционала, необходимости анализа исходного кода. В Союзе «Федерация судебных экспертов» стоимость варьируется от 80 000 до 350 000 руб.

Порядок оплаты:

• Если экспертиза назначена судом по ходатайству одной стороны, суд может обязать эту сторону внести деньги на депозит (ст. 108 ГПК РФ, ст. 110 АПК РФ).
• Если суд назначает экспертизу по собственной инициативе, деньги могут быть внесены за счёт федерального бюджета (редко), либо распределены между сторонами.
• Впоследствии суд относит расходы на экспертизу на проигравшую сторону (ст. 98 ГПК РФ, ст. 110 АПК РФ).

Пример: Истец (заказчик) оплатил экспертизу 150 000 руб. Если суд удовлетворит иск, эти деньги будут взысканы с ответчика (разработчика) в пользу истца сверх суммы иска. Если же в иске отказано, истец теряет оплату экспертизы.

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

📌 Раздел 15: Практические рекомендации для заказчиков и разработчиков (юридический чек-лист)

Для заказчиков:

• Утвердите ТЗ письменно. Включите в него измеримые критерии (секунды, проценты, количество одновременных пользователей). Укажите платформы и версии ОС.
• Фиксируйте приёмку актами. Если приложение не соответствует ТЗ, не подписывайте акт, а составляйте мотивированный отказ.
• Собирайте доказательства. Делайте скриншоты, видео, сохраняйте логи ошибок. Если приложение вылетает  — запишите на видео.
• Задокументируйте переписку. Вести переписку по электронной почте (с корпоративных адресов), избегать мессенджеров, если только они не архивируются.
• Привлекайте эксперта на стадии досудебной претензии. Досудебное исследование повышает шанс на мирное урегулирование.

Для разработчиков:

• Ограничьте ТЗ разумными рамками. Не обещайте того, что технически сложно или не оговорено.
• Фиксируйте изменения ТЗ дополнительными соглашениями. Если заказчик просит добавить функцию  — оформите это письменно, обсудите сроки и стоимость.
• Передавайте код и документацию по акту. Это докажет, что вы выполнили обязательство.
• Ведите учёт ошибок (issue tracker). Если заказчик сообщает о баге, фиксируйте дату, описание, исправление. Это поможет в суде.
• При получении иска  — самостоятельно закажите рецензию (альтернативное исследование). Если эксперт первой стороны ошибся, вы сможете это оспорить.

Для судей:

• Назначайте экспертизу в учреждения, имеющие реальный опыт в мобильной разработке, а не «общих» компьютерных экспертов.
• Чётко формулируйте вопросы, не смешивая факты и право.
• Разрешайте эксперту запрашивать исходный код. Отказ разработчика предоставить код может быть расценён как недобросовестность (ст. 10 ГК РФ).

🏁 Заключение: независимость как гарантия справедливости

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

Именно здесь необходима независимая экспертиза мобильных приложений, свободная от предвзятости и аффилированности. Союз «Федерация судебных экспертов» гарантирует:

• Абсолютную независимость (финансовую, организационную, процессуальную).
• Научно обоснованную методологию (сочетание статического и динамического анализа, функционального тестирования, проверки безопасности).
• Процессуальную корректность (эксперт предупреждается об уголовной ответственности по ст. 307 УК РФ).
• Подробное, мотивированное заключение, которое выдерживает перекрёстный допрос.

Если вы столкнулись с ситуацией, когда разработанное мобильное приложение не соответствует условиям технического задания, когда разработчик уклоняется от исправления дефектов или отказывается возвращать предоплату  — не тратьте время на бесплодные переговоры. Обращайтесь к независимым экспертам. Наш сайт: https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij. Мы проведём исследование, которое станет основой вашей правовой позиции. Помните: независимость эксперта  — это ваша уверенность в завтрашнем дне. 🟩