Когда договор с разработчиком превращается в иск

Глава 1: Пролог в мире обещаний и кода

Ты когда-нибудь заказывал разработку мобильного приложения? 🤔 Знаешь это чувство, когда менеджер студии рисует радужные перспективы: «сделаем за три месяца, будет работать быстро, интуитивно понятно, пользователи будут в восторге». Ты подписываешь договор, переводишь первый транш, ждёшь… и получаешь нечто, что вылетает при каждом чихе, тормозит как черепаха в лаве и выглядит как сайт из 2007 года. А разработчик пожимает плечами: «Всё по ТЗ, деньги не вернём». И начинаются танцы с бубном  — сначала претензия, потом суд, потом экспертиза. 🕺

Мы  — Союз «Федерация судебных экспертов»  — каждый месяц видим десятки таких историй. Заказчики и разработчики приходят к нам с криками «он меня обманул!» и «он сам не знал, чего хотел!». А мы спокойно, методично, с помощью научных методов и железной логики разбираемся, кто прав, кто виноват, и можно ли вернуть деньги. ⚖️

Сегодняшняя статья  — целиком и полностью про IT-экспертизу мобильных приложений. И ключевой акцент мы сделаем на самом больном  — несоблюдении условий технического задания (ТЗ) к договору разработки. Потому что 80% споров возникает именно из-за того, что ТЗ было составлено плохо, разработчик его трактовал в свою пользу, а заказчик надеялся на чудо. Чуда не случилось. Но есть экспертиза. 🔍

Я расскажу три реальных кейса из нашей практики (все детали изменены, но суть настоящая). Покажу, как мы работаем, какие методы применяем, на что обращаем внимание. Будет много технических подробностей, но я постараюсь объяснять на пальцах. Приготовься, будет долго, интересно и полезно. 🧠

Поехали! 🚀

Глава 2: Что такое IT-экспертиза мобильных приложений и зачем она нужна

Давай сначала разберёмся с терминологией. IT-экспертиза мобильных приложений  — это вид судебной компьютерно-технической экспертизы, которая изучает программное обеспечение для смартфонов и планшетов (Android, iOS, реже  — другие ОС) на предмет соответствия заявленным требованиям, наличия дефектов, ошибок безопасности и скрытых функций. 🧩

IT-экспертиза мобильных приложений может проводиться как в рамках гражданского процесса (спор заказчика и разработчика, спор пользователя и магазина приложений), так и в уголовном (если приложение использовалось для мошенничества, кражи данных, распространения вредоносного ПО). Но сегодня мы говорим о гражданско-правовых спорах, а конкретно  — о несоблюдении ТЗ. 📄

Кому это нужно:

Заказчику, который заплатил деньги, но получил нерабочий или некачественный продукт. Он хочет вернуть аванс, взыскать убытки или обязать разработчика доделать работу.

Разработчику, который считает, что выполнил все обязательства, а заказчик просто капризничает и не хочет платить второй транш. Экспертиза может подтвердить его правоту.

Инвестору или венчурному фонду, который вложился в проект, но сомневается в компетенции команды.

Судье, который не понимает в коде и просит эксперта «перевести» претензии на человеческий язык. 🧑‍⚖️

IT-экспертиза мобильных приложений отвечает на вопросы: соответствует ли приложение условиям договора и ТЗ? Если нет  — какие именно пункты нарушены? Являются ли эти нарушения существенными (то есть делающими невозможным использование приложения по назначению)? Кто виноват в дефектах  — разработчик, заказчик (неправильное ТЗ) или третьи лица (например, магазин приложений заблокировал публикацию)?

Без экспертизы суд обычно не может принять решение. Потому что судья  — не программист. Он не отличит критический баг от мелкого неудобства. Поэтому наша задача  — дать ему чёткий, аргументированный ответ. 🎯

Глава 3: Техническое задание  — краеугольный камень спора

Ты можешь спросить: «А почему так важен ТЗ? Разве недостаточно того, что приложение не работает?». Недостаточно. Потому что понятие «работает» у каждого своё. Для заказчика «работает»  — значит, открывается, не падает и выполняет все функции из его головы. Для разработчика  — значит, не падает при стандартных сценариях, а всё остальное  — «улучшения за дополнительную плату». 😬

Что должно быть в качественном ТЗ:

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

Проблема в том, что 90% ТЗ написаны плохо. Они содержат фразы типа «приложение должно быть удобным», «дизайн должен быть современным», «всё должно работать быстро». Это не проверяемые критерии. Эксперт не может измерить «удобство» или «современность». Поэтому в спорах мы отталкиваемся от конкретных, измеримых пунктов. Если их нет  — шансы заказчика на победу невелики. 😥

Но бывает и так: ТЗ составлено хорошо, содержит чёткие метрики («время запуска приложения не более 3 секунд», «приложение должно поддерживать 1000 одновременных пользователей»), а разработчик их не выполнил. Тогда задача IT-экспертизы мобильных приложений  — измерить эти метрики и зафиксировать нарушения. 📏

В каждом из наших кейсов мы будем опираться именно на ТЗ  — как на основной документ. Если ТЗ нет или оно плохое, мы используем дополнительные источники: переписку сторон, протоколы встреч, общепринятые стандарты (ГОСТы, руководства по качеству ПО). Но это менее надёжно.

Глава 4: Кейс первый  — «Фитнес-приложение, которое не считало калории»

🏋️ История первая, классический спор заказчика и разработчика. Заказчик  — известный блогер-фитнес-тренер, решил сделать своё мобильное приложение с программами тренировок, дневником питания и счётчиком калорий. Договорился со студией разработки (назовём её «КодоМания»). Сумма договора  — 4,5 миллиона рублей. Срок  — 5 месяцев. ТЗ было на 80 страниц: там были и макеты, и описание алгоритмов, и требования к производительности. 🏃‍♀️

Студия сделала приложение. Но при сдаче выяснилось, что счётчик калорий работает неправильно: для одного и того же продукта (например, 100 грамм куриной грудки) он показывал разные значения в зависимости от того, как быстро пользователь вводил данные. Кроме того, приложение вылетало при попытке сохранить тренировку с большим количеством упражнений (более 10). 📉

Заказчик отказался подписывать акт приёмки и платить второй транш (2 млн). Студия подала в суд о взыскании долга. Заказчик подал встречный иск о возврате аванса (2,5 млн) и взыскании убытков. Назначена IT-экспертиза мобильных приложений.

Наша работа:

🔹 Шаг 1. Изучение ТЗ и договора. В ТЗ было чётко прописано:

«Пункт 4.2.3: Счётчик калорий должен рассчитывать энергетическую ценность продукта на основе встроенной базы данных USDA (Министерство сельского хозяйства США) с точностью до 1 ккал».

«Пункт 5.1.1: Приложение должно стабильно работать с программами тренировок до 20 упражнений включительно».

«Пункт 6.4: Время отклика интерфейса не более 0,5 секунды при любых действиях пользователя».

Заказчик также предоставил переписку в Telegram, где разработчик обещал «поправить баги за неделю», но прошло два месяца, а ничего не исправили.

🔹 Шаг 2. Воспроизведение дефектов. Мы установили приложение на 5 реальных устройств (разные модели и версии Android, на iOS приложение вообще не было доделано, хотя по ТЗ должно быть под обе платформы). Провели тесты:

Счётчик калорий: ввели 10 продуктов подряд. Для куриной грудки получили значения: 165, 172, 158, 163, 170 ккал. Разброс  — 14 ккал, при том что по ТЗ точность должна быть 1 ккал. Дефект воспроизводится на всех устройствах. 🍗

Тренировки: создали программу из 15 упражнений. При попытке сохранить приложение вылетело с ошибкой NullPointerException. Анализ логов показал, что разработчик не предусмотрел обработку массивов больше 10 элементов. Ошибка в коде.

Время отклика: простейшее действие  — нажатие на кнопку «Добавить продукт»  — приводило к задержке 2-3 секунды, потому что приложение синхронно подгружало всю базу продуктов (1500 записей) из локальной SQLite. Нет асинхронности, нет кэширования.

🔹 Шаг 3. Статический анализ кода (нам предоставили доступ к репозиторию). В исходниках нашли не просто баги, а системные проблемы:

• Архитектура MVP (Model-View-Presenter) была реализована неправильно: Presenter содержал слишком много логики, не покрытой тестами.
• Отсутствовали модульные тесты (unit tests) вообще  — хотя в ТЗ было сказано «покрытие тестами не менее 70% кода».
• Использовались устаревшие библиотеки с известными уязвимостями.

🔹 Шаг 4. Экспертный эксперимент. Мы создали эталонную среду: чистый эмулятор Android 13 с минимальным набором приложений. Установили последнюю версию приложения, предоставленную студией (зафиксировали хэш-сумму APK). Повторили тесты на этой среде  — результат тот же. Значит, проблема не в «кривых руках пользователя» или «заражённом телефоне».

Вывод эксперта:

• Приложение не соответствует пунктам ТЗ 4.2.3, 5.1.1, 6.4.
• Дефекты являются критическими, поскольку делают невозможным использование приложения по назначению (счётчик калорий не даёт достоверных данных, приложение падает при попытке сохранить тренировку).
• Студия разработчика не выполнила обязательства по тестированию (нет unit-тестов).
• Стоимость устранения дефектов по рыночным оценкам  — от 1,2 до 1,8 млн рублей.

Итог суда: Суд отказал студии во взыскании второго транша, удовлетворил встречный иск частично: разработчик вернул аванс (2,5 млн) и выплатил 700 тыс. компенсации. Заказчик нашёл другую студию, которая переписала приложение за 2,2 млн и успешно запустила. 🏆

Методологический урок: IT-экспертиза мобильных приложений в этом кейсе показала, что «мелкие баги» (разброс калорий) на самом деле  — критическое нарушение ТЗ. Всё зависит от того, как сформулирован пункт. Разработчик клялся, что «все приложения считают калории с погрешностью», но ТЗ требовало точности 1 ккал  — и это был приговор. 💀

Глава 5: Типичные нарушения ТЗ, которые мы видим чаще всего

Мы проанализировали десятки наших заключений и выделили топ-5 нарушений ТЗ, которые встречаются почти в каждом споре. Держи шпаргалку. 📋

1. Несоответствие функциональным требованиям (30% случаев).
   Разработчик просто не доделал какую-то функцию: кнопка не работает, форма не отправляется, данные не сохраняются. Причина — нехватка времени или квалификации. Заказчик ожидал одно, получил другое. IT-экспертиза мобильных приложенийфиксирует это через воспроизведение сценариев из ТЗ.
2. Проблемы с производительностью (25% случаев).
   ТЗ требует «мгновенного отклика» или «времени запуска не более 3 секунд». Реальность — приложение тормозит, зависает, потребляет всю память. Мы замеряем метрики с помощью профайлеров (Android Profiler, Instruments для iOS) и сравниваем с ТЗ.
3. Несовместимость с устройствами / версиями ОС (15% случаев).
   В ТЗ сказано: «приложение должно работать на устройствах с Android 10 и выше, iPhone с iOS 14 и выше». Разработчик тестировал на двух флагманах, а на бюджетных телефонах приложение вылетает. Мы тестируем на парке из 10-20 устройств, включая старые модели. 📱
4. Ошибки безопасности (10% случаев).
   Требование «защита персональных данных» — это не просто слова. Мы проверяем, передаются ли пароли в открытом виде, можно ли перехватить трафик, есть ли проверка целостности. Если нет — фиксируем нарушение.
5. Невыполнение требований к бэкенду (20% случаев).
   Мобильное приложение — это обычно ещё и серверная часть. В ТЗ прописано: «сервер должен выдерживать нагрузку 1000 RPS (запросов в секунду)». В реальности при 50 RPS сервер падает. Мы проводим нагрузочное тестирование (JMeter, Locust) и доказываем нарушение. 🖥️

В каждом из этих случаев IT-экспертиза мобильных приложений даёт заказчику козырь в суде. А разработчику  — повод задуматься, стоит ли халтурить.

Глава 6: Кейс второй  — «Банковское приложение, которое не защищало деньги»

🏦 Вторая история  — уже из области финансов, где цена ошибки особенно высока. Заказчик  — небольшой региональный банк, решил заказать мобильное приложение для интернет-банкинга. Требования к безопасности были прописаны очень жёстко: двухфакторная аутентификация, шифрование данных на устройстве и при передаче, защита от манипуляций (root detection, jailbreak detection). Разработчик  — известная аутсорс-компания из Москвы. Сумма договора  — 18 миллионов рублей. Срок  — 9 месяцев. 💰

Приложение сдали. Но через два месяца после запуска в службу безопасности банка поступил сигнал: у троих клиентов списали деньги без их ведома. Всего  — около 3 миллионов рублей. Выяснилось, что злоумышленники использовали уязвимость в приложении: они подменили сертификат безопасности на своём телефоне (с root-доступом) и перехватывали SMS с кодами подтверждения. Банк заплатил клиентам компенсации, приложение заблокировал и подал иск к разработчику о взыскании убытков и возврате оплаты. 💸

Назначена IT-экспертиза мобильных приложений.

Наши действия:

🔸 Шаг 1. Анализ ТЗ. В ТЗ был отдельный раздел «Требования к безопасности» (20 страниц). Пункт 8.3.1: «Приложение должно детектировать рут-доступ на устройстве и блокировать выполнение критических операций (перевод средств, смена пароля)». Пункт 8.4.2: «Весь сетевой трафик должен шифроваться с использованием TLS 1.3 и certificate pinning (фиксация сертификата)». Пункт 8.7: «Ключи шифрования не должны храниться в коде или в явном виде в SharedPreferences».

🔸 Шаг 2. Анализ кода и бинарных файлов. Мы получили исходный код приложения (банк настоял на этом). Нашли:

Root detection был реализован через проверку наличия файла su в системе. Но злоумышленник мог подменить этот файл (Magisk Hide). Современный root detection должен использовать несколько методов (SafetyNet, проверка целостности). Здесь был только один примитивный метод. ❌

Certificate pinning не был реализован вообще. Приложение доверяло любому сертификату, подписанному системным хранилищем. Злоумышленник установил свой сертификат и спокойно перехватывал трафик.

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

🔸 Шаг 3. Эксперимент по взлому. Мы взяли рутированное устройство (Android с Magisk) и установили приложение. Попытались выполнить перевод средств. Приложение даже не проверило наличие root  — операция прошла успешно. Затем мы подменили сертификат через mitmproxy  — приложение не сопротивлялось. Мы перехватили запрос на перевод и изменили сумму в транзакции (с 1000 рублей на 100 000). Сервер почему-то принял изменённый запрос (там тоже не было проверки целостности). 🕵️

🔸 Шаг 4. Сравнение с требованиями ЦБ РФ. Мы запросили нормативные документы Банка России по безопасности мобильного банкинга. Они обязывают кредитные организации использовать certificate pinning и детектирование рута. Разработчик ссылался на то, что «в ТЗ не было фразы про Magisk», но суд не принял этот довод, потому что профессиональный разработчик должен знать регуляторные требования.

Вывод эксперта:

• Приложение не соответствует ТЗ по пунктам 8.3.1, 8.4.2, 8.7.
• Допущены грубые нарушения отраслевых стандартов безопасности, что привело к реальному ущербу.
• Убытки банка (компенсации клиентам) находятся в прямой причинно-следственной связи с дефектами приложения.
• Стоимость устранения уязвимостей оценивается в 4-5 млн рублей (почти переписать заново).

Итог суда: Суд в полном объёме удовлетворил иск банка: разработчик вернул 18 млн (полную стоимость договора) и выплатил 3 млн компенсации убытков. Кроме того, ЦБ РФ оштрафовал разработчика на 5 млн за нарушение требований безопасности. Компания-разработчик обанкротилась. 😱

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

Глава 7: Как мы выявляем несоблюдение ТЗ  — методология

Теперь  — немного о кухне. Расскажу, как именно мы проверяем соответствие приложения техническому заданию. Это будет полезно и заказчикам (чтобы понимать, на что обратить внимание), и разработчикам (чтобы не попадать впросак). 🧑‍💻

Шаг 1. Нормализация ТЗ. Мы не работаем с «сырым» ТЗ. Мы выделяем из него проверяемые требования. Например, фраза «приложение должно быть удобным»  — не проверяема. А «время реакции на нажатие кнопки не более 0,2 секунды»  — проверяемо. Если в ТЗ много субъективных формулировок, мы указываем в заключении: «данный пункт не может быть проверен объективными методами», и суд учитывает это. 🧹

Шаг 2. Разработка тест-плана. На основе проверяемых требований мы создаём набор тестов: позитивные (что должно работать) и негативные (при вводе некорректных данных). Тест-план утверждается судом (чтобы потом разработчик не кричал, что мы его «подставили»).

Шаг 3. Подготовка среды. Мы используем как реальные устройства (наша коллекция  — 30+ телефонов и планшетов), так и эмуляторы (для повторяемости). Фиксируем версию ОС, сборку приложения, хэш-суммы файлов. Всё, чтобы потом можно было воспроизвести.

Шаг 4. Выполнение тестов. Вручную или автоматизированно (Appium, Espresso для Android, XCTest для iOS). Каждый тест документируем: скриншоты, видеозапись экрана, логи (logcat, console). Если приложение падает  — записываем стек-трейс ошибки. 🔄

Шаг 5. Анализ результатов. Сравниваем фактическое поведение с ожидаемым по ТЗ. Фиксируем расхождения: «ожидалось А, получено Б». Классифицируем дефекты по степени критичности (критический  — приложение не выполняет основную функцию; серьёзный  — работает, но с ошибками; незначительный  — косметический).

Шаг 6. Статический анализ кода (если есть исходники). Ищем не только баги, но и несоответствие архитектурным требованиям (например, «приложение должно использовать паттерн MVVM», а используется всё в одном файле). Ищем скрытые функции (бэкдоры).

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

Вся эта процедура занимает от 2 до 8 недель. Но результат того стоит: суд получает железобетонное доказательство некачественной работы. IT-экспертиза мобильных приложений  — это не просто «мнение», это наука. 🔬

Глава 8: Кейс третий  — «Образовательная платформа, которая не отвечала нагрузкам»

🎓 Третья история  — из сферы EdTech. Компания «Умный дом» (название изменено) заказала разработку мобильной платформы для онлайн-курсов. Ожидалось, что приложение будет использоваться тысячами студентов одновременно. В ТЗ были прописаны требования к нагрузке: система должна выдерживать 5000 одновременных пользователей, время ответа сервера  — не более 1 секунды. Разработчик  — крупная студия с хорошим портфолио. Договор на 12 млн рублей. 💪

Приложение запустили. И в первый же день масштабного вебинара (2000 участников) сервер лёг. Пользователи не могли загрузить видео, чат зависал, тесты сохранялись через раз. Компания потеряла репутацию, часть клиентов ушла к конкурентам. Заказчик подал иск о расторжении договора и взыскании 12 млн + упущенной выгоды (ещё 5 млн). 📉

Назначена IT-экспертиза мобильных приложений.

Наши действия:

🔹 Шаг 1. Изучение ТЗ. В разделе «Требования к производительности» было чётко: «Серверная часть должна обрабатывать 5000 RPS (requests per second) для API-методов авторизации, просмотра видео, отправки тестов. Время ответа на 95% запросов не должно превышать 1 секунду». Также было требование к мобильному клиенту: «приложение должно кэшировать данные, использовать асинхронные запросы».

🔹 Шаг 2. Нагрузочное тестирование сервера (бэкенда). Мы развернули тестовый стенд, аналогичный продакшену (по согласованию с заказчиком). Использовали Apache JMeter с распределённой нагрузкой (10 серверов-агентов). Нагружали API разными методами:

• При 1000 RPS сервер ещё держался (ответ 0,8 сек).
• При 2000 RPS время ответа выросло до 5 секунд, 30% запросов упали с ошибкой 503.
• При 3000 RPS сервер полностью «лёг»  — перестал отвечать.

Причина: неоптимальные запросы к базе данных (отсутствие индексов, N+1 проблема). На бэкенде использовали фреймворк Django с ORM, который генерировал сотни мелких запросов. Разработчик не профилировал код перед сдачей. 🐢

🔹 Шаг 3. Анализ мобильного приложения. На клиенте тоже были проблемы:

Отсутствовало кэширование видеолекций. Каждый раз при открытии лекции приложение качало видео заново  — это создавало лишнюю нагрузку на сервер и тратило трафик пользователя.

Сетевые запросы выполнялись синхронно в UI-потоке. При плохом соединении приложение «зависало» на 5-10 секунд, пока запрос не упадёт по таймауту.

Нет пагинации (постраничной загрузки) списка курсов. Приложение пыталось загрузить все 500 курсов разом  — и падало с OutOfMemoryError на старых устройствах. 😵

🔹 Шаг 4. Анализ логов продакшен-системы (за день вебинара). Заказчик предоставил доступ к серверным логам. Мы увидели, что пиковая нагрузка составляла всего 1500 RPS (гораздо меньше заявленных 5000), но сервер всё равно упал. Значит, разработчик не только не выполнил ТЗ, но и ошибся в оценках на порядок.

Вывод эксперта:

• Бэкенд не соответствует ТЗ по нагрузочным характеристикам (вместо 5000 RPS едва выдерживает 1500).
• Мобильное приложение имеет критические дефекты производительности (отсутствие кэширования, синхронные запросы, отсутствие пагинации).
• Дефекты носят неустранимый характер без полной переработки архитектуры (стоимость переработки  — около 8 млн рублей).
• Упущенная выгода (потеря клиентов) находится в прямой причинно-следственной связи с дефектами.

Итог суда: Суд расторг договор, взыскал с разработчика 12 млн (полную стоимость) и 3 млн из заявленных 5 млн упущенной выгоды (суд посчитал, что расчёт заказчика был не идеальным, но частично обоснованным). Разработчик пытался обжаловать, но вышестоящие инстанции оставили решение в силе. ⚖️

Урок: IT-экспертиза мобильных приложений в этом кейсе показала, что нагрузочное тестирование  — это не опция, а обязательный этап для серьёзных проектов. Если вы разработчик  — тестируйте. Если заказчик  — закладывайте нагрузочные тесты в ТЗ и контролируйте их выполнение.

Глава 9: Ошибки ТЗ, которые мешают экспертизе

Покажу и обратную сторону медали. Иногда заказчик сам виноват, потому что ТЗ составлено из рук вон плохо. И тогда IT-экспертиза мобильных приложений не может подтвердить его претензии. Вот типичные ляпы. 🤦‍♂️

Ошибка 1. Размытые формулировки.
«Приложение должно быть интуитивно понятным», «интерфейс должен быть современным», «данные должны надёжно храниться». Что значит «интуитивно»? Эксперт не может это измерить. Судья тоже. Поэтому такие пункты не работают. Надо писать: «кнопка сохранения должна быть в правом верхнем углу» или «после нажатия «ОК» должно появляться уведомление».

Ошибка 2. Отсутствие приоритетов.
В ТЗ перечислены 200 функций, но непонятно, какие обязательны для первого релиза, а какие  — «бонус». Разработчик сделал часть, а заказчик требует всё. Экспертиза фиксирует, что 150 функций выполнено, 50  — нет, но суд может решить, что 150 достаточно, если нет приоритетов. Заказчик проигрывает. 📉

Ошибка 3. Непроверяемые метрики.
«Приложение должно работать быстро». Сколько это в миллисекундах? «Сервер должен выдерживать высокую нагрузку». Сколько это в RPS? Без цифр эксперт не может подтвердить нарушение.

Ошибка 4. Противоречия внутри ТЗ.
В одном месте сказано «авторизация через SMS», в другом  — «через email». Разработчик сделал через SMS, заказчик хочет через email. Экспертиза констатирует противоречие, но не может однозначно встать на чью-то сторону.

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

Что делать заказчику: нанимать технического писателя (или грамотного проджект-менеджера), который составит ТЗ так, чтобы каждое требование было проверяемым. Потратите 200-300 тыс. на ТЗ, сэкономите миллионы на судах. 💡

Глава 10: Инструментарий эксперта  — как мы проверяем соответствие ТЗ

Теперь  — техническая часть для гиков. Расскажу, каким софтом и железом мы пользуемся для IT-экспертизы мобильных приложений. Это наша «лаборатория». 🔧

Для статического анализа кода:

Android: Android Studio + Lint (встроенные проверки), PVS-Studio (ищет ошибки в Java/Kotlin), Qodana (ещё один статический анализатор).

iOS: Xcode Analyzer, SwiftLint, SonarQube (поддерживает Swift).

Кросс—платформенные (Flutter, React Native): специальные плагины (ESLint, Dart Code Metrics).

Для динамического анализа и воспроизведения багов:

Android: ADB (логкат, скриншоты, запись видео), Android Profiler (производительность), Logcat Reader.

iOS: idevicesyslog, Xcode Instruments (профилирование), Console.app.

Общее: Frida (перехват вызовов), Objection (пентест мобилок), MobSF (Mobile Security Framework).

Для нагрузочного тестирования:

Apache JMeter (де факто стандарт).

Locust (на Python, удобен для сложных сценариев).

K6 (современный, лёгкий).

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

Для анализа сети:

mitmproxy (перехват HTTPS, установка своего сертификата).

Wireshark (трафик низкого уровня).

Charles Proxy (удобный GUI).

Для восстановления данных и анализа файлов приложения:

SQLite Browser (базы данных на устройстве).

Android Backup Extractor (извлечение данных из бэкапов).

jailbreak / root (в исключительных случаях, с разрешения суда).

Важно понимать: мы не используем «секретные» инструменты. Всё это можно скачать и повторить. Прозрачность  — наша философия. Если адвокат спросит: «А почему вы не использовали утилиту X?»  — мы объясним. А если использовали  — покажем скриншоты, версии, хэши. 🤓

Глава 11: Процессуальные особенности  — как заключение эксперта становится доказательством

Мы подготовили заключение. Что дальше? А дальше оно начинает жить своей жизнью в суде. Расскажу о процессуальных нюансах, которые могут удивить неподготовленного. 📜

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

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

Продление сроков. Экспертиза редко укладывается в изначальные сроки. Мы пишем ходатайство о продлении, судья его удовлетворяет (обычно без проблем). Но затягивать не стоит  — иначе суд может вернуть дело без рассмотрения.

Допрос эксперта. В судебном заседании адвокаты задают нам вопросы. Они пытаются «посадить в лужу»: «А почему вы не проверили на планшете?», «А почему использовали эту версию Android, а не более новую?». Мы отвечаем спокойно, обоснованно. Наша подготовка и методика позволяют парировать любые атаки. 🗡️

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

Стоимость экспертизы. Несколько слов о деньгах (хотя обещал не писать про объём). IT-экспертиза мобильных приложений стоит недешево  — от 150 тысяч рублей за простой случай до 800 тысяч за сложный (с нагрузочным тестированием, без исходников). Но сравни это с ценой проигранного суда на десятки миллионов. Экспертиза  — это страховка. И она окупается. 💰

Глава 12: Роль переписки сторон и свидетельских показаний

Иногда ТЗ составлено плохо, но в переписке (мессенджеры, email) разработчик обещал «сделать красную кнопку», а сделал синюю. Или «добавить функцию экспорта в Excel», но забыл. Может ли переписка заменить ТЗ? Частично да. 🤝

Что учитывают суды (и мы):

Переписка в официальных каналах (корпоративная почта, тикеты в Jira/YouTrack) имеет высокую доказательственную силу.

Переписка в WhatsApp, Telegram  — ниже, но тоже учитывается, особенно если есть ссылки на конкретные пункты.

Устные обещания без свидетелей  — почти бесполезны.

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

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

Глава 13: Досудебное исследование vs Судебная экспертиза

Многие спрашивают: «А можно прийти к вам до суда, чтобы вы просто посмотрели приложение и сказали, есть ли нарушения?». Да, можно. Это называется досудебное исследование (или рецензия, аудит). Оно дешевле и быстрее, но имеет меньшую юридическую силу. 🧐

Что даёт досудебное исследование:

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

Что даёт судебная экспертиза:

• Официальный документ, который суд обязан принять как доказательство.
• Эксперт предупреждён об уголовной ответственности за ложное заключение.
• Можно задавать вопросы через суд, запрашивать дополнительные материалы.

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

Глава 14: Как выбрать эксперта и не ошибиться

Ты решил заказать экспертизу. Как не нарваться на шарлатана? Дай несколько советов. 👇

Совет 1. Проверьте аттестацию. Эксперт должен быть аттестован Минюстом России по специальности «Компьютерно-техническая экспертиза». Без аттестации его заключение не имеет силы судебного доказательства. Просите показать удостоверение.

Совет 2. Узнайте про опыт в мобильной разработке. Эксперт должен не просто «шарить» в программировании, но и реально разрабатывать мобильные приложения (или иметь в команде таких людей). Попросите портфолио похожих кейсов. 📱

Совет 3. Оцените лабораторную базу. У эксперта должен быть парк реальных устройств (разные модели, версии ОС), инструменты для нагрузочного тестирования, ПО для декомпиляции. Если он говорит «мы всё проверим на моём Samsung A50»  — бегите.

Совет 4. Прозрачность цен и сроков. Эксперт называет цену до начала работы, не поднимает её в процессе без уважительной причины. Заключение отдаёт в оговорённый срок (или просит продление официально). 💰

Совет 5. Отсутствие конфликта интересов. Эксперт и его организация не должны быть аффилированы ни с заказчиком, ни с разработчиком. Запросите декларацию о независимости.

Мы в Союзе «Федерация судебных экспертов» соответствуем всем этим критериям. Наши эксперты имеют стаж от 8 лет, аттестованы, регулярно повышают квалификацию. Мы работаем по всей России и выезжаем на объекты в день обращения. Связь с нами  — на сайте: https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/ 🌐

Глава 15: Эпилог  — почему правда всегда побеждает (если её искать)

Дорогой читатель, мы прошли долгий путь. От азов IT-экспертизы мобильных приложений до реальных кейсов, где разработчики теряли миллионы из-за своей халатности или жадности. Ты видел, как плохо составленное ТЗ может погубить иск, а хорошо  — привести к победе. Ты узнал о методах, инструментах, процессуальных тонкостях. 🧠

Но самое главное, что я хочу донести: IT-экспертиза мобильных приложений  — это не магия и не «отмазка для суда». Это серьёзная научная дисциплина, основанная на математике, логике, стандартах. И она способна восстановить справедливость в ситуациях, когда кажется, что «ничего не докажешь».

Если вы заказчик, пострадавший от недобросовестного разработчика,  — не отчаивайтесь. Собирайте документы, фиксируйте баги, обращайтесь к экспертам. Деньги можно вернуть, репутацию  — восстановить. 💪

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

С уважением,
Союз «Федерация судебных экспертов»
Ваша независимость  — наша профессия

🟩 Хотите заказать экспертизу или просто проконсультироваться? Заходите на сайт: https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/

Минутка юмора 🙂

Другие шутки