В спорах по сайтам, программам, приложениям, базам данных и другим ИТ-проектам заказчик и исполнитель часто смотрят на один и тот же результат совершенно по-разному.
Исполнитель говорит:
Работа выполнена, код написан, время потрачено, результат передан.
Заказчик отвечает:
Пользоваться этим невозможно, функции не работают, сроки сорваны, а теперь нужно нанимать другого разработчика.
И дальше начинается главный спор:
что реально сделано, можно ли этим пользоваться и сколько это стоит?
В строительном споре хотя бы можно увидеть стены, окна, отделку или недоделки. С ИТ-продуктами сложнее: часть результата видна на экране, часть находится в коде, часть — в базе данных, часть — в интеграциях, а часть вообще понятна только специалистам.
Поэтому в спорах по ИТ-разработке важно разбирать не только документы и акты, но и техническое состояние продукта, объем реально выполненных работ, наличие недостатков и практическую ценность результата.
Что вообще считается ИТ-продуктом
ИТ-продукт — это не только программа в узком смысле.
На практике спор может касаться:
- сайта;
- мобильного приложения;
- программы для компьютера;
- базы данных;
- личного кабинета;
- внутреннего сервиса компании;
- модуля для учета, продаж, логистики или аналитики;
- интеграции между разными системами;
- прав на программу, сайт или базу данных.
То есть спор может быть не только о том, «сделали программу или нет».
Он может быть о разных вещах:
1. Сколько стоит сам ИТ-продукт.
Например, если продаются права на программу, сайт или базу данных.
2. Сколько стоят выполненные работы.
Например, если договор расторгнут, но часть проекта уже сделана.
3. Сколько стоят качественно выполненные работы.
Если часть результата пригодна, а часть требует исправления.
4. Сколько стоит доработка.
Если после спора нужно привлекать другого исполнителя.
5. Сколько реально было потрачено.
Если нужно подтвердить расходы на разработку, внедрение или исправление ошибок.
Почему ИТ-споры такие сложные
Главная проблема ИТ-спора в том, что стороны часто говорят о разном.
Заказчик смотрит на продукт как пользователь:
работает или не работает, удобно или неудобно, можно использовать или нельзя.
Исполнитель смотрит как разработчик:
код написан, задачи закрыты, часы потрачены, этапы выполнены.
Юрист смотрит на договор:
что было в техническом задании, какие этапы согласованы, какие акты подписаны, какие замечания направлялись.
А эксперт должен собрать все это вместе и ответить на практические вопросы:
- что было заказано;
- что фактически сделано;
- какие функции работают;
- какие функции не работают;
- можно ли использовать продукт хотя бы частично;
- есть ли существенные недостатки;
- сколько стоит выполненная часть;
- сколько стоит исправление;
- есть ли у результата потребительская ценность.
Именно поэтому по таким делам часто нужны не только экономические знания, но и технический анализ самого продукта.
Передан результат — это еще не конец спора
В ИТ-проектах часто возникает ситуация: результат вроде бы передан, но стороны не согласны, что именно передано.
Например, исполнитель передал архив с кодом. Но код не собирается в рабочий продукт.
Или сайт открыт по ссылке, но ключевые функции не работают.
Или программа запускается, но только в тестовой среде исполнителя.
Или часть модулей есть, но они не связаны между собой и не решают задачу заказчика.
Поэтому сам факт передачи файлов, доступа или архива еще не всегда означает, что создан полноценный пригодный результат.
Нужно разбираться дальше:
что именно передано и можно ли этим пользоваться по назначению.
Что такое потребительская ценность ИТ-продукта
Потребительская ценность — это не «понравился дизайн» или «не понравился интерфейс».
Это вопрос о том, выполняет ли продукт ту задачу, ради которой он создавался.
Например:
- сайт открывается, но через него нельзя оформить заказ;
- приложение запускается, но не выполняет ключевую функцию;
- база данных создана, но данные неполные или неактуальные;
- личный кабинет есть, но не связан с основной системой;
- программа работает только у разработчика, но не разворачивается у заказчика;
- интеграция заявлена, но обмен данными фактически не происходит.
Формально результат может быть.
Но его практическая ценность может быть значительно ниже заявленной.
И наоборот: у продукта могут быть отдельные недостатки, но он все равно выполняет основную функцию. Тогда говорить, что он «ничего не стоит», тоже неправильно.
Поэтому в ИТ-спорах важно не бросаться в крайности, а разбирать:
что работает, что не работает и как это влияет на возможность использовать продукт.
Почему нельзя считать только по потраченным часам
В ИТ-разработке часто спорят о часах.
Исполнитель говорит:
Мы потратили 800 часов, значит, работа стоит столько-то.
Но количество часов само по себе еще не доказывает стоимость результата.
Важно понять:
- кто выполнял работу;
- какая была квалификация специалистов;
- были ли эти часы реально затрачены;
- на какие задачи они пришлись;
- соответствуют ли часы сложности задачи;
- не дублировалась ли работа;
- не исправлял ли исполнитель собственные ошибки;
- можно ли связать трудозатраты с фактически созданным результатом.
Большой объем часов может быть обоснованным, если проект сложный, есть интеграции, безопасность, нагрузка, нестандартная логика и серьезное тестирование.
Но часы могут быть и спорными, если они плохо подтверждены, не связаны с результатом или относятся к исправлению ошибок, которые возникли по вине самого исполнителя.
Поэтому правильный вопрос звучит не так:
сколько времени потрачено?
А так:
какой полезный результат создан за это время?
Техническое задание решает многое
Во многих ИТ-спорах проблема начинается еще до разработки.
Стороны заключают договор, но техническое задание написано слишком общо:
- «создать сайт»;
- «разработать программу»;
- «сделать личный кабинет»;
- «автоматизировать бизнес-процесс»;
- «обеспечить удобный интерфейс».
Потом выясняется, что заказчик и исполнитель понимали это по-разному.
Заказчик ожидал одну систему.
Исполнитель сделал другую.
А в договоре конкретики не хватает.
Для экспертизы это серьезная проблема. Если непонятно, что именно должно было быть сделано, сложно определить, что выполнено качественно, что не выполнено, а что вообще не входило в задачу.
Для ИТ-проектов особенно важны:
- техническое задание;
- описание модулей;
- перечень функций;
- требования к интеграциям;
- требования к данным;
- требования к нагрузке;
- требования к безопасности;
- этапы работ;
- критерии приемки;
- порядок тестирования.
Чем точнее это описано, тем меньше пространства для спора.
Код сам по себе еще не всегда ценность
В ИТ-спорах часто звучит аргумент:
Код написан, значит, работа выполнена.
Но это не всегда так.
Код может быть:
- неработоспособным;
- плохо структурированным;
- не собирающимся в рабочий продукт;
- написанным без документации;
- зависимым от устаревших библиотек;
- частично заимствованным;
- созданным на основе готовых модулей;
- написанным с помощью ИИ;
- непригодным для дальнейшей поддержки.
Проще говоря:
много строк кода — не значит много пользы.
Иногда короткое и аккуратное решение ценнее, чем огромный массив кода, который невозможно нормально поддерживать.
Поэтому при оценке ИТ-работ важно смотреть не только на объем кода, но и на его качество, работоспособность, возможность сборки, документацию и связь с нужными функциями.
Готовые модули и ИИ тоже имеют значение
Сегодня разработка редко делается полностью с нуля.
Исполнитель может использовать:
- готовые библиотеки;
- открытые решения;
- фреймворки;
- типовые модули;
- шаблоны;
- сторонние сервисы;
- код, написанный с помощью ИИ.
Само по себе это нормально. Более того, часто это разумно: быстрее, дешевле и надежнее, чем писать все заново.
Но в споре важно понимать, что именно сделал исполнитель, а что было взято как готовое решение.
Если готовый модуль выдается за полностью самостоятельную разработку, стоимость работ может быть завышена.
Но и обратная крайность неправильна. Использование готового решения не означает, что работа ничего не стоит. Его нужно подобрать, адаптировать, интегрировать, протестировать и встроить в систему заказчика.
То же самое с ИИ-кодом.
ИИ может помочь разработчику, но это не отменяет проверки результата. Важно не то, кто написал фрагмент кода — человек или нейросеть. Важно, работает ли он, соответствует ли задаче и можно ли его поддерживать.
Что делать, если работа выполнена частично
Это одна из самых частых ситуаций.
Проект не завершен, договор расторгнут, стороны разошлись, но часть работ уже сделана.
Тогда возникает вопрос:
сколько стоит то, что фактически выполнено?
Здесь нельзя просто сказать:
готово на 60 процентов.
Или:
сделано почти все.
Нужно понять:
- какие модули завершены;
- какие функции работают;
- какие функции не работают;
- можно ли использовать готовые части отдельно;
- можно ли передать проект другому разработчику;
- сколько стоит доработка;
- какая часть цены договора относится к выполненным работам;
- не придется ли фактически все переделывать заново.
Иногда «почти готовый» продукт имеет высокую ценность.
А иногда 80 процентов кода не дают пользователю ничего полезного, потому что ключевая функция не работает.
Поэтому процент готовности в ИТ-проектах нужно связывать не только с объемом работы, но и с функциональной пригодностью результата.
Когда нужна рыночная стоимость
Не всегда в споре нужно определять именно рыночную стоимость.
Иногда вопрос стоит иначе: сколько стоят фактически выполненные работы по условиям договора. Тогда расчет может опираться на цену этапов, модулей или часа работы, согласованную сторонами.
Но рыночная стоимость может быть важна, если:
- продаются права на ИТ-продукт;
- оспаривается сделка по передаче прав;
- спорят об объективности цены договора;
- нужно определить стоимость завершения работ другим исполнителем;
- нужно понять стоимость устранения недостатков;
- нужно оценить сам сайт, программу, базу данных или иной ИТ-актив.
В таких случаях вопрос уже шире, чем просто «сколько часов потрачено».
Нужно смотреть, сколько аналогичные работы или решения могут стоить на рынке с учетом сложности, качества, состава функций, технологического уровня и возможности использования.
Какие подходы используют при оценке
Если упростить, есть три основных подхода.
Затратный подход.
Смотрят, сколько нужно потратить, чтобы создать такой продукт или заменить его аналогичным. В ИТ это часто важный подход, особенно если продукт уникальный и нормальных рыночных аналогов нет.
Сравнительный подход.
Смотрят, сколько стоят похожие продукты или работы. Но в ИТ это непросто: два внешне похожих сайта или приложения могут сильно отличаться по функционалу, архитектуре, качеству кода, интеграциям и нагрузке.
Доходный подход.
Смотрят, какой доход приносит ИТ-продукт. Но его не всегда можно применить, потому что часто сложно выделить денежный поток именно от конкретной программы, сайта, модуля или базы данных.
Поэтому в ИТ-спорах выбор подхода зависит от того, что именно нужно оценить: права на продукт, выполненные работы, доработку, устранение недостатков или ущерб.
Что особенно часто спорят в суде
На практике самые болезненные вопросы такие:
1. Работает ли продукт?
Не в презентации и не на словах, а в реальной среде.
2. Соответствует ли продукт договору и техническому заданию?
Если техническое задание слабое, спор становится сложнее.
3. Можно ли использовать продукт частично?
Иногда часть системы полезна, иногда нет.
4. Какие недостатки существенные?
Не всякая ошибка делает продукт непригодным. Но некоторые ошибки убивают сам смысл разработки.
5. Сколько стоит исправление?
Иногда дешевле доработать. Иногда проще создать заново.
6. Сколько реально выполнено?
Важно не только количество часов, но и полезный результат.
7. Что создано исполнителем, а что взято из готовых решений?
Это влияет на трудозатраты и стоимость.
8. Не устарел ли продукт еще до завершения спора?
В ИТ технологии меняются быстро, и моральное устаревание может быть существенным фактором.
Почему нужен не только экономист, но и ИТ-специалист
Экономический эксперт может оценивать стоимость, затраты, рыночность, структуру цены и расчет.
Но он не всегда может сам ответить на технические вопросы:
- работает ли код;
- можно ли собрать программу;
- есть ли критические ошибки;
- соответствует ли архитектура задаче;
- насколько сложны модули;
- есть ли заимствованный код;
- можно ли использовать продукт по назначению.
Для этого нужен специалист в сфере ИТ.
Поэтому в сложных делах часто правильнее проводить комплексный анализ: технический и экономический.
Сначала нужно понять, что фактически создано и работает ли результат. Потом — считать стоимость выполненного, стоимость доработки или стоимость самого продукта.
Иначе экономический расчет может оказаться красивым, но оторванным от технической реальности.
Что проверить заказчику до спора
Если возник конфликт по ИТ-проекту, заказчику не стоит ограничиваться фразой:
нам не нравится, оно не работает.
Лучше собрать конкретику:
- договор и все приложения;
- техническое задание;
- переписку по требованиям;
- акты и замечания;
- список функций, которые должны были быть;
- список функций, которые фактически работают;
- ошибки и скриншоты;
- доступы к тестовой или рабочей версии;
- историю задач в трекере;
- сведения о переданном коде;
- оценку стоимости доработки другим исполнителем.
Чем конкретнее зафиксированы недостатки, тем сильнее позиция.
Что проверить исполнителю
Исполнителю тоже важно не надеяться только на акт или переписку.
Лучше заранее подготовить:
- подтверждение выполненных этапов;
- описание созданных модулей;
- перечень работающих функций;
- историю задач;
- учет времени;
- сведения о команде и квалификации;
- описание использованных технологий;
- документы по тестированию;
- инструкции по установке и эксплуатации;
- доказательства передачи результата.
Главная задача исполнителя — показать, что результат не просто «где-то есть», а соответствует согласованной задаче и имеет практическую ценность.
Где почитать подробнее
Для профессионального разбора этой темы можно посмотреть методические рекомендации Ассоциации СРОО «Экспертный совет» «Методические рекомендации по определению стоимости и иных стоимостных показателей в отношении ИТ-продуктов».
В документе рассматриваются права на ИТ-продукты, выполненные и невыполненные работы, устранение недостатков, связь экономической и компьютерно-технической экспертизы, подходы к оценке, трудозатраты, функциональные точки, заимствованный код, ИИ-код и другие практические вопросы.
Главный вывод
В споре по сайту, программе, приложению, базе данных или другой ИТ-системе важно не просто спросить:
сколько часов потрачено?
И не только:
передан ли результат?
Главные вопросы другие:
что реально создано, можно ли этим пользоваться, какие функции работают, какие недостатки есть и сколько стоит привести продукт в нормальное состояние.
ИТ-продукт может выглядеть готовым, но не иметь практической ценности.
А может иметь недостатки, но все равно быть полезным и частично подлежащим оплате.
Поэтому нормальный спор по ИТ-разработке должен строиться не на эмоциях, а на связке:
техническое состояние → потребительская ценность → объем выполненных работ → стоимость → взаиморасчеты сторон.
