
📌 Введение: почему ТЗ — это «конституция» IT-проекта, но даже она не спасает от споров
Техническое задание (ТЗ) — основной документ, фиксирующий требования заказчика к разрабатываемому программному обеспечению. Однако на практике:
- ТЗ меняется в процессе разработки (устно, по электронной почте, в мессенджерах).
- Подрядчик сдаёт акты приёмки, а через несколько месяцев выявляются скрытые дефекты.
- Сопровождение осуществляется без чётких KPI (ключевых показателей эффективности) и SLA (соглашений об уровне обслуживания).
Независимая экспертиза соответствия работ по разработке и сопровождению ПО техническому заданию — это объективный инструмент, который помогает заказчику доказать недобросовестность подрядчика, а подрядчику — защититься от необоснованных претензий. 🎯
⚖️ Глава 1. Можно ли доказать невыполнение ТЗ, если требования менялись устно
Вопрос: Как экспертиза может помочь доказать невыполнение техзадания, если в процессе разработки его условия менялись или были устные дополнения?
✅ Развернутый ответ: Экспертиза способна восстановить «реальную волю сторон», даже если изменения не были зафиксированы в дополнительных соглашениях. Для этого используются:
- Электронная переписка (email, мессенджеры) — если заказчик в письме просил «добавить кнопку экспорта в Excel», а подрядчик ответил «сделаем», это считается согласованным изменением ТЗ (ст. 434 ГК РФ — письменная форма договора может быть соблюдена и в электронном виде). 📧
- Системы управления задачами (Jira, Trello, Redmine) — если в задаче указано, что её исполнитель (разработчик) должен реализовать функцию X, а в акте приёмки она отсутствует — это доказательство.
- Протоколы совещаний — если в них зафиксировано изменение требований (даже без подписи, но с указанием участников).
Что эксперт устанавливает:
- Какие требования были согласованы (пусть и устно, но подтверждены другими доказательствами).
- Какие из этих требований не выполнены.
- Можно ли квалифицировать невыполнение как существенное нарушение (ст. 723 ГК РФ).
Кейс №1 из практики: Заказчик в переписке просил добавить фильтр по датам. Разработчик ответил «ок». При сдаче фильтра не было. Эксперт нашёл переписку и сделал вывод, что разработчик должен был реализовать фильтр. Суд обязал разработчика дописать функцию бесплатно. 💪
📋 Глава 2. Какие данные и артефакты наиболее важны для экспертизы
Вопрос: Какие технические данные или артефакты (например, фрагменты кода, логи ошибок, скриншоты интерфейса) наиболее важны для экспертной оценки соответствия разработанного ПО техническому заданию?
✅ Развернутый ответ: Эксперт использует комплекс артефактов. Вот таблица с приоритетами:
| Артефакт | Что даёт эксперту | Приоритет |
| Техническое задание (ТЗ) и все приложения | Эталон требований | 🔴 Критический |
| Исходный код (репозиторий Git) | Проверка наличия/отсутствия функций, качество реализации | 🟠 Очень важный |
| Логи ошибок (error.log, stacktrace) | Доказательство, что функция работает с ошибками (не соответствует ТЗ) | 🟡 Важный |
| Скриншоты и видео работы интерфейса | Фиксация визуальных несоответствий | 🟡 Важный |
| Акты приёмочного тестирования | Что было принято заказчиком на момент подписания | 🟠 Очень важный |
| Баг-трекер (Jira, Mantis) | Список дефектов, зафиксированных после приёмки | 🟡 Важный |
Что эксперт ищет:
- Функция есть в ТЗ, но отсутствует в коде (или есть заглушка).
- Функция реализована, но с ошибками, которые видны по логам (500 ошибка, NullPointerException).
- Интерфейс не соответствует макетам (скриншоты).
Кейс №2 из практики: В ТЗ было требование: «отчёт формируется не более 2 секунд». Эксперт проанализировал логи и обнаружил, что отчёт выполняется 90 секунд. Суд признал это несоответствием. Без логов (метрик времени) доказать было бы невозможно. 📊
🔧 Глава 3. Оценка качества сопровождения без KPI и SLA
Вопрос: Насколько результативно можно оценить качество сопровождения программного продукта через экспертизу, если в договоре не были четко прописаны KPI или SLA?
✅ Развернутый ответ: Даже без формальных метрик эксперт может оценить качество сопровождения, основываясь на:
- Среднерыночных стандартах (ITIL — библиотека лучших практик управления IT-услугами, ISO 20000).
- Действиях подрядчика (насколько быстро он реагировал на заявки, устранял ошибки, документировал изменения).
Что анализирует эксперт:
| Критерий | Как проверяется | Признак некачественного сопровождения |
| Время реакции на критический инцидент | Сравнение даты и времени создания тикета (заявки) и первого ответа | Неделя вместо нескольких часов |
| Полнота устранения ошибок | Анализ повторных заявок по той же проблеме | Ошибка «всплывает» снова после закрытия |
| Документирование изменений | Наличие changelog (журнала изменений), обновление документации | Изменения вносятся, но никто не знает, какие |
| Время восстановления после сбоя | Анализ даунтайма (простоя) системы | Был ли восстановлен сервис в разумный срок |
Кейс №3 из практики: Подрядчик обязался «оперативно устранять ошибки». Эксперт выявил, что критическая ошибка (не работал платёжный шлюз) устранялась 3 недели. Суд признал это ненадлежащим качеством сопровождения. 💪
💰 Глава 4. Стоимость экспертизы и сроки
Вопрос: Сколько стоит экспертиза разработанного ПО на соответствие техническому заданию и какие факторы влияют на сроки её проведения?
✅ Развернутый ответ: Стоимость и сроки зависят от:
| Фактор | Влияние |
| Объём кода (тысячи строк — KLOC) | 10 KLOC — дешевле; 1000 KLOC — значительно дороже |
| Сложность архитектуры (микросервисы vs монолит) | Микросервисы требуют больше времени на анализ |
| Наличие документации и ТЗ | Если ТЗ нет — эксперт тратит время на реконструкцию требований |
| Срочность | Надбавка 30–50% |
Ориентировочная стоимость (2025 г.):
| Тип работ | Стоимость (₽) | Сроки (раб. дни) |
| Базовый анализ соответствия (ТЗ есть, код до 50 000 строк) | от 80 000 до 150 000 | 10–14 |
| Полная экспертиза (ТЗ расплывчато, большой объём кода) | от 150 000 до 300 000 | 15–25 |
| Экспресс-режим (срочно для суда) | надбавка 30–50% | 5–7 |
📑 Глава 5. Какие документы нужны для экспертизы
Вопрос: Какие документы нужны для проведения независимой экспертизы ПО на соответствие ТЗ, если я хочу оспорить качество разработки или потребовать доработки?
✅ Развернутый ответ: Минимальный пакет:
| № | Документ | Зачем |
| 1 | Техническое задание (ТЗ) и все дополнения | Эталон требований |
| 2 | Договор на разработку и акты сдачи-приёмки | Какие этапы оплачены |
| 3 | Доступ к ПО (тестовый стенд, исходный код) | Для функционального тестирования |
| 4 | Логи ошибок, скриншоты, видео | Доказательство неработающих функций |
| 5 | Переписка сторон (email, мессенджеры) | Подтверждение согласования изменений |
Если вы хотите потребовать доработки, эксперт должен установить, что недостатки являются существенными (ст. 723 ГК РФ). А это значит, что без них система не пригодна для использования.
⏳ Глава 6. Экспертиза постфактум (после подписания актов)
Вопрос: Если разработанное ПО было сдано и принято, может ли независимая экспертиза постфактум доказать его несоответствие техническому заданию, если проблемы обнаружились позднее?
✅ Развернутый ответ: Да, может. Подписание акта приёмки не лишает заказчика права ссылаться на скрытые недостатки (ст. 723 ГК РФ), которые невозможно было обнаружить при обычной приёмке.
Пример: Система работала 3 месяца, а потом стали проявляться ошибки (утечка памяти, падение при нагрузке). Эксперт анализирует логи, код и устанавливает, что дефект существовал с момента передачи ПО.
Срок исковой давности: по общему правилу 3 года (ст. 196 ГК РФ). Если недостаток скрытый — отсчёт с момента, когда заказчик узнал о нём.
Кейс №4 из практики: CRM-система была принята. Через 2 месяца начались потери данных. Эксперт установил, что баг в коде (SQL-запрос без транзакции) был с самого начала. Суд обязал разработчика исправить бесплатно. 💪
⚖️ Глава 7. Использование заключения экспертизы в суде
Вопрос: Как заключение независимой экспертизы ПО на соответствие ТЗ может быть использовано в суде или арбитражном процессе для взыскания убытков или расторжения договора с недобросовестным подрядчиком?
✅ Развернутый ответ: Заключение — это письменное доказательство (ст. 71 ГПК РФ, ст. 64 АПК РФ). Оно используется для:
- Взыскания убытков (ст. 15, 393 ГК РФ) — если из-за сбоев ПО компания потеряла выручку.
- Соразмерного уменьшения цены (ст. 723 ГК РФ) — вернуть часть оплаты за неработающие функции.
- Расторжения договора (ст. 723 ГК РФ) — если недостатки неустранимы или подрядчик отказывается их исправлять.
Важно: заключение должно быть выполнено аттестованным экспертом с предупреждением об уголовной ответственности по ст. 307 УК РФ (для судебной экспертизы).
Кейс №5 из практики: Заказчик взыскал 2 млн рублей убытков, потому что эксперт доказал: из-за ошибок в интеграции интернет-магазин простаивал 7 дней (чёрная пятница). Упущенная выгода была рассчитана на основе аналитики прошлых продаж. 💪
🧠 Глава 8. Предпроектная экспертиза (до начала разработки)
Вопрос: Можно ли заказать экспертизу проекта ПО или прототипа на соответствие техническому заданию еще до начала основной разработки, чтобы минимизировать риски и избежать дорогостоящих переделок?
✅ Развернутый ответ: Да, это называется экспертиза проекта / архитектуры до старта разработки. Она позволяет:
- Проверить ТЗ на полноту, непротиворечивость и реалистичность.
- Оценить выбранный технологический стек (насколько он подходит для поставленных задач).
- Выявить рискованные требования (например, «система должна выдерживать 10 000 RPS» — эксперт проверит, выдержит ли).
Результат: Заключение о том, что проект «жизнеспособен» или содержит критичные ошибки, которые приведут к переделкам.
Кейс №6 из практики: Заказчик показал ТЗ на разработку мобильного приложения. Эксперт указал, что требование к офлайн-режиму противоречит выбранной базе данных (Firebase). Заказчик скорректировал ТЗ до начала разработки, сэкономив 1 млн рублей. 💰
🎯 Заключение
Независимая экспертиза соответствия работ по разработке и сопровождению ПО техническому заданию — это ключевой инструмент:
- для доказательства невыполнения обязательств подрядчиком;
- для взыскания убытков и расторжения договора;
- для превентивной проверки ТЗ до начала разработки.
Для заказа экспертизы ПО обращайтесь в Союз «Федерация судебных экспертов» (сайт: https://bugex.ru/).




Задавайте любые вопросы