🚨 Введение: когда подрядчик не выполнил обязательства 💼
- Ситуация, когда заказчик вложил средства в разработку программного продукта, а подрядчик сдал работу, которая явно не соответствует ожиданиям (или не сдал вовсе), к сожалению, не редкость. Спор переходит в плоскость: «Сколько процентов работы реально выполнено? Что именно не сделано? И во сколько обойдётся исправление ошибок и доработка?».
- Ответить на эти вопросы без независимой экспертизы практически невозможно. Судья не является специалистом в программировании, а разработчик может утверждать, что «программа готова на 95%», хотя по факту — только на 30%. Независимая экспертиза программного обеспечения — единственный способ получить объективную, научно обоснованную оценку и защитить свои интересы.
- Ниже представлен подробный разбор того, как экспертиза определяет процент готовности, выявляет недоработки и рассчитывает стоимость их устранения.
Раздел 1. Что проверяет эксперт при оценке готовности ПО 📋
Эксперт не просто «смотрит на код»; он проводит многоуровневый анализ.
1.1. Анализ технического задания (ТЗ) и проектной документации
| Документ | Что оценивается |
| Техническое задание (ТЗ) | Перечень всех требований (функциональных и нефункциональных), их приоритет (must have – обязательно, nice to have – желательно, но не критично). |
| Договор | Сроки, этапы (вехи, milestones), стоимость этапов. |
| Акты сдачи-приёмки (промежуточные). | Какие этапы были приняты заказчиком без замечаний (это может повлиять на оценку). |
Если ТЗ составлено плохо (размытые формулировки), эксперт даёт заключение с оговорками и использует «обычно предъявляемые требования» (ст. 721 ГК РФ).
1.2. Анализ исходного кода и архитектуры
| Что проверяется | Инструмент / Метод |
| Наличие реализованных функций (сравнение с ТЗ). | Эксперт вручную проверяет код, либо использует автоматическое тестирование (например, Postman для API, Selenium для UI). |
| Качество кода (читаемость, модульность, комментарии). | Статический анализ (SonarQube, PHPStan). |
| Наличие тестов (unit-тесты, интеграционные тесты). | Покрытие кода (coverage). |
| Соответствие архитектурным решениям (MVP, MVC, Clean Architecture). | Ручной ревью (одобрение эксперта). |
1.3. Тестирование работоспособности
Эксперт устанавливает ПО (на тестовый стенд) и проверяет:
- Запускается ли программа.
- Работают ли основные функции (создание документа, регистрация пользователя, импорт данных).
- Нет ли критических ошибок (краш, потеря данных).
1.4. Анализ документации (пользовательской, технической)
- Есть ли руководство пользователя (User Manual).
- Описаны ли API (Application Programming Interface – интерфейс программирования приложений) endpoints.
- Есть ли инструкция по развёртыванию (Deployment Guide).
Отсутствие документации может быть расценено как недоработка, если ТЗ это предусматривало.
Раздел 2. Как рассчитывается реальный процент готовности 📊
2.1. Метод «функциональных точек» (Function Points)
Это классический метод, используемый в программной инженерии. Каждой функции (требованию) присваивается «вес» (weight) на основе сложности.
| Тип функции | Вес | Пример |
| Внешний ввод (пользователь заполняет форму). | 4 | Регистрация пользователя. |
| Внешний вывод (формирование отчёта). | 5 | Отчёт о продажах за месяц. |
| Запрос (чтение). | 3 | Просмотр списка заказов. |
| Справочник (таблица). | 7 | Справочник контрагентов (с возможностью редактирования). |
Расчёт: % готовности = (Сумма весов реализованных функций / Сумма весов всех функций по ТЗ) × 100.
Кейс № 1.
- ТЗ содержит 10 функций с суммарным весом 100.
- Эксперт выявил, что реализованы функции с суммарным весом 60.
- Итог: готовность 60%.
Недостаток метода: не учитывает качество реализации (функция может быть реализована с ошибками). Эксперт может применять понижающие коэффициенты (например, если функция работает, но с ошибками, её вес умножается на 0,5).
2.2. Метод «экспертных оценок» (если ТЗ нечисловое)
Если ТЗ составлено неструктурированно, эксперт (или несколько экспертов) дают свою оценку готовности, а затем усредняют.
Кейс № 2. Три эксперта оценили готовность в 45%, 50% и 55%: (45+50+55)/3 = 50%.
2.3. Учёт выполненных этапов (milestones)
Если в договоре прописаны этапы (например, Проектирование → Разработка → Тестирование → Внедрение), эксперт проверяет, какие этапы завершены.
- Если не завершён этап «Тестирование», то «Разработка» может быть выполнена на 100%, а общая готовность продукта к использованию – только 60% (нет гарантии, что оно работает).
Кейс № 3. Подрядчик утверждает, что разработка готова на 100%. Эксперт выявил, что нет ни одного unit-теста, а нагрузочное тестирование не проводилось. Снизил общую готовность до 70%.
Раздел 3. Выявление объёма недоработок 📝
3.1. Классификация недоработок
| Тип недоработки | Пример | Влияние на готовность |
| Полностью отсутствует функция (not implemented). | Кнопка «Оплатить» не ведёт к платежному шлюзу. | Значительное снижение. |
| Функция реализована с ошибкой (багом). | Калькулятор НДС считает неверно: 120 руб. вместо 118 руб. | Снижение пропорционально критичности. |
| Функция работает, но медленно (производительность). | Отчёт грузится 5 минут (в ТЗ было 5 секунд). | Частичное снижение. |
| Нарушена безопасность (уязвимость). | SQL-инъекция, позволяющая украсть базу данных. | Снижение (может быть приравнено к критической ошибке). |
3.2. Документирование недоработок
Эксперт составляет таблицу (приложение к заключению):
| № | Пункт ТЗ | Статус | Комментарий |
| 2.1 | Регистрация пользователя (email, пароль) | Реализовано с ошибкой | Пароль хранится в открытом виде (не хэшируется). |
| 3.2 | Экспорт отчёта в Excel | Отсутствует | Не реализовано. |
| 4.5 | Время ответа API < 200 мс | Не соответствует | Фактически 1500 мс (под нагрузкой). |
Раздел 4. Расчёт стоимости устранения недоработок 💰
4.1. Методика
Стоимость устранения = Сумма по каждой недоработке (Трудозатраты_i × Ставка разработчика в час) + Дополнительные расходы (лицензии, тестирование).
Трудозатраты (человеко-часы) эксперт оценивает на основе:
- Собственного опыта (сколько времени потребовалось бы на исправление).
- Сравнения с аналогичными задачами (бенчмаркинг – сопоставление с отраслевыми стандартами).
Ставка разработчика в час: берётся из рыночных данных (например, для PHP-разработчика – 2000-4000 руб./час, для системного архитектора – 5000-7000 руб./час). Эксперт может использовать среднюю ставку по региону или ту, которую заказчик реально платит другому подрядчику.
4.2. Пример расчёта
| Недоработка | Трудозатраты (часы) | Ставка (руб./час) | Стоимость (руб.) |
| Исправить хэширование паролей. | 8 | 3000 | 24 000 |
| Реализовать экспорт в Excel. | 16 | 3000 | 48 000 |
| Оптимизировать SQL-запрос (добавить индексы). | 4 | 4000 (DBA) | 16 000 |
| Итого: | 88 000 |
4.3. Учёт дополнительных расходов
| Статья | Пример |
| Покупка лицензий (если подрядчик использовал trial-версию библиотеки, которая истекает). | 10 000 руб. |
| Затраты на тестирование. | 30% от стоимости разработки. |
| Затраты на повторное развёртывание (деплой). | 20 000 руб. |
Кейс № 4. Эксперт оценил стоимость исправления недоработок в 1,2 млн руб. (с учётом интеграционного тестирования).
Раздел 5. Практические примеры (кейсы) 📂
Кейс № 5. Интернет-магазин: готовность 30% вместо 95%
Ситуация: Подрядчик утверждал, что интернет-магазин готов на 95%. Заказчик обнаружил, что корзина не работает, оплата не проходит.
Действия эксперта: Эксперт проанализировал ТЗ (150 требований). Оказалось:
- 50 требований выполнены (33%).
- 70 требований выполнены с ошибками (47%).
- 30 требований не выполнены (20%).
С учётом критичности (корзина — must have) готовность оценена в 42%.
Результат: Суд уменьшил цену договора пропорционально (с 2 млн руб. до 840 000 руб.). Экспертиза (110 000 руб.) окупилась.
Кейс № 6. Мобильное приложение: отсутствие документации
Ситуация: По договору подрядчик должен был передать руководство пользователя (User Manual) и описание API. Не передал.
Действия эксперта: Эксперт констатировал, что документация отсутствует (акт приёма-передачи не подписан). Стоимость разработки документации оценена в 300 000 руб. (на основе трудозатрат технического писателя).
Результат: Суд обязал подрядчика либо дописать документацию, либо вернуть 300 000 руб.
Кейс № 7. Система учёта: критическая ошибка потеря данных
Ситуация: В системе учёта товаров при проведении документа «Списание» терялась информация о поставщике.
Действия эксперта: Воспроизвёл ошибку 10 раз. Признал её Критической (Critical), хотя подрядчик утверждал, что это «мелкий баг».
Результат: Суд обязал подрядчика исправить ошибку за свой счёт, а также выплатить компенсацию за убытки (некорректный учёт привёл к закупке лишних товаров на 500 000 руб.).
Раздел 6. Необходимые документы для экспертизы 📄
| № | Документ | Зачем |
| 1 | Договор на разработку ПО (с приложениями). | Определить объём обязательств. |
| 2 | Техническое задание (ТЗ). | Сравнить реализацию с требованиями. |
| 3 | Акты сдачи-приёмки (промежуточные). | Зафиксировать, что было принято ранее. |
| 4 | Исходный код (архив, ссылка на Git). | Основной объект исследования. |
| 5 | Исполняемые файлы (дистрибутив). | Для тестирования. |
| 6 | Переписка сторон (по изменениям ТЗ). | Если ТЗ менялось в процессе. |
Заключение 🎯
Независимая экспертиза ПО позволяет:
- ✅ Объективно оценить процент готовности (методом функциональных точек или экспертных оценок), отделяя реально работающий код от «мертвых» функций.
- ✅ Выявить все недоработки (отсутствие функций, ошибки, низкую производительность, уязвимости) и классифицировать по критичности.
- ✅ Рассчитать стоимость устранения (трудозатраты × ставка + дополнительные расходы).
Экспертное заключение является весомым доказательством в суде (ст. 55 ГПК РФ, ст. 64 АПК РФ) и основанием для претензии к подрядчику (ст. 723 ГК РФ).
Если вы столкнулись с недобросовестным подрядчиком, не тратьте время на бесполезные переговоры — закажите независимую экспертизу.
Для получения консультации, предварительной оценки стоимости и заказа экспертизы ПО обращайтесь на официальный сайт:
Задавайте любые вопросы