Почему попытка доказать, что «с айтишниками можно судиться», провалилась

Одна такая история приобрела известность после того, как 2 октября на заседании Республиканского клуба директоров директор ЗАО «Гомельлифт» Валерий Корниенко заявил, что «95% IT-компаний в Беларуси — мошенники» и он ищет управу на одну из них в суде. Оказалось, что судиться с айтишниками — дело непростое. Зато весьма поучительное.

Каша заварилась еще в 2017 году, когда «Гомельлифт» заказал у ООО «Элитсофт» комплекс работ по вводу в эксплуатацию, внедрению и тестированию ПО «1С:Предприятие 8». В процессе эксплуатации ПО обнаружились проблемы. Эксперт, нанятый заказчиком, пришел к выводу, что работы выполнены всего на 30%, пользоваться этим ПО невозможно. Поскольку исполнитель с таким мнением не согласился, ЗАО обратилось в суд.

Решение Верховного суда — настоящий бестселлер. Ответчик не выполнил работы по всем этапам календарного плана, за исключением обучения, утверждали представители истца. Но они признали подписание актов сдачи-приемки работ «без проверки выполненных работ — на доверии». Представители ответчика уверяли, что все сделано надлежащим образом и в срок. Уже после суда директор «Элитсофта» жаловался, что работы затягивались по вине заказчика, который потом еще и не заплатил за выработанные часы по договору техсопровождения.

Проблема в том, что качество автоматизации управления и бухучета затруднительно подогнать под «требования, обычно предъявляемым к работам соответствующего рода». А доказать отступления от договора, ухудшившие результат, или иные недостатки, делающие его непригодным для использования, чтобы получить дарованное п. 2 п. 1 ст. 676 ГК право требовать соразмерного уменьшения оплаты, можно лишь в том случае, если в нюансы работы ПО вникнет суд.

Но для суда существуют лишь нормы главы 37 Гражданского кодекса и очевидные задокументированные факты. Вот подписанные сторонами договор, вот спецификация ПО, календарный план-график выполнения работ и концептуальный проект, требованиям которого должны соответствовать объем и качество выполненных работ. Есть протоколы заседания комиссии, товаросопроводительные документы и акты сдачи приемки по этапам «полностью и в срок», также подписанные сторонами без всяких претензий. Все дополнения к ПО, не вошедшие в утвержденные концептуальные проекты, заказчик согласился оформлять отдельными протоколами и выполнять в ходе опытной эксплуатации. По сути, это значит, что целый ряд функций повисает в воздухе. А если работы приняты без проверки, то это, согласно ГК, вообще лишает заказчика права предъявлять претензии.

К тому же через год после принятия работ ЗАО заключило с заказчиком договор по техническому сопровождению части ПО, находящейся в опытной эксплуатации. По мнению суда, это тоже свидетельствует о том, что работы выполнены и приняты. Впрочем, с тем же успехом может говорить о том, что ПО не работает без постоянного устранения текущих косяков и «вбивания» вручную операций, не содержащихся в лицензионной версии программы. Неудивительно, что, пытаясь судиться, заказчик запутался в том, что функционирует, а что — нет. 

Об отсутствии конкретики проекта можно догадаться из фразы в решении суда: по проекту техническое задание не составлялось, поскольку «заказчик, на момент заключения договора не смог определить полный объем задач».

А потому стороны договорились, что «объем и качество работ должны соответствовать концептуальному проекту, который вместе с уставом проекта комплексной автоматизации и календарным планом были подготовлены с участием представителей сторон и «надлежащим образом» утверждены заказчиком.

Это — ключевой момент конфликта.

Публика напрасно хихикала по поводу упомянутых в интервью директора «Гомельлифт» старых советских стандартов. ГОСТы 34.602-89 и 19.201-78, конечно, устарели. Но при правильной интерпретации на их основе получаются вполне приличные техзадания на создание автоматизированных систем. Любители модерна могли бы принять к сведению IEEE STD 830-1998 IEEE 1233-1998, IEEE 1362-1998, еще более современный ISO/IEC/ IEEE 29148-2011, рекомендации Вигерса и т. д. Можно даже и без ТЗ обойтись — если, скажем, разработчик исповедует подходы Agile и неукоснительно претворяет в каждом проекте принципы его манифеста: Working software over comprehensive documentation — работающее ПО превыше всеобъемлющей документации. Иными словами, если вы качественно работаете, нет нужды прятаться за пачку бумажек.

Заказчик никогда не знает всех возможностей ПО, которое намерен приобрести. Он может даже слабо представлять, какие расчеты, отчеты и показатели, ему нужны, какие данные и по какому графику должны передаваться между подразделениями. Для того и существуют бизнес-аналитики. Они вместе с представителями заказчика составляют функциональное описание необходимых задач, делают на его основе ТЗ, которое утверждается заказчиком и воплощается в жизнь. В данном случае проблемы были неизбежны с того момента, когда «Гомельлифт» согласился обойтись без техзадания. Между прочим, на обследование бизнес-процессов и подготовку плана отводилось 50 рабочих дней, которые обошлось заказчику в 12,3 тыс. рублей. Полюбопытствовал ли суд, что сделано за это время и деньги?

К примеру, вы хотите, чтобы в доме был лифт. Надо ясно знать, какой груз и на сколько этажей он повезет, двери должны открываться-закрываться вовремя, кабина — ехать, куда надо и т. п. Если лифт без работников изготовителя регулярно застревает где попало, никакие акты сдачи-приемки не избавят подрядчика от обязанности исправлять свои косяки. Жильцов дома интересуют не реле, кабеля и тросы лифта, а возможность без приключений доехать до нужного этажа. Но если речь идет об управленческом ПО, все совершенно иначе. Заказчика тоже интересуют не коды и изящество алгоритмов, а их способность обрабатывать и представлять информацию. Сначала вам никак не удается справиться с кнопками, затем приходится платить за доработку функций — необходимых, но не учтенных заранее, потом — регулярно оплачивать техподдержку и настройку любых изменений. Все это делает автоматизацию очень долгой и весьма дорогостоящей. Это весьма приятным образом сказывается на выручке и зарплате айтишников (а заодно на кое-каких макроэкономических показателях). Но финансовые результаты и производительность труда в реальном секторе явно не улучшатся. Но ехать-то людям в лифте, а не на алгоритме.

В нашей истории реальная работоспособность ПО суд вообще не интересовала. Настолько, что он отказался вызывать эксперта, признал его выводы предположительными, а заключение — необоснованным, не содержащим «самостоятельно проведенные исследования в области программирования». Зато суд благосклонно принял заверения ответчика о том, что часть замечаний эксперта устранена, а остальное — всего лишь дополнительные пожелания заказчика, не относящиеся к договорному объему работ. Который, замечу, без ТЗ — тоже категория предположительная.

Итак, попытка доказать, что «с айтишниками можно судиться», провалилась. Кому-то с юридической точки зрения решение кажется правильным. Но не странно ли, что для правосудия куча сдуру подписанных актов гораздо важнее фактического результата работ? Ведь заказчик-то остался с не работающим в полном объеме ПО. Которое ему милостиво предлагают доделать — за отдельную плату.

Конечно, В. Корниенко погорячился, огульно обвиняя чуть ли не всех айтишников-внедренцев в обмане клиентов. Ведь никто не пытается привлекать их по ст. 209 УК за мошенничество. Хотя бы потому, что затруднительно доказать намерение обманом завладеть деньгами клиента — авторитетные юристы подтвердят. Но кого-нибудь затерзают смутные сомнения: как это опытные айтишники берутся за проект, по которому даже техзадание невозможно составить?

Интересно, каким был бы вердикт суда, если бы истцом оказалось госпредприятие, а проект финансировался из бюджета? Такие вопросы неизбежно возникнут, когда под флагом «цифровой пятилетки» начнется повальная цифровая трансформация, в том числе в госсекторе. Ведь сформулировать в деталях свои пожелания смогут единицы. А для остальных бесценным будет урок «Гомельлифта». Будущие заказчики теперь знают: не надо обольщаться волшебной силой информационных технологий. Все, что для вас делает и, тем более, не делает разработчик, надо вписать в рамки главы 37 ГК. Каждая ее статья может сработать против заказчика, если он окажется слишком доверчивым и зашоренным. Или защитить — если позаботиться об этом заранее. А потому составлять договоры и техзадания, а также принимать результаты каждого этапа и проекта лучше с помощью опытных независимых консультантов. Тоже недешево, но окупится. Не надо подписывать акты без оговорок, если есть малейшие сомнения. Мы платим не за отработанные часы и устные обещания, а за результат, которого ожидаем.

Несоблюдение этих правил повышает риск потратить зря время, деньги, нервы и остаться с расчетами в Excel «на коленке». А потом можете пенять на самих себя и тихо ненавидеть привилегированное сословие айтишников, разговорчики об IT-стране и светлом цифровом будущем...