🚨 Введение: актуальность независимой экспертизы при спорах о качестве ПО
- В современной практике разработки программного обеспечения конфликты между заказчиком и исполнителем возникают в значительной части проектов. Согласно статистическим данным, до 60% споров связаны с несоответствием разработанного продукта техническому заданию (ТЗ), срывами сроков и скрытыми дефектами, проявляющимися после приемки. Суд, не обладая специальными познаниями в области программирования, не может самостоятельно оценить, является ли выявленная ошибка критическим недостатком или незначительным недочетом. Именно здесь возникает необходимость в независимой экспертизе соответствия ПО техническому заданию.
- Настоящая статья содержит систематизированные ответы на наиболее частые вопросы, возникающие при заказе экспертизы соответствия разработанного и сопровождаемого ПО техническому заданию. Материал подготовлен в научно-юридическом стиле и предназначен для заказчиков разработки, юристов, адвокатов и IT-специалистов.
Раздел 1. Учет изменений ТЗ и устных дополнений при экспертизе
Как экспертиза может помочь доказать невыполнение техзадания, если в процессе разработки его условия менялись или были устные дополнения?
В практике IT-проектов редко встречается ситуация, когда техническое задание остается неизменным на протяжении всего цикла разработки. Появляются новые требования, корректируются приоритеты, возникают технические ограничения. Однако далеко не все изменения фиксируются в письменных дополнительных соглашениях. Экспертиза позволяет восстановить реальную волю сторон и установить, какие требования фактически были согласованы.
Методы, используемые экспертом для учета изменений требований:
| Метод | Описание | Доказательственная ценность |
| Анализ электронной переписки | Изучение писем и сообщений в мессенджерах (Telegram, WhatsApp, Slack) на предмет обсуждения новых функций, изменения приоритетов и признания дефектов. | Высокая (при условии, что можно подтвердить подлинность переписки – нотариальное заверение, выгрузка из корпоративных систем). |
| Изучение систем контроля версий (Git) | Коммиты, сообщения коммитов и комментарии в pull requestах могут содержать указания на изменения требований. | Очень высокая (Git фиксирует автора, дату и точные изменения в коде). |
| Анализ задач в системах управления проектами (Jira, Trello, YouTrack) | Карточки задач, их статусы, комментарии и назначения позволяют восстановить хронологию появления требований. | Высокая (при наличии доступа к системе или выгрузки в формате CSV/Excel). |
| Сопоставление с первоначальным ТЗ | Эксперт сравнивает фактическую реализацию с тем, что было изначально заказано. Если реализация отличается в пользу заказчика (дополнительный функционал), это свидетельствует о согласовании изменений. | Средняя (может быть оспорено утверждением «разработчик сделал сам, без согласования»). |
Ограничения при отсутствии письменных доказательств:
Если устные дополнения никак не зафиксированы (не было ни переписки, ни задач, ни коммитов), эксперт руководствуется первоначальным ТЗ. В заключении он указывает: «Доказательств изменения требований не обнаружено, оценка производится по исходному техническому заданию».
Кейс № 1. Восстановление изменений требований по переписке в Telegram.
Ситуация: Заказчик устно попросил добавить интеграцию с CRM «Амо». Разработчик реализовал. При приемке заказчик отказался оплачивать, заявив, что «в ТЗ интеграции не было».
Действия эксперта: Эксперт выгрузил переписку из Telegram (заверенную нотариусом). Обнаружил сообщение от заказчика: «Срочно нужна синхронизация с Амо, запускайте» и ответ разработчика: «Сделано, проверьте в версии 2.4.1».
Результат: Суд признал требование согласованным, разработчик получил оплату. Экспертиза (40 000 руб.) окупилась.
Кейс № 2. Устное дополнение не подтверждено – суд встал на сторону разработчика.
Ситуация: Заказчик утверждал, что в устной форме просил добавить функцию «массовая рассылка email». Разработчик отрицал, в ТЗ ее не было. Эксперт не нашел никаких письменных подтверждений (переписка, задачи в Jira, коммиты).
Результат: Суд отказал в иске, экспертиза (35 000 руб.) оплачена заказчиком.
Раздел 2. Ключевые артефакты для экспертной оценки соответствия ТЗ
Какие технические данные или артефакты наиболее важны для экспертной оценки соответствия разработанного ПО техническому заданию?
Чем больше исходных материалов предоставит заказчик, тем точнее и обоснованнее будет заключение эксперта. Ниже представлен перечень артефактов с указанием их значимости.
2.1. Обязательные документы (без них экспертиза невозможна)
| № | Артефакт | Значение |
| 1 | Техническое задание (ТЗ) | Содержит перечень требований (функциональных и нефункциональных), критерии приемки, описание интерфейсов. |
| 2 | Договор на разработку ПО (с приложениями, спецификациями, календарным планом). | Определяет объем обязательств, сроки, стоимость этапов. |
| 3 | Акты сдачи-приемки (промежуточные и финальный). | Фиксируют, что принималось ранее; позволяют разграничить недостатки, возникшие до и после приемки. |
2.2. Высокозначимые артефакты (желательны)
| № | Артефакт | Значение |
| 4 | Исходный код (архив или ссылка на Git-репозиторий). | Позволяет оценить качество кода, наличие тестов, соответствие архитектурным требованиям. |
| 5 | Исполняемые файлы (дистрибутив). | Для функционального тестирования. |
| 6 | Пользовательская документация (руководство пользователя, руководство администратора). | Наличие/отсутствие инструкций, соответствие фактическому интерфейсу. |
| 7 | Логи ошибок (application logs, error logs) за период, когда проблемы проявлялись. | Доказательство наличия сбоев. |
| 8 | Скриншоты и видеозаписи (с датой и временем). | Наглядное подтверждение несоответствия интерфейса или некорректной работы. |
2.3. Вспомогательные (повышают полноту анализа)
| № | Артефакт | Значение |
| 9 | Переписка сторон (e-mail, мессенджеры). | Подтверждение изменений требований, признание дефектов, обещания исправить. |
| 10 | Данные из систем управления задачами (Jira, Trello, YouTrack). | Связь функционала с задачами, назначенными разработчикам. |
| 11 | Схемы баз данных (ER-диаграмма). | Соответствие структуры БД требованиям ТЗ. |
Раздел 3. Оценка качества сопровождения без KPI и SLA
Насколько результативно можно оценить качество сопровождения программного продукта через экспертизу, если в договоре не были четко прописаны KPI или SLA?
Отсутствие формальных KPI (ключевых показателей эффективности) и SLA (соглашения об уровне обслуживания) не делает экспертизу невозможной. Эксперт опирается на:
- Отраслевые стандарты и лучшие практики (ITIL, ГОСТ Р ИСО/МЭК 20000-1-2013).
- Обычно предъявляемые требования (ст. 721 ГК РФ).
- Фактические показатели, извлеченные из системы учета заявок (Service Desk).
Критерии, используемые экспертом:
| Критерий | Ожидаемое значение (норма) | Источник |
| Время реакции на критическую ошибку | Не более 2-4 часов | ITIL |
| Время решения критической ошибки (восстановление, workaround). | Не более 24-48 часов | ITIL |
| Доля решенных с первой попытки (FCR – First Call Resolution). | >70% | ITIL |
| Количество повторных открытий заявок (reopen rate). | <10% | ITIL |
| Наличие базы знаний (Knowledge base). | Должна быть | ГОСТ Р ИСО/МЭК 20000 |
Кейс № 3. Сопровождение признано некачественным, хотя SLA не было.
Ситуация: Заказчик жаловался на долгое решение проблем (критическая ошибка не исправлялась 3 недели). Подрядчик ссылался на отсутствие SLA.
Действия эксперта: Эксперт проанализировал заявки в Jira (время реакции – в среднем 10 дней, время решения – 30 дней). Сопоставил с рекомендациями ITIL. Вывод: сопровождение не соответствует обычно предъявляемым требованиям.
Результат: Суд снизил стоимость сопровождения на 30% за период ненадлежащего качества. Экспертиза (55 000 руб.) окупилась.
Раздел 4. Стоимость и сроки экспертизы соответствия ТЗ
Сколько стоит экспертиза разработанного ПО на соответствие техническому заданию и какие факторы влияют на сроки её проведения?
Стоимость и сроки рассчитываются индивидуально. Основные факторы представлены в таблице.
| Фактор | Влияние | Пример |
| Объем кода (тысячи строк, KLOC). | 10-50 KLOC – база 80 000 – 150 000 руб. | 100 KLOC – 180 000 – 300 000 руб. |
| Количество требований в ТЗ | 100 требований – база; 500 требований – коэфф. 1,5-2,0. | — |
| Сложность ПО (интеграции, многопоточность, микросервисы). | Коэфф. 1,3-1,8. | — |
| Наличие и полнота документации | Полная документация – коэфф. 0,9; отсутствие – коэфф. 1,4. | — |
| Необходимость нагрузочного тестирования | +30-50% | — |
| Срочность (экспресс-экспертиза). | Коэфф. 1,5-2,5. | — |
Ориентировочные цены и сроки:
| Тип проекта | Стоимость (руб.) | Срок (раб. дни) |
| Небольшой (сайт-визитка, лендинг, телеграм-бот) | 40 000 – 70 000 | 5-7 |
| Средний (интернет-магазин, CRM (стандартная), до 50 KLOC) | 80 000 – 150 000 | 7-12 |
| Крупный (ERP-система, >100 KLOC, интеграции) | 150 000 – 350 000 | 12-20 |
Раздел 5. Документы для оспаривания качества разработки
Какие документы нужны для проведения независимой экспертизы ПО на соответствие ТЗ, если я хочу оспорить качество разработки или потребовать доработки?
Полный перечень документов приведен в Разделе 2. Дополнительно рекомендуется:
- Журнал заявок в службу поддержки (если сопровождение осуществлялось тем же подрядчиком).
- Претензионные письма (доказывают, что заказчик своевременно сообщал о недостатках).
- Технические требования к аппаратному обеспечению, если причиной сбоев является несоответствие сервера системным требованиям (спор о том, чья это вина – разработчика или заказчика). Эксперт проверяет, были ли эти требования переданы заказчику.
Кейс № 4. Отсутствие ТЗ – экспертиза невозможна.
Ситуация: Заказчик подал иск о некачественной разработке, но ТЗ было составлено в виде маркетингового буклета («мы хотим CRM, похожую на Salesforce»).
Действия эксперта: Эксперт указал, что ТЗ не содержит конкретных критериев приемки, функциональных требований и нефункциональных требований. Заключение: «Установить соответствие / несоответствие не представляется возможным».
Результат: В иске отказано. Экспертиза (80 000 руб.) оплачена заказчиком бесполезно. Вывод: ТЗ должно быть четким и детальным.
Раздел 6. Постфактум экспертиза после подписания акта приемки
Если разработанное ПО было сдано и принято, может ли независимая экспертиза постфактум доказать его несоответствие техническому заданию, если проблемы обнаружились позднее?
Да, может. Наличие подписанного акта не лишает заказчика права на предъявление требований о скрытых дефектах (ст. 724 ГК РФ). Скрытые дефекты – это недостатки, которые не могли быть обнаружены при обычной приемке (например, низкая производительность под нагрузкой, уязвимости безопасности, утечки памяти).
Какие дефекты считаются скрытыми и могут быть оспорены постфактум:
- 🔹 Проблемы с производительностью (отчёт формируется 2 минуты вместо 5 секунд при большом объеме данных).
- 🔹 Утечка памяти (после 10 часов работы сервер вылетает).
- 🔹 Уязвимости безопасности (SQL-инъекция, XSS).
- 🔹 Несоответствие масштабируемости (система падает при 50 пользователях, хотя ТЗ обещало 1000).
- 🔹 Нарушение лицензионной чистоты (использование GPL-библиотек в коммерческом продукте).
Кейс № 5. Постфактум выявлена уязвимость SQL-инъекция (через 6 месяцев).
Ситуация: Интернет-магазин был взломан, украдена база данных клиентов. Выяснилось, что разработчик не использовал подготовленные выражения (prepared statements), что является прямым нарушением стандартов безопасности.
Действия эксперта: Эксперт проанализировал исходный код, выявил уязвимость. Заключение: недостаток скрытый, не мог быть обнаружен при приемке.
Результат: Суд взыскал убытки с разработчика (компенсация клиентам, штрафы Роскомнадзора). Экспертиза (120 000 руб.) включена в издержки.
Заключение
Независимая экспертиза соответствия ПО техническому заданию является эффективным инструментом защиты прав заказчика. Она позволяет:
- ✅ Доказать невыполнение обязательств подрядчиком (даже если ТЗ менялось – через анализ переписки, Git-коммитов, задач в Jira).
- ✅ Оценить качество сопровождения (даже при отсутствии формальных KPI и SLA, на основе отраслевых стандартов ITIL).
- ✅ Получить объективное заключение для суда (ст. 55 ГПК РФ, ст. 64 АПК РФ) и основание для взыскания убытков или расторжения договора (ст. 723 ГК РФ).
Для получения консультации, предварительной оценки стоимости и заказа экспертизы ПО обращайтесь на официальный сайт:
👉 https://fse.ms/ 👈
Задавайте любые вопросы